- Nick Beecroft
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.
Who’s My Buyer? Where Enterprise PoCs Get Stuck
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.
Finding Your Path to the Economic Buyer
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:
- You’re an agile startup, with a small team and limited resources. Your time is extremely valuable and must be spent on high-priority projects (high-priority both for you and for your prospect).
- You must align your company’s resources with the prospect company’s resources at the right time to help them test your solution. You’ll need advanced notice to schedule this work properly.
- You’re asking for the prospect company’s time and resources too. You both need to ensure this is something they’re supposed to be working on and that the work is justified.
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?”
Troubleshooting the Introduction Process
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:
- What are the economic-buyer’s goals from this project?
- What has been budgeted for this project and whose budget does this come from?
- What is the full purchasing process within your organization (i.e. from PoC to Purchase Order)?
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.”
Know When It’s Time to Pump the Brakes
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?”
Scoping the Enterprise PoC
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.
1. Define the Problem and the Impact of Solving it
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.
2. Identify Success Criteria
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.
3. Agree on a Timeline
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).
Leveraging the PoC to Move the Deal Forward
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.