I've been a decision maker on $100M+ of engineering hardware/software/services spend per quarter and here's my perspective on this problem:
1. If you are making developer tools, make sure current/existing developers find it super useful and are strong advocates for your tool.
2. Make sure you don't tick any of the 'veto' boxes – there are a few – opaque contracts, lockins, data security/privacy challenges, sso/auth integration challenges etc.
3. Make sure your pricing makes sense – if it scales linearly with some variable it is likely not going to make sense in some finance spreadsheet. A simple per developer per month fee makes a ton of sense. A site-wide floating seat license makes even more sense. For some, a lumpsum fee for site wide unlimited license makes even more sense. On the last option, you can still charge for your consumables – cloud compute/storage charges you incur – just pass it on as-is. Even better if you can deploy to customer's cloud account directly (that solves for all data privacy/security issues as well).
4. Provide sufficient cost controls – put an upper limit on billing, put an upper limit on usage. don't let anyone turn on any knob that can result in expensive usage charges etc. Also provide sufficient usage reporting facilities.
5. If you do a good job, you can sign multiyear contracts with committed spend. Make sure your service is reliable and you do a quarterly check-in with your large account customers to understand if they are happy or have specific unmet needs.
6. Remember, you can provide and charge for whiteglove professional services (dedicated butts in seat engineers, support etc). This is highly lucrative and also sometimes critical to win and keep certain types of customers. Sometimes your product is controversial inside the customer's company and there maybe detractors who will make your product fail. By having professional services do the initial integration/implementation job you can ensure your product reaches its intended users without much meddling from the IT gatekeepers.
7. Don't bother trying to sell something that a customer strongly believes they can build in-house (even if they are wrong). Even if you win initially, you will lose eventually.
#7 Is usually not so black and white. This is most difficult when the buying product is already in-house and you are looking to replace it or add new functionality.
The problem I have with #7 is the ROI on build vs buy. And, at what point do you determine this?
First, buying a product with very high integration cost is still "building". So I need developer time for integration, time that they could spend on something else or the product itself.
Hopefully this would come out during a POC integration, but then we still need developer time to execute.
1. If you are making developer tools, make sure current/existing developers find it super useful and are strong advocates for your tool.
2. Make sure you don't tick any of the 'veto' boxes – there are a few – opaque contracts, lockins, data security/privacy challenges, sso/auth integration challenges etc.
3. Make sure your pricing makes sense – if it scales linearly with some variable it is likely not going to make sense in some finance spreadsheet. A simple per developer per month fee makes a ton of sense. A site-wide floating seat license makes even more sense. For some, a lumpsum fee for site wide unlimited license makes even more sense. On the last option, you can still charge for your consumables – cloud compute/storage charges you incur – just pass it on as-is. Even better if you can deploy to customer's cloud account directly (that solves for all data privacy/security issues as well).
4. Provide sufficient cost controls – put an upper limit on billing, put an upper limit on usage. don't let anyone turn on any knob that can result in expensive usage charges etc. Also provide sufficient usage reporting facilities.
5. If you do a good job, you can sign multiyear contracts with committed spend. Make sure your service is reliable and you do a quarterly check-in with your large account customers to understand if they are happy or have specific unmet needs.
6. Remember, you can provide and charge for whiteglove professional services (dedicated butts in seat engineers, support etc). This is highly lucrative and also sometimes critical to win and keep certain types of customers. Sometimes your product is controversial inside the customer's company and there maybe detractors who will make your product fail. By having professional services do the initial integration/implementation job you can ensure your product reaches its intended users without much meddling from the IT gatekeepers.
7. Don't bother trying to sell something that a customer strongly believes they can build in-house (even if they are wrong). Even if you win initially, you will lose eventually.