Show, Don't Spec

The Old Workflow

For most of my career as a PM, communicating a product change, even a small one, followed a predictable path.

Write the spec. Get design to translate it into something visual. Align engineering on the visual. Answer questions. Clarify edge cases. Repeat. Then, finally, build.

In a remote world, that loop is slow by default. Async review cycles stretch what should be a quick sync into days of back-and-forth. And even when everyone signs off, there's often a gap between what I meant and what got shipped: a quiet mistranslation that only shows up in QA or, worse, after launch.

The friction wasn't anyone's fault. It was structural. The spec is a compression of the idea. The design is a decompression. The engineering build is a re-compression. Every step introduces signal loss.

What Changed

I'm a Product Manager at a creative tools company. I'm also someone who studied Mechanical Engineering at MIT before business school, which means I've always been comfortable with technical systems, but "comfortable" isn't the same as "able to ship code."

Then AI coding tools changed that equation.

Not because I became an engineer. But because I became capable enough to build a rough, janky, communicative version of what I had in my head. And that changed everything about how I work.

The Story

Recently, I was working on a new suite of AI-powered editing tools with a lean four-person team: myself, one iOS engineer, one server engineer, and an engineering manager. Small, focused, fast-moving. Exactly the kind of setup where clarity is a competitive advantage.

I wanted to drive tool engagement for one of the features. I had a clear picture in my head of the change I wanted to make. But I had constraints that made the old process untenable: my server engineer was heads-down on a separate, high-priority initiative. I was simultaneously driving an exceptionally large cross-functional project of my own. We had no slack in the system.

Writing a full spec, getting design support, running alignment sessions: that path would have taken days, not to mention the setup costs and context switching. And honestly, it might still have missed the mark.

So I built it instead.

Thirty minutes. One focused session with an AI coding assistant. The result was objectively ugly: rough edges, no polish, plenty of uncovered edge cases. It didn't look like a real product. It looked like a PM had built it, which is exactly what it was.

Then I recorded a short demo video from the simulator and dropped the GitHub repo link in a message.

That was the spec.

Within hours, my design partner had translated my janky prototype into something tasteful and production-ready. My iOS engineer looked at the repo, understood the intent, and executed. Two days later, I had a TestFlight build in hand.

What used to require multiple sync meetings, a structured review process, and weeks of back-and-forth was compressed into 48 hours. Remote. With a team under capacity constraints. Without a single wasted alignment session.

Why It Worked

The prototype wasn't better than a spec because it was more detailed. It was better because it was unambiguous.

A written spec describes behavior. A recorded demo shows behavior. There's no room for misinterpretation when the reviewer can watch the thing move. My design partner didn't have to imagine what I meant. They saw it. My engineer didn't have to infer the intended interaction. They could read the code directly.

This is the real unlock that AI development tools offer product managers: not the ability to ship production code, but the ability to collapse the communication distance between vision and execution.

The prototype isn't the product. It's the most precise brief you've ever written.

The Bigger Shift

What I experienced on that feature isn't a one-off hack. It's a new mode of product work, one that's increasingly available to any PM willing to engage with it.

AI hasn't made engineers redundant. It's made the gap between "I know what I want" and "I can show you what I mean" vanishingly small. That gap used to be the PM's core liability: we were always translating between business intent and technical implementation, and something always got lost.

Now, I can prototype in the language of the product itself. I can bring a working artifact to the conversation instead of a document. And the people I'm collaborating with can react to the real thing rather than a description of it.

That's not just faster. It's a fundamentally more effective way to communicate.

The best spec I ever wrote took thirty minutes and ran on a simulator.