18. Customer Discovery Fundamentals

Customer discovery is the discipline of learning what is true before your product, pitch, or ego makes the answer expensive.

It is not validation theater. It is not asking friends whether your idea is good. It is not a survey where people say they “would use” something they will never pay for. It is not a way to collect compliments before you build what you already wanted to build.

Discovery is how a founder enters the customer’s world and comes back with sharper judgment.

The core customer-discovery question is: what do we now understand about the customer’s real problem, workflow, buyer, budget, trust hurdle, and next action that we did not know before the conversation?

That question keeps discovery practical. It prevents the founder from treating interviews as motivation, content, or social proof. Every conversation should make the company smarter about what to build, what to sell, whom to serve, or what to stop doing.

What customer discovery is

Customer discovery is structured learning about a real customer’s problem, workflow, buying behavior, constraints, and trust requirements.

It helps you answer:

• Who has this problem most painfully?
• How often does it happen?
• What do they do today?
• What does the current workaround cost?
• Who feels the pain?
• Who pays?
• Who blocks change?
• What would make them trust a new solution?
• What channel can reach them?
• What next action proves seriousness?

The output of discovery is not a pile of notes. The output is a better decision.

Learning before building

Founders like building because building feels like progress. But building too early can hide weak thinking.

Before building, discovery should reduce the biggest unknowns:

• Is this a real problem?
• Is it frequent or urgent enough?
• Is the segment clear?
• Is the current workaround painful?
• Is there budget or willingness to change?
• Is the buyer reachable?
• Is there a trust hurdle?

If you build before these questions are clear, the product becomes a very expensive questionnaire.

Problem discovery

Problem discovery asks whether the pain is real.

You are looking for:

• Recent examples
• Specific triggers
• Current workarounds
• Cost of the problem
• Emotional or business stakes
• Failed attempts to solve it
• Repeated language across customers

Good problem discovery is about the customer’s life, not your idea. A founder should be able to describe the problem in the customer’s words before describing the solution.

Buyer discovery

User and buyer are often different.

In B2B, the person suffering may be an operator, analyst, sales rep, teacher, nurse, accountant, recruiter, or junior team member. The buyer may be a founder, department head, finance person, procurement team, school owner, doctor, plant manager, or business owner.

Buyer discovery asks:

• Who owns the budget?
• Who approves new tools?
• Who will be blamed if this fails?
• Who benefits if this works?
• Who can block the purchase?
• What paperwork or process is required?

A product can solve a user pain and still fail if the buyer does not care.

Workflow discovery

Workflow discovery asks how the work actually happens.

Do not only ask people to explain the workflow. Ask them to show it where possible.

Look for:

• Tools used
• Spreadsheets
• WhatsApp groups
• Calls
• Offline registers
• Agencies
• Junior staff handoffs
• Approvals
• Manual checks
• Rework
• Exceptions

In India, many real workflows live outside formal software. A founder who only studies the official process will miss the actual operating system.

Pricing discovery

Pricing discovery is not asking, “How much would you pay?”

People rarely answer that accurately. Instead, discover:

• What they spend today
• Which budget pays
• What the problem costs
• What alternatives cost
• How they justify purchases
• What approval threshold exists
• Whether monthly, annual, usage-based, or project pricing fits
• Whether they prefer invoice, card, UPI, bank transfer, or purchase order

Pricing comes from value, alternatives, urgency, and buying process, not just willingness stated in an interview.

Trust discovery

Trust discovery asks what the customer must believe before taking a risk on you.

Trust hurdles may include:

• Founder credibility
• References
• Case studies
• Local presence
• Brand familiarity
• Data security
• Compliance
• Support availability
• Implementation help
• Language comfort
• Refund or cancellation terms

Trust matters especially when selling to Indian SMBs, enterprises, schools, clinics, finance teams, and family-run businesses. A customer may like the product and still not trust the company enough to switch.

Channel discovery

Channel discovery asks where customers can be reached when the problem is active.

