Build Before You Align

I wrote a few weeks ago that prototypes should come before meetings. I still believe that. But there's a failure mode that looks like the same advice and isn't, and I think it's becoming more common as AI makes building cheaper.

It starts when a team disagrees about direction. Instead of having the argument, someone builds a prototype. The prototype looks real: working URL, real data, real enough that people start nitpicking the details instead of debating the premise. Three weeks later the team has been refining something nobody agreed to build. The prototype didn't resolve the disagreement. It just made the disagreement feel impolite.

I've done this myself. When you can go from idea to working demo in an afternoon, the temptation is to skip the messy conversation and let the artifact do the talking. But sometimes the artifact talks over everyone. The thing that was supposed to provoke a decision becomes the decision by default, because it already exists and tearing it down feels like waste.

The distinction matters. Prototypes before meetings is about replacing decks with real things so the feedback is grounded. Building before you align is about replacing decisions with real things so nobody has to fight. One is a speed move. The other is a conflict avoidance move. They look identical from the outside.

The tell is what happens before the build. If the team knows the question: what are we trying to learn, what does success look like, what are we willing to kill, then building fast is the right move. The prototype is the decision. But if nobody articulated the question, the prototype is a decoy. It gives everyone something to react to that isn't the actual disagreement.

I've been in this loop myself. Small test after small test, each one producing just enough data to justify the next test, none of them resolving the underlying tension. The roadmap fills up. Everyone stays busy. The org mistakes shipping velocity for progress. Nobody says the thing out loud: we're not aligned, and we're using builds to avoid admitting it. AI makes this failure mode cheaper and faster, which makes it harder to spot. The team feels productive because they are producing. But producing and progressing are different verbs.

The fix is unglamorous. Before you build, agree on what you're deciding. Not what you're making: what you're deciding. If the room can't articulate the decision in one sentence, the prototype isn't going to make it for them. It's just going to make the ambiguity look productive.

Build fast. Build rough. Show the rough thing early. All of that still holds. But build after you align, not instead of aligning. The most expensive prototype is the one that ships because nobody wanted to have the conversation it was supposed to start.