36. Product Discovery

Product discovery is the work you do before and during building to decide what is worth building.

It connects customer pain, business value, product feasibility, and evidence. Without discovery, the roadmap becomes a collection of opinions from founders, investors, loud customers, and competitors. Discovery does not eliminate uncertainty, but it makes the uncertainty visible enough to test.

Discovery is not a phase you finish forever. It is a habit. The company keeps learning as customers change, segments shift, competitors move, and usage reveals what interviews missed.

Discovery Is Not Asking For Feature Requests

Customers are good at describing pain, workarounds, constraints, and outcomes. They are often less reliable at designing the solution.

Weak discovery asks:

• What features do you want?
• Would you use this?
• Do you like this idea?

Better discovery asks:

• What are you doing today?
• What is hard, slow, risky, or expensive?
• What happens if you do nothing?
• What have you already tried?
• Who else is involved?
• How do you decide to buy?
• What would need to be true for you to switch?

Product discovery should uncover evidence, not collect opinions.

Discovery Inputs

Use multiple sources because every source has bias.

Input	What it reveals	Bias
Customer interviews	Pain, workflow, language, buying context.	People mispredict future behavior.
Sales calls	Objections, urgency, buyer structure.	Prospects may be polite or strategic.
Support tickets	Confusion, failure, repeated friction.	Existing users may not represent the broader market.
Analytics	Actual behavior.	Shows what happened, not always why.
Session recordings	UX friction and drop-off.	Needs interpretation.
Churn conversations	Why value did not sustain.	Customers may soften the truth.
Competitor analysis	Category expectations and gaps.	Can pull you into copying.
Internal observations	Operational pain and delivery issues.	Team may overfocus on what annoys them.

The best discovery combines what people say, what they do, and what they pay for.

Opportunity Mapping

An opportunity is not a feature. It is a customer pain, desired outcome, risk, or repeated friction that may deserve a product response.

Map opportunities by:

• Customer pain.
• Affected segment.
• Frequency.
• Severity.
• Business value.
• Reach.
• Effort.
• Confidence.
• Strategic fit.
• Risk if ignored.

Simple opportunity table:

Opportunity	Evidence	Segment	Frequency	Value	Effort	Confidence	Next test

Do not let scoring create false precision. Scores are a conversation starter, not a substitute for judgment.

Evidence Quality

All evidence is not equal. Discovery becomes much stronger when the team labels evidence quality honestly.

Evidence	Strength	How to use it
Founder opinion	Low	Useful as a hypothesis, not proof.
Customer praise	Low	Useful for language, not commitment.
Repeated pain stories	Medium	Good signal if from target customers.
Existing workaround	Medium-high	Shows pain is real enough to act on.
Customer effort	High	Data sharing, team time, migration, workflow change.
Payment or signed pilot	High	Shows economic commitment.
Repeated usage	Very high	Shows workflow fit.
Renewal, expansion, referral	Very high	Shows value persists and transfers.

In discovery reviews, write both the insight and the evidence level.

Weak:

Customers want analytics.

Stronger:

Four target customers manually prepare weekly sales reports in spreadsheets. Two said the report takes more than three hours and one shared an anonymized sample. Evidence level: workaround plus effort.

This habit protects the team from building on soft signals.

Signals Versus Noise

Product discovery is full of noise. The founder’s job is to separate repeated market evidence from random input.

Input	Treat as signal when	Treat as noise when
Customer request	It appears across target customers and blocks value.	One non-ICP customer asks loudly.
Sales objection	It repeats in qualified deals and stops progress.	It comes from weak-fit prospects.
Support issue	It affects activation, retention, or trust.	It is rare and easy to explain.
Competitor feature	Customers mention it as a buying criterion.	You noticed it and feel behind.
Investor feedback	It challenges a real business assumption.	It changes every meeting.
Internal idea	It connects to strategy and evidence.	It is mainly founder excitement.

This distinction protects the roadmap. Early teams are small, so the cost of chasing noise is high. A single unnecessary feature can steal the time needed to fix onboarding, close customers, or improve retention.

Discovery Sprint

When the team is uncertain about what to build, run a one- or two-week discovery sprint instead of drifting into random feature work.

Sprint structure:

