September 6, 2018
3 DevRel Approaches to Product, Support, and Security
In this post, learn how folks in our community leverage developer relations to have a major impact on their companies.
If you’re running a developer tools business, then it’s almost certain you’re familiar with one of the most common sales problems: running a Proof of Concept (PoC) with a prospect who can’t make a purchase. PoCs can be a powerful sales tool, especially for early-stage companies, but they can also waste a lot of your time. In this article, we’ll outline common issues with enterprise PoCs, how to solve them, and what you can do to ensure that your PoC is successful.
It begins innocently enough: someone wants to try our product, or (even better) starts using our product through a self-service model. Typically, the person who makes first contact is at a ‘practitioner’ level within their organization. They’re the one whose pain your product is solving, or in other words they stand to gain the most from using your product.
This is encouraging as you want to reach your target audience and showcase the awesome product you’ve built, but it isn’t always 100% innocuous. We as humans tend to hear what we want and get lost in educating, training, and collecting feedback from people who aren’t able to make purchasing decisions.
By definition, an ‘enterprise’ or ‘complex sale’, requires more than one person’s approval in order to transact. Testing product-market fit at the user-level has its time and place, but revenue is your goal so you must engage budget-holding ‘economic buyers’ as early as possible for several reasons. An economic buyer, put simply, is someone who has the power to align company budget $ to pay for your solution. Often they are the final signor on the contract and the most senior person you’ll speak to within the prospect’s management chain.
So how do we get time with economic buyers if our primary contact is on the user or ‘practitioner level’?
The answer is: by asking early and with good reason as to why you need to meet with the economic buyer. It can be uncomfortable for people to overtly ask for someone to involve their boss or senior manager early in the sales cycle, but there are several reasons this is necessary that will help you justify the request. My three favorites are below:
If you have limited resources and a schedule of projects to maintain, now it seems less daunting to ask your user-level contact serious questions like “who else needs to approve this solution?, when can we speak with them to ensure this aligns with management-level goals, are you willing to introduce us / sponsor a meeting with the economic buyer?”
If the user-level contact refuses to connect you to the economic buyer (or says that they’re in control of the decision making process), you have a few options depending on how far into the sales cycle you are. If you haven’t yet started a PoC, you could create an ‘up-front contract’ which states you will proceed with aligning your resources to the PoC and in exchange you want to meet with the economic buyer during the PoC.
Often, user-level contacts will state they are in charge of the decision making process. One way you can get to the economic buyer is by getting the user to acknowledge the difference between technical decision making and purchasing processes. You can ask the user-level contact tough questions you need answers to like:
If they don’t know the answer to any of those questions, use that as your bargaining chip to get the meeting with the economic buyer. “If we’re not able to map out how Prospect Company will purchase Our Software if we’re successful, we need to include Economic Buyer to come up with a plan.”
Lastly, if the user-level contact is still not helping you drive the sales cycle forward and gatekeeping you to stay on their level, offer to stop or push pause on the process.
It’s extraordinarily psychologically powerful to ‘take the deal off the table.’ “It doesn’t seem like we’re able to map out how Prospect Company will purchase Our Software if the PoC is successful. Unfortunately, I can’t commit my resources unless we see a path to purchase if we’re successful. Should we stop here?”
You’re busy. You’re successful. Your product delivers copious value to the organizations you choose to sell it to. You’re sending the message that you don’t need this prospect’s business and they’ll either thank you for making it easy for them to say no, or they will give you what you’ve been asking for: the meeting with the economic buyer.
Once you’re in front of the economic buyer, it’s time to ask questions like, “Has this effort been formally projectized / budgeted?, what is the ideal time you’d like to have a solution in place, and what are the steps that outline how your company purchases software?”
Once you’ve got the information you need to start a PoC, the next step is to agree on success criteria that will be used to decide whether or not your product can solve their challenge.
Write down what problem you’re solving for them, the business requirements behind the problem, and ultimately the business value that will be derived from implementing a solution to their problem. “What happens if you don’t do anything about this challenge?” is a great way to get a straight answer on business value.
Next, write down the technical success criteria that align back to the business value. Most often, these are your product features the prospect will derive the most value from, but they need to tell you what those are, and what business value it ties back to.
Finally, it’s a good idea to have a timeline section that states each stage of the POC, who is involved in that stage, and when that stage is to be completed. A sample timeline below:
|PoC kickoff/access provisioning||Our Company + Prospect Company||8/12/20||Completed|
|PoC review meeting||User-level Contact, Executive Buyer + Our Company||8/30/20||Scheduled|
If you’ve ever purchased something for your own organization (and had to have other people’s approval to do so) the content of the PoC document will be seemingly familiar: it’s an outline of an internal business justification for purchase (or in other words, to allocate budget).
Documenting the PoC with the prospect in this way will help them to re-articulate the work you’ve done together and why they should pay for it when they need to go back and ask for money to buy your product.
If you haven’t spoken with the economic buyer before starting the PoC, you have an opportunity to build in a meeting with them during or at the end of the POC. This is a strong way to get introduced to the right level of leadership, but you should strive to get introduced to economic buyers pre-PoC as much as possible.
Keep in mind that the PoC is just a single thread in the tapestry of this deal. Referring back to our definition of a complex sale, all the big deals have multiple approvers / decision makers involved in the purchase cycle. Ideally, you will work to identify the key people who will be involved in the purchase and repeat the same play above to get their alignment. The decision making process can become streamlined and budget buckets opened when you make it easy for your customer to agree on the value you’re delivering and easy for them to share with other people they need to convince internally.