The cost of building the wrong thing, now that it is cheap
Building the wrong thing used to be a failure you could point at. Months spent, nothing to show, a team that knew it halfway through. That is not what it costs any more. When a working version takes an afternoon, the wrong thing is nearly free to build, and the price is everything you did not build instead.
Prototyping that took weeks of specialist design and front-end time now costs close to nothing, which means a team can explore five or ten versions of an idea instead of committing to one or two. Running that many options used to be indefensible, and it was: nine of them were always going to be thrown away, and throwing away nine sprints is money you have to explain to a board. Throwing away nine afternoons is not.
So the decision in front of you changed shape. It used to be which one do we build. It is now how many do we run, and how we tell them apart when they come back.
What did not get cheaper
The build got cheap. Deciding what to build did not. That reads as a platitude until you notice what it does to the order of work: the expensive step is now the one that happens before anyone opens a laptop, and it is the step with no impressive artefact at the end of it.
That step has a name that the people selling it have damaged. Teresa Torres draws the line as cleanly as anyone: discovery is “the work that we do to make decisions about what to build”, while delivery is the work of building and shipping something you can put in front of real customers. Discovery is a decision-making process. It is not a documentation process, and that difference is the whole argument.
What it decides is which risk is going to sink you. Marty Cagan’s four are the ones worth walking through, and none of them need an engineer to explain:
- Value. Will anyone choose this over what they do today?
- Usability. Can they work out how to use it?
- Feasibility. Can it be built with the people and the systems you actually have?
- Viability. Does it work for the rest of the business: how it reaches a market, and what it commits you to legally?
They are rarely equally significant, and value risk is usually the hardest. Discovery is picking the one or two that would sink the build, and testing those before the build starts.
Which is close to the opposite of the thing you have probably been sold under that word. A discovery phase from a supplier usually ends in a document: an audit, a workshop write-up, a specification. That is its standard commercial shape, and it is a reasonable thing to buy. It is not the same activity. One ends with a shorter list of things you have to guess about. The other ends with a longer list of things you have agreed to build.
It also answers what the cheap prototypes left open. When five versions come back, the four risks are what you compare them on.
What the prototype replaces
I have written the thousand-word version of an argument to get a room to agree with it, and I have built the two-hour version instead. The built one wins, and the writing was not the problem. A document asks everyone to hold the same picture in their head from the same words and then say whether they agree. A prototype hands them the picture and asks the same question.
Technical assumptions behave the same way. You can put a workshop, a round of meetings and a document review against the question of whether an integration will hold, and get a shared position out of it. Building the smallest thing that actually calls the system gets there sooner, and what comes back is a result rather than a position.
Where this goes wrong
Reforge names three, and each one looks like progress while it is happening.
Premature prototyping. Building a solution to a problem nobody in the room can state yet. The prototype is real and the problem is still vague, which is a comfortable place to be because one of those is visible and the other is not. The expense used to force the conversation. Now nothing does.
Speed creating false confidence. The first version arrives polished, and polish reads as certainty. The team locks in, and the other options never get built. This is the same error as fixing scope early, wearing better clothes: you commit at the point where you know least, except now you commit to something that looks finished.
Fidelity confusion. Fidelity is how finished a thing looks, and it has nothing to do with how much of it works. When you show a stakeholder a prototype, they cannot tell which one they are being asked about, so you get an opinion on the button colour when you needed to know whether the sequence of steps makes sense. Say which question you are asking, every time, before they see it.
All three have one root. The artefact got cheap and the judgement did not.
Two bars, not one
There is an objection forming by now. If a working version takes an afternoon, why not put it in front of real customers and let them tell you?
Because ship an embarrassing first version was good advice when the alternative to your product was pen and paper, or a spreadsheet. Whatever you are building now, the thing it replaces is polished software, and a user who forms a judgement on a rough first version does not come back later to check whether you improved it. Kyle Poyar’s name for what replaces that advice is the minimum remarkable product: still minimum, still scoped, but with something about it worth remarking on. His example is Jam, which took 18 months and seven failed launches; what changed on the eighth was waiting until the product was bug-free.
So one force pulls towards volume and rough edges, and another pulls towards a first version good enough to be worth talking about. They look contradictory. What separates them is who is looking.
Anything built to answer a question is not the thing you ship. Hardcode it, fake the data, skip the error handling. Throwing the code away does not make it wasted, because what you keep is the answer and the specification it hands to whoever builds the real version. Anything a real user touches carries your name, and it has to be worth telling someone about. Same team, same fortnight, two completely different standards.
Getting this wrong in either direction is expensive. Polish a learning artefact and you have spent the cheapness you were relying on. Ship a learning artefact to real users and you have spent trust, which is the one thing that did not get cheaper. The guardrail Reforge draws is the same one: these tools earn their keep in discovery, not in delivery.
When shipping is the experiment
There is an awkward case in the middle, and it is the one most likely to apply to you.
Some changes are reversible. You can put them in front of a slice of real users, watch what happens, and take them out again if the answer is no. The mechanism is a feature flag, a switch that turns something on for some people and not others, and it is ordinary engineering that most teams already have.
The flag on its own only gets the thing released. What makes it an experiment is being able to read the result, which is why you want the switch and the measurement in one place. PostHog is the one I keep coming back to: feature flags, experiments, product analytics, session replay and surveys against the same users, so the question and the evidence are not sitting in two different systems owned by two different people. It is the simplest thing in the space to start with and it does not run out of room later, which is a rarer combination than it sounds.
Where that is in place, releasing costs less than formally testing beforehand, and discovery stops handing delivery a validated list to build. The two collapse into one loop.
That does not dissolve the two bars. It moves the change onto the real-user side of the line, so the remarkable standard applies even though the intent was learning. And it has a boundary: reversible and low risk. Anything you cannot take back, pricing you have announced, data you have migrated, a promise a customer has planned around, still needs the experiment to come first.
What to do with this
None of it needs a different supplier or a bigger budget. It needs two decisions made out loud that used to get made by accident.
Before anything is built: which of the four risks would sink this? If the room cannot answer, that is the work, and no prototype will do it for you.
Every time something is built: is this disposable, or does a real user touch it? That sets the standard, and the standard stops being negotiable once the thing exists.
What the budget used to do for you
The discipline this needs is the unglamorous kind: carrying on after the first good-looking answer arrives. That used to be enforced for you. Exploring a sixth option was a conversation with a finance director, so the question of whether you understood the problem got asked whether you liked it or not.
Nothing enforces it now. Building the wrong thing costs almost nothing, and it still costs you everything you did not build instead.