How I ship features as a PM who builds

I'm a product manager and a product designer, but most of all, I'm a builder. At the early-stage startup where I'm founding PM, those roles don't happen separately. The decisions and the code move together.

That's becoming normal: Cat Wu, who leads product for Claude Code at Anthropic, describes a world where designers ship code, engineers make product decisions, and product managers build prototypes (Claude blog). But the same year brought a warning. In a 2025 study by METR, experienced developers using AI took 19% longer on real tasks, while believing they'd been 20% faster (METR). METR has since said newer tools have moved past that result. The gap between feeling fast and being fast is the part I hold on to.

Developers feel it too. In Stack Overflow's 2025 survey, 84% use or plan to use AI tools, but only 29% trust the output to be accurate (Stack Overflow). Google's DORA team calls AI an amplifier: it makes strong teams stronger and messy teams messier (Google DORA).

So my process is mostly checks. Here's how one feature, letting managers act on behalf of their team, went from idea to production.

First, a PRD written with Claude. I started with one idea and went back and forth until the edge cases I hadn't thought of were answered. The PRD covers who the feature is for, the research signal behind it, and what it must, should, could, and won't do. I answer the edge cases before the build because an agent working from the spec will fill any gap with a guess.

Second, a comment period with the team. Sales checks it against what customers are actually saying. Engineering checks how it holds up at scale, say for two million users. The founder checks it against the product vision.

Third, a phased build plan: front end, back end, database migration, and SOC 2 compliance checks. Each phase is run by AI agents with the right expertise, some in parallel. I review every phase and test the prototype as it forms.

Fourth, an independent review. A fresh agent reads the code, free of the builders' bias. Anthropic's own guidance recommends the same thing: one instance writes, a separate one reviews (Anthropic). It usually finds redundancies and simpler paths, and those get fixed before anything moves on.

Fifth, tests for every plan and role. I run them, then a teammate runs them again before approving the merge.

Last, everyone tests in dev. Design, engineering, sales, and the founder each try it through their own lens before it reaches production.

The agents make the building fast. The reviews and the team make it solid.