An Actionable Guide to Product Discovery: the Workflow I’ve Used at Typeform & N26

Jul 22, 2020 — 15 min read

There’s a lot of theory out there about product discovery. What’s less clear is how it works in someone’s day-to-day. There aren’t many examples of actual “end-to”end” product discovery workflows, so I decided to share mine.

I’ve refined my workflow over the years I spent building products at Typeform and N26. I hope it can be useful for: 

• Newly minted PMs who are overwhelmed with all the tools & techniques and don’t know where to start. 

• Experienced PMs who are looking for new ways of doing things. 

• Folks outside of product management who want to better understand what product managers do all day. 

Here’s what the workflow looks like:

My product discovery workflow consists of three steps:

1. Collect. Collect as many product ideas as possible in an idea bank. A product idea can be as specific as a customer telling you they need a new feature or as vague as your CEO saying “let’s add some machine learning to our product.”  

2. Validate. Research the most promising ideas to validate or discard them. Write down your findings in one central place called the discovery document. 

3. Prioritize. Create a pitch for each validated idea. Prioritize the idea with the most convincing pitch.

In any given week, I work on ideas in all three stages: 

• Collect: looking for new ideas to add to your idea bank. 

• Validate: researching the 4-6 early-stage ideas that seem the most promising. 

• Prioritize: crafting 1 or 2 pitches for ideas you want to prioritize in the near future. 

I’ll go into each step in more detail. It’ll give you enough detail to use the whole workflow starting tomorrow if you’d like. You can also take the parts that seem interesting to you and adapt them to your own context.

Let’s get started!

Step 1: Collect as many ideas as possible into an idea bank

Your goal is to have as many product ideas as possible to choose from. The more ideas you compare against each other, the better your prioritization decisions will be in the end. This is how you maximize your impact as a product manager. 

If you follow this approach, you will quickly find yourself with dozens or even hundreds of product ideas. To deal with such a large number of ideas, I’ve found a simple tool that works like a charm: the idea bank. 

Idea banks

An idea bank is a central place where you store all your product ideas. I use a simple spreadsheet. Here’s what the idea bank for the product manager in charge of an imaginary mobile banking app could look like:

The essence of the idea bank is column C, the solution ideas. Most people will share their ideas with you in the form of a solution: “we should build X” or “I need feature Y.” It’s how most humans think, and that’s okay. Just record the solution idea in your idea bank. 

Once you’ve recorded the solution idea is when you start adding value as a product manager. Ask the person suggesting the idea, “if we built X, how would our customers be better off? How does it fit with our strategic goals?” With the answers to those questions, you can start grouping solution ideas together into larger areas of opportunity (column B in my example), and connect them to your strategic goals (column A). 

I usually add an additional column where I jot down informal reminders about what kind of evidence we have for an idea so far. Ask the requester, “how did you come up with this idea?” and they might tell you it was a customer request, or they saw it in a competitor’s app and liked it, or a friend told them about it. Whatever it is, write it down, as it will give you a place to start when you actually research the idea later.

Where ideas come from

#1. Others share their ideas with you. Most people around you already have plenty of promising product ideas. You can reap the benefits of these ideas if you adopt a mindset of curiosity. Your default response to any idea that comes up should be: “Interesting. Maybe someday.” You don’t want to say “yes” too early and commit to an idea without any evidence to back you up. You also don’t want to say “no” forever to an idea before you fully understand it. You want to come from a place of genuine curiosity and try to understand the why behind the idea. 

#2. Interview your stakeholders to get their product ideas. Many of your stakeholders are domain experts. Customer support and sales people talk to customers all day. Marketers study the market and the competition. Folks in operations have deep domain knowledge. And all of them usually have valuable ideas that can improve your product. Go talk to them. Ask them how they would improve your product, and you’ll be surprised by how creative and innovative everyone around you can be.

#3. Brainstorm yourself. Many companies release “voice of the customer” reports with the most common feature requests: go through these reports and look for interesting ideas. Read trend reports like Mary Meeker’s Internet Trends reports. Sift through your company’s user research repository. Go through Reddit or other community forums. There are countless sources of product ideas if you’re willing to put in the effort and keep an open mind. 

Ideas ≠ features

A last note on product ideas: product ideas don’t have to be features. They can be removing a feature, or improving an existing feature. Too many teams and executives focus on adding more features, hoping that cumulatively, the impact will make them achieve their goals. Spoiler alert: it won’t. Aim for less, but better. Invest time in improving the features you have, and cut the ones that are not used. Think of product ideas as product changes, not features. 