Day or phase	Work
Frame	Pick one segment, one workflow, and one decision the sprint must inform.
Recruit	Find five to ten people who match the segment. Include users, buyers, churned users, and almost-customers where possible.
Observe	Run interviews, screen shares, workflow walkthroughs, or support reviews.
Synthesize	Group pains, workarounds, objections, and repeated language.
Decide	Choose one opportunity, one assumption, and one experiment.

The output is not a big research deck. The output is a product decision:

• Build a small test.
• Change the segment.
• Improve onboarding.
• Kill a feature idea.
• Run a pricing test.
• Do more discovery because the evidence is still weak.

A discovery sprint should end with fewer options, not more confusion.

Keep A Discovery Repository

Do not keep discovery only in the founder’s head. Create a lightweight repository with:

• Interview notes.
• Sales call objections.
• Support themes.
• Churn reasons.
• Customer quotes.
• Usage screenshots or analytics snapshots.
• Opportunity backlog.
• Experiment results.
• Decisions made and why.

The format can be Notion, Google Docs, Linear, Airtable, a spreadsheet, or plain markdown. The tool matters less than consistency.

For each insight, record the source, customer segment, date, and decision implication. “Customer asked for dashboard” is weak. “Three target customers could not complete weekly reporting because managers need a summary view; this blocks expansion” is useful.

The repository helps when hiring product, sales, support, or customer success. It also prevents repeated arguments. When the team asks why a feature exists, the evidence should be findable.

Turning Discovery Into Product Work

Discovery does not automatically become product work. The translation step matters.

Use this chain:

1. Observation: What happened in the customer’s world?
2. Pain: Why does it matter?
3. Root cause: What creates the pain?
4. Opportunity: What could improve?
5. Assumption: What must be true?
6. Experiment or build: What is the smallest next step?
7. Metric or behavior: How will we know?

Example:

Step	Example
Observation	Sales reps manually update CRM after WhatsApp follow-ups.
Pain	Managers cannot trust pipeline data.
Root cause	Follow-up happens outside CRM because the CRM is slower than WhatsApp.
Opportunity	Capture follow-up status from WhatsApp-like workflow.
Assumption	Reps will update if it takes less than ten seconds.
Experiment	Lightweight mobile update flow with three status options.
Metric	Percentage of follow-ups logged within same day.

Without this translation, teams jump from “customers mentioned WhatsApp” to “build WhatsApp integration.” The real opportunity may be faster status capture, not a full integration.

The Opportunity Brief

Before meaningful product work begins, write a one-page opportunity brief. This keeps discovery connected to product judgment and prevents the team from building a feature whose purpose is already fuzzy.

Use this structure:

Section	What to write
Segment	Which customer segment and role this is for.
Situation	What is happening in the customer’s current workflow.
Pain or outcome	What is hard, slow, risky, expensive, or valuable.
Evidence	Interviews, usage, support, sales, churn, payment, or workaround proof.
Current alternative	What customers use today, including spreadsheets, WhatsApp, people, agencies, or doing nothing.
Business reason	Why solving this matters to activation, retention, revenue, expansion, or strategy.
Assumptions	What must be true for the solution to work.
Smallest test	The lightest experiment before committing to full build.
Decision rule	What result makes you build, change, or stop.
Non-goals	What the team will not solve in this pass.

Example:

Section	Example
Segment	Finance heads at D2C brands doing 500+ daily orders.
Situation	They reconcile marketplace payouts from multiple portals every week.
Pain	Deductions and returns are hard to match, delaying cash visibility.
Evidence	Six calls, three spreadsheet samples, two paid pilot asks, repeated complaint about manual matching.
Current alternative	Excel plus accountant review plus portal downloads.
Business reason	Strong activation event and clear paid pilot path.
Assumptions	Customers will upload reports if matching output is useful within 10 minutes.
Smallest test	Concierge matching on sample data for five customers.
Decision rule	Continue if three customers send real data and two ask to repeat next week.
Non-goals	No full accounting integration in this pass.

The brief should be short enough to read in five minutes. If it becomes a large document, the team may be hiding uncertainty behind words.

Choosing Experiments

Choose the experiment based on the question.

Question	Experiment
Do customers understand the promise?	Landing page, outreach, or message test.
Can users complete the workflow?	Prototype or usability test.
Will buyers pay?	Paid pilot or pricing test.
Will users activate?	Onboarding test.
Will users return?	Retention test.
Does the feature matter?	Fake-door test or concierge version.
Can we deliver value manually?	Concierge, spreadsheet, or service MVP.
Which segment cares most?	Parallel outbound or interview sprint.

