Product Discovery – A Step-by-Step guide (incl. FREE Planning Template)

Product Discovery Framework

Nailing the Product Discovery is an ambitious task for every product manager. Here‘s a hands-on plan for approaching it.

When the roadmaps for the year ahead get crafted, you should place the topics you and your team want to tackle on a timeline.
Most often, the topics result from the epics you’ve worked on before, user feedback or top-down business goals for your department.

So it’s mostly pretty clear what to work on from a high-level perspective. But the remaining questions for you as a Product Manager are which problem exactly needs to be solved next and how can you generate the biggest impact?

This is the point at which a well-prepared and insightful product discovery enters the stage.

Product Discovery Definition

In a nutshell, a product discovery is about ensuring that the right product gets built for the right audience.
It’s the foundation for a successful implementation and launch phase later on and should give you as the owner of the product the confidence to represent your product vision towards your team, your stakeholders, and the upper management.

You’ll quickly notice that, as soon as you discuss your upcoming roadmap topic with anybody, a lot of people will have a strong opinion about the ‘right’ solution.
Particularly in the beginning of a product discovery, you need to stay focused on the problem and avoid falling in love with a solution. The opposite would be to eventually build someone else’s product with which you cannot identify over time and for which you don’t want to stand in for.

So, it’s pretty important to nail it down the right way. Most often, the problem to crack is not even the hardest part here, but orchestrating the available resources in a given period is.

Product Discovery Process

At XING, product management is part of the company’s DNA. This attitude and high ambition level resulted in several product-related initiatives to broaden a product manager’s toolbox for tackling the daily challenges we face.
After focussing on clarifying the intent of a project, we took a deep dive into the so important product discovery phase. The result was a sort of framework from my colleagues Cord, Marc and Sebastian.

Product Discovery Framework
Get the template as fully scalable .pdf right here

This template is a perfect starting point when planning your next product discovery. It divides the time ahead into 3 phases with different levels of granularity and ‘forces’ you to name the key stakeholders, make a commitment to timing and lets you focus on concrete outcomes already in the discovery phase.

Let’s go briefly through the single sections, discussing their context and giving you some examples regarding what to use at which point.

Phase 1 – Goal, Ideation & high-level concept

Phase 1 for you Product Discovery: Goal, Ideation & high-level concept

The first phase is easy to compare with an as large as possible bird’s-eye view on the topic. You should take one or multiple steps back, involve a lot of smart people who can bring an additional angle to the table and let yourself go through various approaches multiple teams.

By the end of it, you and the key stakeholders should have laser-sharp understanding about the goal you want to achieve (more about how to approach that in the Tools section below), gathered all the qualitative and quantitative indicators you may need and ideally have clarified as many impediments as possible, so there are no excuses left for getting shit done in the following phases.

Here are some key questions you should be able to answer after this phase:

  • What problem will your product solve?
  • How do you identify a good solution (e.g. metrics)?
  • How big is the opportunity?
  • What is the plan for the discovery?

Phase 2 – Hypothesis & Test

Phase 2 of your Product Discovery: Hypothesis & Test

After setting the stage, you should gather the most prominent experts for this project around you and approach the real concept together with them.

This phase is about focused and intense work in dedicated groups around the key user problems to crack. You’ll produce a ton of outcome in the form of prototypes just to throw 90% of them into the trash after talking to your users. And then do it all over again.
See the point? While the first phase focusses on solving a lot of meta topics, the hypothesis & test phase should give you the first solid confirmation that you’re on the right track.

You probably won’t involve many stakeholders besides the core team, but you’ll keep them informed and should at least once check-in with them in the process when you’re halfway and almost done.

Here are some key questions you should be able to answer after this phase:

  • What are the hypotheses you want to test?
  • What do you prioritize?
  • How to make tests usable?

Phase 3 – Requirements & Synthesis

Phase 3 of your Product Discovery: Requirements & Synthesis

Now it’s time to filter what you’ve produced in the second phase, crunch it together and make some decisions about what to pursue in your way of starting development.

It’s a good checkpoint to sync the produced output against your intent from the start and take may needed adjustments – on both ends.

While seeming seductively smooth, you shouldn’t underestimate this phase. It’s the time during which you have to stand-in for the taken decisions and defend your concept against may occurring concerns from all sides.
Those nitty-gritty discussions will especially appear while adding the final touches to the Visual Design and estimating first tickets with your whole engineering team. Those tasks usually require a lot of your intention, and you shouldn’t be occupied with zooming out too much of the topic just to counter someone’s arguments.

Here are some key questions you should be able to answer after this phase:

  • What does the solution look like for the customer?

Product Discovery Tools

An Example Impact Map for your Product Discovery
Image by

As a Product Manager, you’re probably able to orchestrate a broad range of tools to get the right answers to the different questions you have to answer along the way.

The trick is, of course, to not just apply them randomly depending on your mood or the hipness of a particular tool. In fact, most tools only work best in a certain phase and are not universally applicable.

It’s, for example, a pretty good idea to get everybody on the same page by writing an ACE in the first phase of your product discovery, instead of trying to hectically achieve stakeholder alignment when you’re in the middle finalizing the Visual Design.

