Building got fast. Learning did not.

In November I shipped three versions of the same onboarding flow in eight days. Felt incredible. Genuinely the most productive week I have had as a builder.

All three were wrong. I found that out in February.

That gap is the thing I have been chewing on all year, so I am starting the year by writing it down.

One cost collapsed. The other did not move.

The cost of turning an idea into working software has fallen off a cliff. Anyone reading this has felt it. A thing that was a two week ticket in 2021 is an afternoon now, sometimes a coffee break.

The cost of finding out whether that thing should exist is exactly what it was. You still have to get it in front of people. They still have to use it for long enough to form a habit or fail to. You still have to sit on calls and listen to someone be politely confused.

Nobody has compressed that. I do not think anybody is close.

So the ratio flipped. Building used to be the expensive part and learning was the cheap part you did around it. Now it is the reverse, and most teams have not restructured for it. They just ship more.

Shipping more is the trap

When building is cheap, shipping feels like progress. It looks like progress on every dashboard your leadership team reads. Velocity is up. Tickets closed is up. The changelog is beautiful.

And you can run that way for two quarters while learning nothing, because you never held anything still long enough to see if it worked. I have done this. It is not a hypothetical.

A team that ships in days but still learns in weeks is not moving fast. It is accumulating uncertainty faster.

What I changed

Nothing revolutionary. Mostly I stopped letting build speed set the rhythm.

• The question comes before the build. Not a spec. A question, written in one sentence, with what would count as an answer. If I cannot write it, I do not build it.
• Ship it, then leave it alone. Two weeks minimum before touching it again, unless it is on fire. Feels awful. Necessary.
• Five conversations a week, permanently. Not a research phase. A standing cost, like rent.
• Prototype to learn, not to launch. Half of what I build now I have no intention of keeping. Saying that out loud up front stops the sunk cost from setting in.

The part I am still bad at

Building your own prototypes is a gift and a trap. When I can implement the idea myself in an evening, I get attached to it in a way I never did when it cost an engineer two weeks. The thing exists, it works, it is mine, and now I am arguing for it in a review instead of evaluating it.

I do not have a clean fix. What helps a bit is writing the kill criteria before I open the editor. If I cannot say what would make me throw it away, I am not exploring, I am just decorating a decision I already made.

The line I keep coming back to

Ship fast, learn faster. The second half is the whole sentence and it is the half that did not get automated.