TL;DR:
The mistake: Treating discovery as a survey to confirm what you already want to build.
The fix: Filter out non-customers entirely. Run sessions built around user tasks and past behavior, not hypothetical opinions.
The tool: Use the embedded session blocks below to force observation over opinion.
Founders often run product discovery as confirmation theater. They arrive with a strong belief about the customer. Sometimes they even claim, "We have no competitors." Then they demo a prototype, ask if the user likes it, and log the polite nods as evidence.
They fill out a document instead of forcing themselves to face reality.
A good discovery session breaks this habit. A simple prototype or session should push you to a point where you realize you thought about the problem wrong.
What is a product discovery template?
A product discovery template is a framework for running user sessions. It forces you to collect evidence instead of opinions. It organizes a session into clear objectives, hypotheses, user tasks, and observation criteria. This stops you from validating your own biases and keeps the focus on the customer's actual behavior.
The Participant Source Check
Before you use any framework, you have to filter your sources. Non-customer opinions are mostly noise. If you listen to mentors, bystanders, or general industry professionals, you will build the wrong product.
When researching the customer voice, your goal is not to find current buyers. You want to find people who describe the underlying problem, or who use competitors and face that problem.
Before you accept any feedback, tag the source. Sort every participant into one of four buckets:
Target customer
Problem-described
Competitor-user
Non-customer noise
Discard the fourth bucket entirely. The only feedback that matters comes from your specific target audience.
Swipe this session structure
This is not a downloadable worksheet to fill out after a call. It is a set of embedded session blocks to run your discovery conversations.
A product discovery template should not substitute for your judgment. These blocks help separate broader customer discovery from feature-level product discovery by focusing strictly on workflows.
Block 1: Session Objective
Define exactly who you are observing and what workflow matters.
Target user: [Insert specific ICP role]
Workflow to observe: [Insert exact process, e.g., "dispatchers updating delivery status"]
Goal: [What you need to understand, e.g., "Map the exact moment they switch context between CRM and routing tools"]
Block 2: Hypothesis
Measure how often users hit an edge case and how costly the failure is.
Assumed pain: [Insert specific pain point]
Cost of failure: [Time, money, or lost data]
Success state: [What changes if the pain is solved]
Block 3: User Task
Give the user a concrete task and ask them to show you what they do.
Prompt: "Show me the last time [X] happened."
Action: "Walk me through the exact clicks you made to fix it."
Current tools: "What tools did you have open?"
Block 4: Observation Criteria
Watch what they do instead of summarizing what they say.
Past behavior: Did they use a manual workaround (like sticky notes or Slack)?
Frequency: How often does this happen?
Friction: Was the workaround effortless muscle memory, or did they express active frustration?
Block 5: Evidence Decision
Make a concrete decision immediately after the session.
Accept: The pain is frequent and costly enough to change behavior.
Reject: The pain is real, but the cost is too low to force a switch.
Keep testing: Need more observations to understand the workflow.
Fixing Bad Product Discovery Interview Questions
Founders love asking customers, "What do you think about it?" and "How do you like it?" These prompts force polite lies instead of actionable insights.
Do not study hypotheticals. Study their past performance and behavior. Try to understand why they behaved in a certain manner. Upgrading your product discovery interview questions stops you from building a feature just because it sounds useful in theory.
Bad prompt | Better prompt | What it reveals |
|---|---|---|
"Would you use this feature?" | "When did this problem last happen?" | If the problem is real or imaginary. |
"What do you think of this idea?" | "What did you do the last time this broke?" | Actual past behavior and workarounds. |
"How much would you pay for this?" | "What did your current solution cost you?" | Concrete budget and pain levels. |
Asking better questions is central to lean product discovery for B2B. To dive deeper into structuring these conversations, NNGroup provides a strong guide on user interviews.
Keep the Template Simple
Founders often ruin discovery templates when they turn them into polished opinion surveys or highly scalable processes.
Early discovery is not about impressing anyone. The goal is to get a deep understanding of who your customer is. You want to work with them, understand their workflow, and map their team dynamics. That context is the advantage that makes a product hard for copycats to beat.
Use the template to block bad questions. Forcing a focus on past behavior helps you avoid opinion-led UX feedback. If you want more frameworks for uncovering this behavior, The Mom Test offers an excellent breakdown of how to talk to customers when everyone is lying to you.
Bridge to Broader Discovery
A great product discovery session ensures you build the right features. But those features must fit into a larger business model.
The Silicon Valley Product Group notes that discovery tackles risks early. One of those risks is whether buyers will understand your value. Once your feature direction is clear, ensure your broader messaging aligns with the value you discovered. A single feature-level template is just the starting point; you need a full customer discovery process to validate the market, test messaging, and confirm pricing.
FAQ
What should a product discovery template include?
A strong template includes clear session objectives, hypotheses, user tasks, observation criteria, and a final evidence decision. It should force you to look at past behavior rather than future intent.
Why use a product discovery template instead of just asking users what they think?
Because founder-led discovery easily creates polite lies, and AI makes it faster to build things people do not need. The template forces a session structure around past behavior rather than hypothetical opinions.
How many sessions should I run?
Stop when you stop hearing new things. If you are hearing the exact same workarounds and pain points from your target customers, you have enough evidence to make a decision.
What if the user asks for a specific feature?
Do not blindly add it to a wishlist. Ask them what they are trying to accomplish with that feature, and how they handle the task today. Dig into the workflow, not the feature request.
