There's a moment every CPO dreads.
You're in a high-stakes prospect meeting. Your product is being compared head-to-head with a competitor. You know your value proposition cold. But then something shifts — the prospect starts describing a specific niche use-case you hadn't mapped in advance. The competitor, who presented before you, had already framed their entire pitch around exactly this scenario. You're sitting there knowing — genuinely knowing — that your product can address this better. But you can't connect the dots fast enough in the room. The moment passes. The opportunity slips.
That meeting stayed with me. Not because we lost — but because we didn't have to.
How We Got Here
Two years ago, the biggest constraint in product was engineering bandwidth. Validating a new idea meant months of scoping, resourcing, and building — just to find out if customers actually wanted it.
We changed that. We started using Replit and Figma Make to build working prototypes directly with customers, before a single line of production code was written. What used to require weeks of engineering risk became a conversation with a working demo on the table. When one of our biggest customers expressed genuine delight at a forward-looking product concept — one that, a year earlier, would have required enormous engineering investment just to test — the decision to build it was instant. The engineers already had a clear picture of what was expected. The prototype did the communication for us.
It was a genuine shift in how product teams operate. Less dependency. Faster validation. More confidence.
But it created a new problem we didn't anticipate.
The Bottleneck Moved
Once engineering bandwidth stopped being the constraint, the bottleneck moved upstream — to decisions.
In 2026, the expectation is no longer just "validate faster." It's "deliver faster." In some cases, by the next business day. The CEO wants it. Customers expect it. The competitive environment demands it.
This sounds like a resourcing problem. It isn't. It's a knowledge problem.
When delivery cycles compress this dramatically, CPOs can no longer run the traditional "research, analyze, decide" cycle. The decision has to happen at the meeting table. Not after it. A CPO who says "let me take that away and come back to you" in a fast-moving competitive context is already behind.
But making a good decision at the table requires something that's genuinely hard to maintain at speed: context. Why was a previous decision made? What did that enterprise customer say about this three months ago? How does this prospect's use-case map against what we know about the competitor's positioning? What does our roadmap say about this area?
That context exists. Somewhere. Scattered across meeting transcripts, email threads, roadmap documents, customer communications, Slack threads, and — most dangerously — individual people's heads. Before I had a better system, my process was exactly what you'd expect: digging through documents, chasing down email threads, piecing together data points from memory. Slow. Incomplete. Unreliable under pressure.
The meeting I described at the start of this article was a product of that system. I had the knowledge somewhere. I just couldn't access it in the room.
The Pattern That Changed Everything
A few months ago I came across a X post by Andrej Karpathy — AI researcher, formerly of Tesla and OpenAI — describing a pattern he called the LLM Wiki.
The core idea is deceptively simple. Most people use AI the way they use a search engine: ask a question, get an answer, repeat. Nothing accumulates. Every query starts from scratch. Karpathy's insight was different: instead of retrieving from raw documents every time, have the AI maintain a living wiki — a structured, interlinked knowledge base that gets richer with every source you add. The AI doesn't just file information. It reads each new source, integrates it with what already exists, flags contradictions, updates cross-references, and builds a synthesis that compounds over time.
I read it as a software engineer's idea. Then I re-read it and saw something else entirely: a solution to the exact problem I'd been living with as a CPO.
What I Built
I took Karpathy's pattern and adapted it for the CPO context. I now feed everything into Claude — meeting transcripts, roadmap documents, customer communications, competitive signals, OKR updates, sprint reviews. Claude doesn't just store it. It organizes my entire product world into a structured, searchable knowledge base across five domains: competitive intelligence, customer insights, product decision memory, delivery tracking, and team performance.
Every new source I add gets integrated with what's already there. If a customer call mentions a competitor, it gets cross-linked to the competitor's page. If a delivery blocker connects to a customer complaint pattern, that connection gets noted. The synthesis is already done before I need it.
At the start of every session, I type one word: Start. Claude orients itself — today's date, how many pages are in the wiki, what was last ingested — and is ready.
The result is something I didn't fully anticipate: it's changed how I show up in meetings. Not dramatically, not all at once — but the quality of my informed decisions has improved by manifold. When a question comes up at the table, I'm not reaching into a fog. I'm reaching into a system.
That prospect meeting I described? I now think about it differently. The niche use-case the prospect raised would have been in my wiki — mapped against our product capabilities, cross-referenced against what I knew about the competitor's positioning. The connection would have been retrievable in seconds. The decision about how to reframe our presentation could have happened in the room.
For CPOs Navigating This Shift
If you're feeling the same pressure — faster delivery, decisions at the table, no time for the old research cycle — I'd offer this reframe:
The problem isn't that you don't know enough. The problem is that what you know isn't organized for retrieval under pressure.
Karpathy's insight was that the expensive part of a knowledge base isn't reading or thinking — it's maintenance. Keeping it current. Cross-referencing. Updating when new information contradicts old assumptions. That's the work humans abandon because it grows faster than the value. An LLM doesn't get bored. It doesn't forget to update a cross-reference. It can touch fifteen documents in a single pass.
Your job is to bring the signals — the calls, the competitive reports, the roadmap debates. The AI does the bookkeeping.
I've open-sourced the prompt I built for this, adapted specifically for CPOs. It's free, it works with Claude Code and Obsidian, and it takes about 15 minutes to set up: github.com/anup-shesh/cpo-wiki
Credit to Andrej Karpathy for the pattern. All I did was bring it into the product org.
Originally published on LinkedIn. View the original →