Every experiment needs:

• A specific customer segment.
• A clear assumption.
• A success threshold.
• A time limit.
• A decision after the result.

Experiments without decisions become theater.

Experiment Decision Rules

Every discovery experiment should have a decision before it starts. Otherwise founders interpret results based on mood.

Use this pattern:

If [behavior] happens with [segment] by [date], we will [decision]. If not, we will [decision].

Examples:

• If 5 of 20 qualified prospects agree to share real workflow artifacts, we will build a concierge prototype.
• If fewer than 2 of 10 target users complete the prototype task without guidance, we will redesign before engineering.
• If 3 customers pay for a manual pilot, we will productize the workflow.
• If users activate but do not return within seven days, we will shift the next sprint to retention instead of new features.
• If the buyer likes the idea but users refuse to change workflow, we will revisit the segment or onboarding model.

Good decision rules include:

Element	Why it matters
Segment	Prevents learning from the wrong customer.
Behavior	Measures commitment, not politeness.
Threshold	Forces a standard before emotion enters.
Time limit	Prevents experiments from running forever.
Next action	Turns evidence into movement.

Avoid thresholds that are impossible or meaningless. “Everyone must love it” is too strict. “Someone said it is interesting” is too weak. The right threshold depends on the cost of the next step. A two-day prototype needs less evidence than a two-month engineering bet.

The Discovery Decision Review

Run a short decision review before a meaningful build. It can fit on one page.

Section	Prompt
Customer	Which exact segment and role is this for?
Pain	What repeated pain or desired outcome are we addressing?
Evidence	What interviews, calls, usage, support, churn, or payments prove this matters?
Assumption	What must be true for this to work?
Experiment	What is the smallest test before full build?
Success	What behavior or metric would make us continue?
Failure	What result would make us stop or change direction?
Tradeoff	What are we delaying or refusing by doing this?

This review is not bureaucracy. It is protection against building from anxiety. If the company cannot name the evidence and tradeoff, the idea may not be ready.

Interview-To-Build Review

After a discovery sprint, do not jump directly from notes to tickets. Run an interview-to-build review.

Use this format:

Review area	Question
Segment	Did the evidence come from the target customer or from adjacent users?
Repetition	Did the same pain appear repeatedly, or only once?
Current behavior	What workaround, spending, or effort proves the pain exists?
Buyer link	Who pays, approves, or blocks the solution?
Workflow fit	Where exactly would the product enter the customer’s process?
Value	What outcome would make the customer care next month?
Scope	What is the smallest product response worth testing?
Non-solution	What should we explicitly not build?

The output should be one of four decisions:

Decision	Meaning
Build small	Evidence is strong enough for a narrow product bet.
Test first	Evidence is promising but the solution is uncertain.
Discover more	Pain exists, but segment, buyer, or workflow is unclear.
Park	The opportunity is not strong enough now.

This protects the team from treating every customer conversation as a roadmap command.

Evidence Quote Discipline

Keep one or two exact customer phrases beside every product bet. Not decorative testimonials. Evidence phrases.

Example:

“We download three settlement files and still call the accountant because the deductions do not match.”

This phrase reveals workflow, anxiety, and current behavior. Good product teams keep such language close because it prevents abstraction. If the team cannot remember the customer’s words, it may be building from summary instead of truth.

Discovery Review Cadence

Discovery works best as a rhythm, not a rescue mission. A simple cadence keeps customer truth close to product decisions.

Weekly review:

Question	What to inspect
What did we learn this week?	Interviews, calls, support, usage, churn, demos.
Which segment did the evidence come from?	Avoid mixing ICP and non-ICP signals.
Which opportunity got stronger?	Repeated pain, workarounds, commitment, usage.
Which assumption got weaker?	Failed tests, confusion, low urgency, no budget.
What should change next week?	Product, messaging, onboarding, pricing, or discovery plan.

Monthly review:

Question	Why it matters
Which product bets paid off?	Connect discovery quality to outcomes.
Which bets were built on weak evidence?	Improve judgment without blame.
Which customer requests should we refuse?	Protect strategy and focus.
Which segment is producing the strongest evidence?	Align product and GTM.
Which old assumption should be deleted?	Prevent stale beliefs from becoming doctrine.

The cadence should be lightweight. The goal is not to create research bureaucracy. The goal is to make sure the roadmap is connected to real customer behavior every week.

