Menu
Learn how to structure your product testing process and establish a clear plan to sign and close customers.
Now that you’ve gone through the exercise of finding prospective customers and conducting thorough discovery, it’s time to structure your Product Testing process AKA Proof of Concept (POC). This guide is intended for B2B companies looking to secure contracts between $30k-$100K+ seeking a playbook for controlling the evaluation process and closing a deal.
Before you can begin the Product Testing phase, identify the “paper processes” required to secure a contract. The earlier you can ask your prospect about their paper process, the better. As soon as you identify a qualified opportunity, ask about their paper process. The timelines below highlight all of the types of paper-processes that can happen in a sales cycle, but it’s important to ask and confirm which of the topics are a requirement for each specific customer since it’s usually not all of them.
.png)
If your prospect can’t map an example of this out for you, that’s a sign you are not as close to a deal as you think. In most cases, the first step is executing a Mutual Non-Disclosure Agreement (MNDA) with your prospect.
Note: Be prepared to complete additional paper processes for each prospective customer. Account for the amount of time required for each step. Going through the full paper process can take over 2 months. Don’t forget to factor this into your sales cycle.
By conducting a thorough discovery process, you should have a clear understanding of the following by the time you kick off the Product Testing phase:
Current State - What is your prospect’s current situation? Tech Stack, Business objectives, and overall needs.
Challenges - What challenges your prospect is facing relative to the problem your solution can solve, and the metrics that quantify how big the problem is (this will help you justify the cost of your solution).
Ideal Solution - Your customer should define what they are looking for in a solution, what their requirements are, and if their requirements are met, would justify a purchase.
Expected Benefits - If the solution is able to meet their requirements, what happens to their business because of it?
Business Case - Use this as a summary that your prospect can use to build a case on your behalf internally during the evaluation process.
Summarize the information by drafting a Product Testing Doc. This document can be mutually beneficial by helping you drive a deal forward, while helping your prospect articulate the business case for buying from you.
Once you complete your Product Testing Doc, set up a POC Scoping Call with the prospect. In preparation for the call, aim to have as much of the Product Testing Doc filled out as possible so you can so you can use the time together to identify where your gaps are and what questions you still need answered.
Once you’re ready for the call, there are three goals you should aim to achieve on the call:
Goal 1: Define Success Criteria
Go through the Product Testing Doc with your customer on the planning call to identify what the customer requires to consider the Product Testing a success (Ideal Solution), how you would meet those requirements, and how that ties to business outcomes (Expected benefits).
Ideal Solution
Expected Benefits
Goal 2: Gain clear visibility into your prospect’s Decision-Making Process and Buying Process
Decision-Making Process
Prior to kicking off any type of test, uncover what your prospect’s decision process is for buying a solution. They should confirm that achieving their defined success criteria would suffice in order to move forward with negotiating a contract.
The prospect should be able to answer these two questions:
If they’re unable to answer them, work with them to identify the answers. This has the possibility to come off as an interrogation, so it’s critical that you treat this conversation as a partnership.
Here’s an example of a prospect mapping out the Decision-Making Process:
Prospect: “If your solution were able to reduce our EC2 costs by the 10% you claim it will and you can automate a process we currently have one Engineer dedicated to, we could move forward with a purchase.”
Founder: “Great, who else needs to be involved if we were able to meet those requirements?”
Prospect: “I have the final say in which products we choose, but my CTO would need to approve it.”
In the example above, we have identified that the CTO is the Buyer in the process. Other questions related to the Buying Process would be:
Goal 3: Build a Mutual Action Plan (MAP) to sign a customer
A Mutual Action Plan (MAP) is a brief document that helps your team and prospective customer build a mutually agreed upon plan to execute on an evaluation in partnership rather than a passive transaction. Using a MAP establishes a level of accountability and visibility of the evaluation and buying process between you and the prospective customer. This can feel like an unnatural process, but the customer’s willingness to participate in this exercise indicates their level of interest and willingness to secure a contract. It’s important to keep in mind that getting budget approval, team participation, and securing a contract may be a challenging feat for the person you are selling to. Building such a plan and partnership establishes a clear path and focus on the right sales cycles.
Continue on to Closing After Testing.
