AI Systems2026● In use
Product OS
A local operating system for running product — plain files on one machine, worked by a set of AI skills. I built it to move the integration work out of my head into a system that keeps one live picture of delivery, customers and strategy, and drafts the outputs I used to assemble by hand.
.timeline
Built and iterated on the job — 2026
.year
2026
.tools
Claude Code, MCP connectors, Markdown, JTBD, prompt design
.role
Product Lead
.problem
Problem
Product leadership is a synthesis job, and the synthesis was all happening in one place — my head. The signal I needed already existed; it was just scattered across seven tools that never talked to each other. The issue tracker knew what was shipping. The discovery board held ideas nobody cross-referenced. The support inbox was full of customer evidence nobody had time to mine. The CRM knew which of that feedback was worth real money. The docs drifted from reality, and the code was the only place that told the truth about what had actually shipped. The one integration layer joining all of it was me, tab by tab.
So every week I rebuilt the same picture from scratch. I re-read boards to reconstruct delivery status before a standup, trawled support threads hoping to spot a pattern, cross-referenced accounts to work out which complaint mattered commercially, and rewrote the same update from memory for each different audience. It was hours of assembly, not decision-making — and it was fragile in a way that bothered me as a product person. Stakeholder comms slipped when the week got busy. Real customer signal died in the inbox before it ever reached a roadmap call. Worst of all, nothing compounded: every correction I made lived in my memory, so the same mistakes cost the same time twice, and if I was off for a week the picture simply stopped existing. That is a single point of failure wearing a lanyard.
.solution
Solution
Product OS moves the integration work out of my head and into a system. It runs entirely on my machine, on three cheap ideas.
The first is a local knowledge base of plain Markdown files — no new SaaS, no new database to secure. It splits in two: a context layer I curate by hand (the products, the stakeholders, the glossary of terms the system must get right, the current strategy) that acts as ground truth and rarely changes; and a state layer that the skills keep fresh (initiatives, customer signals tied to commercial value, launches, escalations, roadmap scores, a running actions list). Because it is just files on disk, the whole picture is diffable, greppable, and mine — there is no lock-in and nothing to migrate.
The second is a set of AI skills — each one a written prompt spec, run on demand through Claude Code. They read the current picture, and where they need something live they query the source tools directly through read-only connectors. They cover the loop of the job: understand delivery, understand customers, decide, communicate, and self-maintain. Their entire job is to draft — a cycle standup, a delivery audit, a support-intelligence report, a conviction score for a roadmap bet, a week's stakeholder comms.
The third, and the part I care most about, is that the system learns in plain prose. Everything a skill produces is a draft; nothing is sent, posted or written back without my explicit sign-off — the human review gate is the only write path out. And every correction I make at that gate is appended to a single lessons.md that every skill loads before it runs. The behaviour of the system is editable text, not retrained weights: fix something once and it stays fixed. A live local dashboard sits on top of the files so I can see the whole picture at a glance.
.story
Story
I built Product OS because I was quietly furious at how much of my week went on assembly instead of judgement — and because I think the most honest thing a product person can do is treat their own annoyance as a product and solve it properly.
The first real decision was to refuse to build another app. The obvious move is a database and a dashboard; I deliberately went the other way and made the whole thing plain Markdown on my own disk. That choice does an enormous amount of work. There is no new system of record to keep in sync, nothing new to secure, and no vendor to be locked into — the state layer is just files, so it diffs in version control, greps in a second, and is trivially portable. It also made the system legible: when it gets something wrong, I can open the file and see exactly what it believed and why.
The second decision was about trust, because this thing reads real company data. I designed it read-only by policy — only read and search tools are in the allowlist, so no skill can quietly change a source system — and I made a single human review gate the only way anything leaves the machine. That is a governance stance as much as an architecture: the AI does the gathering and the drafting, which is where the hours went, and I stay exactly where I add value, on judgement and sign-off. It is the pattern I would want any AI feature I shipped to customers to follow.
The decision I am proudest of is the smallest to describe. Early on, the same corrections kept evaporating — I would fix a skill's tone or a piece of context, and a week later make the identical fix again. So I gave the system one file, lessons.md, that every skill reads first, and wired the review gate to append my corrections to it. That turned feedback from something that vanished into something that compounds: the system now genuinely gets better each time I use it, and it does so as plain, auditable prose rather than an opaque model I would have to retrain. It is a small idea that quietly changed the whole thing from a set of scripts into something that improves.
Product OS is honest about what it is: an internal, single-user tool I run product from, not a shipped product with customers. But it is real, it is load-bearing in my actual week, and I built it end to end — the problem framing, the file architecture, the twelve skill specs, the safety model, and the learning loop. I think it is the truest thing in this portfolio, because it is the one case where I was the user, the designer and the engineer at once — and it doubles as a working answer to the question every product team is asking right now: how do you put AI to work on real data without giving up control of it?
Every problem worth solving has a human at the centre of it.