The AI product management
From empowered teams to AI co-workers
Product management had a best practice before AI: empowered teams, continuous discovery, outcomes over output. AI does not replace that model. It breaks one quiet assumption underneath it, and that changes everything about how the work gets done.
Part 1
The old way: the pre-AI best practice
This is the right way to build products, defined by Marty Cagan (empowered teams, the product operating model, discovery versus delivery) and Teresa Torres (the Opportunity Solution Tree). We call it the old way only because it is human-driven and predates AI. It is the state of the art kster builds on.
A cross-functional team is handed an outcome to drive, then runs discovery and delivery continuously and in parallel: proving what is worth building while shipping the validated pieces, each feeding the other. All the judgment, synthesis, and context live in the humans.
Leadership: vision + Business Outcome
The commercial result. "What business win do we need?"
context ▸ strategy decks · board reports · OKR sheets · market insights
Team and leadership agree a Product Outcome, the team commits to it
The user-behaviour-change bet that drives the business outcome. PM (value + viability), Designer (usability), Engineers (feasibility) collaborate, no handoffs.
context ▸ roadmap tool · planning docs · OKR doc
Continuous discovery
Problem space
Opportunities: a persona's unmet need, pain, or desire that could move the outcome. Big ones (boulders) break down into stones and pebbles. Talk to customers weekly.
Solution space
Solutions carry assumptions across four risks (value, usability, feasibility, viability). Cheap throwaway tests validate them, 10 to 20 probes a week.
context ▸ Dovetail · research repo · Figma · Miro · analytics
Continuous delivery
Build the validated pieces
Small, frequent releases. Each tested pebble that survives gets built as it is proven, not at the end. Ships return real usage and data as evidence.
context ▸ Jira/Linear stories · PRDs · Confluence wiki · tickets
Discovery and delivery run continuously and in parallel. Every shipped pebble teaches the next round.
Measure the Product Outcome metric, learn, keep looping
Continuous, never a one-time project.
context ▸ Amplitude / Mixpanel dashboards · KPI sheets · BI reports
The process is right. The context underneath it is the problem. Every box above sits on its own context layer, and in reality that context is fragmented across tools, owned by different people, and disconnected from the levels above and below.
Two compounding failures
- Horizontal fragmentation. Context is scattered across tools at the same level. Figma is not Dovetail is not the doc is not the ticket. No single connected picture exists.
- Vertical disconnection. The levels do not link. The leadership why never reaches the ticket. The interview insight never reaches the metric. The causal chain the framework requires exists only in people's heads.
And all of it goes stale the moment reality moves. In the old world this was survivable, because humans held a shared understanding and synced it by osmosis.
Part 2
The new world: AI co-workers join the team
The old model assumed one thing that was always true, until now: the whole team was human. That is the assumption AI breaks. Three forces hit at once.
Roles collapse into the Product Builder
The team of ~7 compresses into ~3 Product Builders, sometimes a team of one. The handoffs disappear. One person carries value, usability, feasibility, and viability, with AI doing the labor underneath.
Delivery explodes, so discovery becomes the constraint
AI makes building fast and cheap. Speeding up delivery just moves the bottleneck. Now discovery is the slowest step, and it runs on talking to real people, which you cannot 10x with compute.
So humans bring AI into the loop on both sides
Accelerate discovery: synthesize interviews, frame opportunities, draft solutions, design tests. Generate delivery artifacts: PRDs, stories, tickets, prototypes in minutes instead of days.
Same skeleton as the old-world map: business outcome, product outcome, discovery, delivery, measure, loop. The process did not change. What changed is that a non-human teammate now sits at every level, the labor got faster, discovery became the bottleneck, and the shared-context engine that quietly held it together, human memory, went dark for the one teammate doing most of the work.
Leadership + AI co-worker: vision + Business Outcome
AI drafts and synthesizes, but cannot read the why behind the deck.
context ▸ strategy decks · board reports · OKR sheets · market insights
A team of ~3 Product Builders (often solo) commits to a Product Outcome
Each works with AI co-workers. One builder now owns all four risks. No PM ↔ design ↔ eng conversation to carry the why.
context ▸ roadmap tool · planning docs · OKR doc
Continuous discovery + AI
Problem space
AI synthesizes interviews and frames opportunities (boulders to pebbles).
Solution space
AI drafts solutions, surfaces assumptions, designs tests.
Still slow: humans must talk to real people. You cannot 10x this with compute.
context ▸ Dovetail · research repo · Figma · Miro · analytics
Continuous delivery + AI
AI generates artifacts fast
PRDs, stories, prototypes, working code in minutes or days. Velocity climbs, so pressure pushes back onto discovery, the new bottleneck.
context ▸ Jira/Linear stories · PRDs · Confluence wiki · tickets
Discovery and delivery run continuously and in parallel. Every shipped pebble teaches the next round.
Measure the Product Outcome metric, learn, keep looping
AI reads the number, not the decision it was meant to judge.
context ▸ Amplitude / Mixpanel dashboards · KPI sheets · BI reports
The gap: at every level, the AI co-worker needs the shared context the work runs on. It cannot get it.
- The good context lives in human memory, invisible to AI.
- The written context is fragmented and stale. AI reads the broken version, and every session starts cold.
There is no single clean, connected context that the human and the AI co-worker both share. That hole is the pain.
The break: human memory cannot be shared with a machine
Human memory was a great shared-context engine. It auto-updated, held the why, and spread by osmosis, but only among the humans who were in the room. The new world violates both halves of that. The AI co-worker was never in the room, so every session starts cold. And the team conversation that used to carry context is gone, because a solo builder plus AI has no PM-to-designer-to-engineer dialogue to transfer understanding.
So the shared context has to move out of human heads into something external, structured, and connected. The trap: the moment you externalize it with the old tools (docs, decks, wikis, tickets), you are back to the fragmented, stale, disconnected layer from Part 1, now with an AI that can only read the broken version.
The climax
What builders are doing right now (and why both fail)
Builders feel the gap. They are already improvising around it, and they split into two camps, falling off opposite sides of the same missing thing.
Camp 1 — The Librarian
Understands the gap
- Has the AI write markdown memory files for the AI to read back
- So the AI documents its own assumptions, not reality
- Files multiply, none of them link
- Drift compounds every round
- The builder drowns maintaining them
Right instinct, no ground truth.
Camp 2 — The Vibecoder
Ignores the gap
- Throws prompts at the wall, sees what sticks
- No context, no structure, no plan
- Lots of motion, little signal
- Rework on rework
- The AI bill climbs fast
Fast motion, no direction.
Same root cause: there is no structured, connected, shared context layer. Camp 1 builds an unstructured one by hand and drowns. Camp 2 builds none and burns cash. Neither has the thing the new world actually requires.
Enter kster.ai
One clean, structured, connected context that both humans and AI share. It auto-updates from the learning loop the way memory used to, but lives outside any single head, and is structured (via the Opportunity Solution Tree) so it never drifts into a pile of disconnected files. That is the thing the old toolchain cannot be, the thing the hand-rolled markdown pile cannot become, and the thing AI co-workers require to be real teammates.
The stakes
Where the constraint lands, and why that is the point
When AI absorbs the labor (synthesis, drafting, building, artifact generation), the constraint does not disappear. It rises to the level only humans can work at: judgment and interaction. Talking to customers. Weighing trade-offs against business reality. Deciding what is actually worth solving. That is not a problem to engineer away. It is the work the empowered model says humans should be doing.
It also unlocks something teams rarely have time for: maintaining the software, not just building more of it. Caring for what is shipped instead of an endless feature treadmill. But this is a fork, not a guarantee.
So the shared context layer is not just plumbing for AI co-workers. It is the thing that decides whether AI makes teams better product builders or just faster feature factories. Lift the constraint to human judgment, and give humans clean shared context to judge with, and the team finally has the time, and the basis, to build and maintain great products.