How to succeed with your next Product Discovery

Product Discovery Framework

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 need to be solved and in which way to generate the biggest impact?

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

Why do a Product Discovery at all?

In a nutshell, 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 which needs to be built.
Particularly in the beginning of a discovery, you need to stay focussed 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 down a discovery 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 in order to have all the puzzle pieces be aligned when it comes to building your product certainly is.

How to structure your Product Discovery

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 tool box 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 name the key stakeholders, make a commitment to timing and let’s 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 of a discovery is easy to compare with an as broad as possible bird’s-eye view on the topic. You should take one or multiple steps back, involve a lot of smart people which 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), 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 for the discovery, you should gather the most prominent experts for this project around you and approach the real concept together with them.

This phase is about focussed and intense work in dedicated groups around the key user problems to crack. You’ll product a ton of outcome in 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 is focused 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 on 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?

Which Tools to use

An Example Impact Map for your Product Discovery
Image by impactmapping.org

As a Product Manager, you’re probably able to orchestrate a broad range of discovery tools in order to get the right answers for the different questions a product discovery brings with it.

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 of your discovery 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. I’ll also put up a post looking at the Impact Map in specific later on. Sign up here to not miss-out on it.

During the second phase of your product discovery, 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 user contacts as possible with a clickdummy/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.

Whom to involve in a Product Discovery

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. Key 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 involved 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.

Set a Timeline right from the start. Even when you’re going to miss it.

When you can take the time to split a discovery up into different phases, it’s important to not lose sight of the timeline your on 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.

Which Deliverables matter during your Discovery

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 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 discovery phase, it’s rather easy to define specific deliverables for every stage of the product discovery 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 can 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-maile 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

Summary

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

I hope you can get a lot of value out of this summary and succeed with your next product discovery.
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 via mail or on Twitter – I always love to see my assumptions challenged and get new input from other people.

Further resources around Product Discovery Tools (WIP)