Possible channels:

• Search
• LinkedIn
• WhatsApp groups
• Local associations
• Trade events
• Consultants
• Accountants
• Agencies
• Founder networks
• Referrals
• Communities
• Marketplaces

The best early channel is often the one that gets you the highest-quality conversations, not the one that looks scalable in a pitch deck.

What customer discovery is not

Pitching

If you spend most of the call explaining your idea, you are not discovering. You are selling.

Selling is useful at the right time. But early discovery needs the customer to talk about their world before you contaminate the conversation with your solution.

Asking for opinions

Opinions are cheap. Behavior is expensive.

Weak question: “Do you think this is useful?”

Better question: “When did this last happen, and what did you do?”

Asking “would you use this?”

Future intent is unreliable. People want to be supportive. They also imagine an ideal version of your product with no switching cost, no setup, no payment, and no internal politics.

Ask about past behavior and concrete next steps.

Asking friends only

Friends can help you practice, but they are often poor evidence. They may avoid hurting you, misunderstand the market, or give advice from the wrong context.

If your early conversations are mostly friends, label them as practice, not validation.

Confirming your idea

Founders often use discovery to prove what they already believe. That is dangerous.

The right attitude is: “What would make me change my mind?”

Outsourcing thinking

Customers can describe pain. They cannot always design the company for you. Do not ask customers to become product managers. Listen deeply, then do the founder work of synthesis.

Discovery outcomes

Good discovery should produce seven outcomes.

Pain clarity

You know what hurts, how often, how badly, and what happens if nothing changes.

Segment clarity

You know which customer type feels the pain most sharply and which customer type is weak or noisy.

Buyer clarity

You know who uses, who pays, who approves, who influences, and who blocks.

Workflow clarity

You understand the current process well enough to see where your product would enter.

Budget clarity

You know whether money, time, authority, or attention exists for change.

Trust hurdle

You know what proof the customer needs before trying or buying.

Next action

You know what concrete action should happen next: more interviews, narrower segment, prototype, pilot, pricing test, landing page, sales call, or stopping the idea.

The India angle

Discovery in India often requires more patience and context than a clean interview script assumes.

For B2B and SMB customers, the real workflow may live in WhatsApp, Excel, phone calls, junior staff, accountants, distributors, agencies, or family members. The person speaking to you may not be the person doing the work or paying for the solution.

For consumers, stated preference can be far from actual behavior because price sensitivity, trust, language, local influence, device quality, and habit matter.

Practical adjustments:

• Use warm introductions when possible.
• Ask to see the workflow, not only hear about it.
• Speak to the user, buyer, and operator separately.
• Notice offline workarounds.
• Ask about trust, support, language, and payment behavior.
• Do not assume English-speaking early adopters represent the larger market.
• Separate metro, tier-2, and tier-3 behavior when relevant.

A basic discovery process

1. Choose one narrow segment.
2. Write your current problem hypothesis.
3. Find 10-15 people who match the segment.
4. Ask about recent behavior, current workarounds, cost, urgency, and decision process.
5. After every call, write exact customer language.
6. Look for repeated patterns.
7. Decide whether to continue, narrow, change, or stop.

Do not average all conversations. Segment them. Five strong conversations from the right customer are more useful than 30 polite conversations from random people.

The founder discovery cadence

Customer discovery should not be a one-time pre-product phase. It should become a founder operating habit.

For the first few months, use a simple cadence:

Frequency	Practice
Daily	Capture one customer observation, complaint, phrase, or workflow detail.
Weekly	Run 3-5 customer or buyer conversations in the same segment.
Weekly	Review notes with co-founders and decide what changed.
Fortnightly	Update the problem, segment, buyer, pricing, and trust assumptions.
Monthly	Decide whether to continue, narrow, change, or stop the current wedge.

The cadence matters because discovery is perishable. A founder can read notes and still drift back to old beliefs. A regular review forces the company to convert learning into decisions.

