The PM who codes: where product decisions end and technical decisions begin

The question every PM-who-codes gets asked

"Do you write the code yourself?" Yes, sometimes. "Does that make you a better PM?" It depends on what you do with it.

The ability to write production code as a PM is genuinely useful — and genuinely dangerous in equal measure. After shipping Prodily, contributing to FeatureSmith, and working on Operate at Better, I have a clearer sense of where the line sits and why holding it matters.

When writing the code is the right call

There are specific moments where a PM writing the code removes more friction than it creates. Prototyping a new UX flow that is easier to show than describe. Wiring up a quick API integration to validate a hypothesis before asking the team to scope it. Fixing a copy bug in production when every developer is mid-sprint and the delay costs a real user a real outcome.

On Prodily, I built and shipped the entire product. There was no ambiguity about ownership because there was no one else. The code-and-product boundary collapsed into a single loop: idea, build, deploy, watch users, adjust. That compression was a feature of being a solo builder, not a template I would apply to a team.

When it blurs accountability

On a team, the PM writing code creates an accountability gap that is hard to see until something breaks. If I write a feature and it ships with a bug, who owns the quality bar — me as the PM who scoped it, or me as the developer who built it? The answer is "both" in a way that neither satisfies.

At Better, working on Operate, I contribute to technical discussions, write internal tooling, and occasionally prototype. What I do not do is write the production features my team is responsible for shipping. That boundary keeps the accountability clear. The developers own the implementation quality. I own the problem definition and the outcome. When those roles are distinct, the team can hold each other accountable in clean ways.

The FeatureSmith lesson

FeatureSmith taught me something specific about this. I built the CLI, the core reviewers, and the CI integration. Because I owned the code and the product, I caught problems early — but I also had to be honest about what I was optimising for. A PM wearing a developer hat will often optimise for what ships fast over what is maintainable. FeatureSmith v0.4.0 has 10 reviewers and a clean SDK. It also has decisions I would have made differently if I had handed the architecture to someone with more time on it.

The "AI explains, never decides" philosophy I landed on came from the product side of my brain, not the engineering side. The architecture that enforces it came from thinking like a developer. Both were required.

The line I try to hold

Code when it removes a bottleneck only you can clear. Step back when writing the code means avoiding the harder work of making the requirement clear enough for someone else to build it.

If you find yourself writing code because the spec was not specific enough, that is a sign to stop and fix the spec. If you find yourself writing code because you need to learn something quickly before writing the spec, that is usually fine.

If you want to see how this plays out across the projects I have worked on, the [portfolio guide](/portfolio-guide) has the full workflow, and you can see the kind of work I take on through the [hire page](/hire).