The Joy of Discovery – Part 2

So… after a slightly longer than planned hiatus, let’s get back to our examination of the discovery process.

As we have seen, during a technical discovery call there are four type of questions you should cover:

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

I covered domain discovery and process discovery in the previous post so this article will focus on technology and demo discovery.

Technology Discovery

Technology discovery involves learning about the technology stack in use at the prospect’s organization in order to determine the degree of fit with your product. This is a critical part of discovery because even if your product’s features can solve the prospect’s business problem, you will lose the deal if your technology is incompatible with theirs.

(If your technology is incompatible, tell them early and then respectfully disengage. There is no point chasing a deal you know you cannot win.)

For the build and release management product I currently sell, the questions I ask during technology discovery include:

• Which source code management system (SCM) do you use?
• What languages do you use for application development?
• How do you build your software?

Technology discover can reveal a lot about the culture of a prospect. A company that is still writing software in VB6 is much less of a technology leader than one that’s developing software in RoR or Scala. A company where everyone gets their choice of Windows, Mac or Linux on their desktop is a place where software purchasing decisions are unlikely to happen from the top. A prospect who tells you “we try to use as much open source as possible” will be unlikely to purchase a high priced commercial software package unless there is no open source alternative.

As you conduct more of these  discovery discussions you will become better  at reading these tea leaves.

Demo Discovery

Demo Discovery is something that many sales engineers never consider. If I’m doing a demo I want to know the following bits of information:

• Who will be attending? (Names and roles)
• Who are the decisions makers?
• Will they all be in the same room or are they geographically distributed?
• Will we be onsite or remote?
• How many other vendors are also delivering demonstrations?
• Where do we fall in the order of presentations? (First, middle or last?)

This last question is an interesting one. I’ve heard many debates about whether it’s best to go first or last. (Falling in the middle is universal disliked.) These debates are often academic because you rarely get the chance to choose where you fall in the line-up. Nonetheless, it’s useful to know where you fall. If you are not first, you should ask your coach inside the account (you have cultivated a coach, right?) how the previous demos were received. He might have information (for example “they talked too much about the admin features”) that will help you tune your own demo.

In closing, remember that discovery is your key to winning deals. It’s not just limited to a single phone call; you should be in discovery mode in all of your interactions with prospects. New requirements will arise and existing requirements may change. The more you can learn about your customer and their requirements the better you will be at positioning your product as the right solution.

As you will see in an upcoming post, when I do discovery it continues all the way into the demo.