PM OS
A compounding operating system for product work — prompts, agents, templates, pipelines and a queryable product brain. Built for myself, adopted by my team.
The problem
Product management leaks knowledge. Every spec starts from a blank page, every analysis re-gathers the same context, and the answers to the questions a PM gets asked fifty times live in one person’s head — so they get asked a fifty-first time. AI tools made each of those tasks faster, but faster evaporation is still evaporation: the work sped up and the knowledge kept leaking.
I wanted the opposite property. Not “AI makes me quicker today,” but a system where every unit of product work leaves behind an asset that makes the next unit cheaper — for me, and then for anyone on the team.
What I built
PM OS is that system: four layers that feed each other.
01 — Prompt & agent library. Reusable prompts and agents for the recurring shapes of PM work — research synthesis, spec drafting, experiment readouts, competitive scans. Not saved chats: versioned, documented workflows a teammate can pick up and run without me in the room.
02 — Templates & rituals. Specs, decision logs and experiment write-ups in consistent, structured formats — designed so both humans and agents can consume them. The rituals around them make capture the default: if work happened, the system knows about it.
03 — Automation pipelines. The recurring work that shouldn’t need a human at all runs unattended — recurring scans, digests and triage flows — and delivers its output to the team on a schedule, pre-shaped for decisions rather than raw.
04 — The product brain. A structured, queryable knowledge base of decisions, learnings and customer insight. When someone asks “why did we do X?” or “what do we know about Y?”, the system answers — with the context and the reasoning, not a link to a dead thread.
Adoption
The real test of a system like this isn’t whether it works for its author — it’s whether anyone else picks it up. That’s now happening: teammates on my ~10-PM team are adopting the templates and running the agents themselves.
Adoption changed the design more than anything I planned. Things that were “obvious” to me needed documentation, defaults and guardrails before anyone else could trust them — which is exactly the work that turns personal leverage into organisational leverage.
Operating principles
Every automated output has a human owner. If an agent or pipeline produces something, a named person is accountable for its quality — teaching it, correcting it, retiring it when it goes stale. Automation without ownership is just faster wrongness.
Nothing runs unattended until it’s measured. The same discipline I apply in my side projects — evaluation before automation — applies here: a workflow earns autonomy by being checked, not by being impressive in a demo.
Write once, answer forever. Any question answered twice becomes a documented asset the third time. The goal is that the system’s context survives vacations, reorgs and me.
Judgment stays human. The OS removes the mechanics of the work — gathering, formatting, summarising, remembering. What to build, when to intervene and what good looks like remain the actual job.
Why it matters
The most interesting change AI brings to product teams isn’t faster tasks — it’s that one person’s practice can become infrastructure everyone runs on. Companies are starting to hire for exactly this: roles about scaling AI capability across teams, not just using it personally. PM OS is my working answer to that shift, built in production with a real team rather than as a thought experiment.
The compounding isn’t in the tools. It’s in refusing to let any piece of work be disposable.
Want the details — what’s in the library, how the pipelines are wired, what adoption actually took? Get in touch, or see how I build on GitHub.