A framework for running product work with AI tooling
AI does the heavy lifting, a person owns every decision. The framework defines the workflow; a harness of eight agents staffs it, orchestrated by a Conductor, gated by the product manager.
Knowledge loop
Decision loop
Shared hub
Challenger (both loops)
Conductor
The one idea
Content design, pointed inward
I have been more than a little obsessed with the work Sarah Winters and her team are doing at Content Design London. Their work on Content Design has changed the way I work entirely and I’ve used their principles here to start thinking about how product teams may work alongside AI tooling and treat all documentation as ‘content’.
This framework borrows that discipline and aims it not at customers but at the product manager’s own process — the research, the decisions, the specs, and the updates other teams depend on.
Content used to be something you read. Now it’s something you use. Content design is about giving your user what they want, when they need it, in the way they expect.
Sarah Winters, Content Design London
A single workflow example
Generating a roadmap update and getting feedback from an exec
This is the whole idea in a single run. AI tooling gathers the raw material and drafts the outputs, the person reviews and decides, and everything traces back to one shared record.
Below, raw signal comes in from eight sources, a reviewed roadmap update reaches the exec on WhatsApp, and the exec’s four-minute voice note in reply becomes the next piece of signal to go in.
Capture layer · raw signal in, in whatever form it arrives
Product metrics
usage, activation, retention · via API
Research
deep qual interviews + quant surveys
Site visits
notes from watching customers work
Support tickets
recurring issues, at volume
Sales notes
deals, blockers, feature asks
Meeting transcripts
customer and internal calls
Voice notes
spoken updates, sent async
Team feedback
replies from eng, sales, support
all eight funnel into Capture▾
Capture
Scribe
→
Store
Custodian
Ask Store
query it, plain language
→
Agents
draft the update
→
Review
PM decides
→
Distribute
Distributor
→
Exec
on WhatsApp
↻The exec lives in WhatsApp all day, so the update goes to them there and the reply comes back the same way. Talking is easy, so a short prompt gets you four minutes of honest, detailed feedback the exec would never sit down and type. That reply re-enters at Capture and shapes the next decision. Meet people in the channel they already use, and the feedback actually happens.
Do this continuously and decisions get recorded, teams stay aligned, insight stays current, and debt stops piling up.
Technical notes · what each agent is doing
CaptureScribe
Takes every source in and transcribes anything that was spoken or handwritten.
TechnicalOne Scribe runs per source, in parallel. Each input is transcribed if needed, tagged, and written to Store with a link back to its origin (provenance).
StoreCustodian
The one shared record. Everything downstream is generated from it, so nothing drifts.
TechnicalThe Custodian dedupes, tags, and links related records, so the metric drop, the ticket cluster, and the interview quotes about the same step all join into one thread.
Ask Storequery
Ask the record a plain-language question whenever you want and get an answer pulled straight from the real documents. It hangs off Store as a side tool, ready when you need it.
TechnicalDistribute sends updates out on a schedule; Ask Store works the other way, answering only when you ask. It draws from the approved part of Store, the version that has passed Review, and links the document behind every answer. If Store has nothing on the question, it says so. It runs off the Custodian’s index.
AgentsDrafterChallenger
Working only from Store, the agents turn the clustered evidence into a roadmap update: what moves up, what drops, and why.
TechnicalStrategist weighs the evidence against the goals and frames the options; Analyst sets the metric; Drafter writes the update; Challenger red-teams it and has to back every objection with real evidence from Store.
ReviewPM
The PM reads the draft, edits it, and approves it. No agent can skip this step, and the PM has the final say on what goes out.
TechnicalThe draft waits in a staging area first. It only joins the approved part of Store once the PM signs off, so nothing unapproved can go out.
DistributeDistributor
Turns the approved update into a short WhatsApp message the exec can read on their phone in seconds. Everyone hears the same decision; each team just gets it written up in the way that works for them.
TechnicalThe Distributor shapes the update for each channel and sends them at the same time: the exec on WhatsApp, and eng, sales, and support each in the tool they work in.
The loop closesScribe
The exec records a voice note in reply.
TechnicalThe reply re-enters at Capture as a new input and lands in Store, where it feeds the next decision. That return arrow is what closes the loop.
Drawn as a single left-to-right pass for this example. In the real system the knowledge loop (continuous) and the decision loop (event-driven) run separately and in parallel, Distribute fans out to every team at once, and the Conductor routes every hop in the background.
The problem it removes
Good teams still lose track of their own work
Decisions live in one person’s head, so they get re-argued or accidentally reversed. Documents drift out of date, so people act on stale information. Sales promises one thing while the roadmap says another, and engineering absorbs the gap as rushed rework. This is not a people problem — it is a missing system. The fix is the loop: make a better call, record it once, deliver it to each team in a form they will actually use, measure what happens, and feed that back in.
Debt 1
Documentation debt
Docs go stale and start to contradict each other.
Debt 2
Strategic debt
Decisions get re-argued, or quietly built over.
Debt 3
Technical debt
Teams act on mismatched information; someone patches the gap under deadline.
Debt 4
Risk debt
The cost of a choice arrives later as a surprise, to someone who never got to weigh in.
The four above pile up in the documents and the code. The next two pile up in the PM’s own head. Good AI tooling relieves the first and quietly creates the second, so this system is built to lift the load without hollowing out your grip on the work.
The human cost
PM cognitive overload
A PM carries every decision, document, and open thread in their head at once. All that load leaves little room for the judgment only a person can bring. The system holds the record and drafts the outputs, so the PM can spend their attention on the calls that actually need a human.
The AI-native risk
Cognitive debt
Hand enough of the thinking to AI tools and you slowly lose your grip on your own work, until you cannot recall the detail or defend a decision you approved. This system is built to prevent that. The PM still makes every call, and every output links back to the evidence behind it, so the team stays close to the source as more of the work becomes AI-native.
The whole system
Two loops, one shared hub, one human gate
The workflow runs as two loops that share a single record and a single human checkpoint. Colour tells them apart: green for the knowledge loop, blue for the decision loop, black for the shared hub. Each step names the agent that runs it.
Knowledge loop — raw signal becomes documents, then goes out
Capture
Scribe
→
Author
Drafter
→
Distribute
Distributor
↻ Teams feed signal back into Capture — the loop runs both ways
Store
single source of truth · Custodian
Ask Store
pull, in plain language · sourced
Review
the human gate · PM decides, Challenger first
Decision loop — set the goal, make the call, test it, measure, learn
Strategy
Strategist
→
Decide
Strategist frames · PM calls
→
Validate
PM runs it · Analyst
→
Measure
Analyst
→
Learn
Analyst
Risk & Trade-off
off Decide · Strategist drafts, Challenger tests
Decision Memo
off Validate · Drafter, to a small circle
↻ Learn feeds the gap back into Strategy and the next decision
Conductor — the orchestration layer
Routes work between agents, holds session state, fires triggers, enforces the gates and session handoff. Infrastructure, not authority — it moves the work but never approves it.
Who does what:
Agents draft, check, organise
The PM reviews, decides, approves, asks
Store holds the one true record
The knowledge loop
Moving raw signal into a shared record, and out to the teams
CaptureScribe
Takes in signal from every source, in whatever form it arrives — product metrics, meeting transcripts, a support ticket, a sales note, a voice message from an exec. Normalises it and writes it to Store. It does not interpret or editorialise.
R ScribeC CustodianI PM
StoreCustodian
The shared record and the hub of the whole system. Everything downstream is generated from it rather than copied by hand, so nothing drifts. The Custodian keeps it honest: dedup, schema, archival, and valid provenance links.
R CustodianI PM
AuthorDrafter
AI drafts the working documents straight from Store — decision logs, research summaries, specs, work logs. Guardrails keep the record honest: dated to the real work, and hard to quietly rewrite.
R DrafterC ChallengerA PM
ReviewChallengerPM
The human checkpoint, in two passes. The Challenger pressure-tests the draft adversarially and surfaces holes as questions. Then the PM edits, decides, and approves. Nothing leaves this step without judgment behind it.
R Challenger (adv.)R PM (editorial)
DistributeDistributor
Sends each team the document it needs, shaped for that team and delivered in the channel they already use. Because every version is generated from Store, the teams never end up working from conflicting copies.
R DistributorA PM
The decision loop
Making a call, testing it, and learning from the result
StrategyStrategist
The yardstick — the numbers this product area exists to move, such as gross profit, retention, and activation. Every later decision is judged against them.
R StrategistC AnalystA PM
DecideStrategistPM
The Strategist weighs the options against the objectives and frames them with reasoning. The PM makes the call, chooses what to build and in what order, and records why the other options were deprioritised. This sets the roadmap.
R Strategist (frames)R PM (calls)
ValidatePMAnalyst
Test the riskiest assumption cheaply before committing to it. The PM spins up the test personally — this is where they stay closest to the evidence. A small test produces fresh evidence, which flows straight back into Store.
R PMC Analyst
MeasureAnalyst
Choose the success metric at the moment the decision is made — not reverse-engineered later — then set up the measurement and watch it after launch.
R AnalystA PM
LearnAnalyst
Compare what you predicted with what actually happened. The gap is the lesson, tagged learn-forward and fed back into Strategy and the next decision — so decisions get better over time.
R AnalystC StrategistA PM
The eight agents
One clear owner for every step, without agent sprawl
Each agent maps to one or two workflow steps where a distinct capability is needed. No two share a primary responsibility. Agents are coloured by the loop they serve; the Challenger spans both, and the Conductor is infrastructure.
Scribe
Capture
Ingestion and transcription. Normalises signal and writes structured metadata to Store — without interpreting it.
Custodian
Store · system ownership
Maintains Store integrity: dedup, schema enforcement, archival, provenance. Decides what is tidy, not what is true.
Drafter
Author · Decision Memo · Risk
Generates documents from Store under guardrails — dated, hard to rewrite, shaped for the audience.
Challenger
Review (adversarial) · Risk — both loops
Pressure-tests drafts before Review. Its job is to find holes, not fix them: what is weakest, what was left out, what would make this wrong.
Strategist
Strategy · Decide (framing)
Holds the yardstick, frames options against objectives, and synthesises conflicting feedback into structured resolution options for the PM.
Analyst
Validate · Measure · Learn
Designs the success metric at decision time, sets up measurement, and tags the predicted-vs-actual gap as a lesson.
Distributor
Distribute · channel routing
Channel-aware delivery. Shapes each output for its audience and sends it where that person actually reads.
Conductor
Infrastructure — no framework step
Routes work, holds session state, fires triggers, enforces gates and session handoff. Never drafts, advises, or approves.
The satellites & the query interface
Three mechanisms that hang off the hub
Decision MemoDrafter
A timestamped snapshot of the thinking, circulated at Validate before a decision settles — to a small circle (engineering, product peers, management) whose job is to find holes, not sign off. It runs in two versions: one before the test (assumptions + plan) and one after (findings + current thinking). Comments return through Capture. The difference from Distribute is temperature: wide and settled versus narrow and provisional.
Risk & Trade-offStrategist
Drafted the moment a Decide record is created. A small, consistent shape: the risk named plainly, reversibility (one-way or two-way door), blast radius, the call (accept / mitigate / avoid / transfer), the reasoning in the PM’s own words, an owner, and a Revisit Trigger — a date or condition that forces a second look and feeds Learn. The Challenger tests whether the blast radius is understated.
Ask Storequery
The pull route out of Store: ask a plain-language question and get an answer sourced from real documents. Three rules keep it honest — it answers only from what is in Store, every answer names and links its source, and if nothing covers the question it says so. It reads only the approved, post-Review layer, never drafts.
The teams, both ways
The people who receive documents are the freshest source of signal
The teams are not the end of the line, so the arrow runs both ways. Distribute sends out in each person’s preferred format; Capture takes feedback back in that same format. An exec who gets a briefing on WhatsApp can reply with a voice note in seconds — ask that same person to log into a tool and fill in a form, and you get silence. The channel decides whether feedback happens at all, so the framework treats each person’s channel as part of the design.
Cross-cutting properties
Four things that run through every layer
Provenance
Every output traces back to the evidence that justified it — including every answer given through Ask Store.
Access control
Who can see what, with sensitive material such as personal data or exec-only notes kept protected.
System ownership
One person keeps the system healthy — prompts current, tags tidy, stale evidence archived. The Custodian automates most of it.
Channel routing
Each person’s preferred platform and format, used both to send to them and to hear back — including the small circle on the Decision Memo.
Governance
The principles that keep it honest
Single source of truth. Store is the only authoritative record. All agent output writes to Store or is derived from it.
Human gate on every decision. No agent commits a decision, publishes a document, or distributes externally without PM review.
Provenance on every output. Every document, answer, and recommendation traces back to the evidence in Store.
One Responsible per workflow. Every step has exactly one owner — shared responsibility is no responsibility.
Sequential constraint per decision cycle. A single cycle (Strategy → Decide → Validate → Measure → Learn) cannot parallelise its steps, though multiple cycles may overlap. You cannot validate what you have not yet decided.
Why this is content design, not admin
One shared record removes six kinds of debt at once
It is easy to mistake this for tidy paperwork. It is not. It removes six kinds of debt at once: documentation, strategic, technical, and risk debt in the work, plus cognitive overload and cognitive debt in the people who run it. Removing all six is what lets a team move fast without the mess building up. This framework is a product built for the people who build products — it treats the product manager’s own process as something worth designing, with real users (the PM and the internal teams) and content shaped to what each of them needs.
What it looks like running
A typical week
Illustrative, not prescriptive — the actual cadence depends on the team’s rhythm and volume. The PM touches only the review, decide, and read steps; everything else is agent-driven.
Monday
Capture & triage
Scribe ingests the weekend’s signal; Custodian dedups three overlapping entries; the PM marks two items as input to an active decision cycle.
Tuesday
Author & challenge
Drafter generates a pre-test Decision Memo for a pricing call. The Challenger finds it understates the customer-trust risk; the PM edits and approves circulation to the small circle.
Wednesday
Feedback & synthesis
Two responses arrive and Scribe captures them. The Strategist synthesises the conflict into three resolution options; the PM chooses to narrow the test cohort.
Thursday
Validate & measure
The PM runs the test on the narrowed cohort against the Analyst’s pre-set metric. Drafter produces a post-test memo; the Challenger questions the time horizon.
Friday
Learn & distribute
The signal is positive but below significance, so the PM extends observation. The Analyst tags a learn-forward lesson; the Distributor sends each team its own summary; an engineer queries Ask Store.
Responsibility
RACI — who is responsible, accountable, consulted, informed
Eight columns, coloured by loop. One Responsible per row; the PM is Accountable on every decision-bearing workflow. The Conductor does not appear — it operates around the matrix, routing and enforcing without taking a role.
Workflow
Scribe
Custodian
Drafter
Challenger
Strategist
Analyst
Distributor
PM
Knowledge loop
Capture
R
C
I
Store maintenance
R
I
Author
R
C
A
Review (adversarial)
R
A
Review (editorial)
I
R
Distribute
R
A
Decision loop
Strategy
R
C
A
Decide (option framing)
C
R
A
Decide (final call)
I
R
Risk & Trade-off
C
C
R
A
Validate
C
R
Measure
R
A
Learn
C
R
A
Satellites, query & handoff
Decision Memo
R
C
A
Decision Memo feedback
R
C
A
Ask Store
C
I
Session handoff
I
Key:
R Responsible — does the work
A Accountable — owns the outcome (the PM)
C Consulted — input before
I Informed — told after
Getting started
You don’t build all eight at once
Build in the order that dependencies allow — each phase produces something usable on its own, so value lands early and nothing waits on the whole system. The agent names below are live: click one to spotlight everywhere it works across this page.
1
BuildStoreScribeCustodian
You get a working knowledge base that takes in signal from every source and keeps it clean.
2
BuildDrafterConductor
You get documents generated straight from the record, with basic routing between agents.
3
BuildChallenger
You get a hard, adversarial review that finds the holes before the PM ever sees a draft.
4
BuildStrategistAnalyst
You get a working decision loop — options framed against objectives, with measurement and learning.
5
BuildDistributor
You get channel-aware delivery in each team’s own channel, closing the knowledge loop both ways.
6
BuildAsk Store
You get plain-language questions answered from the record, every answer sourced.
A solo PM at low volume does not need eight agents on day one. The minimum viable harness is StoreScribeDrafter — the PM plays Challenger, Strategist, and Analyst, which is what they already do. Add each agent when its absence starts costing PM attention.
Go deeper
The repo — and where the design principles live
jesscancode / ai-product-framework
An open framework, not a product. Fork it, staff the harness your own way, swap the agents — the one rule that stays is that a person owns every decision.
The framework defines the workflow; this harness is one valid way to staff it. Everything traces back to a framework concept — Store, Review, Author, Challenge, Strategy, Measure, Distribute — and the PM owns every decision. github.com/jesscancode/ai-product-framework