On this page
A problem solution fit sprint is the fastest way to find out whether you are building around a painful customer reality or around your own assumptions. For an early-stage founder in India, that distinction decides whether your first INR spent on product creates learning or creates rework. Run the sprint before you commit to features, hire for a roadmap, or turn a pitch deck into a promise you cannot support.
Define the problem solution fit sprint
Problem-solution fit means a specific customer segment recognises a problem, experiences it often enough to care, and sees your proposed approach as materially better than how they handle it today. It does not mean customers say your idea sounds good. Polite interest is cheap. Evidence sits in their current behaviour: workarounds, money spent, time lost, failed attempts, and urgency to change.
A problem solution fit sprint is a focused, time-boxed research cycle designed to collect that evidence. You start with one narrow customer segment and one problem hypothesis. You then interview people who have lived the problem, map their existing behaviour, test a simple solution concept, and decide whether the evidence earns the next build step.
Keep the scope tight. “Small businesses struggle with payments” is too broad to test. “Independent tuition centres in Coimbatore spend several hours each week chasing monthly fee payments” gives you a customer, a job, a setting, and a cost of inaction.
At Nebula, we treat this as the work that precedes product confidence. Our process starts with idea and market work because a clean product plan cannot rescue a vague problem. Your sprint should produce a decision, not a research report that sits unread in a folder.
Write a testable problem hypothesis
Begin with a hypothesis that can be proved wrong. Founders often start with a solution statement: “We will build an app for X.” That sentence hides the assumptions that matter. Who is X? What are they trying to get done? What triggers the problem? What do they do now? Why is that option insufficient?
Write your hypothesis in this format: When [trigger], [specific customer] struggles to [job], because [constraint]. They currently use [workaround], which costs them [measurable consequence]. The consequence can be money, staff time, delay, error, lost customers, or personal stress. Do not invent a consequence on behalf of the customer; use it as a question to investigate.
- Segment: Name a buyer or user with shared context, not an entire industry.
- Trigger: Identify the event that makes the problem active.
- Job: Describe the outcome the person wants, without naming your product.
- Current method: Record what they actually use today, including spreadsheets, calls, WhatsApp, staff, or doing nothing.
- Cost: State what the current method makes worse.
Choose one primary hypothesis for the sprint. You can hold secondary assumptions, such as who pays or which channel reaches users, but do not test five markets at once. A narrow negative result is useful. A broad positive result usually means you asked questions too loosely.
Recruit customers who have lived the problem
Your interview list should contain people with recent, direct experience of the problem. A friend who likes startups, a broad industry contact, or someone who might face the issue someday will give you weak signals. Recruit for recency and relevance. If the issue happens monthly, speak to people who dealt with it in the last month; if it is triggered by an annual event, find people who went through that event recently.
Use warm introductions, customer communities, local business groups, alumni networks, direct outreach, and relevant WhatsApp groups. In India, trust often determines whether a customer gives you thirty honest minutes. Be clear that you are researching a problem, not selling software. Offer a short call, respect their work hours, and ask for an introduction only after you have earned it.
| Recruiting filter | What you need to confirm |
|---|---|
| Role | They use the current process or own the result. |
| Recency | They can describe a real incident, not a general opinion. |
| Frequency | The problem repeats often enough to justify a new habit or tool. |
| Ability to act | They can influence purchase, adoption, or internal change. |
Recruit across meaningful variation within the same segment. A Chennai clinic and a Madurai clinic may face different workflows, but do not mix clinics, pharmacies, and hospitals in one early sprint. You need patterns before you need breadth. Aim to learn where the problem is strongest, not to collect a representative survey.
If you need an operator beside you while you frame the market, customer set, and first test, Build with us. We work as co-builders across validation, product, fundraising, and go-to-market.
Run interviews without selling
The interview is not a pitch rehearsal. Your goal is to reconstruct a past event in enough detail that you can see the customer’s real workflow, decisions, and trade-offs. Ask for the last time the problem occurred. Then stay with that incident. What happened first? Who was involved? What did they try? What did it cost? What made the experience difficult?
Do not ask, “Would you use an app that does this?” The customer has no reason to predict their future behaviour accurately, and you have no reason to trust a hypothetical answer. Ask questions that pull out facts rather than approval.
Useful prompts: “Walk me through the last time this happened.” “What did you do next?” “What tools or people did you depend on?” “What was frustrating about that?” “What have you tried to change?” “What happened when you did?”
Listen for specificity. A customer who names a deadline missed, a repeated manual task, a failed vendor, or an internal escalation is giving you material to test. Ask permission to see non-sensitive artefacts where appropriate: a redacted spreadsheet, a message thread, a checklist, or a purchase process. These reveal gaps between what people say they do and what their work actually requires.
Take notes in the customer’s language. Do not translate every complaint into startup vocabulary while you listen. Exact phrases later improve your product copy, sales conversations, and investor narrative. More importantly, they keep your team close to the problem instead of attached to a feature.
Turn interviews into a problem map
After every few conversations, bring the team together and compare evidence. Do not wait until the end of the sprint, when memory has blurred the details. Create one record per interview, then tag what you heard: trigger, job, current workflow, workaround, pain, cost, stakeholder, purchase constraint, and quoted language. Separate direct observation from your interpretation.
A problem map makes patterns visible. You are looking for repeated behaviour among the people you intend to serve, not a collection of interesting anecdotes. If three customers complain about the same delay but each has a different cause, you may have a symptom rather than a single problem worth solving.
- Repeated pain: Does the same issue appear across interviews in comparable situations?
- Existing effort: Are customers already spending time, money, or attention to manage it?
- Consequence: What happens if they leave the issue unresolved?
- Priority: Does the customer place this above other active problems?
- Access: Can you repeatedly reach this segment through a credible channel?
Disagreement is useful. If one founder hears strong demand and another hears weak urgency, return to the notes and identify the factual gap. Do not settle the argument by seniority. A shared evidence board gives product, sales, and fundraising work one source of truth. It also prevents a loud interview from carrying more weight than a repeated pattern.
Test the solution before building it
Once the problem pattern is clear enough, test the smallest believable version of your solution. This may be a workflow diagram, clickable screens, a landing page, a concierge service, a manual pilot, or a short proposal. The format matters less than the test. The customer must understand the outcome, the changes required from them, and the reason to act now.
Show the concept after you have discussed their existing experience. Ask them to react to it against the real incident they described. Where would it fit? What would stop them from using it? What would they need to replace? Who else would need to agree? A feature request is not automatically a buying signal; it may only show that the person can imagine a more complete tool.
Do not confuse a prototype with proof. A polished interface can create admiration without demand. The stronger signal is a customer who agrees to a defined next step: shares data, introduces the buyer, joins a pilot, changes a workflow, or discusses price and timing.
For a B2B startup, test the whole buying path early. The daily user, functional owner, finance approver, and founder may each have different concerns. For a consumer startup, test the moment of adoption: what makes someone stop their current habit and try yours? Build only what the next customer commitment requires. This is how you protect scarce engineering time.
Score evidence and make a decision
End the problem solution fit sprint with a decision meeting, not an open-ended backlog. Put the evidence in front of the team and assess your hypothesis against a few fixed questions. Are you seeing a repeated, urgent problem? Do customers use costly workarounds? Does your proposed approach produce a concrete next commitment? Can you reach enough similar customers to keep learning?
Use a simple evidence score, but do not let the score hide judgement. A customer saying “yes” has less weight than a customer who introduces you to their operations lead. A complaint about inconvenience has less weight than a problem tied to revenue, compliance, or daily operating capacity. Record both the pattern and the exceptions.
| Decision | What the evidence says | Next move |
|---|---|---|
| Proceed | Problem, urgency, and customer commitment repeat. | Run a focused pilot or build the minimum product needed for it. |
| Refine | The problem is real, but segment, trigger, or workflow is unclear. | Narrow the hypothesis and interview a cleaner customer set. |
| Pivot | Customers lack urgency or current behaviour does not support the premise. | Change the problem or segment before building further. |
| Stop | No meaningful pattern appears after disciplined research. | Preserve capital and move to a stronger opportunity. |
Carry the result into your product plan and fundraising story. Investors will examine whether you understand the customer’s pain, alternatives, and path to adoption. Your evidence will be stronger when it comes from observed behaviour and commitments, not from a broad market slide.
Make problem learning a team habit
Problem-solution fit is not a certificate you receive once. Customer conditions change, your first segment may differ from your initial assumption, and product work can slowly pull the team away from the original job. Keep discovery active as you build. Put customer conversations on the operating calendar, review evidence before major roadmap decisions, and revisit assumptions when adoption stalls.
Make ownership explicit. One person should maintain the interview records and evidence map, but product, sales, and founder teams should hear customer language directly. If only one person talks to customers, everyone else will build from second-hand summaries. That creates avoidable interpretation errors.
- Review one recent customer conversation in the weekly team meeting.
- Link every planned feature to a named problem pattern or customer commitment.
- Track which assumptions have direct evidence and which remain guesses.
- Re-interview customers after pilots to understand actual use, not intended use.
Our engagement models are built for founders who need to move from a problem hypothesis to product, fundraising, and go-to-market work with operating discipline. You do not need a large research function at this stage. You need a repeatable way to learn before your decisions become expensive.
Run your next problem solution fit sprint with a decision date, a narrow customer set, and proof standards that your team cannot explain away. If you are ready to turn customer evidence into a build plan, 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
What is a problem solution fit sprint?
It is a focused, time-boxed cycle of customer research and concept testing used to determine whether a defined customer segment has an urgent problem that your approach can credibly solve.
How do you know you have problem-solution fit?
You see repeated pain in a specific segment, customers already use costly workarounds, and some take concrete next steps such as joining a pilot, sharing data, making introductions, or discussing purchase timing.
Should you build an MVP before testing problem-solution fit?
Build only the smallest test needed to gain a customer commitment. In many cases, interviews, workflow mock-ups, a concierge service, or a clickable prototype can test the key assumption before a full MVP.
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 →