Rules for running a sales "proof of concept"
Your early prospective customers may ask for a "POC" - is it a good idea?
Imagine this scenario: you’re an early stage founder or sales leader. Every time a customer validates the need for your product, it feels like the best thing you’ve ever heard. Every customer you talk to that isn’t as excited about what you’re building feels like a crushing blow.
In this imaginary scenario, you’ve identified an early prospective customer, and managed to engage them in an evaluation of your product. This alone feels like a huge victory. Fast forward a bit and you’ve now run an endless series of discovery calls with decision makers. Your product impressed the people it needed to impress. You shared pricing and it seems to align with the buyer’s budget. Then, out of nowhere, you hear that dreaded question:
“Would it be ok if we ran a proof of concept first?”
As frustrating as it can be, it’s a fact of life: before your early customers feel comfortable buying, they may ask you for a proof of concept (we will also refer to this as a “POC” for short.) This doesn’t mean you have to grant it, but they will certainly ask.
It’s very easy (and may even feel natural) to excitedly agree to whatever your early customers ask for in order to sell your early key deals. Giving away a proof of concept too easily is one of the most time consuming (and thus, resource and money consuming) mistakes you can make as an early founder or sales leader.
First, what is a proof of concept, aka, “POC?”
It’s basically a trial of your product where a decision maker wants to confirm a certain checklist of items before they purchase.
Let’s start with the wrong way to run a proof of concept- the wrong way is simply saying “sure!” and deploying the product for your decision maker with maybe a quick walkthrough and demo, with a promise in place to reconnect in a month once the trial period ends.
This is not a good idea because, 9 time out of 10, your prospect will just forget about you, you’ll have wasted a month, and be in the same place you started. You need to make sure a prospect is dead serious about buying before you even think about granting a proof of concept.
A proof of concept must be extremely intentional in order to yield fruit. A proof of concept is a privilege for your customer (free usage of the product and a ton of time without any commitment to purchase) so before you, as a seller, agree to that proof of concept, you must establish some key ground rules. Let’s explore what those ground rules look like.
Proof of concept ground rules
First, you should view a proof of concept as a huge give on your end, and it’s your job (as a seller) to make sure that the customer views it the same way. Your team will be spending time, energy, and resources on giving this customer free access to the product and making sure they’re successful
The rules of POCs
First, your customer should understand that you only do POCs for customers who are [far] more likely to buy than not. The purpose of a proof of concept should be, very specifically
(a) the customer refuses to buy the product without trying the product first, and has a valid reason for needing to validate the way the product works
(b) the customer agrees that they expect to buy at the conclusion of the POC if all their success criteria are met. I can’t emphasize this point enough. Just like “coffee is for closers,” POCs are for legitimate, expected buyers, not people who are still on the fence.
Rule #1: You need to get full decision maker buy in BEFORE starting a POC.
You should never grant a POC to a champion without them having full decision maker buy in. Before giving a potential customer the “keys to the kingdom” you need some assurance that you’re working with the person who can sign the contract, or at the very least, this person is committing that the decision maker is ready to move forward if the POC is successful.
Rule #2: Never do a POC to prove ROI - only to prove functionality
Sometimes, decision makers will want to prove impact in a proof of concept. Meaning, I want to PROVE that our team was more productive with your product, that your product drove a meaningful amount of new leads compared to the old way, etc.
You should never allow ROI to become part of your POC success criteria. First of all, a few weeks isn’t nearly enough time to predictably prove anything, so that means you’re just taking a massive coinflip risk on something that is unlikely to work out the way you want.
Secondly, a POC involves time ramping onto the product, oftentimes WITHOUT a customer success manager’s help. So you’re just shooting yourself in the foot if you think a POC will be an accurate representation of what a real rollout would look like.
On the other hand, if your prospect simply wants to confirm the product is easy to use, that a few people on the team actually like it, and that the functionality advertised works as promised, that’s a different story- that’s totally fine.
The litmus test: anything you test in a POC, you should be over 80% sure that it’ll go well. Whenever you fall below this line, you’re taking too big of a risk.
Rule #3: Leadership must approve all one off POCs
This may not be applicable if you’re super early stage, and it is not applicable if a POC happens to be a necessary part of every single sale cycle you run. But at some point, you should not allow sellers to unilaterally decide to grant a POC as a one off. You should have some criteria in place, or an approval process, where a head of sales would need to approve POCs.
This forces sellers to actually think through the purpose of the POC, and first conclude “I can make a strong case for why this POC needs to happen.” That’s important, because it can become way to easy to just grant POCs willy nilly where the prospect isn’t accountable to any outcome, and doesn’t value the free access to the product as a favor.
If the prospect doesn’t value the proof of concept, there is a strong chance that they will forget to start it, get distracted, etc. - and a few weeks can easily turn into months of intending to trial.
Rule #4: Prospect must agree to success criteria before starting a POC
Before you launch a proof of concept, you and your prospect should sit down and map out the exact things they’re looking to test. Make a checklist together- if the following things are true, the prospect must agree that they plan to purchase at the conclusion of the POC.
I think of this a “microcontract” - microcontracts are little agreements or trades throughout the sales process that help you drive accountability.
The bottom line is this: if we prove all the specific things you want to approve, I need to know that you’re planning to buy. The worst possible outcome would be proving all the success criteria, only to have the prospect back away from purchasing. That means you wasted your time.
By the way, as a seller, it’s your job to not allow nonrealistic success criteria. If a prospect wants to tie the success of the POC to a certain level of ROI, a strong seller would push back and explain that it’s unrealistic to prove ROI after 3 weeks. If prospect isn’t ok with that, then you shouldn’t pursue a POC together.
A lot of times in sales, you must be willing to go all in on a belief, and risk losing the deal as a result. This doesn’t mean you should be irresponsible- it just means that if you allow certain conditions, you’re so heavily handicapping yourself from ever making a good sale that it’s not worth it.
Rule #5: POC deployment must align with buying timeframe
Most POCs tend to last four weeks, but my personal feeling is that this is a little bit too long. I think three weeks is the goldilocks zone- there’s enough urgency where there’s pressure to actually get started, but without it feeling like a total squeeze.
Beyond that, you must get a commitment from your customer that they’re ready to get started and actually use the product. Never deploy today so that they can actually start paying attention to the POC in a week or two.
If the customer isn’t ready to actually start the POC, insist on waiting to deploy until they’re ready. That might sound like: “we should both view this end date three weeks from now as the true end date of the pilot. If we don’t think we can make a decision by that date, we should wait to start the POC.”
Rule #6: Customer must agree to a project plan with timed milestones & stakeholders
It doesn’t have to be a crazy heavy lift, but as a seller, you should share a GSheet with key milestones of the POC, and which stakeholder owns them.
This means you can catch the moment where the POC has gone off track- it means that the mini milestones you’ve set up hasn’t been met, and you can pinpoint who was supposed to own that item.
If you establish ahead of time how big a favor the proof of concept is, prospects will value it more and be more respectful of the project plan. If you grant it too easily, or worse, actually PUSH a proof of concept on your prospect, it’s very unlikely they’ll meet you halfway, effort-wise.
Rule #7: The rules don’t go out the window for “bake offs”
There is a certain style of POC that sellers refer to as a “bake off.” This means a prospect will be actively comparing your product to your competition, and picking a winner based on the results.
I’d be very dubious of bake off scenarios- they’re very rarely worth your time as a seller, and puts the buyer in a huge position of power where they feel like they can boss you around at every step.
This could be its own article, but the TL;DR here is that all the rules of a POC that we discuss above apply in a bake off scenario. If you have an industry leading product, the prospect probably knows that too, and you don’t have to give in to a prospect’s demands without them trading an equal level of commitment to you in return.
Rule #8: POC must result in a go, or no-go, decision
This one is very simple and probably the most important- your customer should agree that when the POC ends, they’re either signing a contract, or you’re both going to agree that this is not the right solution.
In sales, a no-decision is the worst case scenario. A “no, this isn’t for us” at least allows you to focus on the deals that are more deserving of your attention, so that outcome is totally acceptable. But you can’t get to a no if the prospect forgets to deploy the POC, or can’t effectively reach a conclusion on the success criteria you outlined.
In summary:
A proof of concept can be a very slippery slope. You should avoid them if at all possible. If they are completely unavoidable, and customer has a valid need to test that the product works as advertised, a few things must be true:
1. Customer must appreciate the gravity of a free proof of concept- product cost is one thing, but human time is the biggest give. It must be valued correctly on both sides.
2. Customer must agree to realistic success criteria
3. Customer must commit to a project plan, and to be accountable for timelines
4. Don’t get in the habit of extending POCs. Explain ahead of time that we should only start the POC when it aligns with a decisionmaking and contract execution timeline.
5. Customer (and their decision maker) must agree that if proof of concept goes well, they will be buying at the conclusion of the POC.
Thanks for reading EarlyGTM post #7!
Mike Marg
Principal, Craft Ventures
(for more thoughts on go to market, and occasional sports-related frustration - @mikemarg_ on Twitter)
And if you don’t already, subscribe now below so you don’t miss out on future monthly issues of EarlyGTM.