Why Product Managers Should Build Things

The clearest sign of where product management is headed is who companies are short on. For most of the last decade, the constraint was engineering. You had more ideas than people to build them, so the PM's job was to choose well and write it all down. Now the constraint is flipping. Engineers on AI-native teams ship multiples faster than they did two years ago. Several companies have said, out loud, that they're hiring more product people because they suddenly have engineering capacity to spare.

When the bottleneck moves from building to deciding what's worth building, the PM becomes the scarce input. That's flattering. It's also dangerous, because not every version of the PM job survives the shift.

Two jobs wearing one title

Aakash Singhal has the cleanest frame for this. The PM role was always two jobs in a trench coat. One is the builder: the person who makes the thing, or gets close enough to it to shape it directly. The other is the information-mover: the person who writes the brief, schedules the alignment meeting, and carries a decision from one person's head into another's.

The information-mover was valuable when moving information was expensive and building was scarce. Both of those facts just changed. A model can draft the brief, summarize the thread, and reconcile the doc. The work that used to fill a PM's week, the moving and synthesizing, is exactly the work that got cheap. What didn't get cheap is judgment about what to build, and the ability to produce something real enough to argue about. That work sits on the builder's side of the line.

This is the part that makes people uncomfortable, so I'll say it plainly. If your entire contribution is producing and relaying documents, you are now competing with a tool that does that part for free.

Opinions are cheap. Built things aren't.

Here's the deeper reason building matters, and it has nothing to do with the labor market.

There is a real gap between having opinions about software and having built some. You can hold opinions forever without ever touching the medium. They sound fine in a meeting. They survive because nobody tests them against a compiler, a layout that won't cooperate, a flow that falls apart the second a real edge case shows up. Building is where opinions meet the constraint. It's where you find out which of your instincts were taste and which were just confidence.

Mollick has a line about the AI era that I keep coming back to: figuring out how to give good instructions to a capable system turns out to be reinventing management. The same is true of building. The act of making something forces a precision that opinions never demand. You stop saying "it should feel simple" and start deciding what, exactly, comes off the screen. That precision is the skill. You can't read your way to it. You get it from contact.

A PM who has built things argues differently. They know where the hard parts hide. They can tell a five-minute change from a five-week one, not because they estimate, but because they've felt the shape of it. That instinct is most of what people mean when they say someone has good product judgment, and it is downstream of having built.

The excuse expired

None of this is new advice. "PMs should be technical" is an old sermon. What's new is that the cost of building collapsed, which means the usual excuse expired.

The honest reason most PMs didn't build wasn't laziness. It was that building required an engineer's hours, and an engineer's hours were the scarcest thing in the building. So PMs traded in the cheap currency: opinions and specs. That trade made sense. It doesn't anymore. The thing that used to take a sprint now takes an afternoon, and the tooling no longer assumes you can code.

When Shopify's CEO told the whole company that using AI was now a baseline expectation, not a perk for the engineers, he was naming the end of the excuse. The bar moved. "I can't build" used to be a description of a constraint. Now it's a description of a choice.

But won't I step on toes?

The most common objection I hear from PMs is that building is the designer's job, or the engineer's, and a PM wading in just creates friction.

It's a fair worry, and I think it mostly doesn't survive contact with reality. The friction people imagine comes from the PM showing up with a half-formed opinion and a strong tone. A working prototype is the opposite of that. It's a far better object to react to than a slide with click-zones drawn on it. A designer can open it, feel what's wrong, and fix the real thing instead of arguing about a picture of it. An engineer gets a spec that actually specifies, because the ambiguous parts already had to be resolved to make it run.

The prototype isn't the PM claiming the work. It's the PM bringing something concrete enough to be worth everyone's time. The relationship tends to get better, not worse, because the conversation finally has a real artifact at the center of it.

What building is not

Two guardrails, because the case for building gets misread in predictable ways.

It does not mean becoming an engineer. The goal isn't to ship the production code. It's to have enough contact with the medium that your opinions are earned. The prototype is a thinking tool and an argument, not the final thing.

And it does not mean producing more. The failure mode Mollick named as "17 PowerPoints" is just as available in prototype form: a PM who generates twelve half-built demos and forwards all of them has not built anything, they've made noise. The value was never in the volume of artifacts. It was in the judgment, and judgment shows up as the willingness to throw eleven of them away.

The way Karpathy frames the new job is the right one: the work is to remove yourself as the bottleneck, to become the person who directs and verifies rather than the one typing. Building things is how a PM earns the judgment to do that well. You manage the build better when you've felt the build yourself.

I came to this as a PM who spent years on the opinion side of the gap. When I started shipping rough, working things instead of briefs, the change wasn't that I produced more. It was that my opinions got quieter and more specific, because they'd been somewhere. That's the whole case. The reason to build isn't the thing you build. It's that you can't fake what building teaches you, and in a world where everyone can generate a confident opinion in seconds, the judgment that comes from having made something is about to be the rarest thing a product person can offer.