On this page
A product discovery repository for startups prevents one expensive failure: building from memory, founder instinct, and the loudest customer call. In India, where users can vary sharply by language, purchasing power, workflow, and city tier, scattered notes create false confidence fast. Your repository should turn every interview, support ticket, sales objection, product test, and lost deal into evidence your team can retrieve before it commits engineering time.
What a product discovery repository for startups does
A product discovery repository is a structured record of customer evidence and the decisions it informs. It is not a folder full of call recordings, a product manager’s private notes, or a backlog with vague labels such as “users want reports.” Its job is to help your team answer: who has this problem, how often does it occur, what do they do today, what does it cost them, and what evidence would change our decision?
Early-stage teams often confuse activity with learning. They run ten calls, collect polite feedback, and leave with a list of feature requests. Without a shared system, the founder remembers one conversation, the designer remembers another, and engineering receives a conclusion without seeing the underlying evidence.
Build the repository before your product becomes hard to change. At the idea stage, it keeps assumptions visible. During MVP testing, it separates observed behaviour from stated intent. Once sales begins, it lets you compare what prospects ask for with what retained customers actually use.
The output is not documentation for its own sake. The output is better product decisions: which customer segment to serve first, which workflow to solve, which feature to defer, and which assumption now needs a direct test. This fits the discipline behind our eight-stage process: move from idea and market evidence toward fit, validation, funding, and scale without treating each stage as a fresh start.
Design the evidence schema before collecting more data
Your repository needs a consistent entry format. If each team member logs information differently, comparison becomes impossible. Start with fields that force precision, then add fields only when they change a product, commercial, or customer-segment decision.
| Field | What to record | Why it matters |
|---|---|---|
| Customer profile | Role, segment, context, and company type | Prevents one segment’s needs from becoming everyone’s roadmap |
| Problem statement | The customer’s situation, trigger, and desired outcome | Keeps the team focused on the job, not the proposed feature |
| Current workaround | Spreadsheet, person, agency, manual process, or competing product | Shows the real alternative you must beat |
| Evidence type | Interview, observation, product data, sales call, support issue, or experiment | Separates direct evidence from opinion |
| Decision link | Feature, segment, pricing, onboarding, or GTM decision affected | Makes every entry usable |
Use direct quotations sparingly but accurately. A quote such as “my team spends two hours reconciling this every Monday” is useful because it contains frequency, effort, and a workflow. “This would be nice to have” is weak unless you capture what the customer does now and whether they would change behaviour.
Record the source, date, interviewer, and confidence level. A founder’s interpretation should never sit in the same field as what a customer actually said or did. That distinction becomes more important when your team grows and product decisions move beyond the founder’s desk.
Collect signal without building a noise bank
The repository should receive evidence from every customer-facing channel, but not every item deserves equal weight. A prospect asking for a feature during a demo may be reacting to the conversation. A user repeatedly abandoning the same step in your product shows a behaviour that needs investigation. Treat these as different forms of evidence.
- Customer interviews: Capture the triggering event, existing workflow, exact pain, and consequences of doing nothing.
- Sales conversations: Record objections, buying process, budget owner, alternatives, and reasons deals stall or close.
- Support requests: Tag recurring friction, but separate usability gaps from one-off configuration issues.
- Product behaviour: Log patterns worth explaining, then speak to users before deciding why they happened.
- Experiments: Save the hypothesis, test setup, result, and decision made from the result.
Do not let feature voting become your discovery system. Customers can describe symptoms and workarounds; they rarely carry the full responsibility for product strategy. Your job is to detect the recurring job behind requests, identify the segment with the sharpest pain, and test whether solving it changes adoption, retention, or willingness to pay.
For Indian startups, segment evidence early. “SMEs” is not a customer definition. A Chennai retailer using WhatsApp for orders, a Bengaluru operations team using spreadsheets, and a distributor managing field staff may all appear to need the same feature while facing entirely different buying and usage conditions.
If your current notes cannot show which evidence supports your next build decision, you do not need more calls. You need a tighter system. Our programs are built for founders who need operators alongside them across validation, product, fundraising, and go-to-market.
Turn raw conversations into decision-ready insights
Raw notes are inputs, not insights. After each conversation, write a short evidence entry within 24 hours, while context remains fresh. Start with what happened, then state your interpretation separately. This keeps the team from turning one customer’s comment into a market conclusion.
Use this evidence chain: observation → pattern → hypothesis → test → decision. For example: three finance managers manually reconcile invoices each week; the pattern suggests reconciliation is a recurring workflow; the hypothesis is that automated matching will save time; the test is a clickable flow or concierge service; the decision follows the observed result.
Tag entries by customer segment, job to be done, journey stage, problem area, and evidence strength. Keep tags limited. When tags multiply, people stop using them consistently and search becomes unreliable. A small taxonomy used by everyone beats a detailed taxonomy used by nobody.
Also record disconfirming evidence. If a customer says the problem is painful but will not change tools, that matters. If users complete a task without the feature your team planned to build, that matters too. A repository that stores only supportive evidence becomes a confirmation machine.
Once a week, turn related entries into an insight card. The card should name the segment, the recurring problem, supporting evidence, contradictory evidence, the open question, and the next test. This is the unit your product, design, and commercial teams can discuss without replaying every call.
Connect discovery to roadmap decisions
A repository earns its maintenance cost only when it changes what gets built. Every roadmap item should link back to a named problem, target segment, evidence entries, and a measurable expected outcome. If a proposed feature cannot pass that test, label it clearly as a strategic bet rather than pretending it is customer-led.
| Before prioritising | Question to ask |
|---|---|
| Problem frequency | How often does this segment face the issue in its current workflow? |
| Pain severity | What time, revenue, risk, or effort does the current workaround create? |
| Segment focus | Is this for the customer group you are trying to win now? |
| Evidence quality | Do you have observed behaviour, repeated interviews, or only requests? |
| Test path | Can you test value before committing a full build? |
This approach reduces two common founder errors. The first is building for the biggest prospective logo, even when that request has no repeat value across your chosen segment. The second is refusing a useful feature because it arrived as a customer request rather than through your original product thesis.
Link discovery decisions to delivery planning, but do not collapse the two systems. A delivery board tracks commitments, owners, and deadlines. A discovery repository tracks uncertainty, evidence, and learning. Combining them usually causes unresolved questions to disappear under delivery pressure.
When a decision is made, write it down: what you chose, what evidence supported it, what trade-off you accepted, and when you will revisit it. This stops teams from reopening settled debates while preserving the logic for new hires and future fundraising diligence.
Run a cadence that keeps the repository alive
The repository fails when it becomes a monthly reporting task. Give it an operating cadence tied to actual work. The founder should remain close to customer evidence in the early stages, even after hiring product or sales talent. Delegating every customer conversation too early creates distance exactly when you need sharper judgment.
- After every customer interaction: Log the evidence entry, source, context, and follow-up question.
- Weekly: Review new patterns, contradictions, and open assumptions with product and commercial owners.
- Before roadmap planning: Audit the evidence behind each major proposed item.
- After a release: Compare the expected outcome with actual customer behaviour and add the result.
- Before investor meetings: Extract the validated problem, customer learning, test results, and remaining risks.
Assign one owner for repository quality, but make evidence collection a shared responsibility. Sales should not hoard objections in a CRM. Customer success should not keep retention signals in a private spreadsheet. Product should not rely only on analytics. The owner’s role is to enforce the format, remove duplicate tags, and make the repository easy to use in decisions.
At Nebula, we work as a venture builder in Tamil Nadu, building for India. We co-build alongside founders across validation, product, fundraising, and go-to-market, with embedded operators and outcome-tied economics. If your customer learning is scattered across calls, chats, and individual memory, Build with us and turn it into a product decision system.
A strong product discovery repository for startups gives your team a record of what customers do, what they struggle with, what you tested, and why you chose your next move. Build it before feature volume hides the signal. Then use it every week, especially when a request looks urgent, a prospect looks large, or your own conviction feels strongest.
Enjoyed this? Get the next one in your inbox.
Fundraising guides and validation frameworks, every two weeks. No spam.
Frequently asked questions
What should a product discovery repository include?
Include the customer segment, problem context, current workaround, evidence source, direct observations, interpretation, confidence level, linked decision, and next test.
Who should own a startup product discovery repository?
Assign one person to maintain quality and taxonomy, but require product, sales, customer success, and founders to contribute evidence from their customer interactions.
Ready to build your startup?
We work with a small number of founders each year — mentorship, fundraising support, and a co-founder network included.
Start a conversation
Talk to the founder directly. We reply within two working days.
Applying to Nebula 1.0? Apply here →