A Brief Guide to Product Discovery
This article offers an overview of product discovery. It explains what product discovery is and why it matters; which questions it should address; when, how and by whom it should be carried out; and what types of discovery there are.
You can listen to the audio version of this article here: https://www.romanpichler.com/romans-podcasts/a-brief-guide-to-product-discovery/
What is Product Discovery?
Product discovery describes the activities required to determine if and why a product should be developed and offered. This increases the chances of creating a product that users actually want and need and achieving product success. Carrying out product discovery involves answering the following questions:
- What is the specific value the product should create for the users and customers? What problem should it solve, or which benefit should it create?
- Which market and market segment should the product address? Who are the users and who are the customers?
- What makes the product stand out? How will it differ from competing offerings?
- What are its business goals? How will it benefit the company? For example, generate revenue or meet a profit margin, reduce cost, or develop the brand?
- What business model will it use in order to achieve the business goals, including revenue sources, cost factors, and channels?
- Will the product make a positive impact on people’s lives, the wider society, and the planet, or will it at least not cause any harm?
- How might people use the product? What are the major touch points? What kind of user experience (UX) should the product give rise to?
- How can the product be built? What architecture patterns and technologies may be used?
In order to answer the questions above, you may want to use techniques such as direct observation, user interviews, prototyping, creating a strategy canvas or E-R-R-C grid, and you may capture some of them using a tool like my product vision board. Whatever you do, I suggest that you follow Steve Blank’s advice and “get out of the building”. Meeting users and customers, at least in form of a video call, not only helps you validate your assumptions and develop new ideas. It also allows you to empathise with the individuals and to better understand their perspectives and needs.
I find it helpful to distinguish two types of product discovery: timeboxed and continuous discovery. Let’s look at timeboxed product discovery first.
Timeboxed Product Discovery
Whenever you create a brand-new product or when you make bigger changes to an existing one, like taking it to a new market, you will benefit from using a dedicated, timeboxed product discovery period. This results in an innovation process like the one shown in the picture below.
In the picture above, product discovery precedes product development. The former focuses on understanding if and why a product should be created or updated. The latter largely determines how the product should be developed. This includes discovering the right UX design and functionality and making the right technical decisions.
Note that I have purposefully drawn discovery and development as overlapping, as I find it helpful to address major UX and technical risks as part of the discovery work — without making the mistake of using big design upfront (BDU). Addressing these risks ensures that the development team has the right knowledge to hit the ground running when starting development. Consequently, the key discovery deliverables include the following:
- Validated product strategy and business model,
- Actionable product roadmap that implements the strategy,
- Initial product backlog that captures the necessary product details,
- A high-level UX design concept and coarse-grained software architecture supplemented by throwaway prototypes (spikes).
As it’s notoriously difficult to correctly forecast how much time a bigger piece of discovery work will require, I recommend timeboxing the product discovery work. To do so, consider the amount of innovation and risk present and allocate an appropriate timebox. If you were to develop a brand-new product for a new market with new technologies, for instance, then you would face more risks compared to taking an existing product to a new market. Consequently, the former will require more time than the latter. You might want to allocate, say, two months for the first initiative, but only two weeks for the latter, assuming that you already serve the new target market. Additionally, I recommend running weekly review sessions to understand the progress of the discovery work and adapt it if necessary.
To carry out the discovery work, bring together the right people, product person, development team representative, key stakeholders, and Scrum Master or agile coach, as shown in the picture below.
As the person in charge of the product, you should lead the discovery and development effort. Here’s why: You can’t be responsible for maximising the value a product creates if you don’t actively participate in, guide the discovery work, and shape the strategic product decisions.
Development team representatives — ideally a UX designer, one or two developers, and a tester — should also engage in the discovery activities. This leverages the individuals’ knowledge and creativity; it surfaces feasibility issues and technical risks; and it allows the team members acquire knowledge about the market and users and understand why the product is being created or updated. The latter will enable the development team to make the right design and technical decisions and own the solution. Do make sure that the individuals continue to work on the team in development and help build the product. Otherwise, you are likely to lose precious knowledge and time.
Inviting the key stakeholders to participate in the product discovery work ensures that their ideas and concerns are taken into account at an early stage; it takes advantage of their expertise; and it maximises the chances that they will support the resulting strategic product decisions: When people are given the opportunity to contribute to a decision, they are more likely to understand and buy into it.
The Scrum Master or agile coach, finally, should facilitate the discovery process and the meetings in order to ensure that everybody is heard, and nobody dominates. This may include suggesting applying a Kanban-based process to visualise and manage the discovery and strategy work, as I recommend in my book Strategize.
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/a-brief-guide-to-product-discovery/
Learn More
You can learn more about product discovery by attending my product strategy and roadmap training course and reading my book Strategize.
Source: https://www.romanpichler.com/blog/a-brief-guide-to-product-discovery/
