A Quick Guide to Product Discovery - 4 Product Discovery Methods
The two most fundamental issues to solve for a product manager are building the RIGHT product and building the product RIGHT.
Both are equally important and are reflected in the phases of product discovery and delivery.
In this article, we take a closer look at what product discovery means and how to do it.
Discovery and agile development
Product discovery is a relatively new concept in the history of software development. It was only made possible by the introduction of agile development practices.
Software development used to be done in a waterfall process.
First came a lengthy requirement phase, then an even more lengthy development phase, testing, and release. With any luck, customers would like the outcome.
Sometimes they did not and the time, money, and effort were wasted.
This all changed when agile development came along. Now it was possible to quickly develop, release, learn and iterate. Incremental smaller improvements became possible, taking days or weeks rather than months or years.
With agile development, it also became possible to test earlier that what is being developed is being taken up by customers. It allowed to change direction more quickly and not waste time and money on useless code.
Product discovery takes this one step further.
In product discovery ideas and designs are validated before anything production-ready is built.
Product discovery versus delivery
When a team uses product discovery the work is split into two parts. The two parts continuously interact and overlap.
Discovery phase
In the discovery phase, you work with customers to work out the right solution to a given problem.
This involves validation on multiple levels. The four questions to answer for any given idea are:
Is the idea valuable, viable, feasible, and usable?
We have discussed these four aspects in our article on empowered product teams.
Building of production code should only start when these four questions have been answered.
Delivery
Once discovery has been done and a good solution has been identified, in the delivery phase production code is produced.
But be careful! The product manager and designer should not cook up a solution and hand it over to the engineers to build.
This can stifle innovation.
Engineers know best what is possible with the technology at hand. Involving the engineers into working out a solution yields better and more innovative solutions.
It also brings more enthusiasm into the team as team members feel involved rather than just executing.
All product team members should be involved in the discovery phase.
Discovery and delivery are not distinct phases like in a waterfall project. They happen continuously and feed off each other.
When a solution has been developed and released, you learn how your customers use it. Over time you build up the knowledge of what works well with your customers. This creates new ideas and feeds the next rounds of discovery.
Why is this important?
Your customers are the only people who can tell you if what you are thinking of building will be a success or not.
Validating your ideas before building code is
cheaper as no development resources are wasted.
faster as you don’t develop a feature for an extended period of time before potentially finding out that nobody wants to use it.
more successful in the long term as you only build things that are adding value to your product. This avoids unnecessary clutter. A feature that nobody uses is not only wasted time and money. It can also be detrimental to the overall experience. Less is often more!
incremental learning as you build up knowledge about your customers and can assess ideas more quickly.
Talking to your (actual or potential) customers is one of the most important things you can do as a product manager. In fact, every team member of a cross-functional product team should regularly interact with real customers.
Make a meeting with customers a regular event that every team member is looking forward to.
4 product discovery methods
Okay, so how do you actually do this product discovery? Well, it depends where you are at in your thinking about a problem.
Identifying good ideas
Chances are that you have lots of ideas already for your product. More than you can (or should!) ever build.
How do you decide which ideas are good and which one to tackle first?
You can do an initial assessment of opportunities by evaluating expected impact and effort, for example with airfocus. This is easier if your ideas are formulated as problems to solve (outcomes) rather than features to build (output-oriented).
Formulating an idea as a problem rather than a solution leaves the room to discover the right solution along the way.
Early idea stage
In order to find out if an initially assessed idea might be good or not, you want to find out if it is valuable (customer focused) and viable (business focussed).
At this stage, you want to talk to (actual or potential) customers to find out what problems they have that your product can solve. Good methods are focus groups or individual interviews.
This is as much about validating your idea as also generating new ideas for future assessment. You should be able to tell after some interviews if an idea is valuable, i.e. will your customers want to use it.
Viability is more about internal validation if your idea fits into the company’s overall strategy and if it poses any legal issues or financial risks. For this, you want to talk to stakeholders around the business.
Early design stage
Once you have determined that customers would benefit from your product idea, it is time to find a good solution. This is all about feasibility and early usability.
At this stage, you want to involve your engineers. They can suggest the best technology to address the problem.
Also, early prototypes can be created here to show to customers. The key is to make prototypes simple and low fidelity so that you can quickly iterate.
They can be paper prototypes or wireframes for example. Ideally at this stage, no coding should be required as the prototypes may be throwaway artifacts.
In this phase, you should brainstorm with the whole team on what a solution could look like.
Final design stage
Once you have defined the rough flows and the technology to use, you can create more detailed high-fidelity prototypes to test with customers.
This phase will really tell you if what you are planning to build is usable. You can test interactions and see if customers “get it”.
A little bit of coding might be involved here for example to show interactions more realistically.
But it is important to note that no production code is being developed yet. It should still be possible to iterate rapidly to optimize your designs.
You should only start production code development once you have fully validated your solution with customers.
There are lots more methods to use in discovery. Be as creative as you like. Anything that gives you insight into your customer needs and how they may use your product will build up your knowledge.
Product discovery and empowered product teams
Empowered product teams are a prerequisite to being able to employ a good discovery process.
It is crucial that the product team is given problems to solve rather than solutions to implement.
This also means that the business needs to be comfortable that it doesn’t know exactly upfront what the product team is going to build as they are going to discover the solutions along the way.
Conclusion
Any modern product organization should use discovery practices to find out what their customers like and can use without wasting time and money on building the wrong product.
Discovery can greatly speed up delivery as only valuable and usable code will be developed.
Product discovery is an important tool set to work out how to build the RIGHT product and to build the product RIGHT.
Kerstin Exner
Read also
Create effective product strategy
Experience the new way of doing product management