Step 2: Filter your idea bank, and research the most promising ideas to validate or discard them

Since you collect as many ideas as you can find, you’ll end up with dozens or hundreds of ideas in your idea bank. You won’t have enough time to research everything. You have to decide which ideas deserve more research, and which ones don’t. 

Which ideas are worth researching, and which are not

You’ll want to research ideas which: 

1. Align with your team goals 

2. Are relevant for your target customer segment

3. Have high potential upside based on a back-of-the-envelope calculation

4. Showed promising early signals like noticeable customer interest or pressure from above

5. Come up when you ask your team, “what would we be stupid not to do?” 

#1. Team goals. If an idea has no potential to positively impact the metrics that your team is currently focusing on, discard it for now. That’s the kind of strategic thinking which is expected from good product managers: deciding what not to do. If you have well-defined company and team goals, this first filter will rule out the majority of ideas in your idea bank. If you don’t have clear goals, make time and create a basic strategy with goals for your product area. Clear direction and focus are essential for good product management, and discovery is no exception. 

#2. Target customer needs. Is the idea relevant to the needs of the customer segment you’re currently targeting? Let’s assume you work on a SaaS product and your target customer is marketers in small and medium businesses. If someone suggests an integration with an HR tool, you’ll know immediately that you won’t want to spend any time researching it in the near future. This sounds straightforward, but I’m often surprised by how many product teams forget about this second filter. 

#3. High potential upside. Imagine you’re comparing two potential ideas. For the first one, you expect it will bring an uplift of 20% to a step in some funnel. The other idea will improve another conversion rate by only 5%. It’s easy to see which one is better, right? Well… no. If you calculate all the way back to your original success metric, you might find that improving a small number by 20% has less impact in absolute terms than improving a large baseline by 5%. You won’t know until you’ve actually done a quick back-of-the-envelope calculation. Your goal is not to predict an exact number, but an order of magnitude. It’ll make sure you focus on the right parts of your product.

#4. Early signals. Are many customers asking about it? Are your stakeholders especially passionate about it? Are you getting a lot of pressure about a certain idea from an executive or the CEO? In cases where you can’t just say no, instead of saying “yes boss, we’ll build it!” you can say “alright, we will research it and get back to you with what we learn.” 

#5. Team conviction. Before I start defining cycle goals, I ask my team a simple but powerful question: “What would we be stupid not to do?” Especially when you have team members that have been around for long enough to develop domain expertise, you’ll get invaluable answers. Don’t get too hung up on the actual answer, but pay attention to the thinking process and how they arrived at their conclusion. Asking this question has often surfaced promising ideas that we’ve researched and later released. 

Structure your research before going all-in on an idea

I use a simple checklist that makes sure I don’t forget to investigate any essential aspects of an idea. For each product idea, I paste the checklist into a document where I then collect all my findings, which I call a “discovery document.” Everything is in one place, and I can share the outcomes with my team and stakeholders. Each product idea has its own discovery document.

Here’s the checklist:

#1 Problem space

• 1.1 What is the customer problem we’re trying to solve? The better you understand the problem, the better your solution will be. Make sure you also understand the broader context and use case of your customer. Look beyond the functional aspects, and include social and emotional factors as well. 

• 1.2 What are our hypothesis & success metrics? I use the following format: Based on [something you learned] we believe [doing something] for [target customer] will encourage them to [desired outcome]. We will know this when we see [increase/decrease] happen to [success metric]. This will be good for our customers, partners, and our business because [reasoning]. 

#2 Customer insights

• 2.1 Insights from customer research. Add the findings from customer interviews, surveys, tests, and wherever else you collect customer data, and look for signals that either support or contradict the product idea. 

• 2.2 Quantitative usage data. Analyze usage data of your existing customers. If there is a workaround available for the problem you’re thinking to solve, how many customers use it? What other signals can you find in the data? 

• 2.3 Direct feedback from your existing customers. Go through customer support tickets and social media inquiries. Do customers mention the problem you’re trying to solve? Keep in mind that this type of feedback usually represents a vocal minority of customers. 

• 2.4 (optional) Relevant trends and market research. Are there any larger trends that are happening and that relate to your idea? While trends alone won’t tell you if an idea is valuable or not, collecting these insights help when thinking about potential solutions. 

#3 Competitive insights

• 3.1 What are your direct competitors doing? List your most relevant competitors, and find out if and how they are solving the problem you are considering to solve for your own customers. It’s not about copying what others are doing, but it’s important for you to know what people expect in the marketplace. 

