Introduction
"Would you use a feature that does this?" is one of the most common questions in customer interviews, and one of the least useful. Almost everyone says yes, and the answer tells you very little about what they'll do.
A team can run interviews, surveys, and roadmap reviews, and the loudest voice in the room can still decide what ships. CB Insights' review of more than 110 startup failure postmortems found "no market need" cited in 35% of cases.
That doesn't show that weak interviews caused those failures. It does suggest that skipping real problem investigation is common, and costly.
Good product discovery questions bring out actual customer problems, behavior, context, alternatives, and desired outcomes. That gives you observations of what people actually do, not just opinions, when you decide what to build.
This article covers a framework for writing stronger questions, examples organized by discovery stage, the mistakes that undermine interviews, and a method for turning answers into decisions you can still explain months later.
Key Takeaways
- Investigate real problems and recent behavior before discussing features or solutions.
- Start open-ended, then probe for frequency, impact, and context before asking closed questions.
- Record each observation, the claims it bears on, and the decision each answer informs.
- Treat discovery as a loop: outcomes from shipped work become evidence for the next bet.
The Product Discovery Question Framework
A strong discovery conversation moves from broad context to specific observations. Jump straight to "would you use this feature?" and all you'll collect is polite guesses.
The Five-Part Question Ladder
Structure conversations around five moves, in order:
- Understand the person and situation: role, environment, and constraints.
- Identify the problem: what's actually going wrong.
- Examine current behavior and workarounds: what they do about it today.
- Assess impact and urgency: what it costs them.
- Define the desired outcome: what success would look like.
Skip a rung, and later answers get harder to interpret. If you don't know someone's role or workflow, you can't tell whether a complaint is a niche annoyance or a company-wide problem.
Matching Question Types to the Moment
Not every question belongs at every stage:
- Open-ended questions let participants describe goals, workflows, and problems in their own words. Use these first.
- Probing questions dig into a specific example: causes, consequences, and the decision behind an answer.
- Focused or closed questions compare patterns across participants, but only once you understand the context.
Product Talk's guidance on story-based interviews recommends this kind of sequencing: anchor the conversation in one specific past incident, then return to it when someone generalizes. Ask "what happened the last time this went wrong," not "would you use a dashboard that tracks this."
Tailor Questions by Participant
The same topic needs different questions depending on who's answering:
| Participant | What they reveal |
|---|---|
| End users | Actual workflows and daily friction |
| Buyers | Evaluation criteria and purchase triggers |
| Customer-facing teams | Recurring signals across many accounts |
| Internal stakeholders | Strategic constraints and trade-offs |
Before you run the research, attach every question to a decision it should inform. Most discovery questions map to one of these:
- Which problem to pursue
- Whose problem it is
- Whether it's worth solving
- Which solution to try
- Whether to keep going, or whether it worked
If a question doesn't inform any of these, cut it from the guide.
Questions to Ask at Each Stage of Product Discovery
The question set should shift as you move from problem exploration to testing and prioritization. Here's what to ask at each stage, and why.
Define the User, Situation, and Desired Outcome
Start broad:
- "Who is involved in this workflow?"
- "What are you trying to accomplish?"
- "When does this situation usually occur?"
- "What does a successful outcome look like?"
Role, environment, frequency, constraints, and desired outcomes give you context for everything that follows. Skip this step and a power user's complaint gets treated the same as feedback from someone who touches the product once a month.
Understand the Problem and Current Workflow
Get specific:
- "Walk me through the last time you encountered this problem."
- "What were you trying to do?"
- "What happened next?"
Probe the current process: tools, handoffs, delays, workarounds, and where the user has to compromise. If someone asks for a feature outright, ask what that change would help them accomplish. The request and the underlying problem aren't always the same thing.
An illustration from demo data: FlowDesk is a fictional demo dataset Shorter Loop uses to show the product, set up as a shift-scheduling company selling to mid-sized logistics operators. In the demo data, 11 of 14 churn interviews describe the same pain: the schedule lives in someone else's account, because dispatchers can't get into the product unless a manager buys them a seat.
The demo dataset's original persona has every field filled in and zero interviews attached. Nobody in the story has asked a dispatcher a single question. The same thing can happen on a real team whenever a persona is filled in from sales notes instead of conversations with the people who use the product.
Explore Severity, Impact, and Urgency
Ask:
- "What happens if this problem isn't solved?"
- "How does it affect your team or business?"
- "Why is this important now?"
Impact shows up as lost time, risk, missed opportunities, poor customer experience, or an unmet goal. Back every business-impact claim with evidence beyond the participant's own estimate. People are often wrong about their own time and money.
Learn About Alternatives and Competing Solutions
Ask:
- "How do you solve this today?"
- "What have you tried?"
- "What do you use alongside or instead of this process?"
- "What would make you switch?"
Spreadsheets, manual workarounds, internal processes, delaying the task, and doing nothing all count as alternatives. Named competitors are only part of the picture.
In the FlowDesk demo data, the dispatcher research produces nine claims. Scoring each for importance against uncertainty narrows that list to two worth an actual experiment, which is the same exercise you can run on your own interview findings.
Validate a Possible Direction Without Leading the Participant
Only after the problem is understood, ask:
- "What would improve this workflow?"
- "Which outcome matters most?"
- "What concerns would you have about changing the current process?"
Use prototypes or workflow descriptions here, not earlier. Record what you observed, not whether the reaction was positive. A smile in a usability session isn't demand.
In Shorter Loop, interview notes and other feedback can be uploaded or pulled in from tools like Intercom, Zendesk, and HubSpot, then linked to opportunities on the Tree view in Product Strategy. Each solution on the tree links to the claims it rests on, and each claim carries a state: backed, evidence disagrees, untested, or untested with nothing found. When Sage cannot verify a point, its answer says so, and each answer shows the Supporting evidence list it worked from.
Months later you can still see which answers a decision was built on and what happened after it shipped. Scheduling the sessions and hosting surveys stays with your research tooling.
From an Answer to an Opportunity: A Worked Example
A single interview answer, carried through to something the team can act on.
What the customer said: "I export the schedule to a spreadsheet every Monday and re-check it against the roster by hand, because twice last quarter the roster had someone who had already left."
The observation. Recorded as what happened, not what it means: this person performs a weekly manual reconciliation, triggered by two specific incidents of stale roster data. Keep the quote, the segment, and the date. The temptation is to file this as "wants better exports," which is a solution wearing an observation's clothes.
The opportunity. Across eight more interviews, six describe some version of the same workaround. That pattern becomes an opportunity: operations leads cannot trust roster accuracy, so they rebuild the check manually. It is a problem statement, not a feature.
The claim and its state. The opportunity rests on an assertion: that trust in roster accuracy is what drives the manual work, rather than habit or policy. With six interviews linked, the claim is backed. Had it rested on the single quote above, it would read as untested, and the difference is visible on the item rather than remembered by whoever ran the sessions.
What makes it durable. Six months later, when someone asks why a reconciliation feature is on the roadmap, the chain runs backwards: the roadmap item, the opportunity, the claim, and the interviews it came from. That is the part that usually goes missing, and it is lost at the first step, when an observation gets filed as a feature request.
Where this lives in Shorter Loop. The interview notes go in through Docs with Upload files, or arrive from a connected app such as Fireflies or Dovetail. The opportunity is created in Product Strategy, and the line under its title shows the claim's state, for example "1 claim · 1 backed". To run the same chain on your own interviews, start a 14-day trial; no credit card needed.
How to Avoid Weak Product Discovery Questions
The quality of an answer depends on the question's neutrality, specificity, timing, and connection to a decision.
Leading or Solution-First Wording
Compare these two:
- "Would you use a dashboard that does X?"
- "How do you currently monitor X?"
Harvard Business School Online's guidance on confirmation bias contrasts a leading prompt ("Do you agree our new onboarding is easier?") with a neutral one that doesn't assume the answer.
Asking someone to approve a feature you've already decided to build invites polite agreement, not reliable feedback. Have someone who isn't invested in the outcome review your questions before you run them.
Hypothetical Opinions Instead of Observed Behavior
Replace "Would you pay for this?" with a question about the last time the participant actually paid for, searched for, or adopted a solution to the problem. Future-intent questions still have a place later in the process. Treat the answer as something to investigate, not as evidence that anyone will pay.
Double-Barreled, Vague, or Overly Broad Questions
Ask one thing at a time. Define the object, timeframe, user group, or workflow you're asking about. Follow up with:
- "Can you give me a recent example?"
- "What did you do next?"
- "How often does that happen?"
A question that tries to cover three topics at once usually gets an answer to none of them.
Questions That Invite Feature Lists
Ask about goals, constraints, and outcomes before asking what features someone wants. Capture their exact language and the surrounding context, so a feature request can be checked against the actual problem later instead of being added to a backlog on faith.
Turning Discovery Answers Into Product Decisions
Discovery isn't finished when your notes are a pile of quotes, tickets, or interview summaries. It's finished when each answer connects to a product decision.
From Quote to Structured Insight
Turn a raw answer into something usable by recording:
- The customer segment and situation
- The observed problem
- The source (interview, ticket or call)
- The current workaround
- The consequence
- How confident you are
Then separate facts from interpretation. Label what the participant actually said or did, what your team believes it means, and what's still unknown. That distinction matters months later, when someone asks why a decision was made and "I think someone said that once" isn't a good answer.
Connect Insights to a Decision
Every insight should point somewhere:
- Refine the opportunity
- Prioritize further research
- Test a concept
- Change a roadmap item
- Decline the idea outright
Then build the follow-up loop: define the next experiment, assign an owner, specify what would change the decision, and revisit the result after delivery.
Review discovery observations with product, design, engineering, sales, support, and leadership together. A decision that depends on one person's memory of one interview is easy to second-guess, and can end up being argued again from scratch later.
Before your next interview round, try this check: for each question in your guide, can you name the decision it informs and the answer that would change that decision? If you can't, rewrite or drop the question. To see questions, claims and opportunities linked in the product, book a walkthrough.
Frequently Asked Questions
What are good product discovery questions?
Good questions are open-ended and behavior-based. They focus on goals, recent workflow, problems, current alternatives, impact, and desired outcomes. Probing follow-ups turn a broad first answer into an observation you can act on.
How do several PMs keep interview findings in one place?
Agree on where findings live and what a finding has to carry before anyone files it: the source, the segment, the date, and the actual words the customer used. Most shared repositories fail on the second part rather than the first, because a summary stripped of its quote and its context cannot be re-read by someone who was not in the room. Make the store searchable before the next round of interviews is booked, and make checking it the first step of planning a round, so the team stops re-discovering problems it has already observed and stops asking the same question across three separate sessions.
How do you ask product discovery questions without leading the user?
Ask about recent behavior and real examples instead of hypothetical scenarios. Avoid naming your preferred solution, use neutral wording, and follow up closely on any answer that surprises you.
How do you know whether a product discovery answer is useful?
A useful answer includes specific context, observed behavior, consequences, or alternatives, not just a stated preference. If someone offers an opinion with no example behind it, dig deeper before recording it as an observation.
