FULL-TEXT REPRINT · COLLECTED READING
韩先凯 著(笔名:离谱) · byoungd and contributors
Original chapter · GitHub · CC BY-NC 4.0 · 中文原作
Noncommercial reprint. Prose is retained; layout and internal links are adapted. Collected on 2026-10-13 · Source updated 2026-09-19 · f13ff2de
On this page
From a Real Problem to First Customers
Write a business idea as a statement that could be disproved: Which people, in which situation, repeatedly face which problem, bear which cost, and would change their behavior for which outcome? If this is still difficult to describe, investigation can reveal the next step before a complete product is built.
Entrepreneurship records the author’s experience, while AI Learning, Development, and Resource-layer Entrepreneurship examines technology and delivery boundaries. This page adds a practical customer-validation process, followed by delivery and operating checks in A Sustainable Small Business. Readers can adapt both to their circumstances. The steps, sample sizes, and thresholds are suggestions from this guide; all examples are hypothetical. They are not research findings, and a handful of interviews cannot establish what an entire market wants.
1. Narrow the Idea to One Task
“Help small businesses use AI” does not yet guide action. A narrower description could be: “Shop owners who update product descriptions weekly need to turn information they have already confirmed into publishing drafts. They currently copy fields individually and sometimes omit specifications.” This identifies a person, a task, an existing approach, and an observable problem.
Record three roles separately: the user, the person deciding whether to adopt the service, and the payer. A sole trader may fill all three. In a team, a user finding something convenient does not establish that a manager will approve payment. Then state the assumption most likely to break the plan, such as “The work happens often enough to justify buying a separate service.”
Look for people who have performed the task, including those still working manually, using existing tools, or having abandoned an attempted solution. Friends are easier to reach, but label that relationship. Enthusiastic friends alone cannot explain demand from strangers. Record invitations, responses, and reasons for declining; silence is not approval.
2. Ask About Past Behavior
An interview should reconstruct a real process, not persuade someone to praise an idea. Start with questions such as:
- When did you last do this, and what triggered it?
- Could you walk through each step from receiving the task to finishing it?
- Where did you wait, redo work, or need help? Can you show an example without private information?
- What do you use now, and why do you still use it? What have you tried and abandoned?
- Who considers the task complete, who decides whether to spend money, and when will it happen again?
Obtain agreement before recording, and avoid collecting unnecessary information. If someone declines audio recording, take summary notes. Do not upload conversations or customer materials to AI without permission. Separate “the person’s words,” “observed behavior,” and “our interpretation.” Do not put your own interpretation in quotation marks.
“Would you buy this feature?” invites a prediction. “What did you do about this last time?” asks about an event. If someone says a task is frustrating, ask about its frequency and consequences. Also ask when the problem is not worth solving and when the current method is sufficient.
3. Compare with Existing Approaches
Alternatives include more than competing products: manual work, outsourcing, doing less, delaying, and doing nothing. For each approach, record the result, total time, direct spending, how errors are handled, and who would have to cooperate with a switch.
| Observation | What it can support | What it does not yet establish |
|---|---|---|
| “That sounds interesting” | Willingness to continue a conversation | Willingness to use or pay |
| A recent work sample | The task has happened | It happens often enough |
| Scheduling a trial and providing usable materials | Willingness to spend time testing | The new process beats the old one |
| Payment for a defined scope followed by acceptance | This particular exchange was accepted | Stable demand or profitability |
| Another purchase under similar conditions | A signal of recurring need | Demand across a larger population |
This table organizes evidence; it is not a universal scoring model. Counterexamples matter too. Some people need help only during peak seasons. Others trust a familiar template, or find switching more troublesome than continuing manually. Do not automatically label them as people who “do not understand the product.”
4. Test the Outcome with a Manual Pilot
Before automating, deliver a narrowly scoped service manually. Tell participants which work is human and which is tool assisted. Do not present manual operations as an automation capability that already exists.
For example, organize one batch of product information confirmed by the owner, delivering a draft and open questions without publishing on their behalf. Agree on input requirements, quantity, completion date, included revisions, acceptance, and withdrawal arrangements. If the necessary permission is unavailable or sensitive material cannot be avoided, use public examples or stop that pilot.
Save a baseline for the old process. In the new one, record work on both sides: preparation, communication, production, checking, revisions, and waiting. Time saved by the provider cannot simply be described as a saving if it becomes extra checking for the user. For AI work, use Development and Resource-layer Entrepreneurship to examine data, capability, and delivery boundaries.
Explain prices, delivery, and exit arrangements before a paid pilot. Hidden charges or exaggerated results do not create useful payment evidence. A free trial can reveal whether a workflow is usable; it does not test acceptance of a particular price. Record discounts, personal relationships, and extra attention too, because the next transaction may not include those conditions.
5. Organize Two Weeks Around One Question
Two weeks is a convenient limit, not a universal cycle. Set a different reasonable period if recruitment or purchasing takes longer. One example is:
- Days 1–2: Write one main assumption, an effort limit, the target group, and decision conditions in advance.
- Days 3–5: Reconstruct recent tasks through interviews, seek counterexamples, and document current alternatives.
- Days 6–7: Offer the same pilot scope to eligible people, recording the price, refusals, and next arrangements.
- Days 8–11: Deliver a few pilots and record quality, time on both sides, spending, and rework.
- Days 12–14: Apply the conditions written earlier, identify what remains unknown, and choose one main change for the next round.
Suppose a round plans six interviews and a maximum of twelve hours, asking only whether another paid experiment is worthwhile. Its advance conditions might require at least three people to show a recent recurring task and at least two to accept a stated pilot price and complete acceptance within the agreed scope. These are team choices, not market validation standards. Meeting them supports only another limited step.
6. Allow a Decision to Change or Stop
Suppose four of six people have a recent task and two pay, but one delivery substantially exceeds its time allowance. A defensible conclusion is “There is an initial payment signal, but delivery costs are not yet workable.” It is not “The product is validated.” The next round could narrow input requirements and measure rework, without immediately hiring or adding features.
- Continue: The advance conditions were met within the effort limit. Retain the working scope and expand the sample slightly or observe repeat purchases.
- Adjust: There is a need, but a process, scope, or price assumption did not hold. Change one main variable in the next round and explain why.
- Stop or pause: Core conditions were not met, the target group could not be reached, or the effort limit was reached. Settle commitments and record what new evidence would justify restarting.
With insufficient observations, the conclusion is “not enough evidence.” It is neither success nor necessarily failure. For every decision, write down what new fact would change your judgment. Record it in the Startup Experiment Card, then check delivery and costs with A Sustainable Small Business.
Explain the Experiment in English
Try reporting to a peer in four sentences, retaining numbers and uncertainty. Do not translate “people were interested” into “validated demand”:
We tested whether shop owners would pay for a narrowly scoped service. Two people paid for a pilot, but one delivery exceeded our time limit. This suggests some willingness to pay; it does not establish a sustainable business. Next, we will test a smaller scope and track revision time.
Useful terms: customer discovery (了解用户问题), current workaround (现有应对办法), willingness to pay (付费意愿), and disconfirming evidence (不支持假设的证据).