A business-development conversation becomes more useful when it examines an actual task rather than a list of desired features. For Thora Vietnam, the proposed discovery process will focus on recent examples, existing workarounds and the people who own the outcome. The aim is to learn enough to shape a testable offer.
Ask for the last real example
Begin with a recent occurrence: the last support request, the last handover, or the last report that needed correction. Ask the person to walk through the steps and show a redacted example if they can. Do not request credentials or confidential material just to make a demonstration feel realistic.
Questions about the past expose details that hypothetical enthusiasm often hides: missing fields, waiting time, approval steps and exceptions.
Understand the existing alternative
Ask what the team does today and why it uses that approach. A spreadsheet may be solving a coordination problem that a new chatbot would ignore. Separate inconvenience from a problem that someone is prepared to prioritize.
Also identify who uses the output, who approves a change, and who would support the system after deployment. The interview participant and the buyer may be different people.
Record evidence and contradictions
For each conversation, record the workflow, observable problem, current workaround and unanswered questions. Keep direct observations separate from your interpretation. If one person says accuracy matters and another says speed matters, preserve that difference rather than averaging it away.
This record should help Thora Vietnam decide which customer segment to investigate next. It is not a scorecard for persuading every interviewee to agree with an existing solution.
Offer a next step that tests understanding
Summarize the problem in the customer’s language and ask what you misunderstood. A sensible next step may be a workflow sketch, a small sample or a scoped pilot proposal. Treat willingness to spend time or provide an appropriate example as a signal to investigate, not proof of a sale.
Choose a workflow before a broad customer label
For a first discovery cycle, Thora Vietnam can compare candidate workflows by frequency, consequence of errors, access to someone doing the work and the ability to observe a complete case. “Small businesses need AI” is too broad to guide a conversation. “A service coordinator copies a request into several tools and checks missing information” is specific enough to investigate, but remains a hypothetical example until observed.
Keep the user, beneficiary and budget-holder distinct. A user may want a better screen while the buyer cares about response delays or support costs. Do not assume one conversation represents everyone involved.
Run an interview that can change the offer
Ask permission to discuss a recent example and to take notes. Use redacted or synthetic material when a customer cannot share the original. The purpose is to understand behavior and constraints, rather than to collect agreement with an AI solution.
- Walk me through the most recent request, from arrival to completion.
- Where did you wait, re-enter information or correct a mistake?
- What do you use now, and why have you kept that approach?
- Who checks the result, and what happens if the result is wrong?
- Who would approve a small test, and what evidence would they need?
- What would make you decide not to change the current process?
Turn notes into an evidence ledger
Record a dated observation, its source, what it supports and what it does not establish. A complaint is a useful signal, but does not establish willingness to pay. A request to see a demonstration is a next step, not a sale. Keep contrary examples visible and avoid reporting interview counts as proof of demand.
Observation and date:
Customer role and workflow context:
Current alternative and consequence of the problem:
Direct observation / reported experience / our interpretation:
Contradiction or unanswered question:
Next test agreed, if any:
Permission and limits for using the notes:Use discovery to choose the next implementation
If the observed problem is infrequent or already handled cheaply, Thora Vietnam can stop or choose another workflow. If the problem is recurring and the responsible buyer wants a test, propose a bounded discovery deliverable or pilot brief. Treat refusal, lack of access and unclear ownership as information to resolve, rather than signs that more features are needed.
When revisiting the segment later, compare new observations with the original notes. Publish anonymized lessons only with appropriate permission, and label illustrative scenarios clearly. Never turn planned interviews into a claimed customer history.
Further reading
Background for the method; the Thora Vietnam workflow above is a proposed application.
Steve Blank — Business Model Hypotheses
