Featured Insights
Product Management
Product Discovery as a key to solving problems
User behaviours evolve, so do technologies, and markets. Discovery helps to validate that solution is fit for the problem and the user.
My last post about building products that solve problems highlighted four key inputs and contributions towards designing products to solve user problems.
Discovery, Assumptions validation, Incremental building, and Data.
Let's focus on discovery today.
Discovery is many things and addresses many perspectives. The aim of discovery is to understand the problem from the user’s perspective before solutioning. It’s important to note that discovery is an iterative and continuous process. User behaviours evolve, so do technologies, and markets. Going back to revalidate and learn about market changes is key to product success.
It’s the process of researching a problem from the perspective of the problem owners (users) and validating the viability of assumptions that have been made with respect to this problem, taking into consideration the market realities, and making informed product development decisions.
David Jonassen’s definition of problems as highlighted in an article by Theresa Torres is a great illustration of the kind of user problems that product managers encounter. Jonassen describes two kinds of problems – structured and unstructured. Structured problems typically have simple and direct solutions; in other words, they have single right answers. However, unstructured problems typically have multiple solutions depending on who you talk to and their context.
I’ve identified these 5 key factors that contribute to successful product discovery.
The goal of the discovery is pretty straightforward – to identify opportunities (pain points, gaps, nice to haves), and solutions to be developed.
The outcomes, however, can be a bit dicey. This is because outcomes need to be aligned with the overall product goals which are derived from the overall business goals. It gets dicey because the product team may find it difficult to be objective and keep an open mind when crafting user interviews. The key outcome of product discovery is assumption validation but to ensure we’re on the right track, the assumptions need to be based on a correct understanding of the problem in the first place.
We keep going back to the users and the market. User behaviours evolve, so do technologies, and markets. Going back to revalidate and learn from the market is the key to product success.
Don’t be misled because this point is not the first on my list. Users are the most important contributors to this exercise. Not buyers, users. The people who interact with the product. The people whose problems we’re solving – users. Users must be involved in the entire process, they must be considered and actively listened to. Their feedback is what determines where the opportunities lie.
Developing empathy for users and finding ways to help them articulate their needs without influencing them is most important. We also need user interactions to get over the ‘arrogance’ that comes from being familiar with our product. Solutions and actions that may seem obvious to us may be novel to the user. What’s more? Our solutions may be creating problems for the user. To ensure that we capture the right information, it’s important to take multiple steps back and put ourselves in the user’s shoes.
These three teams are the key components of a product development team. They feed off one another and help design products that solve real user problems.
Please. Keep. Records! The only way to know where we’re going is an improvement on where we’ve been is by knowing where we’ve been. Documentation can seem tedious but it is absolutely necessary for future reference.
Now that we’ve identified the key ingredients, what steps can we take to guarantee successful Product Discovery?
You’re familiar with frameworks and methods such as design thinking, story mapping, empathy mapping, assumptions mapping, usability testing, A/B testing etc. but I’m not going that route. Frameworks are great, but I prefer to approach things from action and results perspective.
This is an initial exercise that helps you put things in perspective. Does the problem actually exist and what other ways could it be solved? To do this effectively, it’s important to embody the user and the problem as objectively as possible. This exercise helps the PM develop empathy for the user.
Whether you’re coordinating discovery for a new or existing product, reviewing the target market helps to confirm that we’re on track and building for the right users. Evaluate the previously defined personas and ICPs. Do your assumptions remain valid?
What is the competitive landscape? What is the market outlook? I wrote extensively about research in a few articles. This is a great place to start.This is a great place to start.
The most common method for these include interviews, empathy mapping, assumptions mapping, usability testing, A/B testing etc.
Once the collection methods are defined, the next step is to collect the data, evaluate it and start identifying opportunities. PMs have to be super objective when engaging users to collect data. For instance, during interviews, ask open questions, ask the same questions in multiple ways, actively listen and document.
Opportunity-solution mapping is a great way to identify opportunities, map them to possible solutions as well as the business or product goals they may address. Mapping is generally a great mind tool that helps us structure our thinking.
Yay! We’ve successfully identified solutions to our users problems. But remember that the goal of product discovery is to eventually determine what to build and of course at this point, your opportunity map has quite a number of solutions. This is the point to introduce prioritization. Which problems are more important to the users? Which solutions are more viable than others? Which solutions are you able to deliver with the resources you have?
What’s next? Validate our assumptions through experiments. And then, learn and repeat.
Do you have questions about product discovery? Get in touch.
David Jonassen’s definition of problems as highlighted by Theresa Torres https://www.producttalk.org/2016/01/product-managers-level-problem-solving-skills/
