Product OS: The Open, Evidence-First Framework for AI Product Work

Give an AI agent a one-line prompt and it will happily write you a product requirements document. It will be well-formatted, fluent, and completely fabricated. That failure mode is the reason Product OS exists — an open, MIT-licensed, evidence-first operating system for product work, published at github.com/buildbetter-app/product-os and built by the team behind BuildBetter. This guide explains what Product OS is, the design principles that make it more than a prompt library, the 32 skills that compose it, and why the retrieval architecture underneath evidence-first tooling determines whether your AI does real product work or theater.

The Problem: AI Will Write a Confident PRD From Nothing

The most dangerous thing about modern AI in product work is that it produces confident output regardless of whether it has any evidence to stand on. Ask a capable model to "write a PRD for improving onboarding" and it returns a polished document with problem statements, user stories, success metrics, and edge cases — none of which came from a real customer.

Fluency is not truth. Large language models optimize for plausible-sounding text, so the polish of a PRD is uncorrelated with whether it reflects what customers actually said. The more fluent the artifact, the more convincing the illusion that research happened behind it. Reviewers read a clean document and assume the work is done.

Product work is uniquely vulnerable to this. An unmoored blog post wastes an afternoon. An unmoored PRD commits engineering time, roadmap slots, and prioritization decisions downstream. The document is the seed of a cascade — sprints get planned, features get built, and by the time anyone notices the requirement was invented rather than observed, the cost is measured in quarters.

Product OS fills that gap. It is not another collection of clever prompts. It is a framework that forces evidence to precede confidence at every step, so the artifact an agent produces points back to something real. This is the definitional launch of Product OS: an open operating system for product work, designed to make the fluent-PRD-from-nothing problem structurally hard to commit.

What Product OS Is (and Is Not)

Product OS is an open, evidence-first operating system for product work made up of 32 focused agent skills in the common SKILL.md format. It is MIT licensed, vendor-neutral, and usable from any agent harness — Claude Code, Cursor, Codex, Copilot, Gemini, Windsurf, Amazon Q, and others.

Every workflow has an artifact-only fallback. That means the framework runs with zero BuildBetter dependency. You point a skill at documents, notes, transcripts, or research files you already have, and it works. There is no signup and no paywall to use the framework itself.

When BuildBetter MCP is available, evidence-heavy skills get an optional acceleration layer: they pull from organization Skillsets to retrieve evidence at scale. This is genuinely optional — never required for any skill to complete its job.

What Product OS is not matters just as much:

• It is not an agent. It is a set of skills that an agent runs.
• It is not a replacement for talking to customers. It structures and scales the work around real conversations; it does not substitute for them.
• It is not magic if your evidence is thin. Garbage evidence in, garbage requirements out. The framework surfaces the gap but cannot fill it.

The primary source is public: github.com/buildbetter-app/product-os.

The Design Principles Are the Argument

Each Product OS design principle is a direct correction to a specific AI failure mode. The principles are the intellectual core of the framework — they function as guardrails, not templates. A prompt library suggests a format. Product OS enforces an ordering constraint: inputs are required before outputs.

• Evidence before confidence. Corrects the fluent-PRD-from-nothing problem. Skills require inputs before they produce outputs.
• Outcomes before features. Corrects feature-list thinking. Skills anchor to the change you want in customer behavior, not a list of things to build.
• Decisions before documents. Corrects documentation theater. The artifact records a decision that was made — it is not the thing that drives the decision.
• Exact states instead of implied completion. Corrects the "looks done" illusion. A skill reports what it actually did and what remains, so a well-formatted output can't trick a reviewer into thinking work is finished.
• Progressive disclosure and small, focused skills. Corrects monolithic mega-prompts that hide their reasoning. Each skill does one job you can inspect.
• Vendor-neutral core with optional acceleration. Corrects lock-in. The core runs anywhere; acceleration is opt-in.
• Explicit approval for consequential mutations. Corrects silent, irreversible agent actions. Anything that changes state and matters requires a human to say yes.

The differentiator versus a prompt library is that each skill enforces an ordering constraint rather than merely suggesting a wording. The constraints are the product.

The Structure: 32 Skills, 4 Packs of 8

