Lean product strategy
Building stopped being the hard part.
Lean product strategy is the practice of building the smallest thing that tests the assumption your business rests on. For most of that time the expensive part was building it. In the last year that stopped being true for a large class of products, and it changes what the method is for.
What it actually says
The definition that gets quoted — the smallest shippable version of the product — is not the one Eric Ries wrote. An MVP is “not necessarily the smallest product imaginable” — it is “the fastest way to get through the build-measure-learn feedback loop with the minimum amount of effort.” The unit is the learning. The product is whatever produces it most cheaply.
Which is why a landing page with a real price on it, a data sheet, a two-minute video, or a form that a person answers by hand have always counted. None of them is a small version of the product. Each of them is a way of asking a question that would otherwise be answered by building.
Read that way, the method was never about shipping quickly. It was about not paying to find out something you could have learned for less.
What changed this year
Steve Blank has taught the Lean LaunchPad at Stanford for fifteen years; a good deal of this method was worked out there. This spring, every team arrived on the first day with a finished product — the kind of thing the ten-week course was meant to produce by the end of it — built with AI before the class began. Then they learned less than the cohorts that had arrived with nothing but a hypothesis.
The teaching team's first finding was that a product on day one means an MVP is no longer evidence of anything: not discovery, not hypothesis testing, not product-market fit, not even commitment. Blank's own view is that this is the symptom of something larger. It is also the symptom that turns up in your roadmap.
The failure has a shape, and it is worth knowing before you meet it. Cheap building lets a bad idea travel faster. A polished artefact reads as progress, so the team starts collecting compliments instead of looking for the evidence that would kill it. And a thing you have already built is expensive to abandon whatever it cost to make — they pivoted late if at all, where the cohorts before them had pivoted three or four times.
One moat went with it. The time and money it took to build used to hold competitors off on its own. It no longer does — the customer you are selling to can generate an alternative in the same week you can. Distribution and switching costs still work; being first to a working build does not.
How we work it
None of that makes the method obsolete. It makes the deciding half the whole job, and the building half nearly free. So the work moves to the front.
Plan the loop backwards
Build, measure, learn is the order it happens in, not the order to plan it in. Decide what you need to learn, then what would count as measuring it, then the smallest thing that produces that measurement. Teams that plan it forwards build first and look for a question afterwards.
Write the outcome before anything exists
Not a feature and not a user story: the change in behaviour that would count as working, and the window it has to happen in. Agreed in writing, before the first screen. Everything produced after that gets measured against it rather than admired.
Prefer the test that is not a build
A price on a landing page, a form answered by hand, a week of doing the service manually for five customers. These were always legitimate. Now that a built thing proves less, they prove comparatively more — and a price on a page still answers in a day.
Name the assumption that would end it
Every idea rests on something that, if false, makes the rest irrelevant. Usually it is whether anyone will pay, or whether the behaviour you need already exists. That is the one to test first, even when it is the hardest and least satisfying to test.
What it is not
Not a low-budget approach
Lean describes the size of the bet, not the cost. Validation is not free — it is just cheaper than building the thing and finding out.
Not skipping the research
It is research, with a build attached only where building is the cheapest way left to ask. The interviews still happen. They happen first.
Not ship it and see
Shipping without a stated outcome is not an experiment, it is a release with optimism attached. If nobody wrote down what would count, nothing that happens next will settle anything.
Not a generated prototype
Something generated in an afternoon and shown to nobody is an untested idea with a user interface. It is the most convincing artefact in the room and the least informative.
Questions we get
See it in the product planWe already have a roadmap. Do we need this?
Only if nobody can say what has to be true for the top item to be worth building. A roadmap is an order of work; this is the reason that order is right. Teams with a confident roadmap and no stated assumptions are the ones this costs the least and saves the most.
Is this not just discovery?
Discovery is the research half. This is the research half plus a decision with a number attached to it and a date by which it is answered. The difference shows up at the end: discovery produces findings, and this produces a call on whether to build the thing.
You build MVPs with AI yourselves. Is that not the thing you are warning about?
We do, and in days rather than weeks. That is the point: when a product can be built that fast, the building is not the part that proves anything. So we agree what would count as working before we start, and what comes out is the instrument rather than the finding. The warning is not against building quickly. It is against letting a fast build stand in for the answer.
What do we get at the end?
A decision, the evidence behind it, and what it would take to change it. Usually a page, sometimes a paragraph. Where the answer is to build, you also get the scope that follows from it — which is normally smaller than the one you arrived with.
How long does it take?
A first answer in one to two weeks, because the questions worth asking are answerable in that time or they are the wrong questions. It runs inside the work rather than as a separate engagement — the first fortnight of most things we do, on a subscription or a fixed-price project.
What has to be true for this to work?
If you can answer that in a sentence, you probably do not need us for this part. If the answer takes a meeting and people disagree, that is the thing to settle before anyone builds.
Work with us