Discovery Cadence

For early startups:

• Talk to customers every week.
• Join at least some sales calls.
• Review support issues weekly.
• Review activation and retention weekly.
• Review churn and objections monthly.
• Keep an opportunity backlog.
• Link roadmap items to evidence.
• Revisit assumptions after every meaningful release.

If discovery happens only when the product is failing, you are using it too late.

Balancing Customer Evidence And Founder Vision

Discovery does not mean customers run the company. The founder still makes strategic choices.

Use customer evidence to understand:

• Which pains are real.
• Which segment is sharpest.
• Which workflows repeat.
• Which objections block adoption.
• Which outcomes create value.

Use founder judgment to decide:

• Which market to pursue.
• Which opportunities fit the strategy.
• Which customer requests to ignore.
• Which product bets are worth taking.
• Which wedge can become a larger company.

Good product teams are neither opinion-only nor customer-request-only. They combine evidence and judgment.

Experiment Design Matrix

Choose experiments based on the uncertainty, not on what is easiest to build.

Uncertainty	Better Experiment	Weak Experiment
Does the pain exist?	Customer interview, workflow observation, support-ticket review.	Landing page with vague copy.
Will users understand the flow?	Prototype or usability test with realistic task.	Asking if screenshots look good.
Will buyers pay?	Paid pilot, pricing conversation, proposal test.	Free beta signup.
Will the workflow repeat?	Concierge delivery for 5-10 similar customers.	Building a full automation immediately.
Will customers return?	Cohort usage test and follow-up.	One-time demo feedback.
Will onboarding work?	Assisted onboarding test and drop-off review.	Long help document nobody reads.
Will a channel work?	Small outbound, partner, content, or community test.	Assuming launch traffic proves demand.

Every experiment should end with a decision. If an experiment cannot change what you build, sell, or stop doing, it is probably theater.

Opportunity Prioritization Clinic

When the backlog grows, run a clinic every two weeks.

Step	Question
Evidence check	Which opportunities are backed by repeated customer behavior?
Segment check	Which opportunities strengthen the chosen segment?
Outcome check	Which improve activation, retention, revenue, or trust?
Risk check	Which test the riskiest assumption?
Effort check	Which can be tested without building the full solution?
Focus check	Which opportunities should be refused this cycle?

The output should be one chosen experiment, not a ranked list nobody follows. Product discovery is useful only when it changes product decisions.

Assumption Map

Before building a feature, map the assumptions behind it. Most product mistakes hide inside assumptions nobody says aloud.

Assumption type	Question
Customer	Is this the customer we are choosing to serve now?
Problem	Is the pain repeated, urgent, and costly enough?
Workflow	Does the product fit the customer’s real process?
Buyer	Does the buyer care enough to approve, pay, or sponsor adoption?
User	Will the daily user change behavior?
Trust	Will customers trust us with the data, workflow, money, or decision?
Delivery	Can we deliver the promised outcome reliably?
Economics	Can this be supported at the expected price?
Channel	Can we reach more similar customers?

For each product bet, pick the one or two assumptions that could kill the idea fastest. Those become the discovery target. Do not spend three months building around assumptions that can be tested with five calls, a prototype, or a paid pilot.

Customer Evidence Scorecard

Use this scorecard after discovery conversations so the team does not treat all notes equally.

Score	Evidence	Meaning
0	Polite interest.	Useful for language only.
1	Clear pain story.	Problem may exist.
2	Current workaround.	Customer already spends effort.
3	Quantified cost or consequence.	Pain has business weight.
4	Customer shares data, team time, or internal process.	Commitment is visible.
5	Customer pays, signs pilot, renews, refers, or changes workflow.	Strong evidence.

When reviewing opportunities, write the evidence score beside each item. A backlog full of score-1 ideas is not ready for a large build. A score-4 or score-5 opportunity from the right segment deserves serious attention.

Discovery Question Bank

Use questions that reveal behavior.

Workflow:

• Walk me through the last time this happened.
• What triggered the work?
• Who was involved?
• What tools, chats, files, and approvals were used?
• Where did it slow down?
• What happened after completion?

Cost:

• What does this cost you in time, money, risk, or missed opportunity?
• What happens if you do nothing?
• Who notices when this goes wrong?
• How often does it happen?

Commitment:

