Last week, Ken Pouliot, VP of Sales at Gigya, joined us on the Bowery Capital Sales Podcast to discuss “Structuring Proof of Concept (POC) Deals.” We explored a framework for maximizing the conversion impact of a POC, while mitigating the risk that delays, unexpected asks, and unclear goals can present. In Ken’s words, POCs can be Honey Pots or Bear Traps, and preparation makes all the difference. For the purposes of our podcast (and this article), we define a proof of concept as any phase in a deal in which the customer is implementing and testing your product. This occurs hand-in-hand with your team, prior to signing a full contract. So this framework is applicable in some way to nearly every enterprise SaaS company out there. Takeaway #1: if you don’t have a formal proof of concept process, consider crafting one today. That F500 whale you’ve been nursing isn’t likely to close without some period of testing and hand-holding. Here are 5 key questions & answers to help you structure proof of concept deals.
1) How long should my proof of concept deals last?
The goal here is to be able to lay out key value props that the customer wants in a product like yours, and deliver measurable positive KPIs against those value props over the course of your POC. As a general rule of thumb, Ken suggests no longer than 90 days, for a few reasons. First, he believes that a company should be able to prove that their product is useful before then. Second, he thinks that if the potential customer has not bought anything after 90 days, it means that they are not ready to buy. If that is the case, continuing to send them resources is a waste, and the company could be catching itself in a Bear Trap. Because of this possibility, set clearly explained milestones for your customer before beginning the POC.
2) What goals / milestones should I center my proof of concept deals around?
Setting hard & fast milestones in the first place is an all-too-often overlooked step. Without them, you could find customer asks spiraling out of control, your team overstretched, and your customer still wanting after your POC period. Set measurable milestones based on what your product can do today and the customer’s stated needs. Before institutionalizing them in an agreement, make sure you don’t miss any critical customer wants. Also, be sure to establish an explicit hit-list on both ends. Throughout the process, stiff-arm asks that are aren’t relevant to your milestones. Be strict to avoid scope creep. In Ken’s words, your customer will respect you more for it. Messing up by not engaging a customer and circling back later is not ideal. However, it is better than failing on a POC plan with ill-defined goals or wasting time on a tire-kicker. As a result, when your product & team delivers on these milestones, you can come back with the same hit-list and a corresponding set of check-marks & KPIs, maximizing your chance to close. Seeing that you delivered on exactly what you scoped is almost as important as the performance & potential of your product itself. To give you a sense for what an asset a well-run POC process can be: the best POC Ken was a part of achieved an >80% close rate.
3) Who should be responsible for the various touch-points through a proof of concept deal?
During the POC process, your team needs to have established roles and deliverable owners. Even if your business is composed of a few founders, who’s playing the AE, who’s playing the AM, and who’s playing the sales engineer? The customer’s tech contact and dealmakers will then know who to talk to throughout the process for point questions. Ken and I discussed what the overall back-and-forth of comms should look like ideally. Start with the initial scoping meeting in which you will propose and mutually agree upon your goals / milestones. Next, the customer will initially begin using your product after work with your sales engineer to implement. Once live, you must keep an open dialog and inform all parties of progress against goals. At the end of the POC period, Ken believes, there needs to be a final meeting with executives who have the ability to sign off on purchasing your product. This allows you to go over the entire process (Set this expectation from Day 1). In this meeting, make sure to remind them of the initial milestones that you agreed upon. This will demonstrate not only your successful (hopefully) accomplishment of these goals but also your ability to deliver on what was asked.
4) When should I start talking dollars?
Deciding when to propose full-contract pricing to a potential customer can be difficult and somewhat varies by stage. At earlier stages, you will need to fully show the value of your product before locking in exact pricing expectations. They are taking a risk even engaging with you, so cut them some slack on their hesitance. It’s critical, however, to (1) ensure they have a sense for pricing ranges (which you can keep non-exact by citing factors TBD during the POC), and that (2) there are still asks of the customer. As Ken often reminds us, mutual commitment is the name of the game here. Once you have more paying customers, your pricing will be out in the market. Additionally, you can use other customers as references, allowing you to be more direct with pricing upfront. At later stages, you may find POCs less necessary as reference customers bring the sales conversation to a head faster. This will ramp down POCs to 50% of deals closed, then eventually will sunset the POC program.
5) What materials / documents do I need to think about as relates to my proof of concept deals?
The first is an NDA. Tire-kickers are rampant and IP theft, on some level, is a real concern. This will protect you and your client’s information, and there is no negative effect of having one. In fact, it may even screen out the lowest intent leads and help reduce CAC burden in doing so. The second document should outline the specifics of the agreed-upon goals and what each party (not just you!) is commiting to make those happen. This can be as simple as a branded Google Sheet, but should be “stamped & signed” once goals are agreed upon to make your target clear. Finally, you and your customer need a forum (anything from a shared cloud document to a Slack channel could work). You can go back and forth using this medium, to get feedback on your product and to work through deliverables. Naturally, you will also need a vetted MSA and contract with appropriate eSigning capabilities when the time comes, assuming your POC process is working.
Some final words of advice: as a founder or employee in a young SaaS company, it’s important to ensure that you thoughtfully tailor your POC process to your product, company and team. However, per Ken, “sales is not an art”. Start with a framework like this one (with a focus on transparency, clear / limited goals, and mutual commitment). Next, be sure to test with customers until you have a POC framework that converts. Lastly, ensure that your whole team sticks to it religiously.
If you missed the podcast itself, make sure to check out the full episode “Structuring Proof of Concept Deals” with guest Ken Pouliot (VP of Sales at Gigya). Also, check out past episodes and make sure to subscribe to our podcast to get new content every Friday. Thanks and until next time!
