The Case for PMs Who Build

There's a version of product management that's mostly meetings, documents, and alignment. You write a PRD, hand it to engineering, negotiate timelines, and manage stakeholders. I did that for years. It works.

But something changed when AI tools got good enough that I could actually build things myself. Not prototypes in Figma. Real, working software.

What changes when you can build

The most immediate thing is speed. When I have an idea for a feature, I don't need to write a spec, get it prioritized, wait for a sprint, and review the implementation three weeks later. I can build it tonight and see if the idea is any good.

This sounds small but it changes how you think about product decisions. When the cost of trying something is 30 minutes instead of 3 weeks, you try more things. You build the thing and test it instead of debating it in a meeting. The feedback loop gets so tight that the product basically tells you what it wants to be.

The technical intuition gap

PMs who can't read code are making decisions with incomplete information. Not because engineers are hiding things, but because there's a whole category of context that only exists in the codebase.

When I look at a feature request, I can read the relevant code and immediately understand: Is this a one-line change or a refactor? Does the data model support this or do we need a migration? Are there edge cases that the spec doesn't mention?

That context changes the product decision. A feature that seems simple might require restructuring a shared component. A feature that seems hard might be trivial because the infrastructure already exists. You can't make good tradeoff decisions without this information, and getting it secondhand through a technical feasibility review is slower and lossy.

Building things nobody asked for

The best products I've built are things I made for myself. Better Muslim started because I wanted a prayer app that wasn't cluttered. EvalKit started because I needed to evaluate LLM outputs and existing tools weren't rigorous enough. Hadir started because I wanted a personal assistant that actually understood my workflow.

None of these came from a product roadmap or a customer interview. They came from noticing a gap and being able to fill it immediately.

This is the superpower that building gives you. You stop being limited to the ideas that survive the prioritization process and start being able to just make things that should exist.

The PM craft isn't going away

I'm not saying PMs should become engineers. The core PM skills still matter: understanding users, defining strategy, making tradeoffs, communicating across teams. A PM who can code but can't prioritize is just a developer.

What I'm saying is that the bar is moving. The PMs who will be most effective in the next few years are the ones who can operate across the full stack of product work, from strategy down to implementation. Not because they should be writing production code for their team, but because having that ability makes every other part of the job better.

You make better technical tradeoffs because you understand the code. You write better specs because you know what's ambiguous. You ship faster because you can prototype before the sprint starts. You earn more trust from engineering because you speak the same language.

How to start

You don't need a CS degree. You don't need to learn algorithms. You need to be able to read code well enough to understand what a system does, and write code well enough to build a prototype.

Start with the tools your team uses. If they write Python, learn enough Python to read their code. If they use React, build a small app. The goal isn't mastery. The goal is literacy.

AI tools make this dramatically easier than it was even two years ago. Claude Code can scaffold a project, explain existing code, and help you debug. The learning curve for building real software has never been flatter.

The PMs who figure this out early will have a significant advantage. Not because they'll replace engineers, but because they'll be able to make better product decisions faster than PMs who can't build.

That's the case. PMs should build. Not as a hobby. As a core part of how they do their job.