Discovery debt

Just as engineering teams accumulate technical debt, founders accumulate discovery debt.

Discovery debt appears when:

• You build features for problems you have not recently observed.
• You describe the buyer vaguely.
• You quote one customer as if they represent a segment.
• You avoid price conversations because they feel uncomfortable.
• You cannot explain the current workaround.
• You do not know why customers trust or reject vendors.
• Your team debates internally instead of calling customers.

The cost of discovery debt is misallocated effort. The team gets busy, but the company does not get wiser.

Pay it down by returning to basics: one segment, recent behavior, current workaround, buyer, budget, trust, and next action.

What good discovery changes

Good discovery should change at least one of these:

• The customer segment becomes narrower.
• The problem statement becomes sharper.
• The product scope becomes smaller or more focused.
• The sales message uses customer language.
• The pricing hypothesis becomes more realistic.
• The trust hurdle becomes visible.
• The team stops building something weak.
• The founder earns a pilot, intro, data share, or buyer conversation.

If nothing changes after ten conversations, either the conversations are too shallow or the team is not listening.

Discovery Planning Canvas

Before starting a discovery sprint, fill this canvas:

Field	Prompt
Segment	Which exact customer type are we studying?
Exclusions	Who are we deliberately not studying yet?
Problem hypothesis	What problem do we believe they face?
Trigger	When does the problem become active?
Current workaround	What do we expect they do today?
Buyer hypothesis	Who pays, approves, blocks, or owns the outcome?
Trust hypothesis	What proof would they need before trying us?
Riskiest assumption	Which belief would kill the idea fastest if false?
Interview count	How many conversations before synthesis?
Decision rule	Continue, narrow, change, or stop based on what evidence?

The canvas is not bureaucracy. It prevents discovery from turning into random conversations. A founder should know what is being tested before asking for someone’s time.

Discovery Questions By Learning Goal

Different goals need different questions.

Learning goal	Questions
Problem	”When did this last happen?” “What made it painful?” “What happened next?”
Workflow	”Can you walk me through the process?” “Which tools, people, and files are involved?”
Cost	”What does this cost in time, money, risk, or lost opportunity?”
Buyer	”Who owns this outcome?” “Who approves a new tool or vendor?”
Budget	”What do you spend today?” “Which budget would this come from?”
Trust	”What would make you trust a new company with this?”
Channel	”Where do you usually learn about tools or vendors for this?”
Next step	”Who else should I speak with?” “Would you review a workflow or pilot proposal?”

This keeps the conversation anchored in real behavior while still allowing the customer to surprise you.

Discovery Output: The Customer Reality Brief

After a sprint, produce a one-page brief:

• Segment studied.
• Number of qualified interviews.
• Repeated trigger.
• Repeated current workaround.
• Clear user, buyer, and blocker.
• Strongest exact customer phrases.
• Evidence of budget, urgency, or willingness to act.
• Trust requirements.
• Major contradictions.
• Decision and next test.

The brief should be short enough that the whole team reads it. If discovery notes never change product, sales, or strategy, they are just archive material.

The Discovery Ethics Line

Be honest with interviewees.

• Do not imply a product exists if it does not.
• Do not collect sensitive data you do not need.
• Do not record without permission.
• Do not publish quotes with names unless allowed.
• Do not promise outcomes just to get a call.
• Do not use discovery as a disguised sales pitch if you said it was not a sales call.

Trust lost during discovery can damage the company before it starts.

The Discovery Evidence Ledger

Founders often say, “We spoke to customers,” but the actual evidence is scattered across notebooks, WhatsApp messages, CRM notes, and memory. That is dangerous. Memory edits the story in favor of the idea.

Create a discovery evidence ledger. One row per meaningful customer interaction.

