AI-Native Product Manager OS

At a glance

Who it serves

Product managers using AI coding assistants for recurring product work.

What I owned

The operating framework and installable workspace of context, workflows and templates.

Key decision

Make reusable context and review steps part of the workspace, rather than rely on one-off prompts.

Current state

Public, installable local workspace; integrations depend on the user’s connected tools.

Evidence and gap

Repository, setup instructions and workflow materials. Team productivity gains are not independently measured here.

Problem

Product managers moving into AI product work often learn the concepts but still operate from scattered prompts, blank documents, and one-off chats. The knowledge does not compound because the AI has no durable context about the product, users, strategy, metrics, stakeholders, voice, decisions, or governance standards.

The problem is not that PMs need to become software engineers. It is that AI-native PM work now happens inside local AI coding environments, and most PMs do not have an installable workspace that tells those tools how to behave, what context to read, what workflow to run, what artifact to produce, and what governance checks to apply.

The course thesis says the operating system underneath the PM role is changing. This repository turns that thesis into something a learner can put on their machine: open the folder in Codex, Claude Code, Cursor, or Antigravity; fill the context library; run repeatable workflows; and produce product artifacts locally.

Without a structured OS, the learner gets impressive AI output that is hard to review, hard to reuse, and detached from their actual product context. The opportunity was to make the course practical: a portable, local-first workspace where context, workflows, templates, review panels, governance, and outputs are all first-class files.

Architecture

The AI-Native Product Manager OS is a Markdown-first, local-first repository. It has a universal core, runtime adapters, setup docs, fictional examples, validation tooling, release tooling, and ignored local output folders.

The core context library defines the owned product context layer: voice guide, business info, product context, user context, strategy priorities, stakeholders, metrics, meetings, design system, decision log, and career impact log. The AI coder reads these files before drafting artifacts, so output improves as the user fills their own context.

The workflow layer is runtime-neutral. Core workflows cover context setup, PRDs, PRD review panels, prototype briefs, user research synthesis, interview guides, strategy memos, roadmap updates, decision logs, stakeholder updates, impact sizing, metrics frameworks, meeting notes, launch readiness, and AI governance reviews.

Runtime adapters translate the universal OS into the instruction format each AI coding environment expects. Codex uses AGENTS.md, Claude Code uses CLAUDE.md and generated skills, Cursor uses .cursorrules and operating instructions, and Antigravity uses its own operating-instructions file. Adapter files stay thin; workflow logic remains in core/workflows.

The governance layer is built into the install rather than added after the fact. It includes an AI behavior contract, eval-set template, guardrail checklist, risk register, cost-latency worksheet, human review rubric, rollout gates, audit trail, LLM-as-judge template, and kill criteria.

The output layer is deliberately local. Generated work is written to outputs/prds, outputs/research-synthesis, outputs/roadmaps, outputs/status-updates, outputs/meeting-notes, outputs/prototypes, outputs/decisions, outputs/journey-maps, outputs/mcp-integration-logs, and other ignored output folders.

The validator is the product quality gate. tools/validators/pm_os_validate.py checks required files, the 11 base context files, adapter coverage, adapter sync, workflow metadata, governance references, fictional-example labelling, markdown links, privacy patterns, .gitignore protections, release metadata, and packaging files.

The release system builds a clean distributable package. tools/release/build_release.py runs validation, excludes .git, .local, credentials, secrets, dependency folders, logs, keys, environment files, and generated output content, then writes a versioned zip and manifest to dist.

Version 0.1.0 is the first universal plug-and-play release candidate. The local release manifest shows a 239-file package with core context, workflows, governance assets, adapters, examples, docs, validators, and release tooling.

The stack is intentionally simple: Markdown as the durable source of truth, Python for validation and release tooling, runtime-specific adapter files for AI coders, and local filesystem outputs for generated PM artifacts.

Why this approach

The product is a repository rather than a web app because the user already works inside AI coding tools. Opening a local folder in Codex or Claude Code gives the model filesystem context, editable files, and a place to write durable outputs.

The core/adapters split keeps the OS portable. If a workflow changes, the source of truth changes once in core/workflows, then adapter wrappers can be regenerated or checked for sync. That prevents Codex, Claude Code, Cursor, and Antigravity from drifting into separate products.

The OS starts with context because context is the owned layer. Models change, but a user-owned voice guide, product context, user context, strategy priorities, metrics, stakeholder map, and decision log compound over time.

Governance is not framed as enterprise theatre. It is a practical PM habit: define expected behavior, rejected behavior, evals, guardrails, cost and latency constraints, human review, rollout gates, and kill criteria before trusting an AI feature.

The examples are fictional by design. They show what a filled OS can look like without leaking real company data, which makes the repo safer to distribute to course learners and easier to reason about.

Tradeoffs

A local repository is less frictionless than a hosted web app. The user has to download or clone it, open it in an AI coding environment, and work with files. That tradeoff is intentional because the benefit is owned context, privacy, portability, and durable artifacts.

Markdown keeps the system readable and tool-neutral, but it does not enforce every workflow at runtime. The validator catches structure, links, privacy patterns, and adapter coverage, but the quality of a generated artifact still depends on the user filling context with real specificity.

Supporting multiple AI coders creates adapter-maintenance work. The generator and sync checks reduce drift, but every new runtime has to respect the same core workflow logic without copying it into a separate instruction universe.

The OS ships without API keys and without a backend. That makes the base install accessible and safe, but it means advanced integrations such as Notion, Figma, Slack, analytics, or MCP workflows depend on the user connecting their own local tools.

The first release is a structured operating system, not a polished SaaS product. That makes it easier for PMs to inspect, modify, and trust, but it asks more of the learner than clicking through a hosted onboarding flow.

Demo / proof

The repository includes README.md, OS_MANIFEST.md, INSTALL.md, QUICKSTART.md, FIRST_SESSION.md, SETUP_CHECKLIST.md, runtime adapters, core workflows, governance templates, fictional examples, validators, release tooling, and a versioned 0.1.0 release manifest.

The local validator was run against the attached repository and returned: PM OS validation passed.

That validator checks repository structure and packaging. Runtime adapters and governance templates are installable assets; their presence does not establish model behaviour or successful end-to-end execution in every supported AI coding tool.

The repository has adapters for Codex, Claude Code, Cursor, and Antigravity, with an adapter map that keeps the universal core workflows as the source of truth.

The release package manifest records ai-native-pm-os version 0.1.0, a generated zip path, 239 included files, and explicit exclusions for .git, .local, credentials, secrets, dependency folders, environment files, key files, logs, and generated output content.

The Git remote points to the AI-Native-Product-OS repository, making the installable workspace distributable beyond the local portfolio copy.

What I would improve

The next improvement is a polished visual onboarding path inside the portfolio: show the learner exactly how the OS moves from blank install to filled context to first PRD to governance review.

The OS could benefit from more worked examples for non-software PM contexts, such as marketplace, internal tools, operations, education, and B2B SaaS, so learners can see how the same file architecture adapts across domains.

Adapter support should eventually include automated smoke tests per runtime: ask each AI coder to run a tiny workflow against fictional context, then verify the output path, structure, and follow-up questions.

A future release could add optional MCP integration recipes for Notion, Figma, Slack, Linear, Jira, analytics, and docs, while keeping the base OS API-key-free and local-first.

The release process should eventually publish a clean public changelog and install walkthrough video so course learners can understand the repo before opening it in an AI coder.