On this page
A founder in Chennai hears that users “want a better dashboard” and puts two engineers on it for three weeks. Six interviews later, the real problem is not reporting; it is that users cannot complete the first setup without calling support. That is why learning how to conduct user interviews for startup decisions is less about collecting opinions and more about finding the work people already struggle to do.
Start with a roadmap decision, not a research goal
Weak interview plans begin with “let’s learn what users think.” That produces broad conversations, friendly feedback, and no decision. Start with the product choice that is currently blocked: which user segment to serve first, whether to fix activation before adding a feature, which workflow deserves an MVP, or why trial users fail to convert.
Write the decision in one sentence before you recruit anyone. For example: “We need to decide whether small retailers fail during catalogue upload or payment setup.” This gives every question a job. It also stops the team from treating interviews as a ritual performed before building what they already wanted to build.
At Nebula, we treat customer evidence as an input to the validation process, not a substitute for founder judgment. Interviews expose behaviour, constraints, and language. You still have to make the call on what to build, what to postpone, and what to kill.
Use this decision brief before each interview round:
- What product or roadmap decision will this research inform?
- Which user group can answer it from recent experience?
- What would count as evidence against your current assumption?
- What action will you take if the pattern appears?
If you cannot name the decision, do not schedule the calls yet. Refine the problem until the answer can change a roadmap item, a target segment, or a pricing hypothesis.
Recruit people with recent problem experience
The quality of a user interview is usually decided before the call starts. A person who fits your imagined customer profile but has not faced the problem recently will give you theories. A person who handled the problem last week can describe the sequence, the workarounds, the people involved, and the money or time at stake.
For an India-focused startup, recruit across the conditions that change behaviour: city tier, language preference, device type, payment habit, business size, and who actually makes the decision. A founder may sell software to a clinic owner but discover that reception staff, accountants, and visiting doctors each shape adoption differently. Do not collapse those roles into one “user” category.
Ask for a recent event when you invite people. “Have you managed inventory reconciliation in the last 30 days?” is better than “Would you like a tool for inventory?” The first filters for lived experience. The second attracts people willing to be polite.
- Existing customers: useful for understanding adoption, retention, and failure points.
- Lost prospects: useful for finding deal-breakers and unclear value.
- Users of alternatives: useful for mapping current habits and switching costs.
- Non-users with the problem: useful for testing whether the problem is urgent enough to solve.
Do not recruit only friends, startup peers, or people who already believe in you. Their encouragement is cheap; their behaviour rarely predicts a market.
How to conduct user interviews for startup conversations
A useful interview follows the user’s past, not your product’s future. Ask them to replay a specific instance: the last time they tried to complete a task, buy a service, resolve an issue, or coordinate with someone. Keep returning to what happened rather than what they say they would do.
Open with context. Ask what triggered the task, what they needed to achieve, what they did first, where the process slowed down, and what happened when it failed. Then ask what they used instead and what that workaround cost them. Silence is useful here. Let the user think instead of filling the gap with your explanation.
| Ask this | Instead of this | Why it works |
|---|---|---|
| “Tell me about the last time you did this.” | “Would you use an app for this?” | It reveals actual behaviour. |
| “What happened after that?” | “Was that difficult?” | It uncovers the sequence and failure point. |
| “What did you try before?” | “Do you like our idea?” | It shows existing alternatives. |
| “Who else was involved?” | “Are you the decision-maker?” | It exposes the buying group. |
Avoid pitching until the final minutes, if at all. Once you describe your solution, people switch from recounting their world to helping you improve your pitch. That is a different conversation and should be treated as one.
Building a product around evidence takes more than a set of calls. If your team needs an embedded operating partner across validation, product, fundraising, and go-to-market, Build with us.
Listen for cost, workarounds, and exact language
Roadmap-changing evidence has texture. “I need better visibility” is a vague complaint. “Every Friday I export three reports, message two branch managers, and spend two hours fixing missing entries before payroll” is a workflow with a cost. Your job is to get from the first statement to the second.
Listen for four signals: frequency, consequence, workaround, and ownership. Frequency tells you whether the problem recurs. Consequence tells you what failure costs in revenue, time, trust, or compliance. Workarounds reveal whether the pain is strong enough to force action. Ownership identifies who suffers, who pays, and who can approve a change.
Keep a separate column for exact user phrases. Those phrases can improve onboarding copy, sales calls, landing pages, and your pitch deck. More importantly, they stop the team from replacing a customer’s problem with internal product jargon.
Pay attention to moments when users show you spreadsheets, WhatsApp messages, notebooks, screenshots, or manual steps. Evidence of behaviour beats a clean opinion. If a user has built a workaround, ask how long it took to create, what breaks when it fails, and why they have not switched to another option.
Do not treat every complaint as a feature request. A request is often a user’s proposed fix. The underlying problem may require a different product choice, a clearer workflow, or no software at all.
Turn notes into evidence, not anecdotes
One memorable interview can distort a roadmap. Founders remember the loudest customer, the most detailed story, or the person who sounds most like them. Counter this by using the same note structure on every call and reviewing the full set together.
Capture what the user did, what triggered the action, the alternative they used, the cost of the current method, and the exact evidence shown. Separate direct observations from your interpretation. “User sends order updates through WhatsApp because staff do not check email” is an observation. “They need a team-chat feature” is an interpretation.
- Group interviews by user type and job-to-be-done.
- Mark repeated behaviours, not repeated adjectives.
- Count disconfirming evidence against your original assumption.
- Write the strongest competing explanation for each pattern.
- Choose the smallest test that can reduce remaining uncertainty.
Patterns do not require mathematical certainty to guide an early product decision. They require enough repeated, specific evidence that continuing with the old roadmap would be harder to defend than changing it. If users describe different problems, do not average them into one feature list. Segment them. You may have two distinct customers, or you may be interviewing too broadly.
Keep the evidence visible to product, sales, and founders. A shared repository of clips, notes, and decisions prevents the same assumptions from returning three months later under a new feature name.
Change the roadmap with clear rules
User interviews matter only when they create a changed action. After each round, write a short decision memo: what you believed before, what you heard, what changed, what remains uncertain, and what the team will do next. This is where research becomes operating discipline.
Use interviews to alter priority, scope, sequence, or segment. If users fail before reaching your core feature, move activation work ahead of expansion. If a feature matters only to a small high-value segment, package it for that segment rather than making it the default. If users already solve the problem easily with a free habit, pause the feature and investigate a more expensive problem.
Do not promise a roadmap change during an interview. Thank the user, verify the pattern across relevant participants, then decide. A founder who commits to every request trains customers to expect custom work and trains the team to chase noise.
Set a review rhythm. At the end of a round, decide whether you have enough evidence to build, need another set of interviews, or should run a smaller prototype. Our Venture Building and Startup School programs are designed around this kind of decision-making: moving from assumption to evidence, then from evidence to a focused next move.
The goal is not to become interview-rich and action-poor. The goal is a roadmap where each major item has a known user, a real situation, and a reason it belongs ahead of everything else.
Your roadmap should reflect observed behaviour, not founder confidence. Run the next interview round around one decision, capture the evidence cleanly, and change course when the evidence earns it. If you need a team that co-builds from validation through product and go-to-market, Build with us.
Enjoyed this? Get the next one in your inbox.
Fundraising guides and validation frameworks, every two weeks. No spam.
Frequently asked questions
How many user interviews should a startup conduct before changing its roadmap?
Run enough interviews within one defined user segment to see whether specific behaviours, costs, and workarounds repeat. Change the roadmap when the evidence is specific and repeated, then validate remaining uncertainty with a smaller test.
What should founders avoid during user interviews?
Avoid pitching early, asking whether users like your idea, promising features, and treating one strong opinion as a market pattern. Ask users to describe a recent real situation instead.
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 →