One shared way for a product team to work with AI.
Open source, built in Claude Code and Codex, and piloted with a real product team. Every claim traces back to a source.
The problem
Most product teams now use AI every day, but each person uses it their own way. One PM keeps a folder of prompts, another pastes notes into a chat, a third has built a private setup nobody else can see. What each of them learns stays in their own chats, and none of it draws on what the company already knows. The cost shows up in meetings and decisions. Plans reach review unchallenged, because the AI told everyone they looked great. Research gets repeated because nobody can find the last round. Leaders see AI use going up, but can't see what it has changed. The bill keeps growing.
What it does
Four parts that work together in one shared repo, in Claude Code and Codex.
Knowledge layer
Meetings, documents and decisions synthesised into one current picture per project, with every claim traced to its source and stale context flagged.
Sparring partner
Raises the few issues worth discussing, challenges with the evidence, and ends each conversation with a plan in the PM's own words.
Autonomous research
Desk research on the riskiest assumptions, starting from "what if this is false", with a hard cap. Findings are logged as sources, never as facts.
Idea to prototype
One workflow from a one-line idea to an evidence-backed PRD and a working prototype, with design and engineering setting the quality bar.
How it evolved
- 1
V1: built on my own work
- – Ran my own product work on it every day, then released it as open source in May 2026.
- 2
Applied with a product team
- – June to September 2026, at a PE-backed European marketplace: a seven-week pilot with one squad took two roadmap features from idea to production.
- – Designers wrote the wireframe and prototype skills and set the quality bar; engineering co-wrote the gate that rejects incomplete PRDs.
- 3
V2: a team operating system
- – Rebuilt from what I learned in the field. Coming soon.
How I tested it: what held and what didn't
Before claiming anything worked, I measured it against simpler setups. Up to 21 questions with known answers, a control page sealed before any runs, and setups compared side by side. These are the results as they came out, losses included.
-
Context comparison
~What it measured
The knowledge layer and a plain baseline on 21 questions; live tool access and an empty folder checked by hand on a subset
Result
Mixed. The knowledge layer won on names and on saying what it couldn't find, tied on judgement questions using fewer words, and lost two facts when summarising. The rows below break this down.
-
Names and gaps
✓What it measured
Does the agent name the right people, and say what it couldn't find?
Result
The structured knowledge layer did this better than the other setups.
-
Facts through summaries
✗What it measured
Do facts survive when the agent writes a brief?
Result
No. Two facts were lost at the summary step.
-
Company knowledge retrieval
✓What it measured
Same model, same access to company tools: does preparing the knowledge locally beat leaving it in the tools?
Result
Yes. With knowledge prepared in the folder, answers were right and sourced. Left in the tools, it was never searched unless the agent was told to look, and answers were generic or wrong. A re-test confirmed it.
What it means: the knowledge layer shows promise, but it didn't win on every measure.
What comes next: more and larger datasets to tune and test it, starting with a public synthetic one that anyone can rerun.
How I'd start with your team
Three weeks to a working version on your systems, with your data, tested by your PMs.
Start: see it first
The whole flow on a made-up company, so everyone sees what three weeks will produce before anything touches your data.
Week 1: on your systems
Set up on your tools, with access agreed up front, and seeded with one real initiative: its documents, meetings and decisions.
Week 2: learn what you know
Autonomous research runs over your company knowledge, and the PMs get sourced answers on the initiative.
Week 3: test with a real team
PMs use it on live work. Go or no-go on one question: did their answers get better, and did a decision use them?
After that: security sign-off for the platform, fitting it to your processes and standards, and enabling more teams.
"Simon is a talented AI product manager. A stand out feature for me is his ability to work effectively at pace in a highly ambiguous environment."
Key takeaways
AI transformation in a product team is less about the tools than about a shared way of working: one place for the team's knowledge, sources behind every claim, and design and engineering owning part of the process. The evals mattered as much as the build. They showed what worked, what didn't, and where giving an agent access to company tools was not enough on its own.
Available for AI product and AI transformation lead roles, remote or Barcelona hybrid.
Get in touchMore work
See all case studies →