ProductOS

A product operating system in markdown, kept next to your code. Layered documents that carry each decision down the chain, so judgement stays in the loop while agents do the building. No installer: you adopt it by copying the shapes into your own repo. Proven on a real codebase: 20+ Job Specs held against a live UAT harness.

What is ProductOS See it on GitHub Working example: switchroom

your-repo/
├── STRATEGY.md            which jobs are funded now, which are deferred
├── anchors/
│   ├── product-vision.md      the why
│   ├── product-principles.md  the built-well
│   └── invariants.md          the never-cross
├── product-spec.md        names the outcomes, owns the job list
├── jobs/
│   └── <job>/
│       └── job-spec.md    durable, outcome-focused, UAT-verifiable
└── rfcs/
    └── <change>.md        ship-coupled delivery, references a Job Spec

This is the hierarchy you write into your own repo. Nothing to install, no service to run, just markdown files that sit next to your code.

Building got cheap. Knowing what to build got scarce.

An agent can draft the spec, write the code, and run the tests before you’ve booked the kickoff. The bottleneck moved. It isn’t capacity any more.

Product is two things: domain expertise and product discipline. Domain expertise is knowing your customers’ jobs well enough to say what is worth building and why. Discipline is the mechanics of shipping the right stuff, properly. Agents now do the mechanics cheaply, so expertise is the leg that matters more, and it matters more every year.

ProductOS is how that expertise stays in the loop. Each layer of the hierarchy above gets its own document, so the judgement behind every decision carries down the chain while the work runs at agent speed.

Two layers, one direction

ProductOS is two layers, both live now, not a roadmap.

The delivery OS

Anchors, Job Specs, the verdict rule, design loops, outcome UAT, and the agent-executable skills that carry the method end to end.

Agentic Delivery

The Product Playbook

The human product craft, all four disciplines: the six-phase operating loop, discovery, the decision framework, RICE, personas.

Product Playbook

The dependency runs one way: the craft layer may reference the OS, the OS never references the craft.

Built by a PM who runs product with it

I’m Ken Thompson. I built ProductOS because I needed a way to keep judgement in the loop while an agentic workforce does most of the building, and this is the system I actually run product with day to day. ProductOS itself lives at github.com/mekenthompson/ProductOS. For a worked example, switchroom is a real codebase running ProductOS end to end: real anchors, a product spec, and 20+ Job Specs held against a live UAT harness. (github.com/mekenthompson)

One rule decides what ships

The verdict rule

A change ships only when it advances a vision outcome, satisfies its Job Spec, passes every principle, and crosses no invariant.

Agents build fast inside those gates. Humans own the gates.

The rule is the bar, not the paperwork. Scale the gates to the stakes: a quick win ships on a Tech Lead’s nod, a payments change runs every gate at full depth. One path for everything is no path at all.

	Quick Win	Lightweight	Full Spec
Size	≤ half a day	½ day-2 wks	> 2 wks
Process	Flag Tech Lead/PM, ship	1-page brief	Full RFC + RICE
Gates	Outcome sanity check	Outcome UAT + 2-wk review	Full verdict, 2wk/30d/90d

The right context, for whoever’s deciding

Product isn’t one decision. It’s a chain of them, at different altitudes. ProductOS gives each layer its own document, so whoever’s working there, a PM, an engineer, a designer, PMM, or an agent, has exactly the context that layer needs and nothing it doesn’t.

Strategy

Given finite capacity, which jobs are funded now and which are deferred, and why. The context leadership and PMM work from.

Strategy as code

Product definition

What the product is, the outcomes it drives, and the jobs it owns. The anchors that hold and the product spec that lists the work.

Anchors · Product spec

Job definition

The durable, outcome-focused contract for a single job, proven by its UAT. What engineering and design build against.

Job spec

Humans read these to make the judgement calls. Agents read the same documents as executable guidance, with automation and skills layered on top to navigate the chain without losing the plot. One source of context, both audiences.

Adopt it

There’s no installer. You adopt ProductOS by writing these five things into your own repo.

1. Read the method, Agentic Delivery: the four parts and the verdict rule.
2. Copy the shapes: the templates for anchors, product spec, and Job Spec.
3. Write your anchors: vision, principles, invariants. The why, the built-well, the never-cross.
4. Write your product spec and first Job Spec, using the create-product-spec and create-job-spec skills to interview you and write them.
5. Point your agent at your AGENTS.md so it reads the same documents as executable guidance: drafting RFCs with create-rfc, gating every document through review-doc, and guarding ratified specs with amend-durable-doc.

The adopting guide The full walkthrough: read the method, copy the shapes, write your anchors and first Job Spec, wire up your agent.

Using the skills in Claude Where the skills live, how to install them in Claude Code (.claude/skills/), how they trigger, and which one to reach for at each point in the loop.