PMs Should Build

I recently built a prototype of Caption With Intention, a captioning system meant to convey not just dialogue, but emotion and speaker identity.

One guideline mapped vocal volume in 5db level to caption font size: louder speech meant larger text. On paper, it made sense. On screen, it was chaos. The captions kept shifting, competing with the picture, and drawing attention to the system instead of the story. Because I had built it, I could change the rule, test the alternative, and bring a better version back to the team.

If I’d written this as a memo, it would have been a debate. As a working prototype, it became evidence.

That small experience clarified something I'd been thinking about. The "AI changing product work" conversation has mostly framed it as a productivity story. PMs become builders, fewer engineers are needed, output goes up. I don't think this framing is wrong, but I think it misses what matters. The reason PMs should learn to build is not to replace engineers. It's to make better arguments, make better decisions, and, perhaps underrated, become better PMs.

Role Compression, Not Role Collapse

The underlying shift is real. As AI absorbs more of the execution layer across product work, including drafting specs, generating design variations, writing code, and analyzing usage data, the friction between disciplines compresses. PMs can prototype. Designers can ship copy and code. Engineers can explore product ideas without waiting for a fully specified PRD. A lot of work that required several handoffs can now be done by fewer people, faster.

Some call this role collapse: the idea that PM, design, and engineering merge into a single universal Product Builder. I prefer role compression. The two words sound similar, but imply very different futures. Collapse implies disciplines disappear. Compression implies the distance between them shrinks. PM, design, and engineering remain distinct, but the handoffs get shorter, the boundaries get more porous, and the quality of judgment matters more because more people can now produce plausible output.

This distinction matters because AI doesn't automatically improve product judgment. It can generate more ideas, screens, code, and experiments. But more output isn't the same as better direction. The bottleneck moves from production to selection.

What AI Doesn't Compress

What hasn’t gotten cheaper is problem definition. You can generate a hundred PRDs in an afternoon, but you cannot generate the correct user signal to write one against. Someone has to sit with ambiguity, talk to real people, and decide what the actual problem is.

This is a thread I’ve been pulling on for some time, what I call the human-as-a-decision-layer thesis. Even as AI absorbs more execution, humans remain the layer that allocates intelligence, judgment, and attention. More features, prototypes, and code aren’t the same as the right product. And when building becomes cheap, it’s easier to mistake activity for progress.

So the PM's job doesn't become "build more." It becomes knowing when building clarifies the decision, and when it merely creates more noise. The scarce skill is no longer producing artifacts. It is choosing which artifacts deserve attention.

Building as Practice

There’s a quieter benefit to PMs learning to build, less about output and more about developing as a product person.

Prototyping forces me to make my thinking concrete. A vague intuition about a feature becomes a specific set of states, edge cases, and tradeoffs when I try to render it. The ambiguities I used to wave through in a PRD, assuming the engineer or designer would surface them later, emerge immediately when I’m building. Some problems I solve myself. Others I bring to the team earlier, with sharper questions.

Building is quiet practice for the PM role’s hardest part: articulating design and engineering decisions. Choosing between two interaction patterns in my prototype rehearses the reasoning I need to defend in a design review. Making a tradeoff between latency and quality in my code teaches me to discuss that tradeoff with an engineering lead’s precision. None of this makes me a designer or an engineer. It makes me a PM who can hold a more substantive conversation with both, and lead with more credibility because the reasoning is earned, not borrowed.

This is the most underrated effect of the shift. PMs who build aren't just producing better prototypes. They're rehearsing the conversations they will later need to lead.

Personal and Distributed Products

The other thing building taught me is that products built for myself and products built for distribution demand different priorities, even when the interface looks identical. I built Reader, a small AI tool for processing newsletters, around a strong opinion: opinionated summaries are more useful than verbatim quotes for my reading. That belief drove the product, and it was easy to articulate in a PRD.

But when I imagined shipping the same product to others, the priority stack flipped. Cost-efficiency, latency, and cross-device parity, which I had ignored (or at least deprioritized) when building for myself, would suddenly matter more than the summary quality I cared about. AI can solve those problems. The point is not the missing technology, but the prioritization judgment call, felt after watching an API bill climb and waiting two seconds too long for a response that's only useful in one.

That texture, what's slow, awkward, and expensive at scale, teaches you which tradeoffs are real. It doesn't transfer from a document.

Two Futures for Product Teams

The practical implications depend on the company’s stage.

In early-stage startups, people have always worked across boundaries. Founders sell, recruit, debug, write copy, and make product decisions in the same week. AI accelerates this, and the most valuable role is someone who can close the full loop: problem, prototype, feedback, iteration. The title, whether Product Builder, founding engineer, or PM, is almost incidental.

In larger companies, the math is different. Reliability, security, accessibility, compliance, and strategic alignment aren't prototyped; they require depth. So roles don't merge in enterprise teams; they hybridize. PMs become more technical. Designers become more strategic and system-oriented. Engineers become more product-minded. But each retains a primary accountability axis, because focused attention produces better outcomes than distributed attention when the cost of being wrong is high. A PM trying to be a full-time engineer and designer will do all three worse, and spend less time on the work only a PM can do, which is meeting users and defining problems.

There is also a real failure mode here. PM-built prototypes can make rough ideas look more finished than they are. They can anchor teams too early, create false confidence, or blur the line between a learning artifact and a production plan. That risk matters more in larger organizations, where the cost of misalignment is high. The goal is not to make prototypes look shippable. It is to make assumptions visible.

What does shift is team composition. I wouldn’t be surprised if AI-native teams move toward much smaller engineering-to-PM gaps than we’re used to, not because PMs replace engineers, but because engineering throughput changes the coordination problem. But the underlying logic doesn't change. Division of labor still produces better outcomes when the cost of being wrong is high. What changes is the interface between roles. PM-built prototypes become a way to shorten alignment cycles, expose tradeoffs earlier, and let specialists spend more time on the decisions where their depth matters most.

π, Not T

I’m drawn to π, not T. A T-shaped person has one deep axis and broad familiarity across everything else. A π-shaped person has two deep axes, a primary discipline and a strong adjacent one, plus enough breadth to collaborate elsewhere. For PMs, the second axis is likely to be building. The goal is not to flatten the disciplines, but to add a second leg.

The implication for PMs is uncomfortable but exciting. It may no longer be enough to know what to build. We need to get closer to how it's built, not to take over engineering, but to make working arguments, surface tradeoffs in real time, and collaborate at the resolution AI now makes possible.

But this shift is more subtractive than it sounds. It isn't "become an engineer." It's "stop stopping at the spec." The work that matters is still the work: understanding users, defining the problem, and deciding what not to build. Building is not a substitute for that judgment. It is one of the fastest ways to sharpen it.