Concept
Learning first
Learning first is the founder's ordering rule: decide what you must learn before you decide what to build, and treat every build as a question put to customers rather than a deliverable put on a roadmap.
The rule sounds obvious and is violated constantly, because building feels like progress and learning feels like delay. A founder with a learning-first posture asks, before each week of work, which belief the work will test and what result would change the plan. If no result would change the plan, the work is not an experiment; it is a feature, and features come after the assumptions underneath them have survived contact with customers. The posture also changes what counts as a good outcome. An MVP that customers ignore is a success if it settles a question cheaply that would otherwise have cost six months; a polished launch that teaches nothing is a failure even if the press is kind. Ries's phrase for the alternative is 'achieving failure': executing a plan flawlessly and arriving somewhere nobody wanted to be.
A real-life example
A founder in Antalya wanted to build a booking platform for boat tours. Learning first meant her first month had no code at all: she stood on the marina for three weekends, counted how tourists actually chose a boat, and learned that most decided by price and departure time in under a minute. The platform she eventually built showed exactly those two things first, and nothing else above the fold.
How to use it
- 1Before each week of building, write the belief it tests and the result that would change your plan; if nothing would, do the learning first.
- 2Judge an MVP by the question it settled, not by how customers reacted to it.
- 3Keep a list of beliefs that have survived a customer test; only those may be built on.