Product OS is organized as 32 skills in four packs of eight, mirroring the product lifecycle, plus a Complete pack that bundles all 32. Each skill is a SKILL.md file — a portable, human-readable definition that any agent harness can load, which is what keeps individual skills composable and vendor-neutral rather than locked to one tool.

The four packs follow the arc of product work from finding a problem to running the shipped product.

Discovery (8 skills)

• plan-product-discovery
• plan-customer-interviews
• synthesize-customer-research
• cluster-feedback-into-jobs
• define-jobs-to-be-done
• map-customer-journey
• analyze-competitors
• map-product-opportunities

Strategy (8 skills)

• validate-product-problem
• define-product-vision
• shape-product-strategy
• define-product-positioning
• define-ideal-customer-profile
• size-market-opportunity
• prioritize-product-opportunities
• size-product-bet

Delivery (8 skills)

• design-product-experiment
• define-product-metrics
• write-product-requirements
• scope-product-release
• plan-outcome-roadmap
• run-product-premortem
• align-product-stakeholders
• verify-product-outcomes

Operate (8 skills)

• plan-product-launch
• design-pricing-packaging
• design-growth-loop
• evaluate-product-market-fit
• run-product-review
• write-product-decision
• manage-product-sunset
• review-product-plan

A Worked Example: Discovery to Requirements

The principles are easiest to see in a concrete sequence. Here is how Product OS turns the same "write a PRD" request into grounded work, one named skill at a time.

1. plan-customer-interviews. Before drawing any conclusions, you structure the evidence-gathering — who to talk to, what to ask, what you are trying to learn. Evidence collection is designed before opinions form.
2. synthesize-customer-research. Raw conversations become structured findings. This is evidence before confidence in action: the skill won't produce conclusions without inputs to synthesize.
3. cluster-feedback-into-jobs then define-jobs-to-be-done. Signal gets grouped into jobs customers are trying to accomplish, not a wish list of features. This is outcomes before features enforced at the data level.
4. validate-product-problem. Before committing engineering time, you confirm the problem is real, frequent, and worth solving. If the evidence is thin, this is where it shows.
5. write-product-requirements. Now the PRD is written on top of traceable evidence. Each requirement points back to a job and the conversations that surfaced it — not to the model's imagination.
6. verify-product-outcomes. After shipping, you close the loop by checking whether the outcome you anchored to actually moved.

Contrast that with the one-line prompt. Same request — "write a PRD" — but every artifact in the Product OS flow reports exact states and points back to actual customer evidence, instead of presenting implied completion. A reviewer can trace any requirement to its source.

This is also where BuildBetter acceleration earns its place. With BuildBetter MCP connected, synthesize-customer-research and validate-product-problem can pull evidence across thousands of calls, tickets, and Slack threads instead of the handful of notes you happen to have on hand. Without it, the artifact-only fallback still runs — you just feed it the research files you have.

Why Evidence Retrieval Is the Hard Part (The AOT Argument)

Evidence-first only works if you can actually retrieve the right evidence — and this is where most AI product workflows quietly fail. A framework can demand evidence all it wants; if the retrieval layer returns only the top-k most similar passages, the "evidence" behind your requirements is a thin slice of what your customers actually said.

The distinction that matters is the shape of the question:

• Lookup questions: "What did Acme say about SSO?" One answer exists and retrieval finds it.
• Population questions: "How many customers complained about onboarding this quarter, ranked by severity?" The answer is a property of the whole population, not any single passage.
• Absence questions: "Which enterprise accounts never mentioned the feature?" The answer is defined by what is not there.

To be fair to RAG: vector search and top-k retrieval are the right tool for lookup questions. One relevant passage exists and retrieval surfaces it. That is what the architecture is good at.

Population and absence questions break it structurally. You cannot rank a population by scoring individual passages, and you cannot retrieve evidence of absence — there is nothing to match against. Product decisions live almost entirely in population and absence territory: prevalence, severity, who's silent, what's trending.

BuildBetter's AOT (Ahead-of-Time Comprehension) reads and comprehends every conversation at ingestion time rather than at query time. Because comprehension already happened, answering a question isn't bound by a per-query search budget. The published benchmark at buildbetter.ai/aot shows the gap:

• AOT coverage: 99.0% (95% CI 98.3–99.7%)
• Hybrid search: 27.9% even at a generous 400-passage retrieval budget
• Keyword search: 11.3% at a 100-passage budget

