Photo by Rob Bye, courtesy of Unsplash

Product Discovery Tips

Published on 9th January 2018

Last Updated on: September 15, 2021

Product discovery refers to the activities required to determine if and why a product should be developed. Carrying out this work makes it more likely to create a product that users want and need. In this article, I share my recommendations to help you reflect on and improve your product discovery work.

Bring the Right People Together

Product discovery is a team sport. You should therefore involve the right people in the discovery work and secure enough of their time. I find it helpful to form a product discovery team that consists of:

  • Development team members: user experience (UX) designer, developer, tester;
  • Key stakeholders, for example, representatives from marketing, sales, and support;
  • A Scrum Master or agile coach.

Involving others in the discovery work allows you to leverage their knowledge and expertise, builds rapport, and creates support for key product decisions including the selection of a specific market segment and stand-out features.

A UX designer, for example, might help you observe and interview users; and a developer and tester might advise you on technical feasibility, identify technical risks, and build prototypes; a sales rep might get you in touch with prospective customers and help you with competitor research; a Scrum Master might facilitate collaboration and advise on process issues—for instance, which process and tools should be best used to visualize and track the discovery work. (I prefer to use a Kanban-based process and a Kanban board to organise product discovery and strategy validation work, as I discuss in my book Strategize in more detail.)


Focus on Problem Validation, not Solution Building

Your product discovery work should focus on nailing the value proposition, target group, business goals, business model, and stand-out features of the product—not on writing user stories, designing the user interface, or building the actual solution. Your goal should be to mitigate the risk of building a product nobody wants and needs, not to figure out the product details.

Having said that, it’s ok to address key UX and technology risks and evaluate important user interaction and architecture options as part of the discovery work. But the bulk of the UX design, user story writing, and technology work should be done after you have successfully validated the problem.

To get your focus right, consider using a tool like my Product Vision Board to capture your idea, and identify assumptions and risks.


Do Just-Enough Product Discovery Work

Minimise the amount of time you spend on product discovery in order to accelerate time-to-market. You should aim to get a good enough product out as fast as possible, and then adapt it to the market feedback. There is no way to guarantee that the product strategy and business model are spot on, and that the new product or next version will be a success.

But don’t rush the necessary work, and resist the temptation to jump start building the actual product. Explore the key assumptions and risks in your product strategy and business model by systematically testing and addressing them in an iterative fashion using, for example, observations, interviews, surveys, and prototypes.

If you can’t confidently state why people are going to use your product, who those individuals are, what makes your product stand out from the crowd, and why it’s worthwhile for your business to develop and provide the product, then you are not in a position to build the actual solution. Instead, continue the discovery work (persevere or pivot), or stop and move on to another product idea.


Talk to the Users

With all the product discovery work that needs to happen, it can be easy to lose sight of the most important success factor—the people who are going to use the product. There is no point in coming up with a smart business model and sophisticated user interactions, if you don’t understand the user needs, what they may struggle with, what works well for them, and what doesn’t. If the users don’t need your product or if they find it hard to use it, then you will find it hard to monetise it and achieve product success.

Therefore, get out of the building, as Steve Blank recommends, and meet target users face-to-face, be it online or onsite. I know that’s not always easy. But to succeed with product discovery, I find it paramount that you—the person in charge of the product—carry out user research yourself and develop a deep understanding of the user needs.

When communicating with users, take a genuine interest in the people you meet. Listen attentively and let go of preconceived ideas about the problem you think the users have or the solution you believe they need. This allows you to discover what people really want and need thereby maximise the chances of creating a successful product.


Don’t Handoff Product Discovery Work

I’ve seen more than company where a group of people carried out the product discovery work and then handed it of to another group who would deliver the product. But handing off the discovery work is ineffective and wasteful: It requires detailing the knowledge acquired in form reports and other artefacts. This is time-consuming, and it is likely to lead to misunderstandings and loss of knowledge—it is hard to precisely capture the discovery learnings, and written information is open to misinterpretation. In the worst case, the individuals tasked with delivery don’t understand and support the decisions taken during the discovery work, but do what they believe is right.

Therefore, avoid using separate discovery and delivery teams. Ensure that the people tasked with product discovery also participate in developing the actual solution. The UX designer, developer, tester involved in discovery should continue to work on the development team; the stakeholders who participated in the work should continue to be involved and regularly attend product strategy and roadmap reviews, as well as sprint review meetings. This speeds up the product innovation process, creates a smooth transition from discovery to delivery activities, and avoids the issues mentioned above.


Consider Timeboxing the Product Discovery Activities

Knowing upfront how much time and effort will be required to carry out the necessary discovery work can be tricky, particularly when you develop a brand-new product and when you make a big change to an existing one, for example, to extend its life cycle. Luckily, there is a straightforward solution: timebox your product discovery work.

A time box is a fixed period of time, such as one week, that cannot be extended. At the end of the time box, the work stops, and you reflect on what has been achieved. If the work has not been completed, and your product strategy and business model still contain significant risks, you have two options: add another time box—and possibly pivot—or stop the work.

Consider holding weekly review meetings that involve the people carrying out the validation work as well as the management sponsor. Use the meetings to reflect on the risks that are being addressed and the learnings that you have achieved; consider the risks that still exist in your product strategy and business model; and decide if and how to continue.


Don’t Limit Product Discovery to New Products

While the traditional usage of the term suggests that product discovery is the first stage in a new-product development process (as in Cooper’s Stage-Gate™ process), it would be a mistake to limit it to new products.

As your product grows and matures, its value proposition, market, stand-out features, and business model will change. To make and keep your product successful, it is paramount that you practice continuous product discovery and regularly review and adjust your product strategy, roadmap, and business model. These adjustments sometimes require little or no product discovery work.

But when bigger changes are required, such as, taking your product to a new market or adding features and redesigning the user experience to sustain growth, you’ll likely have to carry out specific discovery work, as the picture below shows. If that’s the case, then I recommend anticipating the work and stating it on your product roadmap.

Product discovery effort across the product life cycle

Modern product discovery is hence best understood as a set of activities rather than a clear-cut phase that is separated by a milestone or gate from building the actual solution.

Post a Comment or Ask a Question

6 Comments

  • Mohamed Maqsood says:

    Hi Roman,

    I enjoy reading your articles and thank you – I’ve gained so much knowledge! I am wondering when it comes to product discovery, is there a format that you personally follow to document it?

    I’ve seen some team documenting it in plain text in a wiki pages, some use diagrams in between, some use tables to clearly point out what each individual in the team worked on which topic and in some cases, I’ve seen team using slides.

    I want to know what’s your preference? Is there a template that you follow?

    Thank you,
    MS

    • Roman Pichler says:

      Hi Mohamed,

      Thank you for your feedback and question. I like to work with a tool like my Product Vision Board to capture the vision and strategy of the product and a Kanaban board to manage the product discovery work. (I explain in more detail how I use these tools in my book Strategize.) But I recommend that you use the product discovery processes and tools that work best for you. This may require a bit of experimentation. Additionally, ensure that you involve the key stakeholders and development team members in the work. This frees you from having to document all your decisions in detail.

      Hope this helps!

  • WOLFF says:

    Very good article on the MVP … I think to add it to the bibliography that I distribute to my students. Very clear, synthetic, all the qualities!

  • Namrata says:

    Informative as always. I am huge fan of you Roman. Have read all your books, articles and use product canvas the maximum in my projects

    • Roman Pichler says:

      Thank you for your kind feedback Namrata. I am glad that you find my work helpful.

Leave a Reply

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