What is product discovery and what is the importance of it?
Product discovery is a flexible period during which the product team focuses on “building the right thing” rather than “building the thing right”. The latter would be seen as product delivery.
We see product discovery as an iterative process where an emphasis is placed on reducing uncertainty with regards to the problem or idea at hand to make sure that the correct solution gets built.
When should product discovery take place?
The one question that always gets asked is, “When should we start with product discovery?”, to which the answer is always, “Well it depends…”. The short answer however is, “Always”
Who plays a key role in discovery?
The key here is to remember that everyone: the product team, stakeholders, users, sales, developers, UX, engineering contributes on different levels of involvement. As a product manager I would group them in three different categories: permanent contributors, temporary contributors and supporting contributors. Decide who fits what category taking into account the nature of the project, what resources are available, the type of business and solution you are producing. Every product is different and a cookie cutter solution will not work here.
The six phases of product discovery
Adopting an approach to focus on getting alignment with all the stakeholders in the project from an early stage is worth its weight in gold. Creating alignment early on in product discovery and committing to a particular outcome instead of a set of features assists in clarity and helps build trust between the product team, stakeholders and the product manager.
Researching user problems
Any effort relating to the identification of new product opportunities should start with the question “Why?”. There are most likely multiple business needs to justify a discovery effort but the product’s success ultimately depends on whether it can solve the user’s problem. Without going too deep into user research there are four main quadrants and somewhere in the middle would be the truth, but we can only get to the truth if we do research in all four.
The trick here is to think big. Our typical brainstorming sessions for thinking about solutions will not work as people tend to stay in their comfort zone and stick with what they know. All ideas are equally important and there is no place for Hippo’s (Highest Paid Person’s opinion syndrome) here. Everyone is involved and the emphasis is on finding a solution to the problem.
Prototyping is a great tool but can quickly become very large and the focus can shift from a lean build-measure-learn approach to a high fidelity prototype that steers more to the look and feel. The key here is to constantly bring ourselves back to true north when iterating on the prototype and to place a large focus on learning from the actions and reactions from our users. The expectation that our prototype will be the final solution at its first attempt is unrealistic.
Proving our hypothesis is a critical step in building the “right thing” for the user. This can be seen as the final hurdle to cross before deploying our team.
I always ask myself the question “What proof do I have that it is a good opportunity to spend time, resources and money on?” Do not mistake validation for experiments. Validation checks the underlying assumptions and hypotheses where experiments test the specific measure we are going to use to get answers or results.
Now that we have gone full circle it is time to comb through the results and identify the areas where our next effort should be spent on. In most cases this will be the most problematic area for our users. Take the time to refine these results, prioritise them and get them ready to become backlog items.
This entire process of product discovery should be a journey that leads a product team closer to becoming an empowered team. This will not happen in one iteration, but rather multiples thereof. Remember, anything you take on as a product team should always have a golden thread running through it that leads to value for the customer/user. We always try to be better off at the end of the process than at the start.