When formulating the goals of a project, you probably want to take a deep-dive into existing analytics as early as possible, so you not only get critical insights into the status quo while doing first user tests.
Other great tools for the ‘Goal, Ideation & high-level concept’ phase are e.g. the Jobs-to-be-done framework, a User Storyboard, a Marketing Position Paper or an Impact Map.

Hint: I also created a high-resolution impact mapping template to use right away for your own map.

During the second phase, it’s all about producing output and validating it as lightweight as possible.
You maybe want to consider a focussed Design Sprint with the relevant stakeholders for a bunch of rapid prototyping or co-creation sessions with your target group to build the product close to their needs.

The art of validation is executed best when you can avoid ‘wasting’ engineering resources before having more proof. So you should search as many contacts with users as possible with a click dummy/prototype. Good ways to reach your users during this phase are either guerilla sessions at your local coffee shop, putting together an e-mail presenting the core mechanic or just perform a specifically recruited user interview.

Another Impact Map or User Story Mapping are neat ways for bringing your discovery output together in a structured way when approaching the start of development.

Product Discovery Teams

While your development team is probably in a pretty solid state, the range of people which matter during the different phases of your discovery is not.

That’s why it’s wise to create an overview of the people you need to just keep in the loop along the way or which are critical gatekeepers you need to have aligned with your plans.

It depends on the size of your company, but a differentiation between the actual (value-producing) core team, key stakeholders (owning the budget) and certain individuals who own mission-critical assets has proven to be quite useful.
Examples of the core team are Product Owners, dedicated designers, and engineers. The primary stakeholders are mostly impersonated as Product Directors or even VPs. Besides that, you might want to watch out for horizontally located POs in associated domain topics or universally dedicated teams like customer care or Business Intelligence.

Obviously, you should always be clear about the prioritization of those group of colleagues. Nobody should expect equal involvement at every phase.

Product Discovery Planning

When you can take the time to split a discovery up into different phases, it’s important not to lose sight of the timeline you’re committed to.
Even when your project has more of an explorative character, you shouldn’t just go along without considering how much time is reasonably spent on each phase.

And you also shouldn’t feel bad to just set your best guess as a first estimate for timings. Don’t think of milestones as limitations, but rather use them as constraints which will give you as the Product Owner the best arguments for condensing the generated output into concrete deliverables.
It’s also a good mechanic to frame the scope of the project for the people you work with.

Don’t be scared of moving the milestones you’ve set if you have to and if you can provide convincing arguments. Your initial estimation could only have been based on the situation as you knew it ‘back then.’
If the situation has changed in the meantime, it’s more than fair to communicate the impact of this change to your key stakeholders – As long as you do it early on and are transparent about the impact.

Product Discovery Results

Deliverables of a Product Discovery

When defining the timeline, the needed days, weeks or months are determined by some given constraints like available resources or outside-driven events like press releases.
When it comes to measuring the success of a product discovery, and it’s initial phases, you can apply the same rules as for the overall project when you’ve shipped something: A product will only be as good as the outcome it generates.

While it’s difficult to put concrete measures on the results of a single phase, it’s rather easy to define specific deliverables for every stage you want to accomplish.
Having tangible objects to check off after each phase also prevents you from just moving along for the sake of the timeline.

For creating a convincing story within your discovery, the produced deliverables should always lay the foundation for the first step in the next phase.

Here are some examples you may re-use for your planning of the single discovery phases:

  • After phase 1: Agreed and committed ACE, Analytics deep-dive or user survey, concrete hypotheses for the final product
  • After phase 2: Agreed concept including release packages, Clickable prototypes, quantitative or qualitative validation of your hypotheses via user interviews or e-mail experiments, Planned AB-tests
  • After phase 3: A mapped user journey through your product, Final visual design for first stories, Groomed and estimated tickets in your backlog, Defined implementation of tracking


Planning your product discovery might seem like a bureaucratic overhead to you, especially in the beginning when you just want to get going and produce stuff.
But especially for products which either include a complex stakeholder environment or provide a hard problem to crack, this upfront invested time will help you along the way.

The main benefit of a neatly planned discovery is simply better output and a drastically increased chance of achieving your outcome goals.
Seemingly more like a side effect, but not less important: It’ll be so much easier for you to make progress visible to your stakeholders along the way so you can focus on the important things which matter to you.

If you’d like to discuss the provided framework or want to know more about how product discoveries are performed at XING, hit me up using the chat on the lower right or on Twitter – I always love to see my assumptions challenged and get new input from other people.

Additional Resources

One thought on “Product Discovery – A Step-by-Step guide (incl. FREE Planning Template)”

  1. Great article! I can truly agree with user story mapping can work for product discovery. Let me suggest our user story mapping and product discovery tool, called StoriesOnBoard. It contains the right features for online co-operative product discovery process. Moreover it contains lot of education stuff for beginners. The tool can be integrated to the most project management software (JIRA, Trello, Azure DevOps, GitHub etc…), so you can jump into the dev process after a product discovery session. https:/

Leave a Reply

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