• What have you already tried?
• Who owns solving this today?
• What would make this worth paying for?
• What would block adoption even if the product worked?
• Who else would need to approve?

Switching:

• What would be risky about changing your current process?
• Which data, people, or integrations would need to move?
• What proof would you need before trusting a new product?

These questions are intentionally concrete. Abstract questions produce abstract answers.

Discovery Output Quality Bar

A discovery cycle should produce one of these outputs:

Output	When it is useful
Sharper ICP	You learned which segment has the strongest pain.
Rejected opportunity	Evidence is too weak or segment is wrong.
Experiment brief	A risky assumption can be tested quickly.
Product bet	Evidence is strong enough to build a narrow version.
Onboarding change	Customers want value but fail to reach it.
Pricing or packaging test	Value exists but commitment is unclear.
Sales message change	Pain is real but positioning is weak.

If discovery produces only a pile of notes, it has not finished. The work must change a decision.

Discovery Synthesis Ritual

After every 5-10 serious customer conversations or product observations, synthesize the evidence. Do not let notes sit unused.

Use this ritual:

Step	Question
Cluster	Which pains, workflows, objections, and triggers repeated?
Separate	Which comments came from buyers, users, influencers, or internal teams?
Score	Which evidence reached behavior, data sharing, payment, or workflow change?
Contrast	Which segments looked similar at first but behaved differently?
Decide	What product, sales, pricing, onboarding, or roadmap decision changes?
Archive	Which ideas are interesting but not for now?

The founder should personally join synthesis until the product direction is clear. Discovery delegated too early can become a note-taking function instead of a strategy function.

End with this sentence:

Because we learned ______, we will now ______ and we will stop/delay ______.

If that sentence is impossible to write, the discovery cycle is not complete.

Discovery Cadence By Stage

Discovery should change as the startup matures. The mistake is using the same discovery habit for every stage.

Stage	Main discovery question	Best inputs	Output
Idea	Is this a painful problem for a reachable customer?	Interviews, workflow observation, existing workarounds.	Segment and problem clarity.
MVP	Which assumption should we test first?	Paid pilots, concierge work, prototype tests, sales calls.	MVP brief and success threshold.
Early customers	Why do some customers activate and others disappear?	Onboarding sessions, support notes, usage events, churn calls.	Activation and retention fixes.
Pre-PMF	Which segment shows the strongest pull?	Cohorts, repeated sales objections, renewal intent, referrals.	Segment focus and roadmap narrowing.
Post-PMF	What blocks scale, reliability, expansion, and efficiency?	Customer success data, sales cycle analysis, support load, usage depth.	Product scale roadmap.

Set a weekly minimum until PMF:

• At least three real customer or prospect conversations.
• At least one review of product usage or onboarding behavior.
• At least one written decision from discovery.

The number is less important than the rhythm. A founder who talks to customers only when growth slows will always be late. Discovery should be part of the operating system, not a rescue activity.

Handling Founder Intuition

Founder intuition matters. It is often the source of a good startup idea. But intuition becomes dangerous when it refuses to meet evidence.

Use this rule:

Founder belief	Required next step
”I know this problem is real.”	Find recent examples from target customers.
”Customers will pay for this.”	Ask for payment, deposit, pilot, or budget owner.
”This feature is obvious.”	Observe the workflow where it would be used.
”The market is moving here.”	Identify who is changing behavior now and why.
”Competitors are missing this.”	Confirm whether customers care about the gap.

Do not suppress intuition. Convert it into a sharper hypothesis. The best founders are not evidence robots. They are disciplined enough to test the beliefs they care about most.

India Angle

In India, discovery often requires observing informal workflows. A customer may say they use software, but the real process may include WhatsApp groups, calls, screenshots, cash handling, Excel exports, local agents, paper forms, or a junior employee who knows the workaround.

Do not rely only on Zoom interviews with English-speaking early adopters if your market is broader. Field visits, screen shares, workflow shadowing, support chats, and payment observations can reveal what polite conversations hide.

For B2B, talk to both buyer and user. The person who signs may not feel daily pain. The person who feels daily pain may not control budget.

Common Mistakes

• Asking customers what to build instead of studying their pain.
• Treating investor feedback as product discovery.
• Overweighting loud customers.
• Ignoring users because buyers pay.
• Building every requested feature.
• Running experiments without decision criteria.
• Not documenting evidence.
• Confusing prototype praise with usage.
• Letting competitor features become your roadmap.
• Treating analytics as truth without qualitative context.

