A founder who can build quickly faces a particular temptation: interpreting every complaint as permission to start coding. Yet a complaint may describe an occasional annoyance, a symptom of a different constraint, or a problem that the speaker cannot pay to solve. Before choosing a solution, you need to understand the work closely enough to distinguish these situations.
Chapter 1 introduced an evidence-led operating rhythm. This chapter focuses that rhythm on customer discovery. We will continue with the hypothetical reporting-automation service and develop a practical way to investigate who struggles, what happens today, and why a change might matter. The proposed application to Thora Vietnam remains a plan for learning, without implying completed customer research.
Define a segment you can actually investigate
“Small businesses” covers too many workflows to support a focused conversation. Choose a narrower group using characteristics that affect the problem: the type of service delivered, team size, reporting frequency, customer expectations, or the systems already in use. You need a segment whose members face sufficiently similar circumstances to compare observations.
For example, start with operations leads at small agencies that prepare weekly client status reports from several project tools. This is still a hypothesis. You may learn that account managers own the work or that the difficult step is obtaining approval rather than combining data.
Write down why you chose the segment and how you will reach participants. Access through your personal network can be useful, but it may overrepresent friendly respondents. Keep the recruitment context with the findings so that enthusiasm from a few acquaintances is not mistaken for broad demand.
Ask about recent behavior
Invite the participant to describe the last time they completed the job. Ask what triggered it, which inputs were needed, who was involved, and where the work slowed down. A recent example is easier to examine than a general opinion about whether automation sounds useful.
Useful questions include: “Walk me through last week's report,” “What did you do when an update was missing?” and “Who checked the result before it went to the client?” If appropriate and permitted, ask to see a blank template or a redacted example. Do not request confidential client information simply to make the interview feel concrete.
Avoid presenting your preferred product too early. Once the participant starts reacting to a proposed dashboard, the conversation becomes a concept test. That can be useful later, but it interrupts the opportunity to understand the existing workflow on its own terms.
Distinguish the user, buyer, and risk owner
The person preparing a report may not control the budget. An owner may approve spending, while an IT provider decides whether an integration is allowed. Each participant can describe different constraints. A product that helps the user but fails the buyer's financial test or the risk owner's access requirements may never be adopted.
Map the decision roles in plain language. Identify who feels the pain, who benefits from improvement, who authorizes spending, and who can block deployment. In a small company these roles may overlap, but do not assume that they do.
For a proposed Thora Vietnam pilot, this map would influence the offer. A hands-on operations user might assess the report format. The business owner would assess the pilot cost and expected benefit. A person responsible for data would need to understand what is shared, where it goes, and how access ends.
Investigate the current alternative
A spreadsheet, a weekly meeting, an assistant, or tolerating a delay is already a solution of some kind. Understand why that alternative persists. It may be familiar, flexible, or adequate for the volume of work. Replacing it introduces switching costs that your offer must justify.
Ask what the participant has already tried and what happened. Someone who created a template, hired help, or investigated another tool has shown behavior worth exploring. A person who has never sought an alternative may still have a serious problem, but you need to understand why action has not happened.
Do not dismiss manual work as inherently wasteful. Human review may be the step that catches a client-sensitive issue. The opportunity could be preparing inputs for that review rather than removing the reviewer. Accurate discovery keeps automation from damaging the part of the process that creates trust.
Turn conversation notes into comparable evidence
Capture observations separately
Record a brief description of the participant and workflow, the concrete event discussed, the workaround, and the consequences. Mark direct statements as statements and your interpretation as interpretation. Keep unnecessary personal or confidential data out of the record.
Look for a repeated pattern
Compare similar jobs across participants. Does the same delay occur? Does it affect the same role? Are the consequences important enough to change behavior? A repeated word such as “busy” is weaker than several specific descriptions of the same costly handoff.
Keep contradictions visible
If one participant reports a serious problem and another finds the process easy, investigate the difference. Perhaps their systems, customer contracts, or review requirements differ. Contradictions often help define a better segment; they should not disappear from a summary intended to support the founder's original idea.
Write a problem brief before a feature brief
A problem brief names the user, context, current workflow, consequence, and evidence supporting the interpretation. Include the unresolved questions. Keep the proposed solution in a separate section so that changing the implementation does not erase what the team learned about the problem.
For the reporting example, a brief might say that account managers repeatedly chase missing project updates before preparing a client report. The consequence may be a delayed approval window rather than the time spent formatting. This suggests a different experiment from generating a polished report automatically.
Use the brief to ask a participant whether you understood the workflow correctly. That check does not validate a business model, but it can catch an inaccurate interpretation before the team commits to a prototype. It also demonstrates that the conversation was about understanding their work.
Choose the next question deliberately
If the problem is poorly understood, continue discovery with a narrower question. If the problem is recurring but its importance is uncertain, investigate the consequences and existing spending. If the problem is well understood, a small concept test may help assess whether your proposed outcome fits the workflow.
Set a decision rule for the next cycle. For instance, the team may require several independently described examples of the same approval delay before building a sample workflow. That is a local research decision, not a statistically representative claim about the market.
The first chapter's evidence record remains the place to connect each observation to a decision. Discovery loses value when its results become presentation material that never changes the product plan.
Conclusion: understand the job well enough to change your mind
Finding a worthwhile problem requires specificity, recent behavioral examples, and a willingness to hear evidence that conflicts with the idea. Learn who does the work, how the current alternative functions, and what would make a change worthwhile. A focused problem brief is a stronger foundation for implementation than a long list of requested features.
Before the next chapter, prepare an interview guide and conduct a small discovery cycle within one segment. Write down what remains uncertain. Chapter 3 will use that problem understanding to design a modest business-model experiment, including its budget, offer, and interpretation rules.
