On Builder-PMs
The PM job collapsed into one operator: writing PRDs as structured prompts, code as the source of truth, prototypes as the spec.
A short note on why I stopped writing PRDs the old way.
The PRD used to be a contract. You wrote it once, three teams aligned around it, engineering interpreted it, and six weeks later something close to it shipped. That whole pipeline is gone — not because PRDs are dead, but because the interpreter changed.
When the interpreter is a coding agent rather than an engineer, the rules invert. Ambiguity is no longer “I’ll get to clarify it in standup.” Ambiguity is silent. The agent picks one path, ships it, and the gap only shows up when you look at the running prototype.
So the document has to change. It is no longer a contract — it is a prompt.
What’s different
A PRD-as-prompt is shorter, denser, and structured for retrieval rather than reading. Headings are anchors the agent will jump to. Constraints are explicit rather than implied. The acceptance criteria are runnable.
The shift sounds like a tooling change. It isn’t. It changes who can ship.
The role compression
If the prototype is the spec, the person closest to the user — the person who actually knows what “good” feels like — should be the one running the loop. That used to require a team. Now it’s one operator with the right context.
I’m not arguing this is universally true. It works at HeyGo because the surface area is small, the user (myself, snowboarding) is in the room, and the team is fifteen people who can compress decisions. At enterprise scale you still need the org. But for 0→1, the team-of-one is no longer a romance — it’s a configuration.
This is the first entry. More to come on agent context engineering, hardware-AI loops, and what 12 years of shipping taught me that I’m now unlearning.