Customer Discovery for Startups in Estonia

Choose the decision before the questions

Start with an uncertainty that affects what you build. You might need to learn whether a task happens often enough, whether mistakes are costly or who can approve a purchase. Write the assumption and the evidence that would make you change your mind. An interview without a decision behind it easily becomes an interesting but unusable conversation.

Illustrative example: a Tallinn team considering software for small logistics companies could investigate how dispatchers handle last-minute schedule changes. That is narrower than asking whether the transport industry needs better software. Interview the person doing the work and, separately, the person controlling the budget. Their priorities may differ.

Recruit beyond your immediate circle

Define the role, company type and situation you want to study. Ask a contact for an introduction to someone who fits that description, rather than to anyone interested in startups. Include people using competing tools and people who chose not to buy software. Hearing why a spreadsheet is sufficient can be as valuable as finding an unhappy user.

Our suggested first batch is eight to twelve interviews within one segment. This is a manageable learning exercise, not a statistically representative survey. Record how each participant was recruited. If every interview comes from one friendly partner, identify that limitation before generalising to the wider Estonian or international market.

• Use the same customer definition for the first batch.
• Include at least one person who is satisfied with the current approach.
• Explain the purpose and ask permission before recording.
• Do not publish names, screenshots or quotes without appropriate permission.

Ask for the last real example

Invite the participant to walk through the most recent occurrence of the problem. Ask what triggered it, which steps they took, who else was involved and what happened afterwards. Follow up on vague statements with a request for a specific example. A screen share or document can clarify the workflow, but let the participant remove sensitive information first.

Keep your product pitch for a separate part of the conversation. Questions such as 'Would you use an easier tool?' invite speculation. A more useful question is 'What did you try the last time this happened?' Ask about actual purchases and approval processes without assuming that the interviewee can commit their employer to a pilot.

• When did this last happen?
• How did you solve it, and how long did that take?
• What have you already tried to change?
• Who would need to approve a different approach?

Keep observation separate from interpretation

After each interview, use a consistent note format: recent example, frequency, consequence, workaround, buying process and unresolved question. Label direct observations, participant estimates and your own interpretation separately. 'They manually edited five routes yesterday' is different from 'They need an AI scheduling platform'. The second statement is still your hypothesis.

Compare patterns across interviews without erasing differences. One large buyer's unusual integration request should not automatically become the roadmap for every small customer. Note contradictory evidence and the cases where the problem has little consequence. A pattern table is most useful when it shows both the strongest signal and the reasons to doubt it.

Move from conversation to commitment

Choose the smallest follow-up that tests the remaining uncertainty. An introduction to a budget owner, an agreed workflow observation or a paid, clearly scoped pilot provides different evidence from a compliment. Do not turn every interview into a sales meeting, but ask whether the participant is willing to take a specific next step when that is appropriate.

For the fictional logistics example, offer a manually assisted scheduling report for one week before building an automated platform. Define the inputs, promised result and review date. Decide in advance what outcome would justify another experiment. A small pilot can challenge a hypothesis; it cannot by itself establish product-market fit or prove demand across countries.

Use a two-week discovery plan

In the first two days, write the customer definition and discussion guide. Spend the next week recruiting and interviewing, then reserve time to compare notes before changing the product. End the second week with one decision: test an offer, investigate a different segment or stop work on this particular problem. This timetable is a suggested starting point, not a requirement.

Y Combinator's public Startup School collection includes a talk on speaking to users if you want further study. For a community discussion, bring an anonymised pattern table and the question you still cannot answer. A precise request for feedback is more useful than sharing a long transcript or asking whether the entire idea sounds promising.

Sources: Y Combinator: public Startup School talks