Column	What to capture
Date	When the conversation happened.
Person	Role and segment, not only name.
Qualification	Why this person represents the target customer.
Problem story	The last real occurrence they described.
Workaround	What they do today.
Cost	Time, money, risk, delay, stress, or opportunity loss.
Buyer	Who owns the decision or budget.
Trust hurdle	What would make them hesitate.
Evidence type	Opinion, behavior, access, commitment, or revenue.
Follow-through	Did they reply, introduce, share data, review, pilot, or pay?
Decision impact	What this changed in the startup’s thinking.

Do not let opinions and behavior sit in the same bucket. “I like this” is not the same as “I introduced you to my CFO” or “I paid for a pilot.” The ledger should make that difference obvious.

Evidence Quality Ladder

Use this ladder when reviewing discovery:

Level	Evidence	How to interpret it
1	Polite interest	Useful for morale, weak for decisions.
2	Specific pain story	Better; the problem exists at least sometimes.
3	Active workaround	Stronger; the customer already spends effort.
4	Clear owner and budget path	Strong; the problem can become a purchase.
5	Follow-up behavior	Very strong; the customer spends social capital or time.
6	Paid pilot or pre-order	Strongest early evidence; still validate delivery and repeatability.

The mistake is to make product decisions from level 1 and fundraising claims from level 2. Early founders should push evidence up the ladder before scaling confidence.

Weekly Discovery Review

Run a 45-minute discovery review every week during the early stage.

Agenda:

1. Which segment did we study?
2. How many qualified conversations happened?
3. What repeated pain appeared?
4. What behavior supported the pain?
5. What contradicted our belief?
6. What did customers do after the call?
7. What should change in product, positioning, pricing, or segment?
8. What is the next riskiest assumption?

The review should end with one decision, not a vague feeling. Examples:

• Narrow to mid-market finance teams.
• Stop interviewing students and focus on parents.
• Test whether owners will pay for a manual audit.
• Change the buyer from HR to department heads.
• Delay product build until buyer discovery is clearer.

Customer discovery is not a research project. It is a decision system.

Discovery Sprint Design

Discovery works best in short sprints. An open-ended “talk to customers” instruction becomes vague quickly. A sprint gives the founder a clear question, a narrow segment, a fixed number of conversations, and a decision date.

Use this structure:

Sprint Element	Example
Segment	Owner-led diagnostic labs in Pune and Mumbai.
Hypothesis	Lab owners lose money because follow-up reports and patient communication are handled manually.
Riskiest assumption	The owner sees this as a revenue or reputation problem, not only an admin annoyance.
People to interview	8 owners, 5 front desk operators, 3 doctors, 2 software vendors or consultants.
Evidence needed	Recent stories, current workaround, owner involvement, current spend, willingness for paid pilot.
Decision date	Friday, 5 pm.
Possible decisions	Continue, narrow to multi-location labs, switch buyer, test paid concierge service, stop.

Do not run discovery forever. Run a sprint, make a decision, then run the next sprint. The goal is not perfect truth. The goal is reducing the most dangerous uncertainty enough to act intelligently.

Discovery Kill Criteria

Before the sprint starts, write what would make you stop or change direction. This protects the team from explaining away bad evidence.

Examples:

• Stop this segment if 10 qualified customers cannot describe a recent occurrence.
• Change buyer if users feel pain but budget owners do not care.
• Change problem if customers repeatedly describe a different workflow as more painful.
• Delay product build if no one will share data, introduce a buyer, or review a prototype.
• Test service first if the workflow is messy and trust-heavy.

Kill criteria are not pessimism. They are founder discipline. They let you preserve energy for a better wedge.

Discovery Charter

Before a serious sprint, write a one-page discovery charter. The charter makes the learning goal explicit so the team does not drift into casual conversations.

Use this format:

Field	Prompt
Segment	Which exact customer type are we studying?
Problem	What painful situation do we believe they face?
Riskiest belief	Which assumption would kill the idea fastest if false?
Roles to interview	User, buyer, operator, approver, blocker, influencer.
Minimum evidence	What must we hear or see before moving forward?
Disconfirming evidence	What would make us narrow, change, or stop?
Next decision	What decision will this sprint inform?
Deadline	When will we synthesize instead of continuing endlessly?