Cost tells the same story: $0.03 per question for AOT versus $33.55 for a full-corpus scan at query time — roughly 1/1000th the marginal cost for near-complete coverage. The benchmark ran against 6,018 call recordings, 8,533 support conversations, and 836 verified evidence pieces. The coverage gap widens as the corpus grows, which is exactly where product teams accumulate the most signal.

For Product OS, the implication is direct: the framework demands evidence, and the retrieval model determines whether that evidence is complete or just the top-k slice. Evidence-first product management is only as honest as its retrieval.

Honest Limitations

Product OS does not replace talking to customers. It structures and scales the work around real conversations — it does not manufacture them. If you never talk to a customer, no skill will save you.

It is not an agent. It is a set of skills an agent runs. The intelligence comes from the model plus your evidence; Product OS supplies the ordering and the constraints.

Thin or biased evidence produces thin or biased requirements. The framework will surface the gap — validate-product-problem is designed to fail loudly when the problem isn't supported — but it cannot fill a gap that only more customer contact can close.

And BuildBetter itself is not the right tool for everything. It is purpose-built for B2B product teams working with high-value, unstructured conversation data. It is not built for enterprise survey distribution at massive scale, for mining millions of low-signal public reviews, or for a dedicated research-repository tagging workflow. Those are different jobs with different tools.

Stating this plainly is the point. The credibility anchor for Product OS is that the open core is genuinely open and the acceleration is genuinely optional. A framework that only works when you buy the vendor's product isn't evidence-first — it's a funnel.

How to Start Using Product OS

Install Product OS from github.com/buildbetter-app/product-os. It is MIT licensed, requires no signup, and works with any agent harness.

A few practical suggestions for getting started:

• Start with one pack, not all 32 skills. Discovery is the natural entry point — progressive disclosure applies to adoption too. Get comfortable with plan-customer-interviews and synthesize-customer-research before you reach for the full lifecycle.
• Use skillrank to evaluate skills. github.com/buildbetter-app/skillrank helps you find, install, and evaluate agent skills with real numbers rather than vibes.
• Explore the skills repo for coding workflows. github.com/buildbetter-app/skills collects AI coding skills across Claude Code, Codex, Cursor, Copilot, Gemini, Windsurf, and Amazon Q.
• Optionally connect BuildBetter MCP. When you want evidence-heavy skills to pull from your full conversation history at scale, connect BuildBetter MCP. It's SOC 2 Type II and HIPAA-ready, and it stays optional — the artifact-only fallback runs whether or not it's connected.

Frequently Asked Questions

Is Product OS free and open source?

Yes. Product OS is MIT-licensed and fully open source, comprising 32 agent skills. It works completely without BuildBetter through artifact-only fallbacks — there is no signup or paywall to use the framework itself.

How many skills are in Product OS?

Exactly 32, organized as four packs of eight — Discovery, Strategy, Delivery, and Operate — plus a Complete pack that bundles all 32. Each pack maps to a phase of the product lifecycle.

Does Product OS require BuildBetter?

No. BuildBetter MCP is an optional acceleration layer that helps evidence-heavy skills retrieve evidence at scale. Every workflow has an artifact-only fallback, so Product OS is fully functional with zero BuildBetter dependency.

What is the SKILL.md format?

SKILL.md is a portable, human-readable skill definition that any agent harness — Claude Code, Cursor, Codex, Copilot, Gemini, Windsurf, Amazon Q — can load. It keeps skills vendor-neutral and composable rather than locked to one tool.

How is Product OS different from a prompt library?

A prompt library gives you templates; Product OS enforces design principles as guardrails. Skills require evidence before producing confidence, anchor to outcomes rather than feature lists, and report exact states instead of implied completion — the ordering and constraints are the product, not just the wording.

Why does evidence retrieval matter for AI product work?

Because most retrieval only answers lookup questions. Population questions (how many, ranked by severity) and absence questions (who never mentioned it) require reading the whole corpus, which is what BuildBetter's AOT is built for — 99.0% coverage versus 27.9% for hybrid search in the published benchmark.

Make Churn Optional

Product OS gives you the framework to make evidence precede confidence in every product decision. BuildBetter gives that framework the retrieval engine to make the evidence complete instead of the top-k slice — combining your internal team activity and external customer feedback in one place, then shipping deliverables instead of dashboards. Make churn optional. Book a demo.