Problems with Product Discovery

Working with Product Manager customers on product discovery, I’ve observed some interesting patterns. Teams move from problems to solutions too quickly, use MVPs for solution feedback, are biased on singular requests, and loose context across the process. If the following observations seem like common sense and aren’t problems with your team, good for you!

Moving from Problem to Solution Too Quickly

Even design-thinking technologists move from understanding problems to creating solutions too quickly. Perhaps because we’re grounded in what we know how to build with technology. Perhaps we pattern match to solutions we’ve worked on before. Or perhaps we take customer feature requests from customers seriously.

If you move too quickly into solution mode, it’s not just that you skip real problem discovery. You’ll naturally be biased to extend the solution you start creating and it blinds you to understanding the problem or alternative solutions. Until further down the road when you have negative signals about the solution, which is, expensive.

MVPs Are for Problem Validation First

Most people think of Minimum Viable Products as prototypes that help validate a solution. I think that’s a mistake.

Put aside the MVP, or anything that involves writing code, until you’ve got an understanding of the customer problem with some validation from conversations with customers and those on the front lines (sales, support, customer success and marketing).

Then when you create lightweight prototypes for customers to react to, most of the feedback you seek should be about the problem. Customers may tell you:

• I don’t think you understand my problem
• This is interesting, but let me describe my problem in further detail
• This helps me realize that the adjacent problem is more important

Ask and listen first for insight about problems in reaction to the prototype. Customers will likely have lots of feature ideas if just framed as a solution, and most don’t even solve what’s important for them. And iterating on the prototype should be driven more by what it solves than what it could do.

Problems Come in Patterns

Often when a customer has a feature request it’s viewed as solid problem with readiness to pay for a solution. And with talented salespeople advocating for it in your organization, the singular opportunity offers impact and certainty. But the best problems are patterns across multiple conversations and requests. Continuously organize and associate them until the pattern and business case becomes clear vs. other priorities for what to build next.

End-to-end Context

So much context is lost in product discovery. Yielding less than optimal decisions, designs and implementation. Problem context has value in the initial understanding, relative prioritization, solution design, development implementation, quality assurance, product marketing and more.

Pure fidelity of context is burdensome to capture, so keep it simple. When the product manager sees signal in a customer conversation that is likely to be acted upon, use that moment to gain the context needed to understand the problem. Along with the anecdotes, capture the Who, What, When, Where, Why and sometimes How.

The goal should be end-to-end context from the customer discovery conversations to customer success outcomes. If you capture the context up front, and use the right tools, it can be maintained across the functions of your business.

Shameless plug: if you are a product manager and your team is on Slack, you should be using Pingpad for Collaborative Product Discovery.