The most important field is disconfirming evidence. Founders often know what they want to prove, but not what would change their mind. A discovery charter forces intellectual honesty before emotions take over.

Discovery Risk Register

Every discovery sprint should maintain a risk register: the short list of things you still do not understand.

Common risks:

• The user is not the buyer.
• The pain exists but is not urgent.
• The workaround is annoying but acceptable.
• The buyer has no budget owner.
• Trust requirements are higher than the product can satisfy.
• The segment is reachable only through expensive sales motion.
• The customer wants a service, not a product.
• The problem is real only in one unusual company.

Review the register after every five conversations. If the same risk remains unresolved, design the next interviews around that risk instead of asking the same broad questions again.

Discovery Quality Bar

Not every conversation counts equally. A high-quality discovery conversation has evidence, specificity, and next-step clarity.

Grade each conversation:

Grade	What it means	Example
A	Recent story, clear workflow, real cost, buyer path, next action.	”Last Friday our ops team spent six hours reconciling 300 orders; finance owns the tool budget; I can introduce you.”
B	Real story and pain, but buyer or budget unclear.	”This happens weekly, but I do not know who would approve software.”
C	General pain, no recent example, weak specifics.	”This is a problem in our industry.”
D	Opinion, praise, or curiosity without behavior.	”Nice idea, I would use it someday.”

A founder should not count ten C-grade calls as validation. Three A-grade conversations from the right segment can be more useful than twenty vague calls.

Five-Conversation Checkpoint

After five qualified calls in one segment, pause and ask:

• Are customers describing the same trigger?
• Are they using similar words?
• Do they already spend time, money, reputation, or political capital on this?
• Do we understand the current workflow well enough to draw it?
• Have we spoken to anyone with buying authority?
• Did any customer take a concrete next step?

If the answer is mostly no, do not simply do twenty more calls. Fix the segment, questions, or access path first.

Discovery Governance Rules

Discovery becomes dangerous when it is informal but influential. A founder remembers the calls that support the idea, the product team hears the loudest story, and the company quietly treats weak evidence as fact.

Use a few governance rules:

Rule	Why It Matters
One evidence ledger	Notes, call links, artifacts, and decisions should not live only in memory or chat.
Separate facts from interpretation	”Customer said X” and “we think this means Y” are different claims.
Mark evidence strength	Opinion, story, behavior, access, commitment, and revenue should not carry equal weight.
Name the decision affected	Every discovery insight should connect to segment, product, pricing, messaging, channel, or timing.
Preserve contradictions	Contradictions are not clutter; they are where the next learning often lives.
Review weekly	Discovery without synthesis becomes founder entertainment.
Retire stale beliefs	If new evidence disproves an old assumption, update the operating docs.

The founder should own discovery governance until the company has a mature product or research function. Delegating conversations is fine. Delegating judgment too early is risky.

Founder Synthesis Routine

Discovery creates value only when the founder turns conversations into decisions. Do not let notes pile up until they become emotional evidence for whatever you already wanted to build.

Run a synthesis routine every Friday during active discovery:

Step	Question	Output
Sort	Which conversations were A-grade evidence, and which were just opinions?	Graded call list.
Cluster	Which pains, triggers, workarounds, words, and objections repeated?	Pattern table.
Separate	What did customers say versus what are we interpreting?	Fact/interpretation split.
Decide	Which assumption changed this week?	Updated assumption ledger.
Act	What will we test next week?	Segment, question, artifact ask, or offer.

The most useful synthesis sentence is:

“We used to believe [old belief]. After [evidence], we now believe [new belief]. The next test is [test].”

If that sentence does not change for several weeks, one of three things is happening: the market is very clear, the discovery process is weak, or the founder is avoiding a hard decision. Be suspicious of the second and third.

Good discovery should make the next move smaller and sharper. Bad discovery makes the founder feel informed while the product, segment, and offer remain vague.

