AI PM OS

An LLM chat could already summarize notes, consolidate feedback, or draft a requirement. But the savings disappeared between tasks. Whenever new evidence appeared, I had to explain the product again, find the latest version, reconstruct why a decision had been made, and manually update the artifacts that depended on it. Context, evidence, and decisions were scattered across chats, files, and tools. Context expired, and the PM became the system keeping it alive.

The challenge was to stop using AI for isolated tasks and turn the workflow into a connected sequence. I built a Second Brain as a source of truth, where each artifact keeps its sources, feeds the next stage, and updates when evidence changes without silently rewriting an approved decision. With complete and current information, AI can produce more specific analysis, proposals, and artifacts while preparing, syncing, and keeping the work traceable. The PM still interprets, prioritizes, and approves.

I reviewed existing skills and Second Brain structures from people working in the field to build a system that matched the way I work. I adapted and tested artifacts and flows until I understood what added value in a real product cycle.

My role was to define the Second Brain architecture, conventions, and contracts between stages: what information enters, what artifact each skill produces, which sources it keeps, and how it hands context to the next stage. As the PM, I decided what to research, reviewed evidence and counterevidence, chose the focus, and approved priorities, scope, and trade offs. AI prepares, synthesizes, compares, and proposes; interpretation and decisions remain mine.

I tested the system in a discovery and validation process with real users: interviews, a survey, prototypes, and usability tests. The evidence was not only used to produce summaries. It also showed whether the process could preserve sources, keep context current, and connect research, decisions, and delivery without losing traceability.

From that material, I built derived user personas: representations based on patterns from interviews, surveys, and behavior observed in the tests, not fictional profiles defined in advance. Each one keeps its link to the evidence behind it and updates when a new signal appears.

An observation could then feed an insight, adjust a journey or an opportunity, and reach later artifacts with its context available. AI helped structure and connect those pieces; interpretation and decisions remained mine.

Once discovery was complete, the next step was turning evidence and decisions into product work that could be built, validated, and tracked. The system does not produce a list of features. It helps define which solution makes sense, which assumptions still need testing, and what should enter the next increment.

Delivery starts with a prioritized opportunity and turns it into a solution, a PRD, and an SDD (Spec-Driven Development) phase: an implementation spec, a breakdown into slices, acceptance criteria, a verification strategy, and TDD. Real time updates to Linear through the Linear MCP keep the work status visible and connected to the decision behind it. If evidence changes, the system can update derived artifacts without silently changing an approved decision.

AI PM OS prepares, connects, and keeps the work current; I define scope, resolve trade offs, and approve what moves forward. The diagram below shows the processes and skills that support this delivery flow.

The most important result was being able to use AI PM OS on Sentra, a mobile app that is still under construction. I used it across several key discovery and delivery steps and took interview and usability evidence to a product proposal ready for review, without rebuilding everything from scratch at each stage. Sentra is not complete yet, but it gave me a real workflow to test.

The saving was most visible in tasks such as transcribing audio and video, organizing information, and preparing the documents that follow. The model I built suggests that a complete cycle could return 7 to 13 hours per week. I am not presenting that as an exact number yet, but it is a clear signal that the system can save a lot of time in repeatable workflows.

To know how much time is really saved, I still need to do the same task manually and with AI PM OS, measure both, and compare corrections and rework. That is the next step of the project: test the repeatable workflows and turn this estimate into a measured result.

I learned that the value of AI PM OS is not only about completing a task faster. It is about not having to rebuild the context, evidence, and decisions every time I move through the process. To make that work, I had to think of the system as a set of connected steps, where each output supports the next stage and can still be reviewed.

I also learned that not everything should be automated. Automation requires defining what goes in, what result I expect, and how I will review it. It makes sense when a task repeats; for a single task, doing it directly may be faster. Interpreting the evidence, choosing the focus, and resolving trade offs are still the PM's responsibility.

I am not building AI PM OS to sell it as a product. It is a personal working process that I use to understand how I work as a PM, which tasks take up my time, and where AI can help without replacing my judgment. What I show in this case study is that process, together with the decisions and learnings I keep developing as I use it.