Product discovery: a practical process for small SaaS teams

What is product discovery?

Product discovery helps a team learn which changes are worth building. It combines customer evidence, product observations, and focused experiments to reduce uncertainty about a proposed direction. Delivery turns a chosen approach into a dependable experience; discovery continues as new evidence arrives.

Teresa Torres's introduction to modern discovery emphasizes understanding customers, exposing assumptions, and evaluating ideas. A small team can use that discipline without creating a research department. The useful output is a decision that the team can explain and revise.

This guide focuses on an existing SaaS with customers. For a business that has not yet established a problem worth solving, begin with idea validation. Here, the practical question is what to improve next in a workflow people already use.

• Product Talk: an introduction to product discovery

Start with a bounded customer outcome

Choose an outcome that a product change could plausibly influence and define who should experience it. An original fictional app, ReviewLoop, helps small agencies collect approval on design drafts. Its founder wants more new agency accounts to complete a first review with an invited client.

Write the cohort, event, and time window before selecting a solution. ReviewLoop uses new agency accounts, a client-submitted review, and the first fourteen days. It separately watches invitation failures and support burden. These are example choices, not universal activation standards.

A broad instruction such as improve engagement gives every feature an argument for inclusion. A bounded outcome makes it easier to investigate where the workflow fails. Use product analytics to establish observable steps while keeping customer conversations close to the data.

Separate the opportunity from the requested feature

A request for reminder emails could represent several different needs: the client missed the invitation, could not access the draft, was unsure what feedback was required, or had not agreed to review it yet. Record the observed situation before treating the requested feature as the problem.

In our fictional case, the founder reviews six recent onboarding conversations with permission. Two agency owners describe clients asking which part of a draft needs approval. That is a signal to investigate clarity, not a representative estimate of how often every customer has the problem.

Compare plausible solutions to the same opportunity. A clearer review request, an annotated draft, and a reminder may each help under different conditions. This prevents the first proposed feature from becoming the only option the team considers.

Name the assumption that could change the decision

List what needs to be true for a solution to work. Product Talk groups discovery assumptions around desirability, viability, feasibility, usability, and ethical considerations. Use those categories as prompts, then write a specific belief that evidence could challenge.

For ReviewLoop's decision prompt, one assumption is that agency owners can describe a single requested decision. Another is that invited clients understand the prompt without a facilitator. A third is that the extra preparation does not make owners abandon invitation creation.

Rank assumptions by consequence and uncertainty. A technically easy feature can still fail if nobody wants to use it. If the main uncertainty is comprehension, a production build is an expensive first test. If a provider cannot support a necessary capability, a focused proof of concept may be the next step.

• Product Talk: discovery assumptions and their categories

Choose a small test that answers the actual question

The fictional founder prepares three draft invitations with a decision prompt. In a moderated session, an agency owner completes the prompt and a permitted test participant acts as the client. Ask the participant to explain what decision is required and show how they would respond. Avoid teaching the task before observing it.

Write a decision rule before the session. For this example, the team agrees to revise the wording if a participant cannot identify the decision, and to stop considering the extra field mandatory if owners cannot complete it without assistance. A handful of sessions can reveal concrete failure modes; they cannot establish a population conversion rate.

Record what happened, including hesitation, incorrect interpretations, and facilitator intervention. If the test shows comprehension but says nothing about live invitation delivery, keep that uncertainty open. Do not quietly enlarge the conclusion because the demonstration went smoothly.

Outcome: more new agency accounts complete a client review within 14 days.
Opportunity: invited clients cannot identify the decision being requested.
Approach: an optional one-sentence decision prompt.
Riskiest assumption: the client understands the prompt without explanation.
Test: observe permitted participants interpret three synthetic invitations.
Decision rule: revise after any misunderstanding; evaluate owner effort separately.
Example observation: one participant mistakes an approval request for a request to edit.
Decision: revise the wording and retest before implementing.
Still unknown: live adoption, invitation delivery, and impact on completion rate.

Connect discovery to a delivery decision

End each test with a decision owner and one of several concrete actions: discard the approach, revise it, investigate another uncertainty, or prepare a bounded delivery. Avoid leaving a pile of observations with no explanation of how they changed the plan.

If ReviewLoop proceeds, it can release the prompt to an appropriate limited group and inspect preparation failures, client comprehension, and completed reviews. Define the observation window and comparison limitations before reading a before-and-after chart. A seasonal change or different customer mix could explain an apparent improvement.

Keep discovery evidence beside the relevant product roadmap item. The roadmap can communicate the outcome and current confidence while the delivery plan handles implementation details. New evidence should be able to change the decision without rewriting the history of what was learned.

Build a sustainable discovery routine

A small team can reserve a regular slot to inspect one important uncertainty, review a few recent customer observations, and choose the next test. The exact cadence should fit customer access and delivery capacity. Continuous discovery means keeping learning connected to decisions, not performing an interview quota regardless of purpose.

Reuse a compact record: outcome, opportunity, evidence, assumption, test, result, decision, and unresolved questions. Include the source and permission boundary for customer material. When evidence is weak, label it as weak rather than filling the gap with a confident score.

Our customer interview guide helps collect concrete experiences. The feedback prioritization guide helps compare problems after discovery has clarified them. Together they create a path from an observed struggle to a defensible next step.

Download the discovery decision log

The editable log includes the completed ReviewLoop example and a blank record for your next product decision. It separates an observation from an interpretation, a test result from a broader claim, and a delivery decision from unresolved risk. ReviewLoop and all observations in this guide are fictional. Sources checked October 27, 2026.

• Download the product discovery decision log (TXT)