A startup can meet every delivery deadline and still build something that nobody needs. That is the uncomfortable starting point for Lean Startup work. Early progress depends on discovering which assumptions about customers, value, delivery, and payment are true enough to support the next decision. A polished plan does not supply that evidence by itself.
This series is written for founders and small technology teams deciding where to spend limited attention and money. We will use a hypothetical workflow-automation service as a continuing example. For Thora Vietnam, the methods described are a proposed operating approach for current and future business development and AI automation work. They do not imply customers, revenue, or experiments that have already happened.
Separate a business assumption from a business fact
Suppose a founder believes small professional-service firms lose time preparing weekly client reports. That belief contains several separate assumptions: the work happens often, someone considers it painful, the person can influence a purchase, and an outside service can improve the process safely. A product idea hides all of them inside the word “opportunity.”
Write the assumptions separately. “Operations managers at small accounting firms spend Friday afternoon combining project updates” is more testable than “businesses need automation.” It identifies a person, a setting, and an observable activity. It also makes disagreement useful: evidence can show that the real problem occurs elsewhere.
Keep a distinction between what someone said, what you observed, and what you inferred. A customer describing a frustrating report is an observation. Concluding that they would pay for your preferred software is an inference requiring another test.
Recognize when you are searching
Steve Blank's distinction between searching and executing is a useful starting point: an early venture has important parts of its business model still unresolved. Management practices designed for a repeatable operation cannot remove that uncertainty simply by adding detailed forecasts.
During search, a missed assumption is information. Once a repeatable offer exists, the same failure may indicate an execution problem. For example, a prospect declining an exploratory conversation does not necessarily mean a sales process is broken. It may mean the proposed customer segment or problem description is wrong.
Name the stage for each initiative rather than labeling the whole company. Thora Vietnam could use an established delivery checklist for a known service while separately testing demand for a new automation offer. Evidence requirements should match the uncertainty of each activity.
Replace feature milestones with decision milestones
“Launch a dashboard” describes output. “Learn whether managers will use a shared weekly reporting workflow” describes a decision. The second milestone helps a team choose what to build and what to leave manual. It also makes stopping an experiment a legitimate outcome.
A useful decision milestone states the assumption, the proposed test, the signal to observe, and the action that follows. If prospects cannot describe a recurring reporting difficulty, do more problem discovery. If they describe the difficulty but cannot share representative inputs, investigate access and trust before building an integration.
This approach does not eliminate delivery discipline. Give the experiment a deadline, an owner, and a spending ceiling. The difference is that completion means the team can make a better decision, even when the evidence argues against the original idea.
Design the smallest credible test
Match the test to the question
An interview can reveal how reporting currently works. A sample report can help a prospect assess output quality. A paid, clearly scoped pilot can test willingness to commit resources. These tests answer different questions; none should be treated as proof of the entire business model.
Preserve the conditions that matter
A manual demonstration may be appropriate if the question is whether the result is useful. It becomes misleading if you claim the process is fully automatic or conceal the work required. Explain the experimental arrangement and use data that the participant is permitted to provide.
Decide what would change your mind
Write the interpretation rules before seeing the result. A founder who counts every polite response as validation cannot learn much from a test. Include a negative outcome and an ambiguous outcome, along with what the team would do in each case.
Use constraints to protect learning
A limited budget can encourage focus, but spending less is not automatically learning more. A free survey sent to the wrong audience may be cheap and uninformative. A small number of carefully chosen conversations may require more effort and provide better evidence about a specific workflow.
For an initial Thora Vietnam experiment, the proposed constraint could be one customer segment, one reporting job, and one short discovery cycle. The exact number of conversations and days should fit access and availability. Any threshold is an internal decision rule, not a universal formula for success.
Budget founder time as well as cash. Include preparation, follow-up, prototype work, and analysis. If an experiment repeatedly expands without resolving its question, narrow the question or acknowledge that a different research method is needed.
Keep an evidence record the team can revisit
Create a simple log containing the date, assumption, participant context, observation, interpretation, and next decision. Store personal information only when necessary and with appropriate permission. A useful record should let another team member understand why the direction changed without reconstructing a long conversation history.
For example, record that a coordinator showed a weekly spreadsheet and described three approval steps. Separately record the hypothesis that approval delays matter more than report preparation. That separation prevents a plausible interpretation from later being remembered as a confirmed customer statement.
At the end of a cycle, review conflicting observations rather than averaging them away. If two firms have different workflows, the right response may be narrower segmentation. It may also reveal that a supposedly repeatable service would require extensive customization for each customer.
Decide whether to continue, change, or stop
Continuing is justified when the evidence supports the next limited investment. Changing direction is justified when a specific assumption fails and another plausible route emerges. Stopping is justified when the expected learning or commercial opportunity no longer warrants the cost. None requires pretending that a failed test was a success.
Avoid changing every assumption at once. If you switch the customer, problem, price, and channel simultaneously, you will struggle to interpret the next result. Keep a short decision note explaining which assumption changed and which ones remain uncertain.
The Lean Startup methodology emphasizes learning through a build-measure-learn cycle. In practical terms, your team needs an explicit question before building and a decision after measuring. Activity without either end can become an expensive habit.
Make the operating rhythm practical
A weekly review can be enough for a small team if it reliably produces decisions. Bring the evidence log, current spending, unresolved risks, and the next proposed test. Discuss what changed in the team's understanding before discussing a longer feature list. Assign a single owner to the next experiment.
For Thora Vietnam, this would mean keeping business discovery and AI-assisted implementation connected. Engineers should hear the problem evidence. Business development should understand what delivery and maintenance actually require. A fast prototype is helpful when it tests a meaningful assumption, rather than becoming a reason to avoid speaking with potential users.
Conclusion: earn the next investment
Lean Startup work gives a small team a disciplined way to decide what deserves more effort. Turn beliefs into explicit assumptions, choose credible tests, preserve the evidence, and let the result influence the plan. The aim is a business model that can be delivered responsibly and repeated, not a collection of experiments for their own sake.
Start by listing the five assumptions that would most damage your idea if they proved false. Choose the one you understand least and define a modest test. Chapter 2 will show how to investigate the customer problem before turning that test into a solution.
