A Brief Guide to Product Discovery

Photo by Clark Tibbs on Unsplash

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.

Continuous Product Discovery

As helpful as timeboxed product discovery is, it is not enough. Here is why: When you create a brand-new product, you typically aim to launch a minimum viable product (MVP), a good enough offering that addresses the early market. To achieve product-market fit and make the product successful, more discovery work is required: You now need to figure out how to adapt your product to serve the needs of the mainstream market. But even once you’ve entered the growth stage, you can’t afford to neglect discovery. The world doesn’t stand still: Markets and technologies change, competitors improve their products, and new market entrants may appear.

Product management is therefore like riding a bike: When I am on my bike — which is one of my favourite pastime activities — I have to turn the cranks, change gears, steer the bike, and so on. But if I forget to look ahead, I’ll sooner or later get lost or even crash. The same is true for your product: If you are completely immersed in execution and forget about discovery, you’re likely to miss an opportunity or threat and experience difficulties further down the line.

It is therefore important that you carry out continuous product discovery. This includes the following activities:

• Review the product performance using the appropriate key performance indicators. Analyse the data collected to understand how your product is doing. Do the metrics show a positive, flat, or negative trend? What conclusions can you draw from the analysis? What measures would help you achieve the desired product performance?
• Look for opportunities. Are there any new technology, regulatory, or social trends that you should be aware of? Do they offer an opportunity to innovate, add, remove, or enhance product features, or even create a brand-new product? Talking to users, attending trade shows and conferences, and participating in the online communities can help you spot new trends. Giving the dev team time to investigate new technologies will allow you to take advantage of opportunities and improve your product.
• Keep an eye on the competition. Are your competitors launching new products or features? Are there any new market entrants? Should you respond to any of these changes? If so, which actions are appropriate? Job postings can help you guess your competitors’ plans. Reviewing their products will tell you if your product is still sufficiently differentiated.
• Follow the developments at your own company: Are there any changes to the business strategy? And if so, what are the consequences for your product?

To help you answer the questions above and carry out the related work, I recommend the following two measures:

First, block at least one hour per day in your calendar to carry out product discovery and strategy work. This helps you avoid nasty surprises, such as a competitor leapfrogging you by offering a new killer feature, and it makes it more likely that you recognise early warning signs like declining sign-up rates, increasing churn, or growing number of support calls. This allows you to be responsive and take actions early.

Second, regularly hold collaborative strategy reviews, once per quarter, as a rule of thumb. Assess the product strategy and product roadmap together with development team representatives and key stakeholders. These are ideally the same people who participated in the timeboxed discovery work and who helped you create the current product strategy and roadmap. As mentioned before, involving dev team members and stakeholders leverages their collective creativity and knowledge, creates alignment, and mitigates the risk that the individuals don’t support necessary strategy changes.

A Few Thoughts on Product Discovery in a Scaled Environment

If you manage a larger product and you work in a scaled environment, don’t forget to involve the other people who look after the product, for example, feature and component owners or SAFe product owners, in both timeboxed and continuous discovery.

In addition to the collaboration benefits already mentioned, this makes it more likely that strategic decisions will be translated into tactical ones, and it ensures that tactical insights — like the knowledge gained from analysing user feedback on specific features — informs the strategic decisions.

Learn More

You can learn more about product discovery by attending my product strategy and roadmap training course and reading my book Strategize.