Many product leaders instruct product managers to focus on prioritizing customer problems, not defining solutions. In this framework, the PM presents a prioritized and validated set of customer pain points to the team, not a backlog of pre-determined solutions. When PMs focus on problems and let engineers and designers shape solutions, teams avoid the inefficiencies of “waterfall” scenarios. As a result, they move much faster toward discovering – and building – the right product.
I agree with this framework wholeheartedly, but it can be misinterpreted as a mandate that PMs ignore solution-oriented thinking altogether. While it may seem counterintuitive, I’d argue that solution-first product discovery is also an effective component of the development cycle. When applied early on, and with minimal resource cost, solution mapping helps teams uncover subtle but critical user problems.
Using solution-oriented thinking to find pain points
The reason we shouldn’t think exclusively from a problem-first perspective is that problems and solutions don’t exist in a vacuum. They are interrelated since the landscape of available solutions will influence customer pain points. For example, when a new technology renders an old one obsolete, customers experience new pain points that they may have previously learned to accept. Remember smartphones with keyboards? While at the time an innovative product, the invention of multi-touch interfaces provided a new, better approach to the phone. In turn, this transformed the existence of keyboards into a new consumer problem.
While problem-first reasoning is an important step in product development, reasoning deductively from problem to solution can, ironically, limit the discovery of unconscious issues. Even when interviewed, customers may not give voice to these types of concerns until new possibilities are presented to them.
My suggestion to PMs is not to abandon the problem-first approach, but to also spend time thinking from the other direction. Ideate the solution first, then use these prototypes to reveal the hidden problems that customers might not otherwise acknowledge.
Design exploration as a method to explore the solution space
To arrive at solutions independently of problems, we need a way to methodically explore the solution space. I have found that the best way to do this is to design a product in its ideal state, in detail.
Start by drawing out the product as it might exist in 6 to 12 months. (Also, temporarily suspend your concerns about limitations and feasibility constraints.) Along the way, look for various decision points, and design through the forks in the road. To your surprise, you might be halfway through one solution and discover an entirely new, more optimal, solution. Either way, you should end up with an extensive collection of designs and scenarios.
This is the practice of mapping our own intuition about a product and transcribing our experiences into potential problem areas. Evaluate the various possibilities, then if you feel something is right, try to extract the principles of why it’s right. In essence, find the solution and work backward to the problem.
Once you distill a set of problems, validate them
After going through this exercise, you probably have a strong set of convictions about what the right product looks like. This is, however, only one opinion and the most dangerous of them all – your own! Avoid the desire to spec it out, hand it to your team and say “build this!” Instead, take your list of intuition-fueled, solution-derived problems, and validate them through interviews and tests.
Finally, use designs as examples to frame conversations. Since you took the time to draw the product in detail, you also have a great collection of low-cost prototypes to show your customers. This will help clarify the nature of customer problems, especially if they are of an ineffable visual quality. It may reveal new value axes of the product, or even illuminate how certain UX elements — such as IA, organization — are not only critical to the success of a product, but areas of innovation on their own. These insights not only help us create better customer experiences; they help guide us toward more disruptive products.
The end result is a neatly prioritized backlog of problems for the team to solve. Remember, the idea isn’t to ask teams to build your designs. Instead, find ways to highlight aspects of the problem space that your design reveals, then let your team envision the right solution from there.
When used regularly, design exploration can result in new dimensions of value, a stronger sense of priority, and a set of de-risked assumptions. As a result, your team will move faster and with more confidence, not only toward building the right (i.e. “logical”) solution but toward building the winning solution for your customers.
About the speaker
David Prentice is a Product Manager who is happiest when actualizing ambitious visions, fine-tuning high-quality user experiences, streamlining complex interfaces into simple interfaces, learning by talking with customers, binge-building dashboards, collaborating with cross-functional teams, and shipping products that make a meaningful improvement in the lives of their users. He currently works at CollegeVine, an education startup dedicated to bringing high-quality college guidance to every family, and has led the creation of a new app to help students optimize their college choices. Prior to CollegeVine, he managed brand, platform, and research teams at two of the world’s largest online travel companies. PM-life aside, David is a music, art, and history nerd, who lives in Boston with his girlfriend and three cats.