To qualify design partners as prospective customers for a B2B product, you must learn about more than just the company’s current and desired future states. This article provides the strategy, success metrics, and more.
When we outline the qualification-led sales process with founders, the first question we often get is, “I understand what information we need to pass each gate and why it’s important, but how do we get that information from the prospect customer?”
Enter the concept of the four boxes for performing discovery and taking notes throughout the sales process. These are the four main areas you’ll focus on for discovery:
By following this framework, you won’t forget to cover a specific area and all your notes can be contextualized based on the box they occupy. It’s also easy to continually update this during the sales process and review it with the prospect to make sure you’re aligned.
Here's what a blank version looks like going into a conversation with a potential enterprise customer.
You’ll ask your discovery and qualification questions going left to right, top to bottom. This flow should also align nicely with the (see Building your first customer presentation) that you'll walk the prospect through.
At a high level, these are examples of the questions you should ask for each box as you progress through the sales process.
Even though it's listed as a unique stage in the sales process, discovery never stops while working with prospects. Your goal should be to always leave every interaction with them (live or async) having added value and having learned new information about their problems, their ideal outcomes, their process, etc. If you leave a conversation with a prospect without learning anything about their current state, you’re probably pitching.
The key to great discovery, aside from preparation, is genuine curiosity about the prospect/company's current state:
The current state is all about understanding how things are today for the business, the team, and the individual prospect and what negative consequences (problems) have arisen as a result. Negative consequences should always be quantifiable (money, time, customer count, market share, etc).
You’ll start by learning about the person or team you’re speaking with. You want to understand what they were brought on to achieve in the company and how that’s going. Reference the questions we’ve outlined in the Interviewing innovators Field Guide article to get the most value here. Then, you’ll want to hunt for instances where there's pain around a process or outcome that your product solves, and how the negative consequences are impacting them, their team, and the business as a whole.
The best outcome for the current state is discovering that the prospect agrees with your paradigm on how their workflow could be improved, has a pain that's causing quantifiable negative consequences, and they have a compelling reason and timeline to solve it.
Design partners probably agree with your paradigm on how their workflow could be improved or they wouldn’t be design partners, so you’re likely focused on the last two criteria. For example, you’ll want to uncover if any of the following instances are true.
Now that you’ve got an understanding of the current state and what's broken, it's time to transition your discovery to what an ideal scenario would be.
The future state allows the prospect to step into the hypothetical where their current problems and the negative consequences they cause have been solved. These potential positive business outcomes also need to be quantifiable, and you’ll need to press for those numbers to make sure it’s something the business actually cares about. What gets measured gets managed!
When talking to prospects about their ideal workflow, process, and outcomes, make sure to always ask second- and third-level questions to verify that these aren’t just pipe dreams or nice-to-haves. Again, you’re trying to get to quantifiable business outcomes like these:
The bridge between a prospect's current state and their future state can be found in the required capabilities. These features allow them to solve their negative consequences and unlock positive business outcomes. The majority of required capabilities should tie back to paid features of your product and are, ideally, unique to your solution.
It's OK for one or two of the required capabilities to be product aspects that aren’t behind a paywall, or that your competition (including internal tooling) can do. However, if the majority of the required capabilities don’t tie back to features the prospect would pay for, they're likely not qualified and don’t warrant spending time with until that changes.
Success metrics measure how the prospect’s business will know when they have achieved their ideal future state and positive business outcomes. These are usually technical in nature, since they are how you measure required capabilities.
If positive business outcomes speak to the line of business BUYERS (CEO, CRO, CFO, etc.), then the success metrics usually speak to the technical USERS/BUYERS (VPE, CTO, CIO, CISO, etc.)
Continue to: Scale your sales team to win the early majority