Photo by Clark Tibbs on Unsplash

A Brief Guide to Product Discovery

Published on 6th October 2020

When practiced correctly, product discovery maximises the chances of achieving product success. Unfortunately, I find that it's not uncommon that companies lack an effective product discovery approach. This article offers help. It explains what product discovery is, why it matters, and how it helps you maximise the chances of creating a successful product. It discusses when, how and by whom product discovery should be carried out. Finally, it describes how product discovery helps you progress existing products.

Roman Pichler
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.

product discovery vs product development

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:

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.

Product Discovery Team

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.

Post a Comment or Ask a Question


  • Parvathinathan Venkiteswaran says:

    Hi Roman,

    First things first – big fan! I recently finished reading your book Agile Product Management with Scrum. Every time I read an article by you or an expert in PM, I uncover a new learning which is amazing. That being said, I’m working on a product that was developed to an extent and stopped. I am now the new PO to take this product forward. Being in the middle of knowledge transfer process, I’d like to understand the things I should keep in mind during discovery, strategy and roadmapping. I know the organisation will have their input. But your thoughts will also help learn and be prepared. Thank you in advance. Call me Nathan. 🙂

    • Roman Pichler says:

      Thank you for sharing your feedback and question Nathan. When you take on an existing product I recommend that you:

      • Familiarise yourself with the market / domain the product serves and the category it belongs to, including competing offerings;
      • Talk to (some of the) the users and understand why and how they use the product;
      • Get to know the key stakeholders and dev team members and build trust with them;
      • Review the product strategy, product roadmap, KPIs, business model, and product backlog, preferably together with the stakeholders and dev team reps;
      • Get an overview of the technologies used to build the product.

      Hope this helps!

  • Luke says:

    Hi Roman, you’ve mentioned a validated product strategy and business model is a “deliverable” of the product discovery work, but in order to obtain development team resource and assemble the correct stakeholders would you agree that some of this work will already need to have been completed, making it a “pre-requisite” for discovery (rather than deliverable)? I’m particularly thinking about scenarios when doing product discovery for disruptive innovation type projects (assessing business opportunities) way before a development team is required.

    • Roman Pichler says:

      Hi Luke,

      Thank you for sharing your question. My intention was to recommend assembling a cross-functional team in order to assess a business opportunity and investigate an idea. This team should consist of the person in charge of the (future) product, key stakeholders, and development team members, like a UX designer, developer, and tester. In the case of a brand-new product, the latter should become members of the team responsible for building the actual product.

      To make this approach work, development organisations have to reserve capacity to support innovation/discovery initiatives; developers no longer just implement requirements but help test business ideas. I am not the first one to suggest such an approach btw. Marty Cagan, for instance, suggested in a video published in 2011 a similar setup. Note that the development team members don’t necessarily have to be involved full-time in the discovery work; part-time is often sufficient.

      Having worked for and with a number of large entreprises, my personal experiences with the traditional approach of using a dedicated research group that assesses business opportunities and carries out technology development work has been poor. Even if the group understands the market needs and the capabilities of the development, marketing, and sales organisations, the resulting handoffs usually cause a loss of valuable knowledge. The integrated, cross-functional approach I sketch in the article tries to address these issues.

      Does this help?

      • Luke says:

        Thanks Roman. It does…and FWIW i’m totally bought into the idea of cross-functional teams 100% + reducing handoff’s..but i’m wondering what you would consider to be the prerequisites for starting the discovery, other than just an idea? In my experience big organisations are not short of ideas but often fail to know how/where to start. So in your opinion where does discovery begin and how is it initiated? (Apologies realising my example may be a bit too nuanced for this comment thread!)

        • Roman Pichler says:

          Glad my answer was helpful Luke and great follow-up question! I view an idea generation and selection process as the prerequisite for product discovery. Such a process evaluates ideas for new and significantly enhanced products, often according to strategic fit. This ensures that the idea is aligned with the business and product portfolio strategy. The input of product discovery is therefore an idea, typically one that has been evaluated. Do you agree?

Leave a Reply

Your email address will not be published. Required fields are marked *