The Tool Fragmentation Problem
Every product manager I know has the same problem. They spend their mornings in Jira writing tickets, switch to Notion for strategy docs, jump into Linear for sprint tracking, open Figma for design reviews, build slides in Google Slides, respond in Slack, then update a spreadsheet that nobody else reads. Twelve or more tools running simultaneously, each holding a fragment of the picture, none of them aware the others exist.
The PM's job has quietly become information logistics. Moving context from one system to another. Translating a customer insight captured in a Slack thread into a Jira ticket, then referencing that ticket in a strategy doc, then pulling the strategy doc into a slide deck for the leadership review. Each translation loses fidelity. Each context switch costs time. The actual thinking, the part where you decide what to build and why, gets compressed into whatever minutes remain after the information transfer is done.
I tracked my own workflow for two weeks. The results were brutal. Roughly 40% of my working hours went to moving information between systems. Not analyzing it. Not making decisions based on it. Just copying, reformatting, and relocating it so that the right people could see the right context in the right tool. This is not a workflow problem unique to me. Every PM I have spoken to about this nods in recognition. It is a structural failure of the tool ecosystem.
The industry's answer has been integration platforms. Zapier, Make, custom webhooks. These help with the plumbing, but they do not solve the core issue. The problem is not that Tool A cannot send data to Tool B. The problem is that no tool in the stack understands the PM's full context. Your competitive analysis lives in one place, your OKRs in another, your user research in a third. No single system has the complete picture. So you, the PM, become the integration layer. Your brain is the only system that holds all the context. And your brain does not scale.
I lived with this for years. Like most PMs, I developed workarounds. Personal wikis. Master spreadsheets. Running documents that tried to stitch together the fragments. They helped. But they were band-aids on a structural problem. The tools were never going to converge on their own. Each one is optimized for its own use case, not for the PM's workflow across use cases.
Something had to change. Not the tools themselves, but the layer that connects them.
What If the Stack Was One System?
That question is what led to PM-OS. Not a new project management tool. Not another dashboard. An AI operating system that sits on top of whatever tools you already use and provides a unified layer for the entire PM workflow.
The core idea is simple. Instead of switching between twelve tools and manually maintaining context across them, you work through a single interface that understands the full PM lifecycle. One system that can run competitive analysis, write strategy docs, define OKRs, prioritize features, scope sprints, prepare stakeholder updates, and review metrics. Not by replacing your existing tools, but by acting as an intelligent layer that reads from them, writes to them, and maintains context across all of them.
PM-OS has 27 skills organized across the complete product management lifecycle. Each skill handles a specific workflow that PMs do regularly. Together, they cover the full arc from discovery through delivery and measurement.
The skill count matters less than the coverage. Most PM tools solve one slice of the workflow well and ignore everything else. Jira is excellent at tracking work. It tells you nothing about whether you are tracking the right work. Notion is great for documentation. It cannot tell you whether your strategy aligns with your OKRs. PM-OS is designed to span the full workflow because the value of the system increases when every phase can reference every other phase.
Discovery skills handle competitive intelligence, opportunity assessment, and market research. Strategy skills generate and refine product strategy documents grounded in your actual competitive landscape and company context. User research skills create interview guides, synthesize feedback, and build personas. Define skills write PRDs, refine specs, and record decisions. Planning skills manage OKRs, prioritization, roadmaps, quarterly plans, and sprint scoping. Delivery and communication skills handle launch plans, stakeholder updates, meeting prep, and status reports. Measurement skills review metrics and analyze experiments. Present and cadence skills create slide decks and daily briefings.
Each skill is purpose-built for how PMs actually work. Not generic AI chat. Not "ask me anything." Structured workflows with opinionated defaults that reflect how good product management is actually practiced.
The Knowledge System Is the Product
The 27 skills are useful on their own. Run competitive intelligence on a competitor and you get a solid battlecard. Write a PRD and you get a well-structured spec. Each skill produces a standalone artifact that is better than what most PMs create manually, because the skill encodes best practices and forces completeness.
But the individual skills are not the product. The knowledge system is.
Every skill in PM-OS reads from and writes to a shared knowledge directory. When you run competitive intelligence on a competitor, the battlecard is saved to the knowledge base. When you later run the strategy skill, it reads those battlecards automatically. It does not ask you to paste in your competitive research. It already knows. When you write OKRs, the system reads your strategy. When you prioritize features, the system reads your OKRs. When you scope a sprint, the system reads your prioritized backlog.
This is the compounding effect. Each skill you run makes every subsequent skill smarter. Your competitive intel feeds your strategy. Your strategy feeds your OKRs. Your OKRs feed your prioritization framework. Your priorities feed your roadmap. Your roadmap feeds your sprint scope. The knowledge accumulates, and the system gets more useful over time. Not because the AI gets smarter, but because the context it operates with gets richer.
This is the fundamental difference between PM-OS and the wave of AI chatbots that every SaaS company has bolted onto their product in the last two years. Those chatbots are stateless. You ask a question, you get an answer, and the conversation evaporates. Next time you come back, the AI knows nothing about what you discussed yesterday. It has no memory of your strategy, your competitive landscape, your OKRs, or your team's velocity. Every interaction starts from zero.
PM-OS is stateful. It remembers. Not because it stores chat histories, but because every skill writes structured output to a knowledge base that every other skill can read. The knowledge directory is not a chat log. It is a structured representation of your product context: competitors, strategy, OKRs, priorities, decisions, metrics, user research, sprint history. Each file in the knowledge base has a specific schema and purpose. Each skill knows which files to read and which files to write.
That is the difference between a tool and an operating system. A tool does one thing when you ask. An operating system maintains state, connects processes, and makes the whole greater than the sum of the parts. The knowledge system is what makes PM-OS an operating system rather than a collection of 27 independent AI tricks.
I did not arrive at this architecture by design. I built the first few skills as standalone utilities. Competitive intel was a script that fetched a competitor's website and generated a battlecard. Strategy writing was a prompt that produced a strategy doc. They worked fine in isolation. But every time I ran the strategy skill, I found myself manually pasting in the competitive research I had done the day before. Every time I wrote OKRs, I was copying and pasting from the strategy doc. I was recreating the same information transfer problem that PM-OS was supposed to solve.
The knowledge directory was born out of that frustration. Once every skill could read and write to a shared file system, the whole thing clicked. The system stopped being a collection of tools and started being something more. It started feeling like an operating system.
How It Works in Practice
Theory is fine. Let me show you what this looks like in a real workflow.
It is late March. You are a PM planning Q3. In the traditional workflow, you would spend days gathering inputs: pulling up last quarter's metrics, reviewing competitive moves, rereading the company strategy, collecting feature requests, estimating capacity. Then you would synthesize all of that into a plan, probably in a slide deck, over several more days. Two weeks of work, minimum, before you have a draft that stakeholders can react to.
Here is the same workflow in PM-OS.
$ /competitive-intel Linear > Analyzing linear.app... > Battlecard saved to knowledge/competitors/linear.md $ /write-strategy > Reading competitors, OKRs, product context... > Strategy draft saved to knowledge/strategy.md $ /prioritize > Running RICE scoring against strategy... > Ranked priorities saved to knowledge/priorities/q3-2026.md
Three commands. The competitive intel skill fetches Linear's website, analyzes their product positioning, pricing, recent launches, strengths, and weaknesses, then saves a structured battlecard. You do the same for your other key competitors. Takes about two minutes per competitor.
Then you run the strategy skill. It reads your existing company context (which you set up once during onboarding), your competitive battlecards (which you just generated), your previous quarter's OKRs and metrics (which live in the knowledge directory from last quarter's work), and your product vision. From all of that context, it drafts a comprehensive strategy document with vision, strategic pillars, positioning, and success metrics. Not a generic template. A strategy grounded in your actual competitive landscape and your actual product context.
Then you run prioritization. The system reads the strategy you just generated, reads your backlog of feature candidates, and scores each one using a RICE framework weighted against your strategic pillars. Features that align with your top strategic priorities score higher. Features that are high-effort and low-alignment drop to the bottom. The output is a ranked list with scores, rationale for each ranking, and a recommended cut line for what fits in Q3.
From there, you can run the quarterly planning skill, which reads everything you have generated so far and produces a complete quarterly plan with themes, OKRs, roadmap commitments, resource allocation, and risk assessment. Or you can run the roadmap builder to generate a now/next/later view. Or the sprint scoping skill to break Q3 into sprint-level chunks based on your team's historical velocity.
Each step takes minutes. The total workflow that used to take two weeks of fragmented work now takes an afternoon of focused effort. And the output is better, because every step has access to the full context rather than whatever subset you remembered to paste in.
The important thing to understand is that this is not AI replacing the PM's judgment. At every step, you review, edit, and refine the output. The strategy draft is a draft. You rewrite sections, adjust priorities, add context the system does not have. The prioritization scores are a starting point. You override rankings based on factors the system cannot quantify, like political dynamics or technical debt that needs addressing regardless of RICE scores. PM-OS handles the information gathering, synthesis, and initial structuring. You handle the judgment calls. That division of labor is the entire point.
I have been using PM-OS in my own workflow for months now. The most surprising change is not speed, though that is real. It is the quality of thinking. When you are not spending 40% of your time on information transfer, you have capacity for deeper analysis. You notice patterns you would have missed. You catch misalignments between your strategy and your roadmap that would have survived weeks of review. The system does not think for you. It clears the space for you to think better.
Why I Open-Sourced It
PM-OS is free and open source under the MIT license. Anyone can install it, modify it, and use it for any purpose. I made this decision deliberately, and the reasoning is straightforward.
Product management as a discipline is underserved by AI. Most PM tools that have added AI features have done so by bolting a chatbot onto their existing interface. "Ask AI" buttons that generate generic text. Copilot features that autocomplete your Jira tickets. These features are mildly useful and fundamentally unambitious. They treat AI as a text generation engine rather than as a system that can transform how product work gets done.
PM-OS takes a different approach. It does not add AI to existing workflows. It rethinks the workflow around AI-native primitives. The knowledge directory, the skill-based architecture, the compounding context system: these are not features you can bolt onto a traditional tool. They require starting from a different set of assumptions about how PMs should work.
Open-sourcing it means the ideas can spread regardless of whether anyone adopts PM-OS specifically. If another tool takes the knowledge directory concept and implements it better, that is a win. If a PM team forks PM-OS and customizes it for their specific domain, that is a win. The goal is not to build a product. The goal is to shift how the industry thinks about PM tooling.
There is also a practical reason. PM-OS is built as a plugin for Claude Code, which means it runs locally, on your machine, with your data. There is no server, no account, no subscription. Your knowledge base lives in your file system. Your competitive research, your strategy documents, your OKRs: all of it stays on your machine (or in your team's repo). For PMs working on sensitive products or in regulated industries, this matters. You do not need to send your product strategy to a third-party SaaS platform to get AI assistance with your workflow.
The plugin architecture also means PM-OS evolves with the ecosystem. As Claude gets better, every skill gets better automatically. As new capabilities become available (better web research, deeper code analysis, multimodal inputs), they can be incorporated into existing skills without rebuilding the system. The architecture is designed to compound, both in the knowledge it accumulates and in the capabilities it can leverage.
The goal is not to replace product managers. It is to remove the busywork so PMs can focus on the decisions that actually matter.
I have talked to hundreds of PMs over the past year, at conferences, in Slack communities, through DMs. The frustration is universal. PMs feel like they spend too much time on logistics and not enough on strategy. They feel like their tools work against them rather than for them. They feel like AI should be helping more than it is, but the "AI features" in their existing tools feel like gimmicks rather than genuine workflow improvements.
PM-OS is my answer to that frustration. It is opinionated. It encodes my view of how product management should work, informed by years of doing it across enterprise software, healthcare, and AI products. Not everyone will agree with every default. That is fine. The code is open. Change what does not work for you.
If you are a PM and this resonates, try it. Install the plugin, run the setup wizard, and run one skill. Start with competitive intel or a PRD. See whether the output is useful. If it is, run another skill and watch how the knowledge system starts connecting the dots. The compounding effect is not something I can describe in a blog post. You have to experience it.
The future of PM tooling is not better features inside existing tools. It is better systems that connect the entire workflow. That is what PM-OS is. That is what I think every PM tool will eventually become. The question is whether that future arrives through incremental chatbot additions to existing SaaS products, or through a fundamental rethinking of how product work gets done.
I am betting on the rethink.