• 3.2 What does the user flow look like in other apps? For the competitors who solve the problem you’re investigating, check out the user flows and documentation (landing pages, ads, help center articles). You can learn a lot about how they position the feature and how it fits with their overall offering. 

• 3.3 Lightning demos. What other ideas are out there to solve similar problems? They don’t have to be the same industry or even related to what you’re doing, just look for inspiring ideas that could be remixed and improved. 

#4 Solution ideas

• 4.1 List out all the potential solutions. Stay very high level at this point, and make sure to include pro’s and con’s for each solution idea. Make sure you include tech and design at this stage, and force people to not settle with the most obvious solution. 

• 4.2 Start collecting major risks and potential blockers. People will tell you that a solution might be hard to do because of something? Great, you write it down and you’ll have a starting point when researching the feasibility later on. 

It’s up to you to decide how much time you want to spend in each part, and how deeply you want to research one aspect or another. You can literally copy-paste the checklist above into a document, and start researching your next product idea. 

Tools & techniques for validating product ideas

Now that we have our checklist as the guiding structure for researching ideas, we can talk about which tools & techniques you can use to work through the checklist to validate or discard ideas. 

My favorite tool to validate product ideas is the confidence wheel. It’s like a compass that guides your research: it gives you a level of confidence for each idea, depending on the amount and type of evidence you have collected at that point in time. 

The confidence wheel helps decide how much time to spend on an idea. If you have low confidence, don’t invest too much time yet. Do something quick and cheap, and see if it validates your assumptions. The more your confidence in an idea grows, the more time and effort you invest. The confidence wheel will keep you from spending too much time on bad ideas and force you to follow the objective evidence. 

With the confidence wheel as a compass to guide your research, you’ll need techniques to do the actual validation work. There’s a wealth of idea validation techniques available. They usually don’t require any engineering effort, and the only limitation will be your own time. 

Here are my favorite idea validation techniques. You’ll find links with additional information in case you want to try them: 

Prototypes. Prototypes are essential for idea validation. They simulate the user experience with the intent to answer a specific question so that you can iterate and improve the experience. There are many kinds of prototypes: from clickable mockups you can show to customers all the way to technical proof of concepts written in code. You can learn more about prototyping in this great article written by an Apple and Oculus engineer. If you want to go deeper, I highly recommend the book ‘Sprint’ from Google Ventures.

Qualitative data analysis of customer requests. Go through customer feedback in support tickets, on social media, and in sales conversations. Identify common problems and find out how many people actively ask for the idea you’re evaluating.

Fake door tests. Sometimes also called a smoke test. Without actually building a new idea, you tell customers that the thing exists and ask them to act on it, e.g. to enter their email to access it or to provide their credit card details to buy it. If they do, you know they want it. You can read a great guide by an ex-Googler about this technique here.

Surveys. Surveys are a low-cost way to ask your customers about their attitudes and behaviors. A great way to use surveys is to embed them inside your product. Ask customers how satisfied they are with a certain screen, and route them to a survey where you ask them follow-up questions. You can also use surveys to recruit customers for interviews where you can show them prototypes.

When you visit the ‘Share’ section in the Typeform app, it will ask you for feedback. The image below shows what happens next:

A/B tests. Some ideas require little code but can have great impact: a copy change, rearranging elements on a page, or hiding a screen. This type of idea can be A/B tested easily. You add the new variant to your actual product with little engineering effort and measure the impact with live data. Many growth teams use this technique extensively.

Stakeholder interviews. When it comes to the feasibility and business viability of an idea, interview stakeholders who are domain experts. These could be teams like Legal or Compliance, or tech leads from teams whose code you’d have to touch to implement something new. Share your idea with them. They will point you in the right direction and help you address important risks early on. As a bonus, they will feel more invested in the solution if you involve them early on. 

Reference customers. Pitch your idea to customers, and see if they’re willing to become your reference customers. This means they will be willing to spend time with the product team, testing out early prototypes and helping the team ensure the product works well for them. You can read more about this technique in the classic book ‘Inspired’, along with many more discovery techniques. 

Concierge tests. You provide a new service for very few customers, completely by hand, no technology involved. For example, Wealthfront would work with a handful of customers to provide wealth management advice and portfolio management. They would sit with them, pen and paper in hand, and figure out solutions to wealth management issues step by step. You can read more examples in this article. 

The right technique at the right time

You can use any combination of the techniques. You might use just one single prototype, or a combination of several techniques: it depends on the product idea you’re researching. What matters is not which technique or how many experiments you’ve run, what matters is that you have gathered enough evidence to validate or discard an idea. 

When thinking about what kind of technique you should use, think about which type of risk you’re trying to address: 

