Skip to main content

Top 5 Prospect Interview Mistakes

One invaluable tool that product managers use to understand markets is the prospect interview.  We identify prospective buyers and users who may share a common set of problems, and we conduct one-on-one interviews with them to probe their situations and dig deep into the challenges they face.  The situations and challenges inform our product strategy and decisions.
If you're a company executive, you may be reluctant to empower your product managers to conduct interviews with prospects, as what happens during these interviews could potentially jeopardize a future sale.  Even if you have confidence in your product managers not to jeopardize a sale, you may view prospect interviews as a dubious way of gaining market understanding.

Rest assured that prospect interviews will tend to foster trust and enhance future sales possibilities while providing a richer understanding of the market.  But only if product managers conduct them properly and avoid certain pitfalls.

The top five mistakes product managers make when conducting prospect interviews are:

1.  Pitch the product.

The biggest no-no when conducting a prospect interview is to attempt to sell the product or pitch its benefits.  It immediately puts the prospect on the defensive and undermines the purpose of the interview, which is to understand the prospect.  It communicates to the prospect that you think you already understand her needs, without even having probed into her unique circumstances.  You're effectively telling her what she needs instead of determining what she needs.

2. Ask the prospect what she wants.

If, during our conversations with them, we focus on what prospects want, we distract them from what we really need to understand.  We need to guide the conversation to the situation and challenges they face, not to what prospects think they want.  Once we understand what problems they face, and choose which ones to solve with our product, our team of design and implementation experts can come up with the innovative solutions to those problems.

3.  Ask the prospect to design the product.

As a general rule, prospects are not experts in designing solutions to the problems we may choose to solve for them.  If they were, they probably wouldn't need us or the products we develop.  With a product manager's skilled facilitation, however, we can work with prospects to uncover their problems.  In some cases, it may be beneficial to "co-create" the product with prospects or customers, but a prior investigation and mutual understanding of what problems to solve is a prerequisite.

4.  Ask hypothetical questions.

"How much would a product that does X, Y, and Z be worth to you?"  "How many times per day would you use feature X of our product?"  These types of questions are hypothetical and generally yield little useful information.  Prospects don't know what they would do.  They know what they actually (currently) do.  Conclusions extrapolated from what prospects actually do are often more reliable than direct answers to hypothetical questions.

Some hypothetical questions are necessary and useful.  In general, however, try to rephrase hypothetical questions as factual questions that give you insights into the patterns likely to guide prospects' future behavior.  For example, instead of asking how much they'd pay for a product, determine how much it costs them not to use your product.

On a related note, be careful with direct questions.  A direct question isn't open ended; it makes assumptions that may not be valid and ignores other possibilities that might be important.  Start with open-ended questions to allow for answers you can't anticipate and delve into more direct questions only after you've given the prospect an opportunity to introduce unanticipated topics and concepts.

5.  Ignore change management issues.

No matter what problems a prospect faces, and how much it costs his organization, the problems are usually nestled comfortably within a system that's resistant to change.  Explore these change management issues with the prospect.  Determine the people and processes tied to the problems the prospect and the organization are facing.  Use Buying Facilitation® to determine change management issues that would precede any purchase or attempt to adopt a new solution.  Standing outside the prospect's system, you will never be able to understand all of these issues, but you'll get a more complete picture of the prospect's situation and challenges if you stimulate her to consider the system in which they occur.


In many organizations, it can be an uphill battle for product managers to talk to prospects outside of a sales call or presentation.  Consequently, product managers who do manage to interview prospects feel a sense of accomplishment and confidence in their market understanding and product decisions.  However, this confidence can be misplaced if the product manager has made these common mistakes when conducting prospect interviews.

Comments

Giles Farrow said…
All great points, but I think it's rare for product managers to get to talk to prospects like this when you have sales teams in place.

The only occasions I can think of are
- when there is not much of a sales team and founders / product management are doing business development and customer discovery
- when a new product is being launched as an upsell to current customers

Most of the time sales want product managers to help them sell, to answer technical questions and share roadmap
Roger L. Cauvin said…
Thanks, Giles. Yes, I touched on you point in the last paragraph of the blog entry:

"In many organizations, it can be an uphill battle for product managers to talk to prospects outside of a sales call or presentation."

This problem is obviously a much greater systemic one than the mistakes I've enumerated.
Scott Sehlhorst said…
Great as always. One of the (few) upsides of doing COTS "product management" is the ease of getting to users (who are really prospects for usage, even though they aren't buyers). These tips for prospect interviews are consistent with ones for elicitation interviews.
Bruce McCarthy said…
Great tips. To Giles' point, launching a new product (or major version of a product) is exactly the time when it's most important to get market input, so the opportunity lines up with the need pretty well.

Once you've done enough interviews to design the product properly, it makes sense for the PM to interview early adopters for market feedback as well. Once the product is mature and being sold well, however, there is much less need for the PM to interview prospects - until, of course, sales stop growing and/or it's time for a new version or next-gen product and the cycle starts again.

I've posted my favorite tip for customer interviews at http://www.userdriven.org/blog/how-to-conduct-customer-interviews.html.
Roger L. Cauvin said…
Thanks for the comment, Bruce. I think it's good to stay in tune with the market by conducting prospect interviews periodically throughout the product lifecycle. But it certainly is the most critical as the team is conceiving the product.
Reagan said…
Hi! Great site! I'm trying to find an email address to contact you on to ask if you would please consider adding a link to my website. I'd really appreciate if you could email me back.

Thanks and have a great day!
Yassin Shaar said…
This comment has been removed by the author.
Yassin Shaar said…
This comment has been removed by the author.
Yassin Shaar said…
Great article !

I'm developing a software in the fitness market and currently running interviews to validate if there is a real problem worth solving.

I have already went through 2 interviews. I can't say i didn't learn anything, but i'm having a challenge digging deeper into the prospect's problems.

They tend to give advise on what i should be doing to develop this software rather than talking about their own problems.

I would appreciate your input on this.
Roger L. Cauvin said…
Yassin, some prospects try to design your product instead of sharing deep insights into the situation and challenges they face.

Three approaches can help with these types of prospects.

First, make it 100% clear from the outset that the purpose of the interview is not to design the product but to gain insight on the prospect's situation and challenges. Emphasize that you are not attempting to sell a product or solution and are not asking for feature suggestions.

Second, it's usually helpful to approach the interview as a "day in the life" inquiry. You typically won't have much luck asking, "What problems to you face?" Instead, ask the prospect to lead you through a typical day. You may also ask a facilitative question such as, "How do you currently . . . ?"

Third, when the prospect does make design suggestions, repeat the suggestion back to her in your own words, note the suggestion, and thank her for it. However, immediately thereafter, shift the conversation to what problem it would solve for the prospect.

If the prospect is persistent in making design suggestions and continues to resist talking about her situation and challenges, remind her of the purpose of the interview and suggest a completely separate followup interview to discuss design suggestions.
Unknown said…
Great article, Roger. Making an interview with a prospective client productive from an early stage is imperative to the success of a final product. Drawing out the time spent gauging the prospect's business needs wastes resources of both the product manager and sales team. The number one goal is to determine the business problem and then approach the prospect with your solution. At Seilevel, we utilize these kind of interview practices during elicitation sessions to make any time spent with the prospect/client useful. Equally as important to conducting the interview is listening- and keeping organized for future meetings or interviews. Personally, I find that taking and reviewing notes from every interview/call extremely helpful. A colleauge of mine wrote a blog post with tips for using notetaking skills to enhance time spent with the prospect: http://requirements.seilevel.com/blog/2012/12/notetaking-tools.html
Thank you for your great advice! Look forward to reading more posts from you.
Roger L. Cauvin said…
Thanks, Christine. I read the blog entry on notetaking. Good thoughts around the pros and cons of various note-taking methods and tools.

My favorite note-taking tool is Google Docs. It supports collaborative, simultaneous note-taking, cloud syncing across all devices, automatic version tracking and history, and offline editing and access.
Thank you for this article! It is so incredible helpful and thorough. I will definitely be using your suggestions and appreciate you taking the time to put this together.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio