Anup Sheshadri — Writing

Access Is Not Adoption

2026-06-27T00:00:00Z

A few weeks ago I caught myself doing something that should have been impossible two years ago.

I was on a customer call, and while the conversation ran, I had an agent quietly driving my browser in another window, pulling a week's worth of reports, no clicking, no me. Earlier that morning a scheduled task had already dropped yesterday's metrics into my lap at 7:45. Later I'd ask another agent to read a new spec and write the test cases for it, and it would hand me back forty-five of them, cross-linked to a related spec by shared dependencies. None of this required me to write a line of code. Most of it required me to do nothing at all.

I'm not telling you this to brag. I'm telling you because of the uncomfortable thought that followed. I was one of only a handful of people at my company working anything like this. I'd been open about it the whole way, happy to show a colleague what I'd rigged up, forever experimenting out loud. And still, the way I worked hadn't really spread.

The ladder I climbed without noticing

When I trace how I got here, it isn't a story about better models. It's a story about better context.

It started with ChatGPT for research and brainstorming, a brilliant stranger with no memory. I brought all the context, every single time.
Then NotebookLM, loaded with our product documentation so the support team could troubleshoot customer questions on their own and lean on me less. That was my first taste of giving AI a managed body of knowledge to work from instead of starting cold, and the first time the leverage landed on someone other than me.
Then a custom GPT pointed at one project's specific docs. That was my first real taste of retrievable AI, context that persisted and could be addressed. The model stopped being the point. What I fed it became the point.
Today: Claude and Obsidian, running on something close to auto. My second brain is built on Andrej Karpathy's LLM-wiki pattern, the same architecture I wrote about in The CPO's New Reality, now pointed at two things: my job (a CPO wiki) and my life (a personal one).

Every rung on that ladder was a step up in context, not capability. The reason I'm fast isn't that I prompt better than my team. It's that I spent two years building the scaffolding underneath the prompt. The model was never my advantage. The harness was.

Which is exactly why "how do I get my team as productive as me?" turned out to be the wrong question.

The wrong question

The instinct, when you've found leverage, is to hand people your tool. Here's a login, go be 10x.

It doesn't work, and I have proof at both ends of the scale.

At my end: I set a north-star goal of fully automated bookings, with no human needing to step in. Months in, with the tools available to everyone, we were still stuck with a human touching roughly one in ten, and I found myself reviewing the exceptions one by one to understand why. The tools were never the constraint.

At a far bigger scale, Ramp told the same story. In We Built Every Employee at Ramp Their Own AI Coworker, Seb Goddijn writes that they hit 99% adoption of AI tools across the company, then noticed most people were stuck. So they built their own internal AI product, which they call Glass, to turn every employee into a power user without the configuration pain. Their diagnosis is perfect: "The models are good enough. The harness isn't." People were driving a Ferrari with the handbrake on.

That's the whole thing in one sentence. Access is not adoption. Giving everyone a model is not the same as making everyone effective. The gap between the two isn't technical. It's human, and it lives below the feature line, in the unglamorous territory of fear, ownership, and context.