There are plenty more techniques out there. Don’t get bogged down by all the buzzwords and frameworks. Follow your curiosity and try promising new techniques, but beware: most are variations of existing techniques because someone wants to sell consulting services or a new book. Treat them as tools to get the real job done: gathering evidence to increase your confidence in an idea’s potential, quickly and without needing code. 

An idea is validated once you and your team have gained enough confidence to say, “Yes, it’s definitely worth investing some of our precious design & engineering time to deliver on this idea.”

Step 3: Summarize your findings into pitches that can be prioritized 

Once we’ve researched an idea, are we done with discovery? Not yet. Before any of your validated ideas can go from discovery into delivery, there’s one step missing: prioritization. Your product idea might be validated in your opinion, but it still has to compete with other product ideas to get built. This means that the last step of product discovery is to facilitate prioritization. 

Prioritization = convincing humans

Prioritization is not an abstract process. It is an exercise in decision making run by actual humans, including all their biases and emotions. Depending on your company and your position, it will be a group of people which might include yourself, your head of product or CPO, the CEO, and other leaders of your company. Since you’re dealing with people, the last step of product discovery is to convince this group of people that the idea you’re suggesting is the best possible option. 

Let’s start with what you should not use as a basis for your prioritization: 

1. Your idea bank. The idea bank is a tool for yourself to record your early thoughts about many different ideas. It’s nowhere near the level of insight you need to have before committing engineering time to an idea.

2. Your discovery documents. Their level of detail is usually too high. You can’t expect executives and stakeholders to read 15 page long documents with all kinds of evidence scattered around. Most importantly, discovery documents are intentionally broad. They explore several related problems, different use cases, and loads of possible solutions. Before you can prioritize, you need to decide exactly what it is you want to prioritize. 

You need a different kind of document. A document that summarizes the findings from the initial research, connects the customer problem to one validated solution idea, and makes a compelling case for why we should build something - I call this document a ‘pitch.’ 

I adopted the name from the team at Basecamp, because it fits perfectly: the name ‘pitch’ expresses that anytime you want to get something prioritized, you are pitching to your company for investment in the form of people and time. 

Pitches

An effective pitch consists of 5 elements. 

#1 Problem: 

• A person’s use case and desired outcome, and the problems with current solutions (use the problem statement from your discovery document). 

#2 Strategic fit: 

• Which of your company’s goals you would positively impact by solving the problem. Tie it back to your product vision and your team’s objectives and key results. 

#3 Solution: 

• A high-level summary of the solution presented in a way that the reader can immediately understand. 

• Answer four questions: (i) Where in the current system does the new thing fit? (ii) How do you get to it? (iii) What are the key components or interactions? and (iv) Where does it take you? 

• Fat marker sketches work great for this. They prevent you from taking too many decisions too early, yet make the solution instantly understandable. 

#4 Risks: What could go wrong, blow up scope, or block your team. 

• Technical risks. Will the team have to touch unfamiliar code? Are there any unknown dependencies? Any security risks? 

• Design risk. Are there any unsolved design problems that appear tricky? Will you need to change or add something to the design system? Are other teams working on the same area of the product? 

• Business viability risk. Are there any legal or compliance risks? Any brand risk? These risks are often showstoppers. Make sure you address them early. 

#5 No-gos: Features or use cases you consciously leave out of scope for now. 

• It’s as important for everyone to understand what you will build as to understand what you will not build. Be crystal clear about what will be included, and what’s not. 

• Be ruthless about cutting scope. Focus on the core of the problem, and de-scope all the rest. You do not want to be ashamed of your first release; you want to be proud of doing the few essential things really well. My guiding principle is “less, but better.” 

The important part is to establish the connection between the customer problem and your proposed solution. Readers should be able to understand the solution immediately. Using pitches, you and the rest of your product organization will be able to make well-informed prioritization decisions by comparing well-researched ideas presented in a way that makes it easy to compare them.

And that’s the end of product discovery. After you prioritize a pitch, the product idea goes into delivery, and your team ships it. 

80% of your work as a product manager is done at this point. The ideas you’ve added to your team’s delivery backlog have gone through a rigorous vetting process: 

1. You didn’t just pick the first idea that came to mind. You collected as many ideas as you could in your idea bank, and consciously chose the most promising ideas based on objective criteria. 

2. You picked the right tools and techniques to research several ideas, followed a proven structure, and documented all your findings. 

3. You summarized all your findings into pitches. You clearly outlined what you want to do - including what you don’t want to do - and enabled your product leadership team to prioritize based on facts, not opinions.