The Joy of Discovery – Part 1

Author’s note: Discovery is a big topic, so big that I’m going to cover it in two parts.

Before you ever decide to demo software to a prospect you first have to conduct a process called discovery. There are at least two different types of discovery: business discovery and technical discovery. Business discovery is a discussion with the prospect that usually covers BANT (Budget, Authority, Need and Timeline.) Most of these topics are the domain of the sales representative, but the critical topic of “need” (ie, why do they need this software?’) overlaps with technical discovery, which is the domain of the sales engineer.

You and your sales reps can work out how to coordinate business discovery and technical discovery. I’m not going to go into much detail on business discovery (since I believe it should be handled by the sales rep) but I will say that both types of discovery are equally important; you are not likely to close much business if your team does not develop a complete understanding of your customer’s requirements and their buying process.

Let’s assume that your sales rep has found a prospect and had walked them through enough business discovery to believe that there is a winnable deal here (pending the technical discovery). The next step is the process is to set up a call or meeting to discuss the customer’s requirements. While the sales rep probably has more of their own discovery questions to cover during this call, the bulk of the call will likely be yours to run.

During a technical discovery call there are four type of questions you should cover:

1. Domain discovery – what domain-specific problems are you trying to solve?
2. Process discovery – what is the selection process?
3. Technology discovery – what are your technology requirements?
4. Demo discovery – who, when and what regarding the demo

I’ll address the first two this week and the last two in the next update.

Domain Discovery

Domain Discovery is the heart of sales engineer’s discovery process. The purpose of domain discovery is to understand the business problems that have brought the prospect into a discussion with your company. If you could only ask one question in this discussion, it should be:

Why are we talking today? (Ie, why are you evaluating our software?)

 I usually like to start the discussion with this sort of open ended question because it give the prospect the opportunity to unload lots of information and it helps you avoid conducting what might appear to be an interrogation.

This portion of the discovery process should also delve into specifics that are unique to each product company. For example when I sold an enterprise contract management system we asked a lot of questions about the prospect’s contract management process, including:

• What types of contracts do you have in your business? (Leases, sales agreements, etc.)
• Do any of these agreements automatically renew?
• What is your process for alerting both customer and internal stakeholders when support contracts are 90 days from expiration?
• Have you ever experienced a situation where contracts automatically renewed when they should not have? If so, what impact did this have on the business?

Of course, the domain discovery questions will be different for each company. However, what’s common to all companies is the need to understand the prospect’s business problems that have lead them to you.

During domain discovery one of your goals is to uncover latent requirements that may help your product get selected. A latent requirement is one that the customer truly has, but does not articulate. For example, you might ask “is it important to be able to track not only changes to data, but changes to system configuration?” and get this response “I never thought about it, but yes we definitely need that.” Congratulations, you just found a latent requirement. The more of these you can uncover the stronger you make the case for selecting your project. Of course, your objective here is to ask questions that not only expose latent requirements, but expose latent requirements that your product is uniquely designed to fulfill.

Process Discovery

Another important part of the discovery call is process discovery, which means understand how the prospect plans to evaluate their options, including your product and how they plan to select a vendor. (Note that this is different from how they plan to make the purchase. That topic is the domain of the sales rep.)

Important questions to cover in process discovery include:

• Do you have any written requirements you can share with us?
• What are the roles of the people we are talking to? How long have they been at this company?
• What is the timeline for making a selection? What is the timeline for implementing the new solution? Is there some compelling event that’s driving this schedule?
• What is your process for picking solution? If this process includes a pilot or proof-of-concept, how will you decide which vendors to include?
• Besides our product, which other products are you considering?
• What happens if you choose to do nothing?

This last question is a great litmus test… if the prospect says something along the line of “If we choose to do nothing I guess we will just continue using our homegrown system for a while longer” be very careful; this doesn’t sound like a legitimate sales opportunity.

One important point to consider: some prospects do not have a formal process for selecting software, either because they are inexperienced or because their corporate culture does not require it. (For example, startups often lack a formal selection process for software.) In these cases you may be successful in suggesting a selection process, perhaps by saying, “I’ve seen other companies like yours find a solution to these problems by narrowing their options down to one or two vendors and they conducting a short proof of concept.” Of course, your goal here is to steer the process in the direction that will be most beneficial to your product without being overtly coercive. You might offer to help the prospect by organizing their requirements into a formal requirements document… this is a great opportunity to help them uncover latent requirements.

To Be Continued…

I’ll have more to say about the discovery process in two weeks.