Reader Action

Create an opportunity backlog with these columns: customer pain, evidence, affected segment, frequency, possible solution, risk, next experiment, decision.

Add at least ten opportunities from real customer evidence. Then choose one experiment for the riskiest assumption. Do not build the full feature until the experiment tells you the opportunity is real.

Discovery Evidence Repository

Discovery gets wasted when evidence stays scattered across call recordings, founder memory, WhatsApp screenshots, CRM notes, support tickets, and analytics dashboards. Create one repository where product decisions can trace back to real customer evidence.

Use this structure:

Field	What to capture
Customer/person	Segment, role, company type, buyer/user distinction.
Source	Interview, sales call, support ticket, usage data, churn call, field visit, demo.
Pain quote or event	The exact problem, preferably from a recent situation.
Workflow	Where the problem appears in the customer’s day.
Current workaround	Excel, WhatsApp, people, agency, manual process, competitor, no solution.
Cost of pain	Time, money, risk, lost revenue, delay, compliance, reputation, stress.
Commitment	Payment, pilot, data access, team time, repeat usage, referral, intro.
Product implication	What this might mean for product, onboarding, pricing, support, or GTM.
Confidence	Strong, medium, weak, or unknown.
Next experiment	What evidence would increase or reduce confidence?

The repository should support product arguments like:

We should prioritize this because 8 target customers described the same workflow failure, 3 shared data, 2 agreed to paid pilots, and the workaround is expensive.

That is stronger than:

Customers keep asking for this.

Evidence hygiene

Label evidence carefully:

• Buyer evidence is not always user evidence.
• One large customer’s request is not automatically market evidence.
• Investor opinion is not customer discovery.
• Competitor behavior is not proof of customer pain.
• Analytics shows what happened; interviews help explain why.
• Polite praise is weaker than uncomfortable commitment.

Review the repository before roadmap planning. If roadmap items cannot be linked to evidence, they should be moved down, rewritten, or tested before building.

Discovery Bias Controls

Discovery is fragile because founders hear what they want to hear. Add bias controls to the process.

Bias	How it appears	Control
Confirmation bias	Founder asks questions that invite agreement.	Ask about recent behaviour, current workaround, and actual cost.
Friendliness bias	Customers praise the idea to be polite.	Ask for time, data, intro, payment, pilot, or next action.
Loud-customer bias	One urgent customer dominates roadmap.	Compare against segment-wide evidence.
Investor bias	Investor enthusiasm becomes product proof.	Separate funding feedback from customer behaviour.
Competitor bias	Team copies visible competitor features.	Ask whether customers care about that feature.
Founder pain bias	Founder builds for their own old problem.	Validate with current target customers.

At the end of every discovery cycle, ask: “What evidence would make us change our mind?” If the answer is “nothing”, discovery has become theatre.

From Discovery To Product Decision

Discovery should produce a decision, not an archive.

Use this conversion table:

Discovery pattern	Product decision
Repeated pain, weak willingness to pay	Keep researching buyer, budget, and urgency before building.
Strong pain, manual workaround, clear buyer	Design MVP or paid pilot.
Strong usage, weak retention	Improve onboarding, habit trigger, or workflow fit.
High support load around one step	Fix UX, copy, defaults, docs, or setup.
One segment loves it, others are confused	Lock focus on the strong segment.
Feature request from non-target customer	Say no or charge as custom work.
Competitor gap customers do not mention	Do not prioritize yet.

Before moving an opportunity into roadmap, write:

Evidence summary:
Customer segment:
Workflow:
Pain intensity:
Commitment level:
Riskiest assumption:
Recommended decision:

This creates a clean bridge between discovery and roadmap. Without that bridge, discovery becomes content for meetings instead of fuel for product judgment.

Discovery Coverage Map

Make sure discovery is not accidentally narrow.

Role	What to learn
Buyer	Budget, approval, urgency, alternatives, risk, procurement.
User	Workflow, frequency, friction, habits, real language.
Admin/manager	Implementation, permissions, reporting, team adoption.
Finance/procurement	Payment terms, GST/invoice needs, vendor onboarding, renewal process.
Support/operations	Repeated confusion, manual work, edge cases, trust gaps.
Lost customer/prospect	Why the promise was not strong enough.

