On this page
A student team in Coimbatore can spend one Saturday mapping 20 neighbourhood businesses and learn more than it would from a month of classroom debate. Student founders local SME customer discovery projects work when they produce evidence: who has a recurring problem, what they do today, what the problem costs, and whether they will change behaviour. The goal is not to “support SMEs” in the abstract. The goal is to find one painful workflow that a specific business owner wants solved.
Start with a narrow local SME problem
“Local SMEs need technology” is not a project brief. It is a category statement with no customer, no workflow, and no testable problem. Student founders need a smaller starting point: a type of business, a location, a job the owner repeats, and a moment where that job breaks down.
Choose businesses you can reach without introductions. A student in Chennai might study independent tuition centres around campus. A team in Madurai could focus on spare-parts retailers. In Tiruppur, the first wedge could be small garment units managing repeat buyer enquiries. Do not combine all three into one project.
Make the customer definition operational. “Retailers” is too broad. “Owner-managed electrical retailers with two to five staff who receive customer orders on WhatsApp” is a usable first segment. You can find them, interview them, compare their answers, and see patterns.
A usable discovery brief has four parts: customer type, geography, repeated job, and suspected friction. If one part is missing, your project will collect opinions instead of evidence.
At Nebula, we work through Idea, Market, Product, Team, Fit, Validate, Funding, and Scale. Local discovery belongs early in that sequence. You earn the right to discuss an app, marketplace, or AI tool only after you can describe the existing work clearly. Review our venture-building process before turning early observations into a product plan.
Build a business list before you ask questions
Your first asset is not a slide deck. It is a clean list of businesses you can contact. Build it from street visits, local directories, trade clusters, family networks, campus alumni, and referrals from the first owners you meet. Record enough detail to return to the same person and compare businesses properly.
Do not begin with a form asking owners to rate your idea. Forms create distance and usually attract the people least affected by the problem. Start with a list, then meet people where their work happens: at the counter, in the workshop, at the dispatch desk, or after their busiest hours.
| Field | Why you need it |
|---|---|
| Business type and location | Keeps your segment specific |
| Owner or operator name | Lets you follow up with context |
| Daily workflow observed | Separates facts from assumptions |
| Contact permission | Sets a respectful basis for future calls |
A list also reveals access risk early. If your team cannot get ten conversations with a segment in two weeks, do not assume you will later acquire that segment as customers. Change the segment, find a better access route, or bring in a team member with credible local relationships. Discovery is partly a test of distribution.
Ask about recent work, not imagined solutions
The most useful interview question is usually about a specific event that happened recently. Ask an owner to walk you through the last time they lost an order, chased a payment, reordered stock incorrectly, handled a customer complaint, or trained a new staff member. Then keep moving from the summary to the details.
Ask what happened first, who was involved, what tool they used, where the delay occurred, and what happened next. If they say, “We manage it manually,” ask them to show the notebook, spreadsheet, WhatsApp thread, or billing system they used. Permission to observe the work is stronger evidence than a positive response to your pitch.
- “Tell me about the last time this happened.”
- “What did you do before the problem appeared?”
- “What did it cost in time, money, missed sales, or staff effort?”
- “What have you already tried to fix it?”
- “Who would decide whether to pay for a change?”
Avoid asking, “Would you use our platform?” Most owners will be polite, especially when speaking to students. Politeness is not demand. Ask for past behaviour, current workarounds, and permission to return with a small test. Record direct quotes accurately, but do not treat a quote as proof until you see the same pattern across multiple businesses.
Turn patterns into small tests
After a set of conversations, write down every problem mentioned and group them by workflow. You are looking for repetition, urgency, and an existing workaround. A problem becomes promising when similar businesses describe it without being led, suffer it often enough, and already spend effort or money dealing with it.
Do not build software because three owners said a problem exists. Run a manual test first. If local retailers struggle to track incoming customer enquiries, offer to organise a week of enquiries using a shared sheet and a defined follow-up routine. If workshops lose visibility on service jobs, test a simple job-card process before designing a dashboard.
Your first test should produce a behaviour change. Ask an owner to send real data, follow a new process, introduce you to a staff member, or schedule a second working session. Each action carries more weight than verbal approval.
Write one hypothesis per test: “If we help this segment complete this job in a simpler way, they will do this specific action.” Decide the success condition before starting. A test without a defined action and review date becomes unpaid consulting. Your project needs evidence that can support a product decision, not a collection of helpful tasks.
If you need a structured way to pressure-test these choices with other founders, apply for Nebula 1.0. Bring your interview notes, not a polished story.
Capture evidence a founder can use
Discovery notes fail when each student records information differently. One person writes a story, another saves voice notes, and a third remembers only the positive comments. Use one shared format after every visit. The format should make it easy to compare businesses without stripping away the context of each workflow.
For every conversation, capture the customer segment, the event discussed, the current process, the people involved, the workaround, the cost or consequence, and the next commitment. Mark what you observed directly, what the owner said, and what your team inferred. Those are different levels of evidence and should never be mixed.
- Observation: You saw the owner search old chats for an order.
- Claim: The owner said this happens several times a day.
- Inference: A structured order record may reduce search time.
- Test: The owner agrees to use a manual order record for one week.
This discipline protects student founders from falling in love with their own interpretation. It also makes handovers possible when exams, internships, or team changes interrupt the project. A future co-founder, product builder, or investor should be able to read your notes and see how you reached each conclusion.
Evidence is also the raw material for a better founder narrative. Instead of saying you are building for “India’s SME market,” you can explain the exact operator, workflow, failure point, and first behaviour you want to change.
Work with local businesses with clear boundaries
Local access is an advantage only if you treat it responsibly. Small business owners are busy, and many have seen students, agencies, and vendors promise help without returning. Be clear that you are researching a problem. Do not claim that you have a finished product, funding, partnerships, or outcomes you cannot deliver.
Set expectations at the start of every interaction. Say how long the conversation will take, whether you are taking notes, how you will use the information, and whether you may contact them again. If an owner shares pricing, customer details, supplier terms, or personal information, do not circulate it inside a college group or use it in a public presentation.
Never treat access as consent. A shop owner allowing you into the premises does not give permission to photograph documents, record staff, publish names, or share business data with others.
Give something useful back without turning discovery into a promise. Send a short thank-you note, share a cleaned-up version of a process you documented if they request it, or return with the result of a test they joined. Close the loop even when you decide not to pursue the problem.
Respect also improves your data. Owners are more likely to describe failures honestly when they believe you understand their time constraints and will not misuse what they share. Trust is built in small actions: arriving when promised, asking permission, and following through.
Decide what to build, pause, or drop
At the end of a discovery project, your team should make a decision, not produce a vague recommendation. Choose one of three outcomes: continue with a defined manual pilot, pause until you can answer a specific unanswered question, or drop the problem and move to another segment. Dropping a weak idea is progress when the evidence is clear.
Use a simple review meeting. Put the evidence on the table: repeated problem instances, observed workarounds, people affected, willingness to take a next action, and the access route for a pilot. Then list the assumptions that still need testing. If the project depends on assumptions you cannot test locally, it is not ready for product work.
- Continue when owners take real next steps and the workflow repeats.
- Pause when the problem appears real but the buyer, user, or payment path remains unclear.
- Drop when interest is polite, pain is infrequent, or no one changes behaviour.
The strongest student projects do not pretend to have solved every problem. They show disciplined learning and a credible next step. That is the foundation for validation, product choices, and later fundraising. Explore how Nebula works with founders from prototype through scale-up through our engagement models.
Turn your next local business visit into evidence. Build a narrow list, run honest conversations, test one behaviour, and document what changes. When you are ready to turn that evidence into a founder path, Apply for Nebula 1.0.
Enjoyed this? Get the next one in your inbox.
Fundraising guides and validation frameworks, every two weeks. No spam.
Frequently asked questions
How many SME interviews should student founders conduct?
Start with enough conversations to compare patterns within one narrow segment. Continue until repeated workflows, workarounds, and buyer roles become clear, then run a small behaviour-based test.
What should student founders ask local SME owners?
Ask about recent events: the last missed order, delayed payment, stock issue, customer complaint, or staff problem. Focus on what happened, the current workaround, the consequence, and who decides to pay for a solution.
Should student founders build an app after customer interviews?
No. Run a manual test first. Ask for a real behaviour change, such as sharing data, using a temporary process, or scheduling a follow-up working session.
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 →