The Discovery Assumption Stack

Every startup idea is a stack of assumptions. Customer discovery should not only ask, “Do people have this problem?” It should identify which assumption is weakest and test that next.

Use this stack:

Layer	Assumption	Discovery Question
Segment	A specific group has the problem.	Who exactly has it, and who does not?
Trigger	The problem happens in a recognizable moment.	When does it occur, and what causes action?
Pain	The problem creates meaningful consequence.	What time, money, risk, stress, delay, or loss does it create?
Workflow	The current process can be understood.	What happens before, during, and after the problem?
Owner	Someone is accountable for the outcome.	Who gets blamed, measured, or pressured?
Buyer	Someone can approve spend or change.	Who controls budget, procurement, or internal permission?
Trust	The customer can imagine adopting a new solution.	What proof, support, data handling, relationship, or brand is needed?
Channel	The segment can be reached repeatedly.	How will you find more people like this without luck?
Economics	The problem can support a viable business.	Can willingness to pay, deal size, margin, sales effort, and retention work?

Many founders test only the pain layer. They hear “yes, this is painful” and start building. But a startup can die at any layer:

• Real pain, wrong buyer.
• Clear buyer, no urgency.
• High urgency, no repeatable access.
• Strong access, low willingness to pay.
• Willingness to pay, but trust requirements too high.
• Great first customer, but economics depend on custom service.

Weakest Assumption First

At the start of every discovery sprint, name the weakest assumption:

Our idea depends on many things being true.
The weakest assumption right now is:
If this is false, the idea should:
The evidence we need this week is:
The people we must speak to are:
The artifact or commitment we should ask for is:

Examples:

Weak Assumption	Better Test
”SMB owners care about this.”	Interview owners who recently paid to solve it, not only operators who complain.
”Finance teams will trust automation.”	Ask what proof, control, audit trail, and fallback they need before adoption.
”Students will pay.”	Test payment or parent buyer involvement, not only student enthusiasm.
”This can be sold online.”	Try reaching 30 qualified buyers through the expected channel.
”The workflow is simple.”	Ask customers to show the actual spreadsheet, WhatsApp flow, or handoff process.

Discovery becomes powerful when it is specific about what could kill the idea. The founder is not trying to win an argument. The founder is trying to reduce expensive ignorance.

Customer Truth Repository

Discovery notes become valuable only when the team can retrieve them later. If notes live across WhatsApp, memory, call recordings, Notion pages, CRM fields, and founder intuition, the team will keep rediscovering the same facts.

Create a simple customer truth repository. It can be a spreadsheet, doc database, CRM, or folder. The tool matters less than the discipline.

Field	Why it matters
Segment	Prevents mixing different customer types into one misleading average.
Role	Separates user, buyer, approver, operator, blocker, and expert.
Recent incident	Grounds the conversation in behavior, not opinion.
Workflow artifact	Captures the spreadsheet, report, process, ticket, invoice, or message thread.
Cost of pain	Connects frustration to money, time, risk, reputation, or revenue.
Current workaround	Shows what customers already trust enough to use.
Exact phrase	Preserves customer language for positioning and sales copy.
Commitment	Records whether the customer shared data, made an intro, booked a follow-up, or paid.
Evidence grade	Marks whether the signal is story, behavior, buyer access, or paid proof.
Decision impact	States what changed because of this evidence.

Every discovery note should answer one question: what should the team believe differently after this conversation?

If the answer is “nothing,” the call may still have been polite and useful, but it should not change product, sales, pricing, or fundraising decisions.

Repository Rules

• Write the note within 24 hours.
• Do not summarize away the customer’s exact words.
• Tag the segment before extracting conclusions.
• Attach or describe artifacts when customers show them.
• Mark assumptions separately from evidence.
• Record the next commitment, not just the sentiment.
• Review the repository weekly and delete duplicate conclusions.

