Build before you spec
I went from spec first to prototype first – and then realized the prototype wasn't the deliverable. The prototype was the conversation.
I just stopped writing specs first. For most of fifteen years in product roles, the work started with a doc. A page, a brief, a PRD – some version of writing down what should exist before anything could exist. Then it’d be handed over to the team to make it real. The last few months have flipped that order. The doc still gets written. It just gets written last.
The biggest shift isn’t the output. It’s what disappears – and what takes its place.
Previously, I’d meet with the team. We’d talk through the idea. They’d go away. A few days later we’d reconvene. Questions in chat. A handover to development. Best case, a clickable Figma somewhere in the middle. Someone would ask about a flow we hadn’t thought of, because it was just a wall of text. The loop stretched across weeks, and every handover lost something.
Now: I have an idea. I prompt. I see it. I click through. I notice the missing screen. I iterate. I prompt again. I learn.
The time compression matters, but it isn’t the point. The point is uninterrupted thinking.
When I stay in one context – prompting, testing, iterating – I’m not waiting for anyone’s calendar. I’m not re-explaining what I meant three days ago. The thinking and the testing happen together. The iteration is the thinking.
And because alternatives are cheap, there is no need to commit early. I build multiple approaches and see which one survives contact with a real click-through. That’s what fast learning actually means. Not fast output – fast feedback.
But here’s the part I didn’t expect.
The prototypes changed the conversations more than they changed the work.
When I bring a working prototype into a stakeholder meeting, the conversation isn’t about whether the idea is good or bad. It’s about which version of the idea is good, or how to improve it together. Someone pushes back, I prompt the change, we refresh the browser. Thirty seconds later we’re discussing a different version. The decision happens in the room.
Build before you spec. Not instead of. Before. The spec still gets written – it just gets written after we’ve already learned what it should say. Through conversations and iterations, with the team and with stakeholders.