Why people get stuck (it isn't the model)

Fear is the blocker, not capability. My slow adopters aren't lazy or unambitious. They're afraid of being wrong, and in real work wrong has consequences. A number that comes out off in a report someone sends to a customer. An edit that quietly breaks something and takes days to trace back. When the cost of a mistake is real, "just try the AI" is not the invitation it sounds like. Ramp names the same root cause: they had "created urgency without providing enough infrastructure." Pressure without scaffolding doesn't create adopters. It strands people.

So the leadership job isn't to force usage. It's to engineer low-stakes places to be wrong, and to start where a mistake costs nothing. Brainstorming, research, and first-draft design are fear-free zones. Anything that touches money or a live customer is not. You begin adoption where being wrong is cheap, not where it's catastrophic.

Adoption decays without an owner. Here's the part nobody admits: adoption isn't a launch, it's a maintained state. I've had to realign my team on a single critical automation three separate times. Each time we aligned. Each time it quietly reverted, not from disagreement, but because no one owned the heartbeat. It only held once I named one person accountable for it daily. Adopted-and-left-alone is just delayed un-adoption.

A demo is not adoption. I spent weeks on an AI voice agent to handle routine phone calls to vendors. In a demo it's magic. In live conditions it's brutal: an agent that goes off script the instant a human picks up, a model that says "press one" out loud instead of actually pressing it. So it sits behind a gate, fifty percent clean-call success before it touches the pipeline. We're at ten. It stays out. Enthusiasm that ships before it's gated doesn't become adoption. It becomes operational debt.

What actually moved the needle

Once I stopped trying to mandate AI and started trying to transmit it, three things worked.

1. Show the work, on a problem they already hate

Not "look what AI can do," but "look what AI just did to the thing you dread."

The one that turned the most heads was the wiki. I built a product wiki on the LLM-wiki pattern: every decision, account, and roadmap debate captured as linked notes that an agent keeps current. Now, instead of digging through old threads and documents to answer "wait, why did we decide this?", anyone can just ask the wiki and get an answer with its sources attached. The dreaded archaeology of institutional memory, gone. The colleague I showed it to didn't want a lecture on AI. They wanted their own wiki by the end of the call.

Then the writeups everyone hates. Drop in an hour-long meeting recording, get back a structured summary with decisions and action items, already filed where the team can find it. Then the blank page: a rough product idea turned into a working prototype in an afternoon, help-center articles drafted straight from product screenshots, usability feedback on a design before it ever reached a real user. None of it arrived as a mandate. All of it arrived as a "watch this."

Ramp found the identical thing: the people who got the most value "weren't the ones who attended training. They were the ones who installed a skill on day one and got a result." The result is the teacher.

2. Hand over context, not chatbots

The reason a teammate with ChatGPT open isn't 10x is that they're stuck on rung one of my ladder, re-feeding context every session. My real job, as the person who climbed it, is to build rung three for them: the shared knowledgebase, the project-specific custom GPT, the wiki their agent can read. Ramp's sharpest principle is this exact idea: "one person's breakthrough should become everyone's baseline." The failure mode was never that people couldn't figure it out. It's that everyone had to figure it out alone. Adoption compounds when context becomes shared infrastructure, not when everyone gets a login.

3. Wire it into who owns what

The one adoption that truly stuck was a rework of our QA process, and the idea wasn't even mine. Our CTO proposed it. My part was building the accountability in: developers now generate their own structured test reports with AI, and the lead audits them for completeness instead of re-running everything by hand. It wasn't "please use this tool." It became "this is how the job is done now." Adoption sticks when it's load-bearing, not optional. And it doesn't have to start with you. Some of the best adoption ideas will come from your team. Your job is to harden them into process.

You don't need to build Glass

Here's where my story diverges from Ramp's, and why I think it's more useful to most of you.

Ramp's answer, Glass, was to build a product: a full workspace, a marketplace of hundreds of shared, reviewed skills, a memory pipeline, an engineering team behind all of it. It's magnificent. And almost none of us can do it.

I don't have a platform team. My "AI coworker for everyone" isn't homegrown software. It's ChatGPT, NotebookLM, a few custom GPTs pointed at real workflows, and Claude with Obsidian on a borrowed wiki pattern. My version of Ramp's skills marketplace is a folder of markdown and a knowledgebase the team can query. Total platform engineering invested: zero.

So take Ramp's principle and shrink the implementation to fit your reality: raise the floor, don't lower the ceiling. The philosophy scales down beautifully. The build does not have to. You can start raising your floor this afternoon with tools you already pay for.

Why this is worth the unglamorous slog

None of this, the wiki, the named owners, the fear-free zones, the shared context, shows up in a changelog. It's all below the feature line. So why pour a product leader's scarce hours into it?

Because internal adoption is a rehearsal for the product you'll have to ship.

In a few years, the customer touching your product may not be a human at all. It may be their agent, calling your system. I've made that bet explicit in my own roadmap, and I've argued elsewhere that you should build the differentiation and buy the commodity. A team that's already fluent, support reasoning over a live knowledgebase, QA gating with evals, designers prototyping at the speed of thought, is a team that can build for that agent-first world, because it already lives there internally. The org that adopts AI inside first is the one that survives the agentic shift outside.

Transformation like this is never won at the summit, in the flashy demo. It's earned in the foothills, in the slow, deliberate work of raising one teammate's floor at a time.

I got fast with AI by my side. The harder, more valuable work is helping everyone else get there too. We don't lower the ceiling. We raise the floor, for everyone, at once.

Transformation Is Earned in the Foothills

2026-06-20T00:00:00Z

A little over a year ago, I was halfway up the via ferrata at Nelson Rocks in West Virginia, clipped to an iron rung with more air beneath my heels than I'd felt in years, when something I thought I'd lost came back.

I've spent the last few years building products, scaling teams, optimizing decisions. Good years. But somewhere in them, the part of me that wanted to be exposed, physically and consequentially, on the side of something that doesn't care about your roadmap, had gone quiet. On that rock face, it woke up. And by the time I unclipped at the top, I'd thought a sentence I hadn't let myself think in a long time:

I want to climb Everest.

Not as a metaphor. The actual mountain.

Then, about ten seconds later, came the more useful thought: I cannot just go.

That was over a year ago. I half expected the pull to fade into a nice story I'd tell at dinner. It hasn't.

The gap between the wanting and the ready

Here's the thing about Everest that the summit photos never show you. The mountain doesn't care how badly you want it. It doesn't care about your motivation, your post, or your renewed sense of purpose. Above a certain altitude, your body simply begins to fail, and the only thing standing between you and that failure is preparation you did months and years earlier, at lower and less glamorous elevations.

You don't train for Everest. You train up to it.

You summit smaller mountains first. You learn rope work and crampon technique on peaks where a mistake is survivable. You teach your body what thin air feels like before you bet your life on it. You build the hard skills slowly, on ground that forgives you. Every one of those smaller summits feels like a detour when your eyes are fixed on the big one. None of them are. They are the only path that exists.

The wanting is free. Everyone on the trail has the wanting. The progression is the whole game.

The same mountain, at work

I run product for a living, and I couldn't shake how precisely this maps onto the thing every team I know is staring at right now.

AI is rewriting the landscape under our feet. The way we build, decide, staff, and ship is changing faster than any cycle I've worked through. Navigating it well is, genuinely, our Everest: an audacious, non-optional climb the whole industry is pointing at simultaneously.

And here's where I watch good leaders go wrong: they book the Everest trip.

They announce the transformation. They set the summit date, the kind of aspirational roadmap I've argued is quietly lying to everyone who reads it. They mandate that the team "become AI-native" by some quarter, and then they're surprised when capability doesn't materialize on schedule. They skipped the acclimatization: the reps, the small wins, the skill-building on low-stakes ground where a mistake teaches instead of kills. Bodies fail at altitude that way. Teams do too.

Because ambition was never the scarce resource. Everyone can see the peak. Pointing at it requires nothing but a slide and some conviction. The rare and actually valuable work is choosing the training summit, the deliberately smaller and deliberately survivable bet where your team builds real skill before the stakes get fatal, and then being patient enough to let them earn the altitude.

Here's what that looked like for us.

Before rolling AI-augmented testing across the engineering team, I didn't announce anything. I ran one pilot. We dropped a single PRD into a folder. No configuration, no setup meeting, just the document and the tool. It generated 45 test cases, and then it cross-linked them to a dependency it found in a separate document I hadn't even pointed it to. That one run did more to demonstrate the system's value than any presentation I could have built. The capability spread from there, but only because it earned its altitude on a non-critical document first.

The temptation was to announce the transformation. The actual move was to find the one safe slope and let it prove itself. It's the same restraint I wrote about in Just Because You Can Vibe-Code It Doesn't Mean You Should Build It: the ability to do more is not a reason to do more.

"But you told us to decide now"

A fair challenge, because I've written the opposite. Not long ago I argued, in The CPO's New Reality: Decide Now or Lose the Room, that the modern product leader has to decide now or lose the room, that hesitation is its own kind of failure. So which is it? Move fast, or be patient?

Both. They're not in tension once you see what each one governs.

Speed of decision and speed of capability are different mountains. A leader should decide fast: commit to the climb, pick the route, refuse to dither in the room. But you cannot decide your team into readiness. Capability compounds at its own pace, summit by summit, and pretending urgency can skip that is how expeditions die above the death zone. You decide fast. You let the team climb slow. Confusing the two, demanding capability on the timeline of a decision, is the most common way I see ambitious leaders hurt the very teams they're trying to elevate.

Patience, here, isn't the opposite of urgency. It's what urgency looks like when you're responsible for other people's altitude.

The part nobody tells you: even the strategy is earned on the foothills

There's a deeper version of this that I only understood in hindsight.

We're working toward a thesis that our platform needs to expose itself to agents, not just humans. It's a real strategic bet about where the commercial ground shifts next. And if you'd asked me to write that memo on Day 1, I couldn't have. Not because I lacked the intelligence to reason about it, but because I lacked the reps.

The conviction didn't come from a strategy document. It came from months of personally living in this world: running SQL queries without writing SQL, pulling health data off my wearables, extracting transcripts, wiring up scheduling workflows. The intuition built one small climb at a time. And the moment the thesis actually crystallized wasn't in a product meeting. It was noticing that one product was effortless for an agent to navigate (clean DOM, inspectable structure) and another was a wall, and understanding in my gut why that distinction would matter commercially within a year.

That's the part the summit-photo crowd misses. The foothills aren't just where you build skill. They're where you build judgment, the strategic insight that looks like vision from the outside but is really just accumulated reps. You couldn't have written the memo on Day 1. The foothills were the research.

What I'm actually doing about it

So I'm not booking Everest. Not this year, maybe not for several. I'm picking smaller mountains, real ones, and learning to suffer correctly on each, building the body and the hard skills the death zone will eventually demand, on slopes that let me make new mistakes instead of repeating fatal ones.

I'm trying to lead the same way. Less pointing at the peak. More choosing the next honest foothill, and protecting the time it takes my team, and me, to climb it.

Ambition sets the destination. Progression is the only thing that gets you there.

Lead the foothills, not the summit photo.

Your Roadmap Is Lying to Everyone. Including You.

2026-06-14T00:00:00Z

I used to write roadmaps that made everyone happy.

Features for the anchor customer. A few exciting bets for the team. A forward-looking narrative for new prospects. Organized by theme, color-coded by quarter, presented in a meeting where people nodded along.

They looked good. But they were lying. Not because I was being dishonest. Because I was answering the wrong question. I was writing a roadmap to communicate ambition — to customers, to investors, to the team. What I wasn't doing was answering the harder question: whose problem are we choosing not to solve this quarter?

That's the real question a roadmap exists to answer. And most roadmaps never go near it.

A roadmap is a bandwidth budget.

Your team has a fixed amount of capacity. Every hour spent on one problem is an hour not spent on another. The roadmap is just an answer to how you're distributing that capacity — and more importantly, what you're consciously choosing not to prioritize.

When you write a roadmap as vision, the trade-offs are invisible. Everyone reads hope into it. The customer sees their request somewhere on the timeline. The team sees the interesting problems. The investor sees scale. Nobody feels the constraint — because you never made the constraint explicit.

But when you write it as bandwidth allocation — this customer's needs get X% of our capacity, this governance work gets Y%, this new customer onboarding gets Z% — suddenly the trade-offs are on the table. And the conversations that follow are honest ones.

That shift is uncomfortable. Telling a customer "we're putting 20% of capacity toward your account this quarter, not 60%" is harder than "it's on the roadmap." But it's the only version that actually means something.

The problem: you can't allocate honestly what you can't see clearly.

Here's where it breaks down in practice.

Making a real bandwidth call requires holding a lot in view at once. What is each customer actually asking for, and why? What's the team's current load and where are the real blockers? What competitive pressure makes certain bets more urgent than they appeared last month? What have you already committed to, and to whom?

Most CPOs making these calls are working with scattered, incomplete context. Customer needs live in CRM notes and email threads. Delivery status lives in project trackers. Competitive signals live in someone's slide deck from last quarter. Financial signals live in a spreadsheet that arrives on Fridays.

None of it connects. None of it is organized for the moment of decision.

So what happens? You allocate bandwidth to whoever showed up to the meeting. To the customer who escalated loudest. To the feature that's easiest to explain. Not to what the full picture actually says.

What changed for me: building a CPO wiki.

I started building a personal knowledge system — a CPO Intelligence Wiki — where every source that informs product decisions gets ingested, synthesized, and cross-linked into a single organized structure: customer conversations, competitive signals, delivery status, team capacity, financial data. Maintained by AI. Owned by me.

I wrote about the in-meeting version of this in an earlier piece — how it changes real-time decision speed. But the deeper change has been in the roadmap itself.

Now when I sit down to make a bandwidth call, I'm not reconstructing context from memory. I can see account health across every customer, what's in flight and what's blocked, the competitive signal that makes one bet more urgent than it appeared, and what I committed to, when, and why.

The decisions aren't always easier. But they're honest.

Recently I made a call to put an anchor customer on reduced bandwidth — not because their account wasn't important, but because across the full picture I could see that what would actually protect their account long-term required fixing something structural first. That's not a call I could have defended confidently without organized context. With it, I could explain exactly why — to my team, and to them.

The roadmap is only as honest as the information behind it.

Most product leaders spend more time formatting their roadmap than organizing the intelligence that should inform it. I used to be one of them.

The roadmap that makes everyone happy is usually the one doing the least work. The one that reflects real bandwidth decisions — including the uncomfortable ones — is the one that actually guides execution.

You can't get there by thinking harder. You get there by answering the question most roadmaps avoid: whose problem are we choosing not to solve this quarter?

Just Because You Can Vibe-Code It Doesn't Mean You Should Build It

2026-06-05T00:00:00Z

My team came to me with a customer request, a rough spec, and the kind of confidence that comes from knowing exactly how long something will take to build.

"We can vibe-code this in no time," they said. "And if we build it ourselves, we can integrate it directly with the core product — better insights, cleaner analytics, the full picture."

It was a good argument. They weren't wrong.

I still said no. Not "let's evaluate it." Not "let's put it in the backlog." Just no.

A customer had recently asked us for more functionality in the way they interact with our customer support team. They wanted a better dashboard, clearer tracking, more analytics, and easier access to updates on the topics they cared about.

The request was reasonable. The customer support platform we were using had limitations, and it was not meeting all of their expectations.

My team's response was also reasonable. After all, this is 2026. We could vibe-code most of what the customer wanted, connect it to our existing systems, and release something surprisingly capable in very little time.

Can you guess my response?

No.

The real question is not whether we can build it

The cost of building software has fallen dramatically.

What once required months of engineering effort can now be prototyped in days, sometimes hours. That changes the economics of product development — but it does not eliminate the need for product strategy.

In fact, it makes product discipline even more important.

When building becomes easier, teams become more likely to build things simply because they can.

But the real cost of a feature is rarely the initial development effort. The real cost is everything that happens after launch:

Customers begin depending on it.
Customer Success begins positioning it.
Feedback starts arriving.
Bugs need to be fixed.
Integrations need to be maintained.
Reporting requirements expand.
One customer's workflow becomes another customer's expectation.
A temporary solution quietly becomes part of the product.

Vibe coding compresses development time. It does not eliminate product ownership.

We are trying to reduce support involvement, not improve it

Today, more than 90% of the travel we serve is handled directly by the product. Our customer support team becomes involved in less than 10% of transactions. And my long-term goal is to bring that number as close to zero as possible.

Realistically, it will never reach absolute zero. Travel is unpredictable. Flights get cancelled, hotels lose reservations, suppliers fail, and unusual situations will always require human judgment.

But strategically, the direction is clear: every recurring support interaction should be treated as an opportunity for the product to become better.

That is why building a sophisticated customer-facing support dashboard felt wrong. It would make the support process easier to observe and manage. But it would not reduce the customer's need for support. We would be building a better interface for a workflow we are actively trying to minimize.

I would rather have my product and engineering teams investigate why customers need those updates in the first place.

Can the product detect the issue earlier? Can it resolve the issue automatically? Can it proactively notify the traveler or travel manager? Can we eliminate the uncertainty that makes the customer ask for a status update?

Those are harder problems. They are also the problems that move our product forward.

Every feature creates a constituency

Once we build something, it becomes very difficult to treat it as temporary.

The customer understandably assumes: we built this, therefore we own it. The next request might be a new filter. Then a different report. Then customized alerts. Then role-based permissions. Then integration with another system. None of these requests will sound unreasonable.

Customer Success managers will also advocate for them — and they should. Their responsibilities include customer satisfaction, retention, and helping customers get value from the platform.

But this creates a predictable internal dynamic. The customer sees an incomplete product. Customer Success sees a retention risk. Engineering sees something that can be implemented quickly. And gradually, an internal support utility becomes a roadmap competing for product investment.

This is not because anyone is making a bad decision individually. It is because each team is responding rationally to its own incentives. Product leadership has to protect the company from the cumulative effect of those individually rational decisions.

Listening to customers does not mean building what they request

The customer's request was valuable. It told us that they lacked visibility, confidence, and control when an issue required support intervention.

But a customer request contains two different things:

The underlying problem.
The customer's proposed solution.

We should take the problem extremely seriously. We do not always have to accept the proposed solution.

Customer obsession is not the same as request fulfillment.

Sometimes the most customer-centric decision is to build exactly what the customer asks for. Sometimes it is to solve the underlying problem differently. And sometimes it is to use an existing third-party tool rather than turning a supporting workflow into a proprietary product.

That is what we chose to do. We selected a customer support platform that could provide the dashboards, analytics, tracking, and communication capabilities the customer needed. We will clearly communicate what the platform offers. But we are not creating a custom product roadmap around it.

Buy the commodity. Build the differentiation.

This decision reflects a broader product principle: buy the capabilities that help you operate. Build the capabilities that make you different.

A better support dashboard might improve the experience of managing exceptions. A better travel product reduces the number of exceptions. Only one of those strengthens our core differentiation.

AI-assisted development makes it tempting to build both. But having the ability to build more things does not mean a company should own more things.

The easiest feature to build can become the hardest strategic decision to unwind.

So yes, we could have vibe-coded the requested functionality. We chose not to.

Because the goal is not to build software faster. The goal is to build less of the wrong software — and direct our energy toward making customer support progressively less necessary.

The CPO's New Reality: Decide Now or Lose the Room

2026-05-30T00:00:00Z

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.

Startups and Product Management: A Tale of Passion, Agility, and Innovation

2024-01-14T00:00:00Z

In the dynamic world of business, the role of a product manager is pivotal, serving as the nexus between the development team, the customer, and the broader market landscape. However, in the context of a startup, this role takes on a uniquely challenging and exhilarating dimension. Startups, known for their agility and innovation, offer a playing field drastically different from that of established corporations. This difference is particularly evident in the realm of product management.

At the heart of every startup lies the passion and vision of its founders, which often forms the primary driving force behind its products. Unlike established companies, startups typically do not have an abundance of market data or historical trends to inform their product development strategies. Instead, they rely heavily on the intuition, insights, and often untested convictions of their founding team. This approach, while fraught with uncertainty, is also a wellspring of innovation and disruptive potential.

In startups, product managers often find themselves navigating a landscape that is not just uncharted but also rapidly evolving. The absence of structured processes and the need to constantly adapt to changing market demands, internal dynamics, and resource constraints define the startup environment.

Product-Led Growth 101

2022-09-03T00:00:00Z

What is Product Led Growth (PLG)?

"Product-led growth is a business strategy that relies on using your product as the main vehicle to acquire, activate, and retain customers." — Wes Bush, author of the book Product-Led Growth

Some great examples of such products are — Zoom, Dropbox, Slack, and Netflix. For none of these products will you ever have to talk to a "human" to purchase and use their service/subscription.

Why adopt Product Led Growth (PLG)?

One of the reasons to adopt Product Led Growth is driven by the market — nearly 75% of B2B buyers say they'd prefer to buy online instead of through a salesperson. This means that product experiences have become an essential part of the buying process.

But importantly, it has great benefits for any company adopting PLG, especially the early-stage startups who are yet to mark their presence in the market. The benefits include:

It's an opportunity to taste the real market from day 1
You can run agile growth experiments and learn much faster than traditional sales
Significantly lower cost of acquiring customers (CAC)

What Would It Take for Product Leaders to Succeed in 2021?

2021-05-08T00:00:00Z

Product management is a highly collaborative role, requiring coordination with many teams and business functions — sales & marketing, customer service, market research, user research, tech-engineers, partners, external stakeholders, and so on. With the pandemic hitting in 2020, this role is forced to be performed from home/remotely and poses a unique challenge for product leaders to move things forward efficiently.

To get a view of product leadership in 2021, I recently had the honor of speaking with four great leaders in the product management community. I learned that each has their own perspective, but there are some common themes in what thought leaders in this domain are thinking.

Starting with a high-level view of what it takes to be a product leader, Tarun Upaday, serial entrepreneur and investor, laid out the five skills that a leader needs to succeed — providing a deep insight into how to overcome the challenges of being a product leader.