This repository becomes a founder asset. It improves product decisions, sales scripts, investor memos, positioning, onboarding, and hiring because the team can point to customer reality instead of arguing from memory.

Discovery Cadence By Stage

Customer discovery should not be a one-time startup ritual. The cadence changes by stage.

Stage	Discovery cadence	Main question
Idea search	5 to 10 conversations per week in one narrow segment.	Is this problem real, repeated, and reachable?
Validation	Weekly interviews plus artifact review or manual tests.	Will customers commit time, data, workflow change, or money?
MVP	Discovery around usage, onboarding, trust, and support moments.	Where does the product fail the customer’s real workflow?
Early revenue	Founder joins sales and success calls weekly.	Why do customers buy, delay, expand, or churn?
Scaling	Monthly customer reviews by segment and cohort.	Which segment is becoming the best business?

Early founders often stop discovery once they start building. That is usually when discovery becomes more important. Before product, customers tell you stories. After product, customers reveal the gap between your promise and their behavior.

Set a weekly discovery rhythm:

Monday or Tuesday: book calls and collect artifacts
Wednesday or Thursday: run calls, demos, or workflow reviews
Friday: synthesize patterns and decide what changes
Weekend or Monday: adjust product, sales, positioning, or next tests

If the team is too busy to talk to customers, it is probably too busy to learn. Startup speed is not just shipping speed. It is learning speed.

Discovery Decision Packet

At the end of a discovery sprint, do not leave the team with scattered notes. Create a short decision packet. The packet should help a founder decide whether to continue, narrow, change, or stop.

Use this format:

Sprint dates:
Segment tested:
Problem hypothesis:
Number of useful conversations:
Roles interviewed:
Strongest repeated pain:
Current workaround:
Buyer or budget owner:
Trust blocker:
Strongest commitment:
Weakest assumption:
Decision:
Next test:

The packet should include a small evidence table:

Evidence	Count or example	Strength	Decision impact
Recent painful incidents		Weak / medium / strong
Workarounds seen		Weak / medium / strong
Buyer access		Weak / medium / strong
Budget or spend signal		Weak / medium / strong
Follow-up commitments		Weak / medium / strong
Contradictions		Weak / medium / strong

The decision should be explicit:

Decision	Use when
Continue	Evidence is repeating and the next test is obvious.
Narrow	One segment, trigger, workflow, or buyer shows stronger signal than the rest.
Change	The pain is real but the buyer, problem framing, offer, or channel is wrong.
Stop	The problem is weak, unreachable, not urgent, or not worth the cost to solve.

Discovery without a decision packet becomes memory. Memory becomes storytelling. A packet keeps the founder honest.

Discovery Quality Review

Review discovery quality before trusting the conclusions.

Quality check	Good sign	Warning sign
Segment discipline	Most conversations match one narrow segment.	Calls mix too many customer types.
Role coverage	User, buyer, approver, blocker, and expert are mapped.	Only friendly users were interviewed.
Recent behavior	Conversations include last-time stories and artifacts.	Notes are mostly opinions and future guesses.
Commitment	People give time, intros, data, workflow access, pilot interest, or money.	People praise the idea and disappear.
Contradictions	Team records what does not fit the idea.	Notes only preserve supportive quotes.
Decision impact	The sprint changes product, sales, segment, or next test.	The team simply says “more research needed.”

If quality is weak, do not pretend the answer is known. Improve the next sprint: tighter target, better role mix, harder questions, stronger commitment asks, and cleaner notes.

Reader action

Before building, run five discovery calls with one narrow segment. For each call, record:

• Last occurrence of the problem
• Current workaround
• Cost of pain
• Buyer
• Urgency
• Trust requirement
• Exact customer language
• Concrete next step

Then write one decision: continue, narrow, change, or stop.

Related links

• 19. Finding People to Interview
• 20. Running Customer Interviews
• 21. Interpreting Customer Discovery
• 132. 7-Day Customer Discovery Playbook
• 146. Customer Discovery Templates