Lean Startup
Turn risky assumptions into evidence before you spend money building the wrong thing.
12 min · Eric Ries
What is this framework?
Lean Startup says: don't build a full product on a guess. Instead, name your riskiest assumption, run a small experiment, look at the real evidence, and decide whether to keep going, change direction, or stop. Repeat this cycle quickly and cheaply.
Eric Ries developed Lean Startup from his own experience building products nobody wanted, and from studying lean manufacturing at Toyota. His central insight was that a startup is not a smaller version of a big company — it is an organisation searching for a repeatable, scalable business model under conditions of extreme uncertainty. That search should be managed scientifically, not with a five-year business plan.
The method reframes entrepreneurship as a sequence of experiments. You surface the assumptions your idea depends on, rank them by risk, and test the riskiest ones first with the smallest possible investment of time and money. Evidence from real customer behaviour — not opinions, surveys, or your own conviction — decides what happens next.
For Malaysian students building campus or community ventures, Lean Startup is useful precisely because you have limited capital and time. It stops you from spending a semester's savings and effort on an app or product before knowing whether anyone will actually pay for it or change their behaviour because of it.
What problem does it help solve?
- Avoids months of wasted building on an unvalidated idea
- Forces you to identify which assumption, if wrong, kills the whole venture
- Gives you a repeatable discipline for testing before scaling
- Replaces founder opinion with real customer evidence
- Makes pivoting a planned, rational response rather than a panic decision
The framework
The cycle repeats: each decision either confirms the direction, adjusts it, or triggers a pivot — and produces a new assumption to test.
Every part explained
Assumption
The specific belief your venture depends on that has not yet been proven true.
Ask: If this turns out to be false, does my whole idea collapse?
Example: Students will pay RM3 extra to skip the canteen queue during peak hours.
Experiment
A small, fast, low-cost action designed to produce real evidence about the assumption.
Ask: What is the smallest thing I can do this week to test this?
Example: Take pre-orders via WhatsApp for priority pickup at one canteen stall for five days.
Evidence
What actually happened, measured as a number or observed behaviour, not a feeling.
Ask: What did people actually do, not what did they say they would do?
Example: 18 of 60 students approached placed a pre-paid priority order across the week.
Learning
The insight you extract from comparing evidence against your expectation.
Ask: What does this evidence tell me that I did not know before?
Example: Willingness to pay exists mainly in the 12–1pm rush, not throughout the day.
Decision
The concrete next step: persevere, adjust the idea, or pivot away from it entirely.
Ask: Based on this evidence, what should I do next, and why?
Example: Persevere, but narrow the service to the 12–1pm window only for now.
Minimum viable product
The smallest version of your offer that lets you run the experiment and collect evidence.
Ask: What is the leanest version of this that still tests the real assumption?
Example: A shared WhatsApp order form instead of a custom-built ordering app.
Worked example — CampusEats — priority food pickup service
A team believes students will pay a small premium to avoid canteen queues between classes.
Riskiest assumption
Students will pay RM3 extra for guaranteed pickup within 5 minutes during the lunch rush.
Experiment design
Offer RM3 priority pre-order via WhatsApp for one stall, for five lunch periods, no app built.
Minimum viable product
A WhatsApp broadcast list, a shared order form, and a labelled pickup counter.
Evidence collected
27 pre-orders placed out of roughly 150 students who saw the WhatsApp broadcast; repeat orders from 9 students by day five.
Learning
Willingness to pay is real and concentrated among students with back-to-back classes; the RM3 price was not resisted.
Decision
Persevere: expand to two more stalls next week and test whether repeat usage holds over a longer period.
Next assumption to test
Students will keep pre-ordering after the novelty wears off, without reminder messages.
Note that CampusEats spent under RM50 and one week to learn this, instead of building a delivery app first.
How to use it
- 1List every assumption your business idea depends on to work.
- 2Rank them by how much risk they carry and how little evidence you currently have.
- 3Pick the single riskiest, least-proven assumption to test first.
- 4Design the cheapest, fastest experiment that could produce real evidence about it.
- 5Build only the minimum viable product needed to run that experiment.
- 6Collect evidence from actual behaviour, not opinions or hypothetical answers.
- 7Extract the learning and make an explicit decision: persevere, adjust, or pivot.
- 8Repeat the cycle with the next most important assumption.
Try it yourself
Work through one full Lean Startup cycle for your own idea.
Cycle
Your work stays on this device. Nothing is uploaded, so use the same browser to come back to it.
When to use it
- At the very start of a venture, before writing code or ordering inventory
- Whenever you are about to invest significant time or money based on a guess
- When deciding whether to keep, adjust, or abandon a feature or product line
- Before scaling anything you have not yet tested with real customers
When not to rely on it
This framework does not prove:
- • It does not prove a business is profitable at scale, only that an assumption holds at small scale
- • Early evidence from a tiny sample can be misleading if the sample is unrepresentative
- • It works less well for ventures requiring large upfront capital or regulatory approval before any test is possible
- • Speed can be overvalued if teams treat every cheap answer as sufficient evidence, regardless of quality
Common mistakes
- Testing an assumption that does not actually threaten the business if wrong
- Building a fuller product than necessary because 'MVP' gets treated as version one of the final product
- Counting opinions, likes, or survey answers as evidence instead of observed behaviour
- Running one cycle and then reverting to a rigid multi-month plan instead of repeating the loop
Connections
Related concepts
Related frameworks
Quick check
What should you test first when applying Lean Startup?
Remember this
Test your riskiest assumption cheaply before you invest in building anything bigger.