For Indian B2B especially, buyer and user truth may differ sharply. A founder who interviews only senior buyers may miss daily workflow pain. A founder who interviews only users may miss budget reality.

Discovery Sampling Plan

Discovery quality depends on who you speak with. Ten friendly conversations from one network can create false confidence.

Create a sampling plan before a discovery sprint:

Segment or role	Target count	Why this group matters	Access source
Daily users		Workflow truth
Economic buyers		Budget and urgency
Admins/operators		Implementation and adoption reality
Lost prospects/customers		Objection and trust truth
Expert insiders		Market rules and failure patterns
Adjacent segment		Boundary testing

Use this rule:

If all interviews come from people who already like you, discovery is under-sampled.

Sampling does not need to be academic. It needs to protect the founder from building for the easiest people to reach instead of the market they claim to serve.

Discovery-To-Roadmap Traceability

Every important roadmap item should trace back to evidence.

Use a traceability table:

Roadmap item	Evidence source	Customer segment	Workflow pain	Commitment signal	Decision
	Interview / analytics / support / sales / churn / pilot				build / test / defer / reject

Rules:

• A feature request without segment evidence becomes a test, not a roadmap commitment.
• A buyer request without user evidence needs workflow discovery.
• A user complaint without buyer impact may be UX/support work, not strategy.
• A support issue repeated across accounts deserves product attention.
• A sales promise without evidence should enter the commitment ledger, not the roadmap blindly.

Traceability keeps discovery from becoming theatre and roadmaps from becoming opinion lists.

Opportunity Evidence Council

When a startup has more ideas than capacity, founders need a lightweight council for product opportunities. This does not need bureaucracy. It needs a repeated habit of comparing evidence before committing the team.

Run the council weekly or fortnightly with founder, product/engineering, sales/customer success, and one person who has recently spoken to customers.

For each opportunity, review:

Evidence area	Questions
Segment	Which customer type has this problem most sharply?
Pain	What exact workflow pain, cost, delay, risk, or frustration exists?
Frequency	How often does it happen? Daily, weekly, monthly, seasonal, rare?
Existing workaround	What do customers do today, and what does it cost them?
Buyer value	Who cares enough to pay, approve, or prioritize it?
User adoption	Who has to change behavior for the solution to work?
Trust risk	What would make customers hesitate to rely on the product?
Build risk	What is technically, operationally, legally, or design-wise uncertain?
Strategic fit	Does this deepen the chosen product direction or create distraction?

Use four decisions:

Decision	Meaning
Build	Evidence is strong enough and the opportunity fits the current strategy.
Prototype	User workflow or trust risk is unclear.
Interview more	Segment, buyer, urgency, or value is unclear.
Park	Interesting but not aligned with current stage, segment, or capacity.

The council should maintain one visible “parked opportunities” list. Parked does not mean forgotten. It means the company is choosing focus consciously instead of carrying every possibility in the founder’s head.

This is especially useful when Indian customers ask for custom workflows. Some custom requests reveal a repeatable segment opportunity. Others are one-account service work wearing product clothing. The council’s job is to tell the difference.

Discovery Synthesis Memo

Discovery work becomes useful only when it changes a decision. After each discovery sprint, write a short synthesis memo instead of leaving notes scattered across calls, WhatsApp messages, CRM fields, and founder memory.

Use this structure:

Section	What to write
Segment studied	Which customer type, role, geography, company size, or use case did we study?
Strongest repeated pain	What showed up across multiple conversations or behaviors?
Customer language	Exact words customers used for the pain, workaround, risk, or desired outcome.
Current workaround	What they do today and what it costs them.
Buyer/user split	What buyers care about versus what daily users experience.
Trust blockers	What would stop them from adopting, paying, importing data, or relying on the product?
Evidence strength	Which signals were behavior, payment, data shared, introductions, or only opinion?
Contradictions	What did not fit the founder’s original belief?
Product implication	Build, test, change copy, narrow segment, change onboarding, adjust pricing, or stop.
Next discovery question	What still needs evidence before roadmap commitment?

End with one sentence:

Because we learned [evidence], we will [decision], and we will not [tempting distraction].

This memo should be uncomfortable when evidence is weak. That is useful. A founder who cannot summarize discovery into a decision probably has not finished discovery yet.

Related Links

• 18. Customer Discovery Fundamentals
• 35. MVP
• 37. Product Roadmaps
• 147. Product Templates