Read more

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by: LogRocket

This is the AI analytics, logs, and session replay tool you need. I ran a head-to-head eval against PostHog to test their AI, and published my results here.

Check it out

Today’s episode

There are hundreds of guides on writing PRDs with Claude. Dozens on running user interviews. Almost nothing on how a VP of product actually uses it in-depth.

Matt Wensing is the VP of Product and Design at Customer.io. They crossed $100M ARR, just shipped an AI agent, and are one of the fastest growing companies in B2B SaaS right now. I asked him to show me his actual documents, his actual Slack threads, and the exact sessions where Claude helped him produce leadership grade output.

What he showed me changed how I think about AI for leaders. Claude has the instincts of a brilliant new hire, it wants to deliver before it fully understands what you need, and at the VP level that gap shows up fast.

Matt has spent months figuring out how to manage it, and in this episode he shows you everything. You’re not going to find another video in the world with real VP of product examples from their real work.

Apple Podcast

Spotify

• To get access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, Relay.app, Magic Patterns, Speechify, Bolt.new and Mobbin - become an annual subscriber ($150), and grab Aakash’s bundle.

• To get access to my AI PM customizations - PM OS, Job Search OS, and Prompt Library - become a founding subscriber ($250).

Newsletter Deep Dive

Thank you for having me in your inbox. Here is how a VP of product at a $100M ARR company actually uses Claude:

1. How a VP of Product Actually Works With Claude

   • Why Claude produces slop, and why executives catch it instantly

   • How to build leadership grade presentations with Claude

   • Using Claude as a thinking partner vs. output machine

2. A VP of Product’s AI stack

Subscribe now

Before we get to the longer article, here’s the most important takeaway in an infographic.

Share

Now into the deep dive…

1. How a VP of Product Actually Works With Claude

Why Claude produces slop, and why executives catch it instantly

Matt has a rule he shares with every new hire at Customer.io:

Junior employees, however talented, will race to the finish line before they have enough context to do the job well. They hear the first instruction, want to impress, and just go.

They skip the clarifying questions. They come back with something that looks complete but misses the point entirely, and now you have to tear it down and start over.

Claude does the exact same thing.

Give it a goal and it will sprint. It will generate a low grade Word doc. It will use jargon mid session and put it straight into the executive document. It will suggest the next step before you have finished thinking through the current one, nudging you toward a deliverable you are not ready for yet.

Matt calls this “the slop problem.” And it gets worse the higher up you go, because the audience reading your output gets sharper.

Executives are the best slop filters in the room

Senior leaders spend their careers reading documents that try to persuade them. They have a filter that kicks in within the first paragraph. They are not looking for polish. They are looking for evidence that the person who wrote this actually understands the multi dimensional nature of the problem.

A one shot alignment deck fails that test every time. Years of organizational history and unspoken context get compressed into a clean seven slide narrative. Matt calls this the “flat projection problem.” You present a shadow of the problem to people who have been staring at the real thing for months. They filter it out, and depending on where you sit in the hierarchy, that looks like polite nodding or your work simply getting ignored.

The fix is a different way of working with Claude entirely.

Instead of giving it the full problem upfront, you feed it context in layers, one piece at a time, making it earn the right to generate the final output. You kill the eager suggestions the moment they show up. You stay in control of the pace.

Matt puts it simply - a 200 iteration session with a great deliverable at the end is worth far more than saying yes to the first draft.

The document you produce is less polished but higher in insight density. When an executive reads something that matches the complexity they have been living with, they do not filter it out. They lean in.

How to build leadership grade presentations with Claude

In the episode, Matt shared an interesting story, he woke up at 5am with a company all hands due at 11. His week had been fully booked, the way every leadership week is (you know this better).

He started with - Six hours, a blank slide deck, and Claude.

By 11am, he had a polished Q2 roadmap presentation in front of 400 employees.

Here is exactly how he built it.

Step 1: Take inventory before you touch Claude

The single biggest mistake leaders make is jumping straight into building. Matt’s first move was not opening Claude. It was taking stock of what raw material he already had.

In this case he had two things. A Zoom recording of the engineering team’s demo day, and a strategy doc outlining Customer.io‘s three investment themes for the year. Neither was shaped correctly for the audience he needed to reach. The demo day was engineering talking to engineering. The strategy doc was internal direction, not a story for 400 people across sales, marketing, and engineering.

Raw ingredients first. Always.

Step 2: Pivot, don’t write

Once Matt had his ingredients, he did something specific. He did not ask Claude to write slides. He asked it to reorganize the demo day Zoom transcript around the three themes from the strategy doc.

Think of it as matrix multiplication. You have content shaped one way. You have a framework shaped another way. You ask Claude to pivot the first into the shape of the second. The output is not a finished product. It is strategically shaped raw material you can actually work with.

Step 3: Using Claude as Script Writer

Matt is a believer in show don’t tell. So he built the slides before he wrote a single word of the talk track.

Once the slides were done, he took screenshots of each finished slide and fed them back into the same Claude session. Then he asked Claude to write the talk track using all the context it had already ingested, the Zoom transcript, the strategy doc, the slides themselves, with one specific instruction. Do not just repeat what is on the slide. Use everything you know to say something more interesting than what is already there.

The result was a talk track that added depth instead of narrating the obvious.

Using Claude as a thinking partner vs. output machine

Matt does a lot of his Claude sessions by voice, on walks. You will see why this detail matters in a moment.

He was trying to build a pricing philosophy document for his CEO. The kind of document that shapes how an entire company thinks about value and growth for the next two years.

He did not tell Claude any of that upfront.

Start in the abstract, reveal the domain last

If he had opened with “help me build a pricing philosophy for Customer.io,” Claude would have pattern matched against every pricing philosophy document in its training data and produced something that looks like all of them. Generic tiers. Value metrics. A document that could have been written for any SaaS company.

So Matt tricked it.

He opened with a biology metaphor. An ecosystem. A two by two grid. Things enter from one corner, move through it, sometimes grow, sometimes stall, sometimes leave. He asked Claude to think about the different paths something could take through this system.

If you can see, he talked in completely abstract terms, never mentioning customers or pricing.

Claude had no idea where he was going. And that was exactly the point.

Here's the exact prompt he tried, transcribed straight from voice mode, stumbles and all:

Layer complexity in slowly

Matt did not dump everything into the session at once. He started with the simplest version of the framework, four boxes, basic rules of movement between them. Once Claude understood that, he added one layer of complexity. Then another and another.

He compares over prompting to a bad game night host. The person who explains every rule and every exception before anyone has touched a card. Nobody understands the goal. Nobody knows how to win.

Feed Claude the core rules first. Let it stabilize on those. Then add the exceptions.

Reveal the domain only when the model is clean

It was not until deep into the session, many iterations in, that Matt finally told Claude what the exercise was actually for. A pricing philosophy document for his CEO.

You have spent all that time building a clean mental model in the abstract. The moment you reveal the domain, you can apply that model as a stress test. Does it generate things that match reality? Does the framework hold up when pointed at actual customers? If yes, you have something worth presenting to a CEO.

2. Customer.io’s full weekly AI stack

Most of what you have read so far is about Claude desktop. Long sessions. Iterative context loading. Abstract frameworks that get applied to real problems. That is the deep work layer of Matt’s stack.

But there is a whole other layer running underneath it, every day, without Matt having to think about it.

The analysis bot

His team built an internal Slack bot with access to Snowflake. Matt had 2,000 customer records he needed to analyze for a report going to other executives. Instead of waiting for a data pull or writing SQL himself, he talked to the bot in natural language. Asked questions. Got answers. Followed up. Went deeper.

Two things he is careful about here. One, he has a data team that can jump in when the bot produces something that does not look right. Two, he never takes a non-deterministic answer at face value for something going into an executive report.

The Slack scanner

Customer.io has over 400 employees spread across dozens of Slack channels. There is no version of Matt’s job where he can read every thread that might need a product perspective.

So one of his teammates built a scanner. It runs across several dozen channels continuously, looking for conversations where a product person should probably be involved but is not. It surfaces those threads to Matt at set times during the day, without overwhelming him.

Matt is clear about what this tool is and is not. It keeps him close to the ground while he is deep in a Claude session or running back to back executive meetings. He can see a support conversation with a specific customer that needs product input, flag it, tag the right person, and turn it into a process improvement opportunity all in the same thread.

This is the thing most leaders lose as they get more senior. Proximity to the real problems. The scanner gives it back without adding hours to the day.

Chiefys

The third tool is the most strategic one. Chiefys is a bot that Customer.io‘s CEO Colin built. It lives in Slack and has one job. It holds the corpus of Customer.io‘s official company documents, the operating model, the strategy docs, the things the company actually runs on, and it checks new work against all of them.

When Matt produces something new, like a pricing philosophy, he can run it through Chiefys. It will tell him whether what he just wrote contradicts anything already established across the company’s core documents.

It works in both directions. New document contradicts an old one, Chiefys flags it. Old documents go stale because the company shipped something new, Chiefys flags those too. Every leader has experienced the pain of getting alignment on something in January and watching that document become invisible by April because three other things changed around it. Chiefys is the accountability check that nobody has time to do manually.

Get Transcript

Where to find Matthew Wensing

• 1:1 Video Consultation

• LinkedIn

• X

• Customer.io

Related content

Podcasts

1. PM’s Guide to Claude - YouTube | Spotify | Apple

2. How to Become a Builder PM - YouTube | Spotify | Apple

3. We Built an AI Product Manager in 58 mins - YouTube | Spotify | Apple

Newsletters

1. How to Build Product Strategy with Claude Code

2. My Claude Code PM OS

3. Team OS

PS. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

Refer a friend

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by:

1. Bolt.new - Ship AI-powered products 10x faster

2. Product Faculty - Get $550 off their #1 AI PM Certification with code AAKASH550C7

3. Customer.io - Send smarter messages using your product data

4. Ariso - Ship AI agents and features faster, with fewer regressions

5. Jira Product Discovery - Plan with purpose, ship with confidence

Today’s episode

Six months ago, I showed you Codex is the best way to use ChatGPT for PM work.

Those who tried it have had great reviews:

But most of the content out there for PMs is all about Claude Code (myself included). So I wanted to get you the advanced setup for Codex, that’s up to date as of June 2026.

That’s what today’s episode is - an inside look at expert usage of Codex, from an OpenAI PM himself.

Abhi Muchhal is an International Growth PM at OpenAI and before that was at Meta and Nubank. He opened his actual setup on camera: the harness… everything. Then he covered how to crack a role like OpenAI yourself.

Apple Podcast

Spotify

• To get access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, Relay.app, Magic Patterns, Speechify, Bolt.new and Mobbin - become an annual subscriber ($150), and grab Aakash’s bundle.

• To get access to my AI PM customizations - PM OS, Job Search OS, and Prompt Library - become a founding subscriber ($250).

Newsletter Deep Dive

Thank you for having me in your inbox. Here is the complete guide to using Codex like a senior PM:

1. The PM’s Ultimate Guide to Codex

   • The Codex harness setup

   • Automations that run while you sleep

   • Prototyping without a designer or engineer

2. How ChatGPT has Grown to 1B monthly active users

3. [BONUS] How to break into AI PM at a company like OpenAI

Subscribe now

1. The PM’s Ultimate Guide to Codex

In this section, we cover:

• How to setup Codex or your agent’s harness

• The 3 automations Abhi swears by

• How to build prototypes in Codex

The Codex harness setup

As I wrote in my Ultimate Guide to ChatGPT Codex, the harness is what separates a one off interaction from a persistent system. It is the connectors, the folder structure, the permissions model. Without it, you are just using a very expensive autocomplete.

Data connectors

The first thing to set up is every data source Codex needs to know about.

At OpenAI, the international growth team was pulling from seven or eight sources. Tableau dashboards. Databricks dashboards. Different tools, cadences, and formats.

Connect all of them.

The permissions model

Give Codex three levels of permission:

1. Reading tasks get full autonomy.

2. Synthesis and writing drafts get full autonomy

3. Anything going to another human needs your approval.

Skills, skills, skills

One growth engineering team at OpenAI got tired of running experiment reviews by hand. So they built a skill. Point it at a StatSig experiment, and it writes the hypothesis, monitors the experiment, and generates a postmortem and recommendation automatically.

That is what skills are. Reusable workflows, written once, triggered by name. PMs skip this layer entirely because building a skill feels like an engineering task. It is not.

When asked who builds these skills, Abhi said:

“The beautiful thing about Codex is that the person who cares the most is the one who makes the skill. It doesn’t matter if it’s an engineer, an analyst, or even a PM. I’ve made some skills as well.”

I’ve been hammering this home for months. Good skills are everything!

Abhi’s Top 3 Automations

Abhi swears by three automations:

Automation 1 - Daily Slack triage

Abhi works across time zones. By the time he wakes up, his Slack has 200 unread messages across a dozen channels. He was missing important things because there’s no priority filter for him.

So he built a Slack inbox triage that runs every day at a fixed time. It knows which channels matter, which senders are priority, and what kinds of messages need a response. It delivers detailed outline, things you have not read that you should, and things you have not replied to that are waiting.

The key prompt structure:

Automation 2 - A dashboard that updates itself

Abhi’s team was pulling from seven or eight different sources to understand how ChatGPT was growing across priority markets.

So he built a web app that pulls from all of them, refreshes every morning at 9:30 AM, and gives you the combined view plus the key takeaway. Country tabs. Top line metrics. Codex generated strengths and risks for each market relative to peer countries.

Let’s take a moment here and ask yourself - what are the sources you check manually every week, and what would it look like if they were in one place with a machine generated TLDR waiting for you?

Automation 3 - A weekly update

The weekly stakeholder update is the most time consuming, least value added task on most PM calendars. It pulls from Slack, Google Drive, Notion, and the same dashboards powering the growth view.

So he automated the synthesis. Codex pulls from every source, writes the first draft, and posts it to a channel he owns. He reviews it, edits the things that need his judgment, and sends it to his stakeholder group.

Prototyping without a designer or engineer

Before AI, getting a prototype in front of engineers meant writing a PRD, convincing a designer to prioritize your request, doing two or three rounds of mocks, and then finally handing something over. That whole loop could take three weeks for a simple feature. OpenAI cuts the loop, as Abhi described it:

Step 1 - Replace the PRD with a prototype plus companion doc

A prototype with a companion doc that addresses the obvious questions gets to the same place faster and creates a better conversation.

The companion doc answers ten questions. Why are we doing this. What must work for V1. What are the edge cases. What does success look like. It’s more like an FAQ that lives beside the prototype.

Showing a working prototype changes the quality of the conversation. Engineers stop asking what you want and start asking how to make it better. That shift leads to a huge leap in productivity.

Step 2 - Spec the output before you prompt

Vague prompts return vague prototypes. Before you send a single message, write down three things:

Paste that as your first message. Everything Codex builds follows from that. The more specific the spec, the less time you spend in correction loops.

Step 3 - Preview in app before handing off

Codex can now spin up a local preview inside the interface. You do not need to open a browser. You do not need to configure localhost.

Run the preview. Check the layout. Ask Codex to match a specific brand aesthetic if needed. Use Playwright to verify the fix. Then hand it to engineering team.

The biggest failure mode at this stage is showing an engineer a prototype that crashes in the first click. Test it before you show it. Codex will catch most of the surface level issues itself.

Getting to 80% without engineering time is non negotiable.

2. How ChatGPT has Grown to 1B monthly active users

There is an assumption baked into every AI PM playbook written in the last two years. The user has a desk. The user reads English. The user has a knowledge worker job that involves staring at a screen.

Abhi’s job is to break that assumption.

As International Growth PM at OpenAI, he is responsible for markets where knowledge workers are a single-digit percentage of the working population. India is under 10%. Brazil is 10-20%. These are OpenAI’s fastest-growing markets.

He emphasized three strategies the team implemented that I want you to notice:

Building for language diversity

The people in Bangalore opening a bookstore are not thinking in English. They want a website in Kannada. They want invoice templates in Hindi. They want a YT shorts caption that lands for an audience in Tamil Nadu.

Codex can generate, translate, and format across languages at a level that was not possible 18 months ago. Character rendering in Indian scripts, Japanese manga-style layouts, multilingual infographics.

Synthesizing information that lives on WhatsApp

In markets like India and Brazil, business happens on WhatsApp.

With checking everything manually you can now point Codex at your WhatsApp desktop app, ask it to summarize what you missed, identify action items, and draft a reply based on your calendar availability. In the episode, this entire flow took just over a minute. The reply appeared in the WhatsApp composer, pre-typed, waiting for you to hit send.

This is a workflow every PM building for international markets should understand.

Validating decisions in markets you are not in

The hardest part of international growth PM work is not building the product. It is understanding whether a feature that works in the US will land in Southeast Asia or West Africa.

Codex cannot replace user research. But it can synthesize the data you already have and surface the gaps faster. In growth work, the teams running the fastest are not collecting more data. They are synthesizing what they have with more precision.

For regulated markets or markets where your data pipeline is limited, the synthesis layer matters even more. If your Databricks dashboards are behind a compliance firewall, a Codex skill that only reads from approved exports still beats manual review by hours.

The PM who understands where their product actually lives in the world is harder to replace than the PM who only knows where it is built.

3. How to break into AI PM at a company like OpenAI

The question I get most from PMs reading this newsletter is some version of - how do I get from where I am to OpenAI, Anthropic, or a frontier lab?

I wrote a complete guide on breaking into OpenAI here. Since then, I have talked to four OpenAI PMs on this podcast.

Three key ingredients come through from the 4:

Key Ingredient 1 - Deep PM fundamentals, not just AI familiarity

Every frontier lab PM I have talked to had a serious pre AI career. Not just a familiarity with the tools. Deep PM fundamentals. Structured thinking. Analytical decision making. Communication under ambiguity.

This should be reassuring. The PM skills you have built are not obsolete. They are the foundation. The AI fluency is what you build on top.

What I covered in my AI PM job search guide still holds. The comp at frontier labs is real, but the evaluation criteria are not that different from a strong senior PM role anywhere. You need to show you can own a problem end to end.

Key Ingredient 2 - You have to build something

Every OpenAI PM I have spoken to built something with the APIs before they were hired.

Not a side project that exists as a GitHub repo nobody has seen. Something that actually ran. Something you had to debug. Something where you discovered what Codex or GPT could not do and had to work around it.

The builder credential matters because it is the only way to know what the model actually fails at. You cannot interview your way into that knowledge. In Abhi’s case he built a Chrome extension for real time language translation, deployed it on the OpenAI API, and was demoing it at the time of their application.

One honest caveat here. This path is more accessible to PMs who have slack time to build and who can access paid API credits. If you are in a market where that is not trivially affordable, start smaller. A Codex CLI project on your own machine costs almost nothing to run. The goal is to understand failure modes, not to ship a production app.

Key Ingredient 3 - Speak the language of evals

This is the one that surprises most PMs.

Evals are how frontier labs measure progress. A rubric that defines what good looks like for a specific capability, a baseline measurement, and a goal to beat.

You do not need to have run 50 evals to talk about this fluently. You need to understand why they exist, what they replace, and what a good eval measures versus a bad one. I covered this in depth in my LLM Judge guide and in the Ankur Goyal episode where we built one live on camera.

The PMs who get the farthest in frontier lab interviews are the ones who can say: here is a capability I care about, here is how I would measure it, here is how I would know if the model improved.

Every PM who can think in evals is already speaking the language of the companies building the future. That’s it for today, try to reread and understand the full workflow. See you in the next episode.

Get Transcript

Bonus. How to Get the Most Out of Codex:

Share

Where to find Abhi Muchhal

• LinkedIn

• X

Related content

Podcasts:

1. The Ultimate Guide to ChatGPT Codex

2. How PMs Ship 100K Lines of Code at OpenAI

3. Evals are the new PRD

Newsletters:

1. My PM OS

2. AI Agents Guide for PMs

3. How to Land a $300K+ AI PM Job

PS. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

Share

It feels like it has amnesia.

The session that wrote you a great PRD yesterday remembers none of it today. The pricing test that you ran last quarter is long forgotten.

Today’s models have real intelligence. But the memory is a sieve.

Plenty of people have noticed. A few have shipped solutions. The two loudest are Garry Tan’s GBrain and Andrej Karpathy’s Second Brain, both of which I’ve covered for you.

Over the past month, I put both Gbrain and Second Brain to the test on my PM OS and Job Search OS. What I learned is: neither is truly the right fit.

So I built it for you.

Not only that - I decided to build you memory for whatever harness you use. So, that’s what you’re getting today: three files to give your agent memory, covering any source:

1. If you run Hermes or OpenClaw → Memory that models GBrain’s ambient approach

2. If you do intentional research sessions → Memory that models Karpathy’s brain

3. If you run Claude Code → Memory that takes the best of both

Today’s Post

This isn’t your typical newsletter post. It’s a highly tested product drop + research writeup:

1. Why I needed to build these

2. My memory layer for Hermes + Open Claw

3. My Karpathy second brain memory layer setup

4. 🔒 The memory layer I use for Claude Code operating systems

5. 🔒 What I learned building these, how to do it yourself, and where I land

Subscribe now

1. Why I needed to build these

I live in my PM-OS and Job Search OS in Claude Code. Neither fits perfectly with GBrain or Second Brain.

Start with GBrain.

First, it wants Telegram, but I live in my OS-es, in Claude Code at my desk. Routing every message to a different chat app just doesn’t make sense. Second, the setup doesn’t fit well on top of Claude Code. I tried for days. First, the install failed in a bunch of ways, so I needed to do workarounds. Then, it didn’t play well with my context library. When I finally worked that out, it cited invented numbers as if they were true.

Now let’s talk Karpathy’s second brain.

It needs you to stop and curate, so as live operating memory it goes stale fast. It doesn’t scale either: the single-index approach starts straining around a hundred sources. And there’s no lifecycle, so bets and commitments blur, with nothing marking “this is a hypothesis, that’s a decision.”

Both tools are great at what they were built for, but neither fits a typical PM setup.

2. My memory layer for Hermes + Open Claw

I’ve written about Hermes and OpenClaw. Both are really cool harnesses for PMs.

Garry Tan, CEO of Y Combinator, built GBrain on top of either. It captures what you say to an always-on phone agent and consolidates it overnight. It shines on:

• Screenshots and on-the-go capture. You see a competitor’s pricing page in the wild, screenshot it, send it to the bot. By morning it’s a page in your brain, cross-referenced. No tool that lives on your laptop catches that moment, because you weren’t at your laptop.

• Conversational dumps between meetings. The 90 seconds of “here’s what just happened with Acme” that you’d never sit down and type.

GBrain’s best idea is the ambient capture. If you want to steal that idea without the whole Gbrain setup, I took that and packaged it into a recipe you can run on the OS you already have:

Here’s me doing it in Telegram with Hermes:

Here’s what you get: an append-only capture inbox, dumps filed automatically as you talk, and a consolidation pass that routes each one into your real knowledge files with a source on every claim and a CONFLICT: marker instead of a silent overwrite. Plain markdown, no phone, no database.

3. My Karpathy second brain memory layer setup

Karpathy’s LLM Wiki pattern is the opposite philosophy of GBrain, and it’s excellent at what it does. You curate sources into a folder, the model compiles them into an interlinked wiki, and you query against compiled knowledge instead of re-deriving from raw docs every time.

It shines for deliberate, bounded work.

The clearest example is next-quarter planning, built from a selected set of inputs. Five competitor teardowns, last quarter’s interviews, the strategy doc. Deliberate inputs, deep synthesis, a wiki you’ll read like a document. The curation is the value.

The trade is you feed it by hand. It doesn’t capture as you work, and it isn’t trying to.

I packaged this one too.

Here’s me doing it in Claude Code:

It scaffolds and builds the whole wiki pretty fast:

As a result, here’s what you get:

You drop dated sources into raw/, and it compiles interlinked wiki pages with a citation on every claim, a fully regenerated index, [!CONFLICT] markers when sources disagree, and a lint pass that catches dead links and orphans. The compile is idempotent, so re-running it is safe.

4. Combining Both for Claude Code → My Ideal Memory Setup

I wanted to build a system that:

1. Took the ambient concept of Gbrain and the intentional concept of Karpathy

2. Worked well with Claude Code OS’s

I went looking around and didn’t find anything, so I built it myself last week, and have spent the intervening 5 days testing and improving it.

🔒 The rest of this post is for paid subscribers.

Below the line: the full Claude Code Memory System product.

It has one-command install, ambient capture that needs no command, two hooks that make it enforce itself, and the worked example of an input compounding into the right place.

It’s a downloadable layer that drops onto PM OS, Job Search OS, or any Claude Code project.

Plus: my thoughts on building these memory systems and what’s next.

Read more

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by:

1. Product Faculty - Get $550 off their AI PM Cerficiate with code AAKASH550C7

2. Bolt - Ship AI-powered products 10x faster

3. Customer.io - Send smarter messages using your product data

4. Ariso - Ship AI agents and features faster, with fewer regressions

5. Pendo - The #1 software experience management platform

Today’s episode

Most companies are still debating whether PMs should ship code. OpenAI is debating the best ways for PMs to ship code. They’re living in the future.

The builder behind a lot of that harness engineering is Ryan Lopopolo. He wrote the OpenAI post on harness engineering and runs a frontier team where PMs, designers, and engineers all ship using the same system.

The wild part for me? His PMs shipped around 100K lines of production code.

Did they open the IDE? Hell no! Their coding happened through PRDs, tests, docs, and harness rules. The model did the typing.

As someone who spent a decade in PM growth roles, I’ve seen how long it takes to move a feature from PRD in a doc to code in prod. For most companies, that latency is weeks, months, or quarters.

In Ryan’s world, it can be days, hours, even minutes. And the PM is inside the loop - not watching from Jira. So I had to understand how that works - and that’s today’s episode:

Apple Podcast

Spotify

• If you want access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, Relay.app, Magic Patterns, Speechify, Bolt.new and Mobbin - become an annual subscriber ($150), and grab Aakash’s bundle.

• If you want access to my AI PM customizations - PM OS, Job Search OS, and Prompt Library - become a founding subscriber ($250).

Today’s post

Here’s the guide to shipping code like PMs at OpenAI:

1. How the harness works

2. Ryan’s Frontier team case study

3. The new job for PMs, designers, and engineers

Subscribe now

1. How the harness works

You don’t need to copy every detail of OpenAI’s setup.

You do need the big pieces, because that’s the system you’ll be dropped into as an AI PM. Ryan thinks of the harness as the environment inside the repo that teaches the agent how your team builds software.

agents.md and the docs tree

Every repo has an agents.md file at the root. When they run Codex on that repo, this file is always in the model’s context. agents.md does two things. It explains the operating loop like read docs, plan, implement, run tests, and ask for review. Then it points the agent at the docs tree like markdown files with performance patterns, networking practices, user journeys, design guidelines, and past decisions.

Each run’s execution plan gets written back as implementation history. Design docs move out of slides and Slack into the repo. And tests fail if docs fall out of sync, which forces the agent to update them while editing code. The model needs a repo that it can search to show how your team works. As a PM, that’s where your decisions belong.

Tests and lints that enlist taste

Ryan’s team encodes taste and non‑functional requirements directly into tests and lints. No please remember I beg of you paragraphs. A few examples:

1. The build fails if any user‑facing markdown or HTML string uses straight quotes instead of curly quotes, because their design team is finicky about typography.

2. Business logic has to belong in the right modules. Tests enforce boundaries so a ball of mud doesn’t form.

3. When docs need to move together, tests enforce that they stay in sync.

Because the model is trained to make tests pass, each failure message is an instruction. You’re not arguing taste in Slack. The suite is the style guide. In growth roles, I learned the hard way that if something matters, you have to measure it and enforce it. Their approach is the same idea, just pointed at code and docs instead of funnels.

Review agents as virtual staff engineers

On the review side, they run a matrixed CI job that spins up specialized review agents, each with a persona doc:

1. frontendarchitect.md

2. reliabilityengineer.md

3. appsecengineer.md

That feedback goes back into the loop. The implementation agent uses it to fix the current change. The team updates the docs or tests so the same class of mistake doesn’t come back.

Observability and UI control

Finally, the harness gives the model eyes on the product. The agent can spin up a local observability stack (metrics, logs) and use it to debug like a human. With GPT‑5.5’s computer use, it can click through the app, inspect elements, and verify flows end‑to‑end.

The rule is simple; the agent has to prove the feature works through the same paths your users take. As a PM, that’s where your acceptance criteria also need to land.

2. Ryan’s Frontier Team Case Study

In mid‑2025, his team ran an experiment. Could Codex do the entire software engineering job for a new internal agent product?

The constraints?

1. Start from an empty repository.

2. Build an app that supports non‑engineering knowledge work inside OpenAI.

3. Let the agent handle on‑call triage, internal tools, and text‑heavy workflows.

4. No human is allowed to type production code. Engineers can only touch the harness.

By the end, the app had around 1M lines of code. It also had roughly 250K lines of markdown prompts inside the repo. And it ran as an Electron app with multiple agents coordinating summarization, repo gardening, skills distillation, and execution.

Any time the agent failed, the team asked what was missing in the harness that led to this failure. The codebase improved because humans improved the environment. Nobody jumped in and rewrote everything.

3. The new job for PMs, designers, and engineers

For most of my 10+ years in product, PMs were kept away from the repo. You were the human API between customers and engineering. You wrote PRDs, argued in sprint planning, and waited. The typing was someone else’s job.

Ryan describes a different world.

In his team, code is no longer the scarce resource. With GPT‑5, the model can generate code at scale. The difficult part is validating it, safely deploying it, and making sure it solves the right user problem. That means the harness (the environment of docs, tests, lints, review rules, and observability) is where work gets done.

Once the harness is strong, engineers aren’t the only ones who can write code. PMs and designers easily plug into the same system.

And literally everyone gets a new job description.

The new role for PMs

In late 2025, Ryan’s team wanted to explore a ‘skills system‘ so the agent could learn and reuse user preferences for data analysis. In most companies, this would kick off a chain of product reviews and engineering estimates. Here is what they did instead:

1. The PM wrote a markdown PRD that defined the skills library

   • How the agent should interview users about the metrics

   • How should it store and reuse that knowledge

   • How this should appear in the product surface

2. The team reviewed the PRD once in their weekly meeting.

3. By the end of the week, the feature existed in the app. The tests the PM had vibed into existence were passing.

The PM and engineers did not need a week of back‑and‑forth. The harness carried the intent into code. This worked because business logic was embedded in modules with high‑fidelity fakes. Also, the tests from the product side exercised the behavior.

The important bit: the PM’s leverage came from writing artifacts that the harness understands. If you’re a PM reading this, imagine your next feature:

1. Could you express it as PRD + tests + evals the agent can run on its own?

2. If you couldn’t touch the IDE at all, what would you have to write differently?

That’s the muscle you need to build.

Designers generate painted doors with

Early on, if a designer tried to ship a feature, they had to schedule agent runs inside their internal app. Then, to demo it quickly, they had to push a backend‑style cron system into the front of the stack. Usually, the scheduler logic ended up tangled inside frontend JavaScript.

Ryan looked at it and knew they’d regret it later. So decided to revert the change. Their team came out of that with a simple norm:

1. Designers own full painted‑door flows at the front of the app: the UI, the interaction pattern, and how scheduling is exposed.

2. Behind the door, the backend can be a no‑op plus instrumentation. They measure clicks, intent, and drop‑off before committing engineering time.

The harness then decides, based on data, which doors deserve a backend. So the JD for designers is to build high‑taste, high‑signal surfaces that the harness sees as experiments. A designer now must give the agent and engineers the best possible signal about what’s worth building.

Coding engineers became harness engineers

Ryan’s definition of the modern engineering job is very close to how I think about great growth engineers. Your value is the leverage you create for everyone else.

In his team, the primary output is leverage. Every engineer is responsible for adding tests, docs, CI rules, and observability that let many concurrent agents work. Internally, they use a simple mental model. Think of it as you just hired a cluster of interns named Codex. Your job is to manage them.

Emotionally, that’s difficult. Many engineers (including Ryan) grew up measuring their contribution in commits and lines of code. Letting the model do the typing can feel like losing the craft. But he argues that the craft moved. The new skill now is who can build the harness that makes GPT‑5 a strong teammate for this particular product and company?

“Every engineer on the planet now has hundreds or thousands of concurrent hands on keyboards, modulo token budget.”

That’s the world your PM career is walking into. You’ll be working with engineers who measure themselves by the systems they build.

Why should YOU care? Does it matter?

Most teams use AI to speed up function‑level coding but keep the rest of their software development lifecycle unchanged. Ryan’s world is what it looks like when you redesign the system around agents that can do the full job. The differentiator is how much of your team’s judgment is embedded in your harness.

If you’re a founder or product leader, that’s what AI strategy now means. It’s how you design the engineering system your PMs and designers plug into, so they can ship.

If you’re a PM, this is the future job description. You’ll still need taste, discovery skills, and stakeholder management. You’ll also need to think like a harness engineer: what tests, docs, and rules would I write if the model were my team?

Get Transcript

[Bonus] Downloadable Takeaway

I turned Ryan’s six‑month harness plan into a one‑pager you can use as a checklist with your team.

Where to find Ryan Lapopolo

• X

• LinkedIn

• OpenAI

Related content

Podcasts:

1. How to Run Evals in Claude Code with Aparna Dhinakaran

2. How to Build a Full AI Dev Team in Claude Code with Gabor Mayer

3. This CPO Uses Claude Code to Run His Entire Work Life with Dave Killeen

Newsletters:

1. PM’s Guide to Claude with Pawel Huryn

2. How to Become a Builder PM with Mahesh Yadav

3. How to Build a Team OS in Claude Code with Hannah Stulberg

PS. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by:

1. Superhuman - The fastest email experience ever. Get 1-month free with my link

2. Land PM Job - My 12-week AI PM + Job Search Course

3. Vanta - Automate your compliance. Close deals faster

4. Product Faculty - Get $550 off their AI PM Certification, code AAKASH550C7

5. Bolt.new - Ship AI-powered products 10x faster

Today’s episode

If you’re building in Claude Code, you should learn how to build evals in… Claude Code.

There are two major evals platforms in the market today. We’ve already had the CEO and founder of one on, Ankur Goyal of Braintrust.

Today we return with the other major platform, Arize. And we have on the CPO and founder, Aparna Dhinakaran.

Many of the smartest AI teams are running their evals on Arize - Uber, Booking.com, Pepsi... I even offer Arize in my bundle. So now we bring you the guide to using it.

This episode builds upon the basics I taught with Hamel Husain, Shreya Shankar, and Ankit Shukla. It even includes a segment that, if a candidate did it in an interview, Aparna said she would hire them on the spot:

Apple Podcast

Spotify

• If you want access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, Relay.app, Magic Patterns, Speechify, Bolt.new and Mobbin - become an annual subscriber ($150), and grab Aakash’s bundle.

• If you want access to my AI PM customizations - PM OS, Job Search OS, and Prompt Library - become a founding subscriber ($250).

Newsletter Deep Dive

I’ve put together the complete guide for running evals in Claude Code.

1. Evals don’t have to take forever and be hard

2. Step-by-step, how to run Claude Code evals

3. How to build a self improving loop

4. The new PM operating system

Subscribe now

Save this. A 3-step playbook on how to run Claude Code evals with exact commands.

Share

1. Evals don’t have to take forever and be hard

In the past, I’ve taught you the ways of Hamel Husain and Shreya Shankar who said that you need to look at the traces yourself, categorize them yourself.

In practice, what this means is a lot of PMs skip evals because it takes too long.

That’s a mistake. You can actually use Claude Code to do all those steps.

Here is what changed.

The old assumption - Evals need human-led error analysis

The old model assumed you had to be the one reading every trace. You needed to understand what went wrong before you could write an eval that tests for it. That meant the eval quality was capped by how much time you had.

That assumption made sense when models were weaker. It does not hold the same way anymore.

The new reality - Claude can suggest your first eval

When I asked Aparna, she said:

“I think it’s okay to start with Claude suggesting what a good suggestion of an eval could be. These models have gotten so good. Having it go through and look at your answers and suggest, that probably is something you should flag and look at. I would trust it. I would trust it as a first pass.”

This is not about replacing rigorous eval work. Hamel and Shreya’s methods still produce the most calibrated evals over time. But you do not need to start there. Claude gives you a working v0 in minutes. That v0 gets you data. That data gets you something to actually improve.

Aparna demoed “vibe based evals” using Claude Code. Here’s how it works.

2. Step-by-step, how to run Claude Code evals

You have an agent running. It is producing output. You have no idea if that output is accurate or just confident looking.

Here is exactly how to change that in one session.

Step 1 - Install the Arize skills into Claude Code

Open Claude Code. Run one command:

Claude Code now has access to instrumentation, eval suggestion, and improvement skills, you do not need to write any eval code yourself. You just ask Claude Code in plain English what you want. It calls the right skill for the job automatically.

The instrumentation skill is the first one you need. It looks at your codebase, identifies every LLM call and tool call, and wires them to Arize for tracing.

Step 2 - Ask Claude to suggest an eval

Once you have traces, ask:

Claude looks across your traces and returns candidates. In Aparna’s live demo it surfaced three:

• Report groundedness. Do the issues cited in the final PM report actually exist in the source data?

• Priority alignment. Does the P0/P1 ranking in the report match the highest-scored issues?

• Report actionability. Is the output something a PM can act on the same day?

Good starting point. But these are output level evals. You want to go one layer deeper.

Step 3 - Get specific about what you actually care about

Ask something more targeted:

Claude runs this across your spans. In the demo it flagged four failure categories: bug priority scoring, feature request scoring, legacy scoring system conflicts, and low priority edge cases.

Now you have something real. Specific categories of failure, with specific spans attached. That is what you need to improve the agent systematically.

You cannot fix what you cannot name. The eval names it for you.

3. How to build a self improvement loop

Your eval is running. It is flagging failures. The natural next question is: now what?

Most PMs stop at the eval. They have the signal. They do not build the system that acts on it. That is the difference between a PM who runs evals and a PM who has a self-improving agent.

The loop - three moves, on a schedule

The loop is not complicated. It is three moves that run automatically on a cadence you set.

Move 1 - Fetch everything the eval flagged as wrong. Claude pulls every span from the last cycle where the priority accuracy eval fired.

Move 2 - Find the pattern. Claude groups those failures by category. Bugs being underweighted. Long feature requests getting inflated scores. Edge cases involving third party integrations always landing wrong. The categories tell you where the agent’s logic is broken.

Move 3 - Propose a fix. Claude suggests a specific prompt change or scoring adjustment that would address the most common failure category. A concrete edit you can review and approve.

To set this on a schedule, ask Claude:

Claude spins up the equivalent of a cron job. Every day, or every week, your choice, the loop runs. It fetches failures, groups them, proposes a fix, and waits for you.

The human stays in the middle, always

This is the part that gets skipped in the excitement of automation. The loop is an accelerator. It is not a replacement for your judgment.

Eval changes need your sign-off before they run. Agent changes need your sign-off before they ship. The loop proposes. You approve. That is the design.

Aparna put it cleanly:

“Get data in, get an eval set up, give it criticism and let it go run on a loop.”

The criticism is still yours. The speed is Claude’s.

What compounds and what does not

The teams that build this loop are getting smarter with every cycle. Each round of failures produces better calibrated evals. Better evals produce more accurate agents. More accurate agents produce fewer failures. The signal to noise ratio improves over time.

The teams that skip the loop keep starting from the same baseline every sprint.

4. The new PM operating system

Step back from the mechanics for a second.

What you just learned is not a new feature to add to your existing workflow. It is a different operating system for how you do the job.

What the old operating system looked like

Monday morning. Open Linear. Read 40 new issues. Mentally rank them. Write a summary for standup. Two hours gone before you have typed a single Slack message.

Thursday. Pull up Gong. Watch three customer calls. Try to find the pattern. Write a themes doc that gets skimmed in a meeting and never opened again.

That cycle has a ceiling. There are only so many issues you can read. Only so many calls you can watch. Only so many sprints in a quarter.

What the new operating system looks like

The new operating system runs differently. Your agent already ran overnight. It pulled the latest issues, scored them by severity, recency, and reaction count, and wrote the PM report. It is sitting in your repo when you open your laptop.

Your job is a five-minute scan. Do you agree with the priorities? When you disagree, that disagreement is your next eval.

As Aparna said:

“If you are doing things the same way you were doing them last year, you have not caught up yet.”

That’s it for today. If you have any doubts, Aparna demoed the full process in the episode. Run the simple commands shared above. Watch Claude Code vibe it.

See you in the next episode.

Get Transcript

Where to find Aparna Dhinakaran

• LinkedIn

• Arize

• X

Related content

Podcasts:

1. AI Evals with Hamel Husain and Shreya Shankar

2. Evals are the new PRD with Ankur Goyal

3. AI PM Crash Course with Aman Khan

Newsletters:

1. AI Evals for PMs: Everything You Need to Know to Get Started in 2026

2. Your Complete AI PM Course & Career Roadmaps

3. AI PM’s Guide to LLM Judges

PS. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

Share

Two things happened the same week. First, Farza, one of the cooler solo builders with taste, shipped Clicky: an AI that lives next to your cursor, sees your screen, hears your questions, and points at the answer. He built it in three weeks. Here’s the demo.

Then, Google DeepMind published the first major rethinking of the mouse cursor in 50 years, calling it Magic Pointer. Same idea as Farza! A 1280×800 PNG is ~200KB; on Claude's vision builder and the world’s best-resourced AI lab both ship the same idea in the same week, it’s worth paying attention.

Here’s the argument: the chatbox may have been a transitional interface, not the final one. It was the fastest abstraction to ship. It might not be the best one. And the evidence for what the right interface looks like is now sitting on my Mac menu bar.

This post starts with Clicky the product, then goes further. I’ll give you a design spec for building cursor-layer features into your own product, three prototypes you can run this week, and an audit toolkit to find where your product needs this thinking most.

Today’s Post

1. What Farza Built With the Cursor Layer

2. Why Google Shipping the Same Thing the Same Week Matters

3. The Cursor Layer Design Spec

4. Three Cursor-Layer Features You Can Prototype This Week

5. Score Your Product This Week

Subscribe now

Read more

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by:

• Customer.io: Send smarter messages using your product data

• Amplitude: The market-leader in product analytics

• Bolt: Ship AI-powered products 10x faster

• Ariso: Your AI chief of staff for meetings, follow-ups, and coaching

• Product Faculty: Get $550 off their #1 AI PM Certification with code AAKASH550C7

Today’s episode

If you haven’t coded before, you’re getting pinched on all sides. Builder PMs coming from technical backgrounds. Layoffs targeting the managerial class. It’s tough out there.

Today’s episode is the antidote. We show you a step-by-step process to graduate from tools like Lovable to multi-agent systems in Claude Code.

I’ve brought in Andre Albuquerque, who has worked with over 4,000+ students at Builders Camp, runs five business with Claude Code and … has never been a developer!

Live on the episode, he builds a fully functional product from scratch. And he describes things in the most easy-to-understand way.

If you have been putting off Claude Code because it feels too technical or intimidating to set up, this episode is for you.

Apple Podcast

Spotify

• If you want access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, Relay.app, Magic Patterns, Speechify, Bolt.new and Mobbin - become an annual subscriber ($150), and grab Aakash’s bundle.

• If you want access to my AI PM customizations - PM OS, Job Search OS, and Prompt Library - become a founding subscriber ($250).

Newsletter deep dive

Thank you for having me in your inbox. Here is the complete guide to Claude Code for non-technical PMs:

1. Why non-technical PMs are getting left behind

2. The four levels of building

3. What changes when you start building

Subscribe now

1. Why Non-technical PMs are Getting Left Behind

Andre identified three major blockers holding non-technical PMs back. None of them is your fault, but they are absolutely your problem to solve.

Blocker 1 - You are kept away from building

Thanks to corporate bureaucracy, non-technical PMs have essentially become the human API between customers and engineering. The job becomes more about translating requirements than anything to do with the actual product.

Andre has seen this from the inside across more than 4,000 product people in 30 countries. The pattern is the same everywhere: smart, capable PMs who have been systematically kept away from the one thing that would make them most valuable - building. In his words:

They’re bureaucrats. They’re stuck in JIRA, they’re stuck in Linear, they’re stuck in PowerPoints, they’re not actually building, they’re not pushing code, they’re not adding features, they’re dependent on their technical teams to do that.

Contrast that with AI-native organizations, where everyone builds. Even the CEO writes code. The Shopify CEO’s GitHub shows green every single week. LinkedIn literally scrapped its associate product manager program and replaced it with an associate product builder program.

One thing that is becoming increasingly clear is that companies expect you not just to “manage” things but ship real value. That is the gap you’re competing against, and the only way to survive this is to actively build.

Blocker 2 - The false ownership and Latency tax

When you label one person as the absolute “owner” of the product, you accidentally give everyone else a free pass to stop caring.

As Andre put it:

“You end up with squads that are completely disempowered. And it starts with the fact that there is a product owner rather than a team feeling like owners of the product.”

When you cannot build, you are forced to protect your territory using artificial authority, endless meetings, and rigid documentation. This protective behavior creates what I call the Latency Tax - the massive loss of time and context every time an idea gets passed down.

Think about how a standard feature gets built today.

A customer shares a painful problem → You write a PRD → Design turns it into wireframes → Engineering reviews it and estimates the story points. Finally, weeks later, it gets scheduled into a sprint.

By the time an engineer actually sits down to write the code, the original insight has passed through three departments over two to four weeks. That delay is your latency tax. When a PM builds the prototype themselves, that collapses to hours.

This is the same argument I made in my product strategy keynote. When a PM can build the functional prototype themselves, the Latency Tax drops to almost zero. That’s because the person who understands the user’s problem is the same person building the solution.

Your build will not be perfect, but it will be a tangible MVP focused on solving the user problem. Instead of handing down a static text mandate, you hand over something real that design and engineering can actually interact with and improve upon.

Blocker 3 - The Wrong Starting Point

This blocker is the most fixable - yet sadly, it’s the one that almost every online tutorial gets completely wrong.

“Open Claude Code and start prompting“ is a lame starting point, to be honest. Most tutorials assume you are buzzing with excitement and already know exactly what you want to create. But the basic reality is: as a non-technical PM, you were never taught how to build. Your entire career has been focused on scoping, strategy, and managing timelines.

Because of that, when you finally sit down to build, your brain automatically goes to a massive project like a marketplace or a SaaS platform. You think you need to clone a massive app just to practice. That feels way too complicated, completely useless for your actual day job, and impossible to finish - so you don’t even start.

Even if you do force yourself to try, you immediately freeze on step one. I know exactly how frightening a blank terminal screen is when you’ve never touched a command line.

The solution is a better entry point. Andre showed a specific four-level path that dramatically increases the odds you actually stick with this.

2. The Four Levels of Building

This is the exact four-level stack Andre uses to build your technical confidence without forcing you to learn how to code from scratch:

1. Level 1: Lovable only

2. Level 2: Lovable + Claude Code + GitHub

3. Level 3: Claude Code + Vercel + Cursor

4. Level 4: Multi-Agent Infrastructure Stack

One quick tip: do not try to jump straight to Level 4. Start with Level 1. It’s more fun that way.

Level 1 - Building with Lovable

Lovable is the right starting point for one reason: it is way less scary than Claude Code.

You open it up. You describe what you want to build in plain English, and boom - something appears on your screen. All of that without you writing a single line of code.

Andre’s first Lovable project was just a basic tool to manage his family’s vacation home availability. He highly recommends building a personal project first because it keeps things fun. Since there’s zero business risk, you can explore freely.

One underrated step at this level: ask Lovable to critique your own prompt before it builds. Ask it what you are missing. It will respond the way a good senior engineer would - listing your exact blind spots. That exercise will teach you faster than any product management course ever could.

The moment you feel comfortable on Lovable, you will naturally want more. You will want to build something more complex, more controlled, and that is exactly when you move to Level 2.

Level 2 - Lovable as QA Infrastructure

You are ready to tackle Claude Code, but vibe coding still feels scary. So what do you do?

Andre solved this beautifully by connecting Lovable and Claude Code through the same GitHub repository. You can push code with all the flexibility Claude Code offers, but you can still see the visual evolution of your product on Lovable.

Three things to know before you start:

First, Claude Code is not just a code editor. You can have a real conversation with it just like any other LLM.

I did a full Claude Code walkthrough with Carl Vellotti that takes you from zero to confident. If you’re starting fresh, start there.

Second, Branch and merge sound technical, but the concept is simple: A branch is a copy of your project. You build on the copy. When you are happy, you combine it back with the main version.

Third, Even after Claude Code saves the changes, you need to click Publish in Lovable to make the app live for real users. Before you publish, you have a private preview link. Share it with your team, test it on your phone. Make sure it looks right first.

Now, here’s the exact setup:

One critical rule: This sync only works in one direction. You must start on Lovable first. If you build a project in Claude Code first and push it to GitHub, you cannot port that code back down into Lovable. Start on Lovable, then extend it in Claude Code.

Level 3: Claude Code + Vercel + Cursor

Level 3 is when you start wanting speed.

The moment you start playing with Claude Code, you’ll see yourself very quickly wanting to build multiple features at the same time. That means working with multiple branches, and Lovable no longer fits the bill here.

The three tools at this level each do one job:

1- Claude Code: where you write and build 2- GitHub: where the code lives 3- Vercel: the bridge between your GitHub and your users

You may add Cursor for a visual layer. Andre actually runs Claude Code directly inside the Cursor terminal rather than using the standalone desktop app for two highly practical reasons:

First, Cursor has a great free plan. If Claude Code ever breaks or gives you a confusing technical error, you can simply paste that error into Cursor, and it will help you debug it.

Second, Cursor syncs with GitHub automatically once you log in -meaning all your projects link up without manual configuration.

The visual layout in Cursor also massively helps non-technical builders. You can see yellow branch lines sitting outside the main purple line. Yellow is where you are building. Purple is what users see. When you merge, they combine.

Also, I want to give you a heads up. When you first open Vercel, it will look complicated. Do not worry about most of it. Just find the preview link. Click it. See if the feature looks right. That is all you need to do.

If you want a step-by-step walkthrough of these exact stacks - Lovable, Claude Code, Cursor - I covered them from an experimentation angle in my Vibe Experimentation guide.

Level 4: The Machine That Builds The Machine

Level 4 is agents. Think of it like hiring a personal team, except your team is made of AI agents. Each agent has one specific job. They work together, and you act as the director, telling them what to create.

Andre calls it the Team Claude Config. It has three parts: a Claude.md, a set of agents, and a set of skills.

Grab Andre's Claude Config

CLAUDE.md - the culture

CLAUDE.md is simply a text file that loads every single time you start a Claude Code session. Think of it like a list of core rules your AI team reads every morning before starting work.

Andre calls it “the values of your Claude.” It holds your rules, constraints, and operating principles. The most important rule Andre puts in his file is this: “For every single task, call the PM agent first.”

As you build, Claude.md should constantly evolve. When you catch yourself repeating the same instruction - “always use product context,” “create .md files,” “ask a clarifying question before starting” - add it to Claude.md. The next session starts with that rule already in place.

I have iterated on my own CLAUDE.md over 100 times. If you want a battle-tested version of what Andre is describing, grab it here.

The PM agent

The PM agent never does the work. Its only job is to receive the task and decide which agents handle which parts. Andre’s instruction inside the pm.md file: “Never do the work yourself because there’s going to be some agent better than you.”

The agents Andre built mirror his actual team:

Researcher - user research, competitive analysis, market context Discovery - structured problem framing before any solution work begins Designer - UX best practices, design system knowledge, visual decisions Engineer - code quality, architecture review, prevents bad patterns from entering the codebase Implementer - the one who actually writes the code

I strongly discourage you from copying someone else’s setup. Build a setup that mirrors your own team. How do they work? What do they care about? Write that down and turn it into agents.

Gabor Meyer, a PM at Google, took this to another level and has 21 agents. I broke down his full setup here.

The 50/50 Rule

Here’s the number that surprised me most in this conversation: AI-native teams spend 50% of their time improving the infrastructure and only 50% shipping features.

50% infrastructure. 50% features. That’s the split.

The logic is simple: the better the infrastructure, the faster and cleaner the shipping becomes. If you ignore this split, you end up shipping slop.

Slop is what happens when you let the AI do all the thinking for you. So it gives you the output, which looks functional, the UI looks super cool, but it doesn’t actually solve anything for the end user.

When something ships badly, your first instinct is to fix that one thing. Change the button. Redo the layout. Ask Claude Code to try again. That is the wrong way.

The right way is to ask: why did this happen? What rule is missing from CLAUDE.md? Which agent made the wrong call? Fix that. Because the next time you’re going to have a feature, you don’t want that to happen again. You improve the machine so that in the future it becomes way easier to just focus on the problem, ask your team, ask your agents, and ship the feature better.

Three Skills that Block Slop

Slop enters your product at two points: when you define the work, and when the code gets written.

Andre runs three specific checks before building any new feature:

1- A Jobs to Be Done (JTBD) skill - what is the user actually trying to accomplish? Write it out clearly

2- An Opportunity Solution Tree (OST) skill - based on Teresa Torres’s framework - what problem are you solving? What are all the ways you could solve it? Pick one before you start.

I had Teresa Torres herself on the podcast to break down how OSTs work in the AI era. If you are going to use her framework as a skill, hear it from her first. She covers how AI can speed up discovery, but warns that AI summaries can miss 20-40% of important details if you pull humans out of the loop.

3- A MoSCoW skill - sort your requirements into must-have, should-have, could-have, and won’t-have. Be honest about the won’ts.

3. What changes when you start building

There is a kind of knowledge that only comes from building yourself. When you have built with Claude Code, watched it succeed, watched it fail, watched it produce slop, and watched it produce something genuinely useful, you develop what Andre calls builder’s gut.

This intuition is what creates Technical Empathy.

The most friction-heavy relationship in tech is between a non-technical PM and a Senior Engineer. This tension usually comes from the PM asking “How long will this take?” A question that reveals a total lack of technical empathy.

Andre told me about a feature he scoped before he started building. He estimated it would take his team a day. After he tried building a similar feature himself in Claude Code, he realized the “simple” request actually required restructuring how the database handled user sessions. What felt like a one-day ask was actually a three-day architectural change. He never would have known that without building it himself.

That experience repeats in small ways every week once you start building. You stop over-scoping AI features because you know where agents break. You write better specs because you understand what the agent is working against. You stop asking “can we add one more thing?” because you’ve felt the cost of scope creep in your own Claude Code sessions. You know what a branch conflict feels like. You know that “simple UI change” sometimes means rearchitecting three components.

Andre described the shift in how engineers respond to him now. Before he could build, standups felt adversarial. He’d push for timelines, they’d push back with technical objections he couldn’t evaluate. Now when an engineer says “that’s going to touch three services,” Andre knows what that means because he’s hit that wall himself. The conversation moves from negotiation to problem-solving.

“Imagine a reality where every single person in the product squad can do this for the actual backlog.”

That intuition sharpens every product decision you make. Engineers stop seeing you as an authority they have to answer to and start seeing you as a collaborator who actually understands the tradeoffs they’re navigating.

That is not a distant future. That is what these four levels lead to.

Get Transcript

Where to find Andre Albuquerque

• LinkedIn

• Builders Camp

• Andre’s Newsletter

• Andre’s GitHub

Related content

If you’re starting from zero, watch the Carl Vellotti walkthrough first. If you’re already in Claude Code and want to set up agents, the Gabor Meyer episode (21 agents) is your next step. If you want the team-level version of what Andre described, start with Hannah Stulberg’s episode on Team OS at DoorDash.

Podcasts:

• Claude Code and agents with Gabor Meyer

• n8n, Claude Code, and OpenClaw with Mahesh Yadav

• Claude Code with Hannah Stulberg

Newsletters:

• How to Ship Your First Pull Request as a PM

• I spent the last week building you a Team OS in Claude Code

• How to Build Product Strategy in the Age of AI: Step-by-Step with Claude Code

PS. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

Share

I’ve spent the last year inside this space. I interviewed the CEO of Bolt, the CPO of v0, the co-founder of Wix, the CEO of Magic Patterns, as well as Sachin Rekhi who teaches this at Reforge. I ran live bakeoffs on the podcast. I built my cohort business entirely on one of these tools.

This week, I wanted to assess the latest state of the market of these tools. So, I ran a real head-to-head bakeoff on two workflows: AI prototyping a product feature, and building a PM portfolio.

In today’s post, I’m going to share everything I’ve learned: a real head-to-head bakeoff with screenshots, the verified feature comparison, and the 5 workflows that make any tool work better.

But first, some news.

Bolt.new is Now in my Bundle 🎉

I just added Bolt.new to my bundle. We have 2,000 codes. Bolt will decide whether to add more based on performance. If you want one, claim it now.

I built landpmjob.com on Bolt. It runs the entire cohort business.

All the tools in my bundle retail for a total of $28,000+ combined. Annual subscribers get them all for $150/year. That’s less than $13/month for the newsletter plus every tool.

If you’re on a monthly plan, you’re paying $180/year for just the newsletter. Annual subscribers pay $150 and get every tool in the bundle: Arize, Reforge Build, Magic Patterns, Dovetail, Bolt, Mobbin, Descript, Relay.app, and Linear.

Founding members get three digital products on top: the PM OS, the Job Search OS, and the Prompt Library. Those retail for $147 combined. The founding upgrade is $100.

How to Get the Bundle

If you are not subscribed, you can head to the subscribe page and choose the annual plan:

Subscribe

If you are a monthly subscriber, you can head to the account page, then hit change:

Account Page

Annual and founding members get access to every tool in the bundle. Just go to bundle.aakashg.com to claim your codes:

Bundle Page

I want to add more tools! Reply to this email if you have a tool you think should be in the bundle.

Now, Today’s Deep Dive

The landscape has changed dramatically since I wrote my original AI prototyping guide with Colin Matthews in March of last year:

• Lovable 24x’d its ARR to $400M.

• Replit tripled its valuation to $9B.

• Vercel announced a $9.3B valuation itelf.

So I re-ran the comparison from scratch: Bolt.new vs Lovable vs Replit vs v0. Real bakeoff, real screenshots, updated feature data.

Then, I pulled together what I learned from 8 podcast conversations with the builders behind these tools into the workflows and mistakes that make any tool work better.

Today’s Post

What comes together is the ultimate guide to AI Prototyping tools in May 2026 (where most other content on the web is outdated):

1. The Bakeoff: Lovable v Replit v Bolt.new v v0

2. The 5 Expert Workflows That Make Any Tool Work Better

3. Which Workflow + Which Tool for Your Situation

4. The 5 Mistakes That Turn Good Tools Into Slop

5. Downloadable AI Prototyping Skill File

Subscribe now

1. The Bakeoff

Let’s review the state of the AI prototyping market these days. Then we’ll run the top tools through a bakeoff.

The Market Right Now

The numbers tell the story of how fast this space moves.

Lovable is the revenue leader at $400M ARR as of February 2026, up from $100M just eight months earlier. Valued at $6.6B after a $330M Series B. 8 million users. 146 employees. That’s $2.7M in revenue per employee, roughly seven times the SaaS industry benchmark.

Replit raised $400M at a $9B valuation in March 2026, tripling from $3B just six months prior. 50M+ users. $240M revenue in 2025 with a target of $1B by end of 2026. The company has shifted hard toward non-technical users with Agent 4, which runs 10x faster than its predecessor.

Bolt hit $40M ARR in 5 months on a $700M valuation and was profitable. 5M+ registered users. The browser-native WebContainers technology (no VM spin-up) is a genuine technical difference for speed. Eric Simons, the CEO, told me on the podcast this architecture is why Bolt feels faster than everything else.

v0 by Vercel now has 4M+ users as of February 2026. Vercel raised a $300M Series F at a $9.3B valuation. The February 2026 update added Git integration, a full code editor, and database connectivity, moving v0 from a prototyping tool to something closer to a development platform. Tom Occhino, the CPO, walked me through all of this on the podcast.

Other Tools Worth Knowing

1. Dazl is built by Nadav Abrahami, co-founder of Wix. Strongest visual editor of any prototyping tool I’ve used. You can select individual elements, tweak colors with an eyedropper, and edit components directly. It builds full server-side applications, not just client-side prototypes. Nadav walked me through the whole thing live on the podcast.

2. Base44 had the most remarkable story in the space. Maor Shlomo, solo founder, scaled to an $80M all-cash exit in 6 months. Purpose-built for building entire apps. Colin Matthews and I wrote the full production guide covering how to take prototypes to this level.

3. Reforge Build is designed for product teams. It knows your customers, your product, and your strategy. If your team has an established design system and wants prototypes that reflect real pricing tiers and real customer language, this is worth trying. (It’s in the bundle.)

4. Claude Artifacts changed the game for quick one-offs. Claude renders React, HTML, and interactive applications inline. For a mockup you want to show a colleague in 30 seconds, you don’t even need a separate tool.

5. Google Firebase Studio is Google’s entry. If your company is on Google Workspace, this may be the fastest path because there’s zero procurement friction.

6. Figma Make is Figma’s response. It imports your existing Figma design system directly. Designers will gravitate here because it’s already where they work.

If your company already uses Google, Microsoft, or Figma, you may already have access to a prototyping tool through your existing stack. Start there.

Clearly the big 4 right now are Bolt, v0, Lovable, and Replit. So I compared these 4 as they sit today.

The Feature Comparison

Here’s how the 4 tools compare across every dimension that matters for PMs. I verified each cell against current product pages and public data as of May 2026.

Best for, in one line

1. Bolt - Speed and full-stack iteration. The all-rounder.

2. v0 - Front-end polish, especially if your team already deploys on Vercel.

3. Lovable - Non-technical PMs who want a finished page, not a code editor.

4. Replit - Internal tools with persistent data. The only one with a real built-in database and auth.

The Bakeoff

If there’s one takeaway from the features comparison, it’s this:

I ran the same feature through each. Here’s what happened.

The Prompt

I built a PM portfolio page: hero section with name and tagline, career highlights as metric cards, a skills section, and a contact area. This is relevant to PMs (portfolio content is one of my most-read topics), visually rich enough to show design quality differences, and simple enough that all 5 tools can handle it.

The exact prompt used:

Test 1: AI conversational search for Yelp’s homepage

Type: feature add to a familiar consumer product. Tests AI-aware UI patterns, branded restraint, edge cases on a high-traffic surface.

Yelp’s homepage is a passive listings grid with a basic keyword search bar. Internal research shows 67% of dinner-decision queries are multi-constraint (”date night under $50 with patio, not too loud”) but the current search bar only handles a keyword and a location. Users either give up or open three other tabs to compare. The fix is conversational search, shipped into the existing homepage without redesigning anything else.

We’re adding AI-powered conversational search to Yelp’s homepage. The rest of the homepage stays exactly as-is: the existing nav, the For You grid below the search bar, the curated category strip, the footer. You’re shipping ONE new feature into an existing page, not redesigning Yelp.

Current state: a basic search bar at the top of the homepage with two inputs (what + near). Users type “ramen” and “94110” and get a static results page. Average session has 2.3 searches before the user finds something or gives up.

Build the new search experience:

1. The search bar sits where the current one does, full width below the nav. Single input field, not two. Placeholder rotates every 3 seconds through real conversational queries like “Best ramen open right now”, “Date night under $50 with patio”, “Coffee shops with strong wifi nearby.” The bar has a subtle sparkle icon on the right edge so users understand this isn’t keyword search.

2. On focus, the bar expands into a chat-style interface that overlays the top of the page (the For You grid behind it dims to 40% opacity). As the user types, show three suggested completions based on prior queries from similar users.

3. On submit, stream the AI response. A short paragraph of natural language reasoning, followed by 3-5 restaurant cards stacked vertically. Each card shows the photo, name, price/distance/rating, and ONE pulled-out reason why it matches the query (”Open until 11pm, patio confirmed, average bill $42”).

4. The user can refine in plain English. A follow-up input below the results says “Refine your search...” with example prompts like “Closer to me” / “Anything cheaper” / “Vegetarian options.” Refinements re-rank the same surface, not navigate away.

5. The search overlay can be dismissed with Escape or a close button. When dismissed, the For You grid restores to full opacity. The user’s last query persists in the bar in case they want to resume.

Design constraints: keep Yelp red (#D32323) only on the active search state and the close button. The chat surface uses a clean light card with subtle shadow, not a full modal. Mobile takes the full screen instead of an overlay. Tap targets minimum 44px.

Edge cases: if the AI returns no matches, show 3 alternative search suggestions (”Try expanding distance” / “Try removing ‘open now’”) rather than an empty state. If the user types a non-restaurant query (”buy a couch”), redirect gracefully: “Yelp is best for places to eat, drink, and visit.” Loading state uses shimmer in card slots, not a generic spinner.

First Outputs

Here’s what each tool produced from the identical prompt:

Bolt — 3 minutes

Bolt shipped fastest, beating v0 by 2 seconds and finishing a full minute ahead of Lovable and Replit. No questions asked, no clarification requested, just output.

What stood out: Bolt was the only tool that respected the Yelp brand. Real red logo, the actual nav (Restaurants, Home Services, Auto Services, More), red used only on the live “Open Now” badges. v0 didn’t show the brand at all. Replit modified it. Lovable softened it.

The most interesting move was unprompted. Most cards say “Verified,” but a couple say “Verify before going.” That’s the data-trust edge case from iteration 3 of my prompt, and Bolt baked it into V1 without being told. That’s the kind of inference you get from someone who reads the whole spec before opening Figma.

v0 — 3 minutes 2 seconds

v0 took the prompt’s “AI search as the centerpiece” so literally that the search IS the entire page. No nav, no logo, no For You grid, no categories. Just a headline, a subtitle, and a search bar floating in space.

Zero Yelp brand. No red, no logo, no nav. Swap “restaurants” for “products” in the copy and you could ship this as a search demo for any company. The placeholder was the weakest of the four: “Best sushi in the city...” where Bolt gave you rotating specifics like “Date night under $50 with patio.” Generic where specific would have helped.

Lovable — 4 minutes 3 sec

Lovable was slowest, and the output reads like it spent that time playing it safe.

The hero copy was the strongest of any output: “What are you in the mood for?” with “Describe it like you’d tell a friend, we’ll figure out the rest.” Warmer than anyone else got close to.

But Lovable collapsed two distinct sections the prompt explicitly separated. For You and the curated category strip became one section of 6 large editorial collection cards. No prices, no ratings, no “Open Now” anywhere. It looks like a magazine landing page. Wrong product surface.

Replit — 4 minutes

Replit took 33% longer than Bolt and shipped a duplicate-content bug. It added a “Recent Activity Near You” section nobody asked for, and the two reviews in it are literally the same review from “Alex M” about Tartine Bakery, pasted twice.

The one thing that worked: real San Francisco restaurant names in the cards (Nopalito, State Bird Provisions, Zuni Cafe, Kin Khao). The output felt like a real product, not a mockup. Then it modified the Yelp logo to “yelp+” and swapped the real nav for its own version (Write a Review, Events, Talk). The brand wasn’t in the prompt to redesign.

Iteration

Obviously as PMs, we shouldn’t ship first outputs. So, I gave each tool the same 3 follow-up prompts: a color scheme change, adding case study cards, and fixing mobile typography.

Iteration 1 (Group decision mode)

Our highest-frequency unsolved use case in user research is “I’m trying to pick a place for a group and everyone has different constraints.” We watched 14 users get stuck in this pattern, opening 4-6 tabs to cross-check. Add a group decision mode to the search.

In the chat overlay, add a “I’m with a group” toggle below the search input. When toggled on, the AI prompts the user to capture each person’s constraints in plain English. “Sarah is vegan, Alex is gluten-free, Maya wants under $40 a head.” The user can list 2-6 people. As they describe constraints, the AI summarizes them into a visible “Group profile” card above the search results so the user can see the AI captured everything correctly.

The recommendations that follow are constrained by the intersection of all preferences. Each card shows a small “Works for all 4” badge or, if it’s partial, “Works for 3 of 4 (Maya: closest to budget)” with the friction surfaced honestly.

Add a “Share group plan” CTA at the bottom of the results that generates a one-tap shareable link any group member can open without an account.

Edge case: if the group’s constraints have no intersection (vegan + steakhouse-only), the AI says so plainly and suggests the closest-fit places for each subgroup, not a fake compromise.

---

Iteration 2 (Conversational memory across sessions)

Returning user research shows 23% of users come back within 7 days to revisit a search they didn’t complete. Today they start over from scratch because the search has no memory. Add conversational memory across sessions.

When a logged-in user opens the search bar, show a small “Pick up where you left off” pill above the placeholder if they have an unfinished search from the last 7 days. Tapping the pill restores the full prior conversation, results, and any refinements they applied.

The AI itself should reference past sessions when relevant in new searches. “Last week you looked at Saigon Deli but didn’t go. Want me to include similar places nearby?” Frame these as suggestions, never assumptions, and always with a “Forget this” link that clears the memory thread.

Add a small “Search history” link in the chat header that opens a sidebar with the last 30 days of conversational searches, each summarized in one line. Users can re-run any prior search with one tap, or delete it. History is per-account, never shared.

Edge case: incognito or signed-out sessions have no memory at all and surface no past-session pills. The first signed-in search after a long absence (over 30 days) should NOT reference old context. People’s tastes change.

---

Iteration 3 (Hardening for ambiguity and outdated data)

In a stress test of 500 random queries, the AI returned at least one closed-down restaurant in 31% of responses, and gave confidently wrong answers about hours, menus, and reservations in 18%. The hardening pass below is non-negotiable before this ships to GA.

Three changes:

1. Add a confidence indicator on every restaurant card. Green dot if the AI has verified data from the last 30 days (hours, menu, current price range). Yellow if the data is 30-90 days old. Gray with a “Data may be outdated” footnote if older. Never show data older than 180 days without an explicit “verify before going” prompt.

2. When the AI doesn’t know, say so. Never fabricate. If a user asks “Does this place do reservations?” and the AI doesn’t have signal, the response is “I don’t have reservation data for this place. Try calling or checking their site.” This is more important than appearing smart.

3. Add a “Report incorrect info” link on every card and chat response. Tapping it opens a quick form with one tap for common errors (closed, wrong hours, wrong price, wrong cuisine). Reports feed back into the data pipeline and the user’s home feed should show “Thanks, we updated this” within 48 hours of a verified correction.

Don’t change the happy path UI. This iteration is about what the system does when it doesn’t have a clean answer.

Final Results

Here’s how they handled it.

Bolt - Most production-ready output of the four.

Yelp red used only on the logo and live “Open Now” badges. Everything else stays grayscale plus the food photography. The kind of brand restraint that usually takes a senior designer to enforce.

The hero copy is the strongest of the four: “Find your next favorite spot. Ask in plain English. Our AI finds exactly what you’re craving.” Specific enough to teach the user how to interact without resorting to “AI-powered” buzzwords. Sticky nav matches real Yelp exactly. Eight individual restaurant cards in a 2x4 grid with the full information set the prompt asked for: photo, status badge, name, rating, cuisine, price, distance.

And again, the unprompted touch from V1 survived all three iterations. Most cards say “Verified,” a couple say “Verify before going.” Bolt internalized the data-trust requirement and carried it through without drift.

v0 - Most minimal interpretation, almost to a fault.

v0 kept the same problem through all three iterations. The search IS the entire page. No nav, no logo, no For You grid, no categories. A headline, a subtitle, and a search bar floating in space.

The hero copy stayed generic: “Discover Your Next Favorite” with “Find restaurants that match your mood with conversational search.” Could be any food app. The placeholder never improved either. “Best sushi in the city...” where Bolt is cycling through real multi-constraint queries. If you need a clean search component and plan to drop it into your own layout, v0 gives you that. If you need a prototype that looks like the actual product, it doesn’t get there.

Lovable - Strong editorial choice, wrong product surface.

Lovable’s hero copy remained the warmest: “What are you in the mood for?” with “Describe it like you’d tell a friend, we’ll figure out the rest.” The placeholder was concrete and on-brief: “Late-night bites after 11pm.” Lifted straight from real user behavior.

The structural problem persisted. The For You restaurant grid and the curated category strip stayed collapsed into six editorial collection cards (Cozy weeknight dinners, Quiet coffee for deep work, Date-night under $50). No individual restaurant data anywhere on the page. No prices, no ratings, no distance, no “Open Now.” Beautiful output, wrong product.

Replit - The most opinionated swings, some off-brief.

The real restaurant names held up. Nopalito, State Bird Provisions, Zuni Cafe, Kin Khao still made the output feel like something you’d actually ship.

Everything else stayed off-brief. The “yelp+” logo modification persisted. The custom nav (Write a Review, Events, Talk) replaced the real one. The duplicate “Alex M” Tartine Bakery review was still there after three iterations of follow-up prompts. The brand mods, nav restructure, and duplicate review together push it out of “ship-ready” territory. (The specific mistake pattern that causes bugs like this to persist across iterations is one of the 5 mistakes I cover below.)

Bolt wins, and this wasn’t scripted. In fact, this wasn’t the only test I ran. I actually ran all these tools through a PM portfolio. You can find all those results here:

PM Portfolio

There again, Bolt won. That’s why I worked so hard to get Bolt into the bundle; be sure to grab it. And yes: I would’ve published the results even if Bolt didn’t win.

Where we go from here

That’s the bakeoff. Now the question is how to actually use these tools well. I spent a year interviewing the builders. What they taught me everything that follows.

🔒 For paid subscribers:

1. 5 expert workflows from Sachin Rekhi, Boris Cherny, Colin Matthews, Dan Olsen, and Nadav Abrahami, each sourced from their podcast appearances

2. The decision framework: 7 situations mapped to the right workflow + tool combination

3. The 5 mistakes I made building landpmjob.com (and that Dan, Sachin, and Nadav each named independently)

4. My personal setup and the production bridge

5. Downloadable AI Prototyping Skill file with before/after demo

Read more

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by Arize: Ship AI agents and features faster, with fewer regressions.

Today’s episode

If you’ve gotten an enterprise Claude subscription, you want to get the most out of it.

And the first question is: When do you use Claude Chat vs Cowork vs Code?

The second question is: How do you use each of them best?

Today’s episode answers both questions. I’ve brought back Pawel Huryn for a record fourth time. You guys loved his prior episodes on discovery, AI PM, and n8n.

Now, he’s back with a masterclass on the Claude ecosystem for PMs:

Apple Podcast

Spotify

• If you want access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, Relay.app, Magic Patterns, Speechify, and Mobbin - become an annual subscriber ($150), and grab Aakash’s bundle.

• If you want access to my AI PM customizations - PM OS, Job Search OS, and Prompt Library - become a founding subscriber ($250).

The roadmap from here

We’ve built the complete guide to building a self-improving AI PM operating system across Cowork, Claude Code, and Dispatch:

1. Why chat is a dead end for serious PM work

2. The Cowork power setup

3. What Claude Code unlocks that Cowork cannot

4. The self-improving knowledge system

5. The 24/7 PM workflow

Subscribe now

1. Why chat is a dead end for serious PM work

We’ve all used ChatGPT and Claude Chat to do work. But you shouldn’t be anymore.

Chat has three hard constraints that make it a dead end:

1. No continuity across devices or sessions

2. No access to your real files or tools

3. No systems that persist and improve

Each one is worth marinating on for a little bit.

Constraint 1 - No continuity

If you start a complex task on your desktop and then get pulled into a meeting, you cannot pick up that same session on your phone. You cannot resume it from a web browser.

Your only option is to copy the entire conversation into a new context and hope the agent reconstructs your state correctly.

Cowork and code do not have this limitation. You can build a multi-agent system with file access, tool connections, and persistent project context.

Constraint 2 - No file access

Chat cannot read your desktop. It cannot organize your invoices.

In the episode, Pawel dropped a folder of mixed invoices - PDFs, images, different months, duplicates with different filenames - into Cowork.

Then he plugged in a single prompt. From there, the agent built a step plan, extracted dates from PDFs, identified duplicates using hash functions, created month folders, move files, and verified. Four folders appeared in seconds. Duplicates removed. Images that were also invoices got sorted correctly even though the prompt only said “PDF invoices.”

Chat would have described how to organize invoices. Cowork organized them. On a real desktop. In a real file system.

Constraint 3 - No persistence

Chat has very little controllable memory across sessions.

You cannot build a system that learns from its mistakes, extracts patterns from your data, and applies those patterns to the next task automatically.

We’ll show you how to in Code and Cowork.

Putting it all together

So how should you be using the three surfaces? Here is Pawel’s setup:

• 70% Dispatch + Claude Code web sessions

• 25% Claude Code locally

• 5% chat

But you don’t need to get there right away. You can use cowork instead of code, too (as I’ll show in the next section). The real key point is you should keep chat to 5%, and use more powerful surfaces for everything.

2. The Cowork power setup

So if you shouldn’t be using Chat, what should you use? The next level up is Cowork. It’s a user-friendly skin on Code. Here’s how to set it up like a power user:

Step 1 - Skills + plugins

I wrote about this on Monday. Skills are the new prompts.

The agent reads only the name and description first. If the description matches the current task, it loads the full instructions. If it does not match, the instructions never enter your context window.

This is progressive disclosure. You can have dozens or hundreds of skills loaded. The agent consumes context only on the ones it needs right now. Here is what that looks like in practice.

Pawel’s PM skills marketplace has soared past 11,000 GitHub stars. Inside, there are numerous plugins. Each plugin bundles multiple skills.

Two plugins I’d highlight you install now:

1. Product discovery plugin - analyze feature requests, brainstorm ideas, plan experiments, create tracking metrics, identify and stress-test assumptions

2. Product strategy plugin - Ansoff matrix, pricing strategy, competitive analysis, product strategy canvas generation

Now here’s the caution:

The real ROI is in iteration. Here is the process I have found works:

1. Install a marketplace skill. Use it on a real task.

2. The output has problems. Give Claude the specific failure. Not “this is bad.” Something like “the acceptance criteria are missing edge cases around null values and the priority labels do not match our team’s P0-P3 scale.”

3. Tell Claude to read the conversation, identify the root cause of the failure, and rewrite the skill from first principles so it does not make that mistake again.

4. Test the updated skill on another real task. Find the next failure. Repeat.

After five or six iterations, the skill handles 99% of cases correctly. I gave you a full skill to improve skills automatically on Monday if you want to accelerate this cycle.

You cannot just sit and use some magic technique to get it right on the first try. Build, test, give feedback, iterate. That is the whole game.

Step 2 - MCP connectors for real tools

Cowork connects to your actual systems through MCP servers - and some are even more bundled into connectors. I covered building a PM OS from these connections with Mike Bal a few months ago.

You want to connect Gmail. Google Drive. Slack. Analytics tools. User research platforms. CRM. The more data flows in, the smarter every skill becomes.

Now here is how connectors work in practice for a PM.

In the episode, Pawel ran a live email demo on his inbox. One prompt:

The agent connected to Gmail, counted, and reported back. It even drafted replies.

Here’s our recommendation: start drafting your comms with this.

1. Configure the Gmail connector to draft-only mode. The agent proposes replies but cannot send.

2. Configure Slack the same way. Drafts appear with a “send” button you approve manually.

3. After every session, the system reviews your edits to its drafts and learns your voice. Next batch of drafts gets closer.

This is the AI-drafted email workflow I wrote about last year supercharged. The agent drafts. You approve. The agent learns from your edits. Your approval rate climbs over time.

Step 3 - Drive Strategy

AI really compounds when you don’t just use it to do work but to be a stratgic partner.

In the episode, Pawel loaded a product strategy skill via slash command (which I recommend - it ensures the right skill fires instead of relying on auto-detection).

The agent asked clarifying questions defined by the skill, then generated a full product strategy canvas as a PowerPoint deck.

Two things blew my mind. First, Claude is dramatically better at using PowerPoint than it was even two months ago. There is no excuse to walk into a stakeholder meeting with a bad presentation anymore.

Second, the output reflected the specific skill definitions around north star metrics and guardrails. A good skill is the difference between generic AI output and McKinsey-level output.

If you put these three steps together, you’re now a Cowork power user.

3. What Claude Code unlocks that Cowork cannot

At this point you are thinking - Cowork does everything I need. Why do I need Claude Code?

The answer is not about raw capability. If you load development plugins into Cowork, it can do similar things technically.

The answer is about interface, control, and systems that grow past 20 files:

The explorer view and multi-file systems

In Cowork, if you want to find a file the agent created, you use the little build in-browser.

This hits a wall fast. The moment your system grows to 50+ files - knowledge databases, skill files, templates, infographics, invoices, contracts, brand guides - you need the explorer panel. It shows folder structure. You expand directories. You click to open any file. You see what the agent has created and where it lives.

Any PM building a serious personal operating system will need this view. The file system IS the operating system.

Claude Code also gives you features Cowork lacks entirely:

1. Hooks - scripts that trigger before or after tool calls. Automate quality checks. Block requests that fail conditions.

2. Subagents - parallel workers that handle sub-tasks independently and report results back.

3. Local MCP servers - credentials scoped to specific projects. In Cowork, MCP connections are global across all sessions. In Claude Code, you define which connections each project can access. This matters for security.

4. Lifecycle control - what happens before a tool is called, what happens after, ability to block or retry.

If you want the foundations, I walked through the full Claude Code setup for PMs and the team OS pattern in separate guides.

HTML infographics and the component library

Every viral infographic from Product Compass - the Anthropic team calendar, the Claude Code pricing breakdown, the 74-release tracker - was built in Claude Code. Not Canva. Generated as HTML, iterated through natural language conversation, and exported as PNG.

The mechanism is more interesting than the output.

The system maintains a growing library of HTML components. When a new infographic performs well on social media, the agent analyzes it. It extracts the layout patterns, the visual components, the density characteristics. These get stored as reusable building blocks.

When a new infographic is requested, the agent assembles from the library. New layouts from proven components. Each new output that works feeds the library. The components compound.

The process works because of context engineering - feeding the agent the right information at the right time. Feed it winning infographics. It extracts patterns. Feed it your brand system. It applies constraints. Feed it new content. It generates within both.

Building your second brain for agents

Karpathy recently presented a system for building a personal wiki with LLMs. A knowledge base for humans. Agents organize your articles, attachments, notes into a browsable second brain.

The approach in the episode is the inverse. Build a second brain for your agents, not for yourself. You are the curator. You feed in articles, screenshots, infographics, competitor posts. The agent does not just store them. It decomposes them.

Feed it 10 high-performing LinkedIn posts from a specific creator. The agent extracts:

1. Hook patterns - what opening structures correlate with high engagement

2. Sound bites - phrases and sentence structures that get quoted and shared

3. Voice archetypes - tonal signatures that differentiate one creator from another

4. Engagement metrics - what format, length, and topic combinations drive reactions

It organizes this by platform. X in one domain. LinkedIn in another. Substack in another. Each domain accumulates its own knowledge. When you ask the agent to write for a specific platform, it loads only that platform’s rules.

The agent that wrote for X a month ago is measurably better at writing for X today. Because it has more data, more confirmed patterns, more rules to apply.

You are curating a knowledge base that makes every future session smarter than the last.

4. The self-improving knowledge system

Every PM building with Claude hits the same wall. Your CLAUDE.md grows. You keep adding instructions, examples, good output, bad output. Eventually it consumes half your context window on every prompt. A grammar check carries the same overhead as a strategy task.

This is the most important section of this newsletter. It is the difference between using Claude and building with Claude.

The CLAUDE.md router pattern

Do not put detailed instructions in your CLAUDE.md. Your CLAUDE.md has one job - explain the project structure and tell the agent where to find specific knowledge.

Here is what goes in CLAUDE.md.

1. Project description - what this project is about, in two or three sentences

2. File structure - what is in each folder so the agent does not scan the repo on every prompt

3. Who I am - basic context. Role. Audience. Goals

4. Knowledge system instructions - how to find domain-specific knowledge, how to route to the right file, how to update knowledge after tasks

5. Workflow references - pointers to workflow files for specific operations like fetching Twitter data, analyzing LinkedIn posts, or drafting Substack notes

Here is what does NOT go in CLAUDE.md.

1. Detailed writing style rules - put in a voice file

2. Lists of good and bad examples - put in a patterns file

3. Platform-specific instructions - put in platform-specific files

4. Historical data or metrics - put in a metrics file

The index file routes everything. X rules live in X knowledge files. LinkedIn rules live in LinkedIn files. Product strategy frameworks live in strategy files. The agent loads only the relevant domain for the current task.

I covered the foundations of this in my context engineering guide. The CLAUDE.md router is the implementation layer that makes context engineering work in practice.

Rules, hypotheses, and rejected patterns

This is where self-improvement actually happens. When the agent analyzes data - posts that performed, offers that converted, candidates that got hired, experiments that shipped - it does not just summarize what worked. It generates three types of knowledge:

1. Rules - patterns confirmed across enough data to apply by default. Example from the episode - “achievement-as-proof hooks outperform achievement-as-point hooks.” Confirmed across 46+ posts. The agent applies this automatically to every new hook it writes.

2. Hypotheses - patterns observed but not yet confirmed. The agent tracks these with evidence counts. A hypothesis can be promoted to a rule when evidence accumulates, or demoted to rejected when counter-evidence appears. Example - “emotional diversification correlates with higher average engagement.” Currently hypothesis, not yet rule.

3. Rejected - patterns that were considered but disproven by data. The agent keeps these to avoid re-testing dead ideas. Example - a specific hook format that was hypothesized to work but showed negative results across multiple tests.

The agent manages all three categories without being told what to look for. It discovers its own patterns. It updates its own confidence scores. It organizes by domain automatically.

In the episode, the knowledge database had entries the builder had never seen before. Hypotheses the agent generated independently from analyzing patterns across hundreds of posts. That is the compound effect.

The three-line prompt that makes any domain learn

You do not need to build the full system from day one. Here are the three instructions you paste into your CLAUDE.md. They work for any domain - testing, marketing, strategy, release notes, customer offers, interview prep, whatever:

That is the entire mechanism. Show the system 10 good examples and 2 bad examples. Ask it to create something new. It reviews the rules it has already extracted. It applies the confirmed ones. You give feedback on the output. It updates the knowledge. The next output is better.

The knowledge self-organizes by domain. Pricing rules stay in pricing. Testing rules stay in testing. Marketing rules stay in marketing. You do not need to manage the taxonomy. The agent builds it from the data.

If you do nothing else after reading this, do three things this week.

1. Add the three-line self-improving prompt to your CLAUDE.md.

2. Feed it 10 examples of good work in one domain you care about.

3. Ask it to do one task in that domain and see what rules it applied.

That alone will put you ahead of most PMs still briefing from scratch every session.

5. The 24/7 PM workflow

If you can build a system that works while you are away from your desk, why would you limit yourself to working only when you are sitting at your laptop?

The answer most PMs give is “I would not.” The problem is they do not know how to set it up. So let’s explain it.

Anthropic shipped four remote surfaces - web sessions, remote control, Dispatch, and Channels. Not all four matter equally. Here is what does.

Dispatch as your mobile command center

Dispatch is a single chat interface on your phone (and desktop) that can start multiple background tasks simultaneously. You type “create an infographic for this text.” While it works, you type “how many emails did I get in the last two hours.” While both run, you type “analyze the last 5 posts by competitor X.”

Each task delegates to a separate agent thread. You monitor progress. You provide feedback. You approve outputs. You dispatch the next task. All from your phone.

The description from the episode was specific - “my life works much better integrated with life now. I do not have to have blocks dedicated to work. I go for shopping, I go somewhere with my kid and I just dispatch tasks. I provide text feedback in the chat. I look at the results. I dispatch another task and continue what I was doing.”

This is not about working 24/7. It is about decoupling PM work from the desk.

Code web sessions for focused work

When you need the full explorer view, the file tree, the terminal - use code web sessions. These run on Anthropic’s servers, connected to your GitHub repo.

The critical insight - put your entire operating system into GitHub. CLAUDE.md. Skills. Knowledge files. Everything syncs. Code web sessions point at your repo. Now you can access the same system from any device. Your laptop does not need to be online. This is also the most secure setup because everything stays on Anthropic’s infrastructure.

The pattern - start something on your desktop. Continue it on your phone through Dispatch. Finish it from a web browser through code web sessions. One system across every device.

I walked through the setup in my Claude Code guide. The GitHub sync step is the one most PMs skip.

When to use which (and the n8n question)

Here is the decision framework:

1. Dispatch - mobile, multiple lightweight tasks in parallel, quick feedback loops

2. Code web sessions - focused work with full file explorer, any browser, laptop offline is fine

3. Cowork - desktop knowledge work with files, the daily driver for most PM tasks

4. Claude Code - complex multi-file systems, hooks, subagents, HTML generation

5. Chat - grammar checks and one-off questions. 5% of your time

But here is the question everyone asks. If Claude Code can automate everything, is n8n dead?

No. And the distinction matters.

Everything above is personal automation. Your judgment stays in the loop. You approve drafts. You review outputs. You provide feedback. The agent suggests. You decide. This is where Claude Code wins.

Production automation is different. Customer ticket responses. Onboarding flows. Compliance checks. Data pipelines. For these, you need guarantees that Claude Code cannot provide.

Claude Code workflows are text files an agent interprets. The agent can respect the instructions. It can also ignore them. You cannot tell an agent “if the API fails, retry three times” and guarantee it will. You cannot enforce “verify customer email exists before sending” as a hard rule. You cannot prevent one customer from seeing another customer’s data with a markdown file.

For production systems, you need n8n or a similar workflow engine where the logic executes as code, not as suggestions. Conditional branches. Retry mechanisms. Access controls. Deterministic execution paths.

• Personal automation - Claude Code. Text files. Agent interprets.

• Production automation - n8n. Code logic. Deterministic execution.

Knowing which one you need is what separates a PM who ships from a PM who demos.

Final Words

The PM role in 12 months will not disappear. But it will compress vertically. Super individual contributor PMs at the bottom. CPO and CEO at the top. The middle thins.

Most of your time will be orchestrating multiple agents, switching contexts, assessing outputs. The trivial parts - tickets, debugging, presentations, release notes - will be automated. The PMs who survive are P-shaped or broader. Marketing. Strategy. Technology. Product. Customers. And enough about every area to delegate the work and assess the output.

Get Transcript

Where to find Pawel Huryn

• LinkedIn

• Product Compass Newsletter

• PM Skills Marketplace on GitHub

Related content

Podcasts:

1. n8n Masterclass with Pawel Huryn

2. Claude Code PM OS with Carl Vellotti

3. Claude Code Team OS with Hannah Stullberg

Newsletters:

1. The complete Claude Cowork guide

2. How to use Claude Code like a pro

3. Build your PM operating system

PS. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

Share

For my money, Claude (or insert-your-agent) Skills are the highest alpha technique in AI right now. So I spent dozens of hours last week testing out different skill setups.

That’s what today’s piece is. I’ll give you all the results from my testing on skills the past 6 months.

Plus, a hardened skill to…

Read more

“That Slack discussion that aligned the team on an architectural pattern? If it isn’t discoverable to the agent, it’s illegible in the same way it would be unknown to a new hire joining three months later.”

They were talking about AI coding agents. But read it again. It applies to your entire product team.

That pricing decision your team made in February? If it’s buried in reply #31 of a Slack thread, it doesn’t exist. Not for the AI. And not for the PM who started last month. That customer call where the VP of Engineering said the integration was a dealbreaker? If the summary lives in one PM’s personal notes, it might as well not have happened. The churn query your analyst wrote last quarter? If the engineer paged at 2 AM can’t find it, she’s stuck until morning.

The knowledge exists. It’s just trapped: in someone’s head, in a personal setup, in a tool nobody else can search.

The Solution: A Team OS

Hannah Stulberg, a PM at DoorDash, showed the solution on my podcast a few weeks back.

She built a shared repo where every team function checks in their context and anyone on the team can query it in natural language. She demoed a query that found the answer using 3% of the context window.

The part that stuck with me was what happened the following week, when a new engineer needed context about a customer decision from three months ago.

Hannah wasn’t involved. She wasn’t even online.

She had made herself unnecessary for context questions. The team treated her as more valuable for it. Every PM book tells you to make yourself indispensable. Hannah's bet was the opposite. She freed herself from being the bottleneck so she could do the work that actually requires judgment.

I’ve spent months building personal AI setups. My PM OS has 41 skills and a context library and sub-agents. I’m proud of it. And I’ve slowly realized it solves the first problem. It makes me faster. The harder problem is making the team faster. When I’m asleep at 2 AM and an engineer needs the churn query, my personal OS can’t help them.

I’ve spent the past week studying four implementations of what I’m calling a Team OS. Hannah at DoorDash. Dave Killeen at Pendo. Gabor Meyer at Google. Carl Vellotti building solo. Four people, four companies, four different levels of complexity. They all converged on the same architecture.

That convergence is what convinced me to write this.

Today’s Post

I’ve partnered up with to make sure this followup to her podcast is the highest quality possible guide to building a Team OS in Claude Code out there.

She is the author of In the Weeds (including her viral Claude Code for Everything series) and is running a Maven workshop on the topic this weekend.

Why We Built This

• New hires take 6 to 7 months to feel settled.

• Only 12% of employees say their company does onboarding well.

• 47% of companies call institutional knowledge loss their top offboarding challenge.

Most of that time, most of that loss: context that already exists somewhere, trapped in someone’s head or buried in a tool nobody else can search.

A context question is rarely just the lookup time. It's the lookup, the Slack ping, the wait, the context-switch back. At 10 of those a day at 10 minutes of total productive time lost each, you're at over 8 hours a week. Most teams I've talked to are higher.

And the pattern isn’t Claude Code specific. Codex, Cursor, GitHub Copilot. This architecture can be moved wherever you are, because it’s just Markdown files. The examples here just use Claude Code because that’s what is most popular with AI-native PMs right now.

The Deep Dive

🔒 For paid subscribers, we’ve put together everything you need:

1. How to Upgrade your Personal OS to a Team OS with 1 command

2. The Architecture That Works (The 3 Layers)

3. Three Ways Teams Actually Use It

4. How to Build One in 4 Weeks

5. The Real Problems You’ll Encounter

6. What the First Month Actually Looks Like

Plus 6 downloadable resources, including: a skill to convert your personal OS to a team OS, a starter repo, and an adoption playbook.

Subscribe now

Read more

That’s Prasad Reddy, former CPO at El Nutra and former VP at Danaher. He’s seen it from the interviewer side at the C-suite level. I’ve been seeing the exact same pattern at the IC and senior PM level.

I’ve coached 80+ AI PM candidates in the last two LPM cohorts. 22 have landed offers. Across the rejections, one pattern keeps showing up. Safety was the round candidates underestimated. It was treated as a paragraph at the end of a case, or it never came up at all.

Hacker News recently saw the same story.

So I brought three people who have sat on both sides of this table.

1. Ankit Virmani, AI PM at Uber, former Group PM at Meta. He has interviewed and hired AI PMs.

2. Prasad Reddy, former CPO at El Nutra, former VP at Danaher. He led teams shipping AI in regulated environments where one mistake meant lawsuits.

3. Dr. Bart Jaworski, who has coached 12,000+ PMs through interview prep. He scored every mock in the episode against the rubric used in real onsites.

We did three live mocks. We got scored on the same rubric used in real loops. Nobody saw their grades until they went on screen.

If you are interviewing at any AI company in 2026, this is the episode to watch the day before your loop.

Apply to Cohort 3 of Land PM Job

If you want live coaching from me, Ankit, Prasad, and Dr. Bart on the exact frameworks in this video and newsletter, apply to Cohort 3 of Land PM Job:

1. Starts this week. 12 weeks of live coaching.

2. Live mocks scored on the same rubric used in this episode

3. AI PM Course teaching you everything you need from evals to protytping

We are accepting 75 candidates total. Apply here.

Today’s Post

Now, into this week’s deep dive on the Safety & Ethics round:

1. Why this round is rejecting candidates

2. First principles + the 4 precedents to memorize

3. The SHIR framework to lean on + 2 worked examples

4. Our mock breakdown: what scored and what didn’t

5. Calibration and prep

   • How each top AI lab actually asks the question

   • Which AI PM roles get safety questions, and which ones get hammered

   • Six anti-patterns that kill candidates

   • 60 questions to drill

6. AI tools to practice with

Subscribe now

1. Why this round is rejecting candidates

There’s more than a few people who are well prepared for their interviews and come back to say they failed safety ethics.

I see 3 major reasons why.

Shift 1 - Safety is no longer a checkbox at any top company

Two years ago, safety was important on paper. Reviews were required but nobody had time for them. That has completely flipped.

Shift 2 - The bar moved from philosophy to production

Generic answers are failing. Here is what a generic answer sounds like.

“We would test for bias, check edge cases, and make sure outputs were appropriate.”

Every word is correct. The interviewer still writes “no evidence of production safety experience.” There is no incident. No scar tissue.

The candidates who score highest describe a system they built. They name the architecture. They cite the business impact.

Shift 3 - Silence on safety is the pattern in rejection debriefs

Here is the rule I give every candidate. The 40-minute safety rule.

If you are 40 minutes into a 60-minute interview and you have not mentioned safety, find a way to bring it in. Interviewers are watching for it. And it is not enough to mention it once across a five-interview day. Safety is important enough that you should reference it in almost every interview.

So how do you bring it up? Three things. The first principles that explain what you're actually being asked. The framework that gives you the structure. And the precedents that prove you've thought about this before.

🔒 The rest of this post is paid. Here is what’s behind it:

• The SHIR framework with 2 worked examples

• The 4 precedents to memorize

• How each top AI lab actually asks the safety question

• 60 safety and ethics questions to drill, categorized by type

• AI tools to practice with against the same rubric Bart used

If your safety round is in the next two weeks, this is the playbook.

Read more

Hermes, from Nous Research, just passed Claude Code in GitHub stars. Seven weeks to cross 100K. Faster than LangChain, AutoGPT, or any agent framework I’ve tracked.

GitHub stars is an engineering metric. So I spent a month figuring out what actually matters for PMs.

Some of the migration was security-driven (OpenClaw had 512 vulnerabilities and 335 malicious skills documented in January). That explains the timing. It doesn’t explain why people stayed.

I set up a competitive monitoring workflow on a Tuesday. Same prompt every Monday for six weeks. By week six, the briefing was surfacing competitor patterns I hadn’t caught in three weeks of doing it manually. The prompt never changed. The skill underneath rewrote itself four times.

That’s the gap I’m going to show you today. The Monday Gap - the difference between a static skill library and a self-improving one. Widens every week.

Why Hermes Matters for PMs

Every AI tool you use has the same gap. Every Monday, you re-explain who you are, what you’re working on, which competitors matter, what you decided last quarter. Custom instructions help. A Claude project helps. My PM OS helps. They all share one limit: the skills and prompts you wrote are static. They produce the same output in week 50 as week 1.

Hermes writes its own skills.

Every 15 tool calls, it pauses, looks at what worked in the session, and saves a workflow file to ~/.hermes/skills/. You can read it, edit it, delete it. My competitive briefing skill from week one isn’t the one running today. The agent rewrote it four times.

Numbers from my logs: same task took 20 minutes week one, 12 minutes week four, 8 minutes by week six. Same prompt. Same outputs. The agent stopped rediscovering the procedure every Monday.

The model isn’t where the value lives. Hermes runs Claude, GPT-4o, Gemini, or local Llama. Same skills, your choice of model. If Anthropic rate-limits you mid-launch, you have a fallback. If a cheaper model gets the job done, you save the spend.

Three things make Hermes worth the 20-minute setup on top of what you already have:

1. Skills that rewrite themselves based on what worked in your last 10 sessions

2. Model-agnostic runtime so the same skills run on Claude, GPT, or local Llama

3. One agent across Telegram, Slack, WhatsApp, Discord, Signal

What’s in the toolkit (paid subscribers):

• 3 SKILL.md files (competitive-intel, signal-log, decision-log)

• SOUL.md template (PM persona, pre-filled)

• USER.md template (with auto-update fields)

• 30-day rollout plan (week 1, 4, and 8)

Drop the folder in ~/.hermes/skills/ and the skills load automatically.

Today’s Deep Dive

1. The Setup (20 Minutes, Then It Runs Forever)

2. 3 Use Cases for PMs to try today

3. How self-learning agents look at the end of 30 days

4. Three things I’d tell you if you were starting Monday

5. Where to Start

6. The Toolkit (3 SKILL files + templates + 30-day plan)

7. Honest Limitations

Read more

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by:

1. Maven - Get a $675 discount off Gabor’s course with my code

2. Amplitude - The market-leader in product analytics

3. Testkube - The leading test orchestration platform

4. Land PM Job - My 12-week AI PM + Job Search Course starts Monday!

5. Product Faculty - Get $550 off their #1 AI PM Certification with code AAKASH550C7

Today’s episode

Here’s the problem with most Claude Cost demos: they stop at the prototype.

Nobody shows what happens next. You try to add a second feature. The first one breaks. The styling reverts to default. The code is so tangled that you spend more time debugging than you saved by generating.

Gabor Mayer showed me what happens when you stop treating Claude Code like a magic prompt box and start treating it like a team.

He is a PM at Google. He has not written production code in 15 years. But over the past several months, he has been building real mobile apps using 21 specialized Claude Code agents. Not prototypes that live in a demo. Apps that are on the App Store.

In today’s episode, he walked through the entire workflow live and share all the resources free.

Apple Podcast

Spotify

If you want access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, DeepSky, Relay.app, Magic Patterns, Speechify, and Mobbin - grab Aakash’s bundle.

Do you want to become an AI PM? I’ve created a course for you. Starts next week.

Newsletter deep dive

Thank you for having me in your inbox. Here is the complete guide to building a full AI development team in Claude Code:

1. Why one-prompt vibe coding fails

2. The 21-agent team architecture

3. The spec-first workflow

4. From design to code without touching either

5. What changes when PMs actually build

Subscribe now

Save this. The full 10-step playbook on one page. Everything below is the why and how behind each step.

Share

1. Why one-prompt vibe coding fails

Every PM I know has built something with Bolt, Lovable, or Replit. The prototype looks great. It runs. It impresses people in a Slack message.

Then you try to ship it to real users. And you hit a wall.

Blocker 1 - Context compression silently destroys your spec

This is the failure mode that nobody talks about in tutorials. When you give one agent one massive prompt, the model compresses context. Details get dropped. Not randomly. Strategically. The model decides what is “important” and what is not.

In the episode, Gabor defined a complete color palette. Oranges, neutrals, specific accent tones. The agent received everything. The output used none of it. The layout was there. The structure was solid. But every color was a default.

The reason is straightforward. When the context window is full, visual styling details are lower priority than functional logic. So the model drops them. Silently. Without warning. Without an error message. You just get generic output and wonder what went wrong.

The fix is not better prompts. It is context engineering. Smaller, scoped tasks. Each agent gets only the context it needs for its specific job. The designer agent gets the brand guideline. The CTO agent gets the architecture spec. Neither gets the full 50-page document.

Blocker 2 - AI-generated code compiles but is not maintainable

A Reddit comment that hit home for Gabor -

“Vibe coding is just the rebranding of unmaintainable, low-quality source code.”

This is the real prototype-to-production gap. The code works today. You can demo it. You can push it to TestFlight. But the moment you touch it to add a feature, three other features break. No naming conventions. Circular references between modules. Zero comments explaining why anything was built the way it was.

The fix is a dedicated code quality agent. Gabor calls his the Spaghetti Agent. It runs after every sprint and checks naming conventions, circular references, comment coverage, and structural debt. When he ran it on his codebase for the first time, it caught issues he never would have found manually.

If you are building anything beyond a one-off demo, this agent is not optional. I covered similar quality patterns in my AI testing guide and my AI evals deep dive.

Blocker 3 - No dependency mapping means cascading failures

When you build without organizing work into sprints, agents try to build features that depend on code that does not exist yet. Front-end components reference API endpoints that have not been created. Database queries call tables that have not been defined.

The Atlassian MCP currently cannot create sprints directly in JIRA. That is a real limitation. Gabor uses tags as a workaround. He tags tickets as Sprint 1, Sprint 2, Sprint 3 and maps dependencies between them manually before starting the build. Without this step, the entire multi-agent workflow falls apart.

Every PM who has gone from prototype to production with AI agents has hit at least one of these blockers. The ones who shipped figured out the workarounds. The ones who quit assumed the tools were the problem.

Here is what the three blockers look like side by side, and what flips the moment you stop one-prompting and start running a team.

2. The 21-agent team architecture

You do not need 21 agents to start. Three will get you surprisingly far. But understanding the full architecture shows you where the complexity lives and which roles to add as your projects grow.

Here is the full roster: four clusters, 21 roles, and the markdown file pattern that makes them portable across every project you build next.

2a. The core agents every PM needs

The System Analyst is the linchpin. It breaks down product requirements into technical specifications. It asks clarifying questions one at a time. It documents decisions in Confluence. It creates tickets in JIRA. Without this agent, every other agent operates on incomplete context.

In the episode, the system analyst asked 14 clarifying questions before a single line of documentation was written. Vector DB choice. Usage limit mechanics. Conversation history handling. Search fallback strategy. API provider. Minimum iOS version. Screen count. Naming conventions. Each question one at a time so the answers stay deep.

The prompt pattern that makes this work -

“Please act like a good system analyst. Ask clarifying questions until you have a complete and comprehensive understanding. Ask questions one at a time. Do not start writing documentation until all questions are answered.”

Two critical instructions. “One at a time” prevents the agent from dumping 25 questions at once. “Do not start writing” stops it from jumping ahead before the spec is complete. Different LLMs have different tendencies. Some love to start coding instantly. You need to explicitly constrain them. This is the same principle behind the prompt engineering techniques that work across any AI tool.

The Spaghetti Agent handles code maintainability. Naming conventions. Circular references. Comment quality. Structural debt. Born from that Reddit comment. When Gabor ran it on his codebase for the first time, it caught problems he never knew existed.

The UX Flow Architect creates clickable prototypes using Figma’s built-in prototyping arrows. This is a small but important detail. The early versions of this agent placed visual drawn arrows between screens instead of using Figma’s actual prototyping connections. The prototype looked like it had navigation. But when you clicked play, nothing happened. It took months of iteration to fix.

Each agent has a specific Claude Code agent markdown file that defines its role, its constraints, and its interaction patterns. The setup mirrors how you would build a Claude Code Team OS for a human team.

2b. The real blockers nobody warns you about

The Figma MCP color problem. When you connect Claude Code to Figma through the MCP and pass it your full specification, the screens look structurally correct but the colors are wrong. Not slightly wrong. Completely wrong. The model compressed the context and dropped your entire visual identity. The fix is to pass the brand guideline as a separate, focused input to the Designer Agent. Never bundle it with the functional spec.

The Atlassian MCP sprint limitation. The MCP currently cannot create sprints directly in JIRA. Gabor uses tags as a workaround. Sprint 1, Sprint 2, Sprint 3. It works. But it means dependency mapping is a manual step in the system analyst prompt, not an automated feature.

The consumer app vs Claude Code gap. An agent role you set up in the Claude consumer app does not automatically transfer to Claude Code. You need to define agents separately in both environments. The system analyst in your consumer app conversation is a different instance from the system analyst in your Claude Code agent folder. Your AI PM stack needs to account for this separation.

The $200 Max plan economics. On the Max plan, a major build session uses roughly 10% of your monthly allocation. That means you get about 10 full build sessions per month. For a side project, that is plenty. For a production workflow with daily iterations, you need to be deliberate about when you run multi-agent sprints.

2c. Why reusable agents beat fresh setups

Every painful lesson, every edge case fix, every API workaround gets encoded into the agent markdown file. The next project starts from a position of strength. The Spaghetti Agent that took weeks to calibrate on project one is immediately useful on project two. The UX Flow Architect that took months to stop drawing fake arrows works correctly from day one on every subsequent project.

This is the compound interest of building with agents. The first project is slow. The second is faster. By the fifth, your agent team is genuinely effective. Gabor’s Maven course walks through the full setup at maven.com/gabor/productbuilder.

The 21 agents are not the point. The point is that every role on a software team can be replicated by a scoped, reusable AI agent. Start with three. Add roles when you hit friction.

3. The spec-first workflow

Most tutorials start with the terminal. Open Claude Code. Start prompting. Start coding.

That is backwards. The workflow that actually ships production apps starts in the consumer app. On your phone. Possibly while walking your dog. The process maps cleanly to the PM OS framework that works for any complex project.

3a. Define the system analyst role first

Before you describe your app, you ask the LLM to define what a good system analyst does. This creates a behavioral framework that the agent will follow for the rest of the conversation.

The prompt -

“What is the difference between a good system analyst and a bad system analyst in a software development team? Be as detailed as possible.”

The response gives you a blueprint. Requirement elicitation. Stakeholder management. Process modeling. Dependency documentation. You then instruct the agent to act like a good system analyst.

This is the same principle behind AI agents for PMs. Define the role explicitly before assigning the task. It works in Claude Cowork the same way it works in Claude Code.

3b. Dictate, do not type

This is where superwhisper changes the game. In the episode, the app specification was dictated in a single long monologue. Technology stack (Flutter + Firebase). Data storage rules (device-only, no server-side user data). API key security (Firebase Secret Manager, never exposed to front-end). Usage limits (20,000 word cumulative cap with escalating cooldowns). Tone of voice (friendly but firm, like a 20-year referee friend). Vector database configuration (Vertex AI embeddings for IIHF rulebook and Situation Book).

Typing that specification would have taken 30 minutes and produced half the detail. Dictating it took five minutes and captured every nuance. The longest dictation prompt in the history of this podcast.

Here is the actual prompt, the five-step workflow it kicks off, and the two-word constraint - “one at a time” - that stops the agent from face-planting.

The key rule - even if you ramble, even if you are not perfectly concise, the LLM will understand. You lose nothing by over-specifying. You lose everything by under-specifying. This applies whether you are building a prototype or shipping to production.

3c. Documentation before design

The system analyst creates the full Confluence documentation before any design or code begins. Product overview. Technical architecture. AI agent specification. Data flow diagrams. API endpoint mapping.

Without documentation, every agent operates on partial context. With documentation, every agent operates on the same source of truth. I covered this exact approach in my PRDs guide. The principle is identical whether your team is human or AI.

The boring part of building is the specification. The exciting part is watching agents create screens and write code. But if you skip the boring part, the exciting part produces garbage. The PMs who understand product strategy already know this.

4. From design to code without touching either

Once the specification is locked, the workflow shifts from the consumer app to three parallel tracks. This is where the 21-agent architecture pays off and where most of the real-world friction surfaces.

Three tracks - design, tickets, build - running in parallel into four sprints. 72 minutes from idea to App Store submission. Here is the map.

4a. Design through Figma Make and Claude Code

Start in Figma Make. Go to Spotted in Prod. Take screenshots of apps you admire. Feed those into Figma Make to create a brand guideline. Typography. Color palettes. CTA buttons. Error states. Transitions.

In the episode, two inspiration images produced a full brand guideline. One of them was a photo of a laptop cover. Figma Make derived custom colors from the image without manual hex entry.

Claude Code then used the Figma MCP to build actual screens in Figma based on that style guide. Five screens appeared in real time. Each one matching the brand guideline. The Chrome DevTool MCP lets Claude Code visually verify designs in a browser, catching visual bugs the Figma MCP alone cannot detect.

4b. Tickets with the full team review

The system analyst creates JIRA tickets. The entire agent team reviews every ticket before development starts. This is the step that separates production builds from demo builds. Same product launch discipline, different toolchain.

Designer agent verifies screenshots are attached. Test Architect ensures test coverage. Spaghetti Agent sets naming expectations. Product Council confirms data storage policies. CTO Agent validates architecture. This maps to the AI observability principles I wrote about previously.

4c. Sprint execution with the dependency mapping workaround

Tickets organized into sprints using tags (Atlassian MCP workaround). Dependencies mapped. Database setup in Sprint 1. API in Sprint 2. Front-end in Sprint 3. Integration in Sprint 4.

“Claude, start building. Go for Sprint 1. Once done, Sprint 2, then Sprint 3, and so on. If you have any questions, ask.”

Multiple agents work in parallel. The coding phase is the fastest part. On the $200 Max plan, roughly 10% per session.

Everything before the code is the hard part. Once those are right, the code practically writes itself. This is true whether you are shipping to production as a PM or managing an engineering team.

5. What PMs gain by building with agents

If agents can spec, design, code, and test, what is the PM actually doing?

Making product decisions. The tools just got absurdly faster.

Gain 1 - Firsthand understanding of agent behavior

When you interact with agents daily, you develop intuition for context window limits, hallucination patterns, and compression behaviors. That intuition directly improves your roadmap decisions. You stop over-scoping agent features because you know where agents break down. You stop under-investing in evals because you have seen what happens without them.

Gabor has not written production code in 15 years. But he now understands agent behavior better than most PMs who have only read about it. That understanding compounds across every product decision.

Gain 2 - A portfolio that proves competence

A working app on the App Store is undeniable proof. Password-protect a section showing the build process. Confluence docs. JIRA tickets. Agent architecture. That portfolio item says more than any certificate. It says you shipped.

Gain 3 - Iteration speed that compounds

The first build is the hard part. The UX Flow Architect alone took months. The Spaghetti Agent needed weeks of tuning.

But once v1 ships, everything accelerates. New features take a morning. The reusable agent files carry forward every lesson. The PM who has shipped one app can ship the next in a fraction of the time. Not because the tools are better. Because their agents are better.

Stack those three gains over a year and the gap between PMs who build and PMs who watch stops being a gap. It becomes a moat.

You do not need to know how to code. You need a willingness to understand how software works and the patience to specify before you build. If you want to get started, my Claude Code guide walks through the full setup.

Where to find Gabor Mayer

• Maven course - Go from PM to AI Builder

• LinkedIn

• X

Related content

Podcasts:

1. My Claude Code PM OS with Dave Killeen

2. Claude Code OS Layer with Carl Vellotti

3. How to Design like OpenAI and Figma with Ed Bayes and Gui Seiz

Newsletters:

1. The complete guide to Claude Code

2. AI agents for PMs

3. How to build AI products

PS. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

Share

Do you see what these questions are asking? You need to combine a depth of knowledge on product sense and AI.

Today’s guide helps you do so.

Not Just Google

Ankit Virmani, former Group Product Manager at Meta, just finished a full AI PM job search - nabbing offers at Cisco, Uber, and Atlassian. He told me something I didn’t expect.

70-80% of his rounds were still traditional behavioral and product sense. The same “tell me about yourself” and “improve Snapchat” stuff. But the one round that showed up at every single top AI company was AI product sense.

To show you exactly what a 10/10 looks like in April 2026, I recorded a full mock with Ankit on one of the hardest AI product sense questions in circulation right now -

The question - “How would you increase Claude Code weekly active users 10x?”

This is the type of question top AI companies actually ask. And what makes the mock realistic is the curveball. Halfway through Ankit’s answer, I threw him a pivot he didn’t see coming.

For Live Coaching

Want live coaching like this from Ankit and I? Apply for our Land PM Job cohort which starts Monday. Here’s our teaching schedule:

This is our third cohort. We have added in both AI PM and PM fundamental mini-courses. This is the only PM cohort I'm aware of that runs dedicated AI PM and PM fundamental mini-courses alongside the core curriculum.

Apply Now

Apply now. 41/75 seats left.

Why Now

Six months ago, I published the first AI product sense interview guide on the internet. I did a mock with Dr. Bart Jaworski on “How would you double ChatGPT image creation WAU with 3 engineers?”

That guide has been read by 80,000+ people. And in the six months since, I’ve coached another 80 candidates through 2 cohorts - including folks who encountered AI product sense rounds at OpenAI, Anthropic, Figma, Meta, and Amazon.

The round has changed again. Significantly.

In October 2025, AI product sense was a niche round at a handful of AI-native companies. Today, it’s spreading everywhere. Meta literally added it as a 4th interview.

Per IGotAnOffer's deep dive with ex-Meta Sr. Product Leader Audrey, the "Product Sense with AI" round is for IC6+/M1/M2 roles in their Central Products org, where candidates vibe-code a prototype while the interviewer evaluates judgment.

Google’s AI teams test it like Jaclyn, inside existing interviews. Even Stripe and Uber are weaving AI into their product sense rounds now.

And the bar has moved since October.

Today’s Post

I’ve updated everything I know about AI product sense based on 6 months of new coaching data:

1. What Changed Since October 2025

2. How to Pass the Updated Interview

   • 2 practice tools (Claude Skill, Custom GPT)

   • What Ankit did differently from every candidate I’ve coached below a 7

   • The 5 AI-specific thinking shifts that separate strong from weak

3. The Full Breakdown

   • The Ankit mock analyzed in detail (what I scored and why)

   • How the top 5 companies ask this differently in April 2026

   • Where to practice next

Subscribe now

1. What Changed Since October 2025

When I wrote the first guide, I said “this interview doesn’t exist yet, but it’s coming.” Six months later, it’s here.

The round is no longer optional. It’s spreading everywhere.

Ankit categorized the landscape into three tiers based on what he actually experienced during his search -

1. Tier 1 - In Everything. OpenAI, Anthropic, Google DeepMind. AI product sense is part of every interview in some way. At OpenAI, you get questions like “how would you double ChatGPT image creation with just three engineers?” At Anthropic, “how would you increase Claude Code WAU 10x?”

2. Tier 2 - Added to existing loops explicitly. Meta is the biggest shift here. They literally added a 4th interview called “Product Sense with AI” for IC6+/M1/M2 roles. This is specific to the Central Products org. Figma has also added a specific round called ‘AI Product Sense.’

3. Tier 3 - Woven into 1-2 rounds. For instance, LinkedIn asked Ankit about how OpenAI and Anthropic launching into their markets should reshape product strategy in another interview. This is the sneaky one. Your recruiter email won’t mention “AI product sense.” But if you’re interviewing for an AI PM role, expect it.

Here’s the thing Ankit said that hit me hardest.

“Even at companies that don’t have a dedicated AI round, AI fluency is being evaluated inside the regular and traditional product sense round. The bar has very much shifted.”

I’d triple-click on this for you. If your recruiter doesn't list 'AI product sense,' that doesn't mean you won't be tested on it. It means it's embedded inside a round with a different name. The candidates who prep for it specifically are the ones who walk out knowing they nailed it.

The nature of what’s being tested has changed.

In a traditional product sense interview, you’re designing features for a deterministic system. User clicks a button, something predictable happens. You can use CIRCLES. You can follow a template. You can honestly pattern-match your way through it.

That’s the fundamental shift. Traditional frameworks can’t solve for this. You can’t CIRCLES your way through “how would you increase Claude Code WAU 10x?” because the answer requires you to understand how agentic workflows work, what Opus 4.6 is capable of, how slash-loop infrastructure enables proactive behavior, and what Cowork is as a product surface.

The round now decides your level, not just your pass/fail.

This is the insight from our Land PM Job cohort data that blew my mind.

Across 80 cohort candidates, the pattern I keep seeing is that AI product sense correlates more with level placement than behavioral. Candidates who came back saying 'I was expecting L5, I got L4' more often than not pointed to the AI round when we debriefed.

Ankit's framing on this was the clearest I've heard. 'Behavioral gets you through the door. AI product sense is the round that truly decides your offer. The level, the money, the negotiation leverage all flow from this round.

The compensation makes this the highest-stakes round in PM.

The Tier 1 comp data below comes from public Levels.fyi medians and cohort candidates who interviewed at the frontier labs over the last six months -

1. OpenAI - $860K median, ranges from $300K (Manager) to $950K+ (Staff). PPU-driven equity.

2. Meta - $515K median, ranges from $173K (L3) to $2.24M (Senior Director). L7 PMs at $987K median.

3. Google - $473K median, ranges from $182K (APM1) to $2.45M (L9/L10). Group PM at $757K median, public equity.

4. Anthropic - $468K median, ranges $468K-$651K. Pre-IPO equity at $60B+ valuation, which could change the comparison materially over 4 years.

These are public-data US medians for the PM role at each company, not specifically AI PM medians (which Levels doesn’t break out separately). Ankit’s experience and what I’ve seen in cohort placements suggest AI PM roles cluster at or above these medians at frontier labs. Specific offers vary by team, level, and negotiation. AI PM roles in India, Europe, and at non-frontier-lab companies (think enterprise AI, healthcare AI, fintech AI) operate on different curves.

The takeaway from Section 1 - If you’re interviewing for an AI PM role in April 2026, you will face AI product sense. The question is whether you’ve prepared for it differently from traditional product sense. If you’re still using CIRCLES or the old frameworks, you are bringing a knife to a gunfight.

🔒 The rest of this post is for paid subscribers only. You’ll get -

1. The 5 AI-specific thinking shifts with before/after examples from real interviews

2. The full Ankit mock breakdown (what I scored 10/10 and what cost him 1 point)

3. How OpenAI, Anthropic, Google, Meta, and Amazon ask this differently in April 2026

4. 2 practice tools I built (Claude Skill, Custom GPT)

5. Where to go from here

Read more

Read more

Then I partnered with PostHog to analyze 4.2 million survey responses across nearly 6,000 in-app surveys. What we found upends most of what PMs think they know about surveys.

This Reddit post captures what most teams experience:

106 upvotes. 17 comments. Near unanimous agreement.

The problem was never surveys. The problem was how they ran them.

They send surveys. They collect data. Nothing changes. Users stop responding. The PM concludes “surveys don’t work” and goes back to guessing.

Meanwhile, every PM I know is obsessed with shipping AI features. Prototyping with Claude Code, building agents, vibe coding products in an afternoon.

Most of these AI features will fail. But the teams shipping them won’t know why until their retention curves tell them months later. By then the feature has shipped, the PR cycle is done, and the data is pointing at a problem they can’t diagnose.

Catching it early requires talking to users at the right moment. In-app surveys do that better than any other tool in a PM’s kit.

Today’s Post

Today’s post is a collaboration with Jina Yoon, Adam Bowker, and Cory Slater at PostHog. We’ve jointly put together the ultimate guide to in-app surveys:

1. The 5 Survey Mistakes Exposed by 4 Million Responses

2. Real Survey Teardowns from 6 Companies

3. The In-App Survey Playbook

4. Two Claude Skills You Can Download Today

5. How to Analyze Your Survey Data with AI

Subscribe now

1. The 5 Survey Mistakes Exposed by 4 Million Responses

Mistake 1 - You’re Not Surveying Users Who Are Leaving

We often assume users who are leaving are already upset. Why would they take time to give feedback?

Wrong. Exit surveys got the highest response rate (15.5%) of any survey intent type. Compare that to general satisfaction surveys at 8.4%.

PostHog gets an impressive 42% response rate on exit surveys for their Session Replay product. The feedback is specific enough to act on:

1. “I wish I could set it to sample only 1% of sessions.”

2. “It would be awesome to limit the total amount of recordings per month.”

3. “We’d definitely continue using if we were sure this is HIPAA and SOC2 compliant.”

Each of those is a product decision you can make tomorrow. Compare that to “Great product, love it!” from a satisfaction survey.

Reed Hastings writes about Netflix’s feedback culture in No Rules Rules: the ratio inside the company is 25% positive, 75% developmental. Negative feedback is always more actionable.

The fix: Always have an exit survey. If you’re only going to run one survey, make it an exit survey. Trigger it on the cancellation or downgrade flow. You’ll catch users at the moment they’ve made their decision, when the feedback is freshest. This is the highest-signal input you can get for your retention strategy.

Mistake 2 - Your Timing Is Wrong

Have you ever been hit with a “How can we improve?” popup right after visiting a website for the first time?

That’s URL-based targeting. Surveys triggered when a user lands on a page. Many teams use it because it’s easy to deploy.

Event-triggered surveys get 1.6x more responses than URL-based targeting (11.7% vs 8.8%). Users who get surveyed on page load are in a background tab, mid-task, or never actually see it.

This is what Sprig figured out when they rebuilt on event-driven architecture. Surveys fire based on what the user just did, not what URL they’re on. That single shift is what let them scale their infrastructure to over 10 billion API interactions per month.

The fix: Trigger your surveys right after the user does something relevant. After they complete a product tour. After they use a feature. After they hit a milestone. If you need a refresher on where those moments sit in the user journey, my onboarding and activation guides map them out.

And your first question’s format alone creates a 3.6x response rate gap. More on that below.

Mistake 3 - Your First Question Is Wrong

First impressions matter. Your survey’s first question is the whole ballgame.

Surveys that started with a single-choice question get 3.6x more responses than those that started with an open-ended one.

The full ranking:

1. Single choice: 15.6%

2. Multiple choice: 14.4%

3. Ratings: 8.8%

4. Link: 8.6%

5. Open-ended: 4.3%

This tracks with behavioral psychology. Cialdini’s commitment and consistency principle says small, low-cost actions create momentum. Same reason Yelp asks you to write a review before asking you to sign up.

The fix: Lead with single or multiple choice. Escalate to ratings. End with open-ended. Shallow end to deep end.

The format sequence is what the data validates. The specific questions are yours to customize.

Mistake 4 - Your Open-Ended Questions Are Too Open

Open-ended questions are low response rate by nature (4.3%). Typing takes more effort than clicking.

But you can do much better by asking them well.

The default “What can we do to improve our product?” in PostHog only gets 3.2%. Questions that connect to the user’s context get 6%. Nearly 2x from framing alone.

Generic questions fail because they ask the user to scan every feature, every frustration, every wish, then prioritize, then articulate. That’s a 30-second mental task. They close the popup.

Three better approaches (adapt to your product):

1. Anchor to what they just did: “What did you think about that template creation process?”

2. Use dead time: “Before we load your dashboard, what metrics matter most to you?”

3. Give something back: “Want to earn a certificate for completing this training? Tell us your email.”

Another option: the foot-in-the-door technique for recruiting interview candidates. Launch a single-choice question first. People who respond are psychologically primed to say yes to “Would you be open to a 15-minute call?” Your survey becomes your interview recruitment pipeline. One of the best ways to feed your continuous discovery practice.

Mistake 5 - Your PMF Survey Is Diluted

Sean Ellis coined the famous PMF question: “How would you feel if you could no longer use this product?” If 40%+ say very disappointed, you’ve hit product-market fit.

But PMF surveys only get a 13.1% response rate. Buffer’s team wrote about this on their open blog: you need 40-50 active user responses before the signal stabilizes. That means surveying 300-400 active users.

At a startup, you might not have 300 active users. You survey everyone, including yesterday’s signups and free trial lurkers. Their responses dilute your signal.

At a big company, you have plenty of responses but from a mix of power users, casual browsers, enterprise admins, and freemium tire-kickers. The aggregate describes nobody.

Superhuman’s fix (from Rahul Vohra’s First Round Review piece): add a second question: “What type of people do you think would most benefit from [product]?”

Happy users almost always answer by describing themselves. Those self-descriptions become your ICP. Superhuman went from 22% “very disappointed” to above the 40% threshold by narrowing their focus based on these responses.

The fix: Only trigger PMF surveys after activation milestones. If your aha moment is “collaborate on a board with two people” (Miro), only survey users who’ve crossed that threshold. Users who haven’t activated will say “somewhat disappointed” and that’s noise.

And contextualize with the self-description question. Your PMF score and your ICP definition come from the same survey.

2. Real Survey Teardowns from 6 Companies

The 5 mistakes tell you what not to do. The 6 companies below show what running this well looks like end to end. Six different survey types, six different decisions they drove.

Superhuman’s PMF Segmentation Engine

Source: Rahul Vohra, First Round Review

Section 1 covered the segmentation move. Here’s what Section 1 didn’t cover: the fourth question.

Superhuman’s survey had four questions, not three. The fourth was “How can we improve?” and it’s where the roadmap came from.

“Very disappointed” users told them what was already working. “Somewhat disappointed” users who valued speed told them what was missing. The top request from that second group was a mobile app. Superhuman built it.

That’s the dual job of the Superhuman survey. The first three questions tell you who to build for. The fourth tells you what to build next. The survey told them exactly what to build and exactly what to ignore.

Slack’s 3-Question Onboarding Personalization

Source: Appcues evolution teardown, Userpilot teardown

Slack asks three survey questions during workspace creation: team name, what you’ll use Slack for, and invite teammates. The answer to “what will you use Slack for” gets reflected back immediately in the workspace setup.

The user’s answer is immediately reflected in the product. You see your own words in the channel name. Onboarding feels tailored from minute one. And Slack gets free segmentation data: they now know what problems each workspace is trying to solve.

Slack’s onboarding has changed at least 3 times since 2014. Each version reduced friction. But the 3-question survey persisted across every iteration. That tells you something.

PostHog’s Slack Response Pipeline

Every survey response at PostHog pipes into a dedicated Slack channel instantly. Someone responds within minutes. Not automated. Human.

Their numbers: 42% exit survey response rate on Session Replay. Users share detailed, actionable feedback because they know someone is reading.

Teams that treat survey responses as the start of a conversation keep getting responses. Teams that don’t watch response rates decay. (If you want more data like this from the PostHog team, their newsletter is here.)

Three patterns connect Superhuman, Slack, and PostHog. Context beats generic timing. Surveys feed product decisions, not spreadsheets. And closing the loop with human follow-up is the difference between 4% and 42% response rates. Three more companies show different angles on the same principles.

🔒 The full guide continues for paid subscribers.

Below: The complete In-App Survey Playbook with four survey templates, conditional branching flows, and 12 bad/good/awesome mockups showing exactly what to ship for every survey type. Two downloadable Claude Skills (a Survey Analyzer that scores your draft survey and rewrites weak questions, and a Survey Generator that builds complete surveys from a goal). A 30-minute AI analysis workflow that turns a CSV export into a 1-page action brief, replacing 10+ hours of manual synthesis. Three more teardowns (Amplitude, Miro, Sprig). And a printable poster with the complete framework.

Read more

The first is personal: what you need to know before every decision and every meeting. Competitor moves, user feedback, stakeholder context. When this breaks, you’re the last person in the room to know things you’re supposed to know first.

The second is your team’s: the systems that serve your users, surface …

Read more

Check out the conversation on Apple, Spotify, and YouTube.

Brought to you by:

1. Maven - Get discounts off Mahesh's courses with my links

2. Amplitude - The market leader in product analytics

3. Jira Product Discovery - Prioritize what matters with confidence

4. NayaOne - Airgapped cloud-agnostic sandbox to validate AI tools faster

5. Product Faculty - Get $550 off their #1 AI PM Certification with my link

Today’s episode

LinkedIn just scrapped its APM program and replaced it with an Associate Product Builder track, and introduced a Full Stack Builder career ladder alongside it.

What does it even mean to be a “builder PM”?

Well, tools only get you so far. Learning Claude Code is helpful, but means nothing if you don’t have an understanding of the underlying first principles.

That’s today’s episode.

Mahesh Yadav created one of our most popular episodes, with over 35K views on YouTube, and now he’s back. Earlier, he taught you AI agents.

Today, he’s teaching you how to become a builder PM:

Apple Podcast

Spotify

If you want access to my AI tool stack - Dovetail, Arize, Linear, Descript, Reforge Build, DeepSky, Relay.app, Magic Patterns, Speechify, and Mobbin - grab Aakash’s bundle.

I’m giving a free talk on how to get interviews at the top AI PM companies on Thursday (April 23rd) @ 9:00AM PDT. Grab your seat.

Newsletter deep dive

Thank you for having me in your inbox. Here’s the complete guide to “becoming a builder PM.”

1. What is a “Builder PM”

2. The Builder PM Tool Stack

   • n8n

   • Claude Code

   • OpenClaw

3. Mastering AI Agents

   • The first principles of agents

   • How to build self-improving agents

4. The 10-week roadmap to Builder PM

Subscribe now

1. What is a Builder PM

Every PM has already used Claude Code or ChatGPT to get something done. But if that’s where it stops, you are not yet a builder PM.

There are two kinds of builder PM, and they’re different jobs.

Type one ships customer-facing product without engineering handoffs. Customer to 10 paying users, solo. This is what the LinkedIn APB program is training for and what lands you the comp trajectory Mahesh describes.

Type two builds internal agents that automate their own PM work. PRD reviewers, competitive intel, data dashboards. Same skills, different trajectory: stay in your current org, ship 3x more, get promoted faster.

Most of this guide teaches type two. Type one is the aspirational endpoint.

Why this title change happened now

The title change is a response to something that actually shifted in the last six months.

Six months ago, most autonomous agents broke within minutes. METR’s latest benchmarks show frontier models now sustaining multi-hour jobs, with Opus 4.7 running coding tasks for 3 to 6 hours in practice.

When agents can only run for 3 minutes, the PM’s job is to prompt them. When agents can run for 6 hours, the PM’s job is to design the system those agents run inside.

Designing that system is what builder PM actually means.

The compensation trajectory, in case you need the motivation

Mahesh’s comp trajectory shows you the top end of what’s possible. He went from $120K at Microsoft to $1.3-1.4M in his last Google role (Senior PM, AI), with a rough doubling every two years. A few of his AI PM friends at Nvidia are at $2-2.5M.

Levels.fyi still pegs median Senior PM comp at top tech around $350-450K. What Mahesh is describing is the premium the US tech market pays specifically for builder-skill AI PMs, where companies approach you and offer 30-40% over your current number. The $2M+ tier is a small group.

International markets pay differently - builder skills still move comp in EU, India, and APAC, just with different absolute numbers and different negotiation dynamics. And if you’re in mission-driven PM work where comp isn’t the yardstick, the same builder skills still let you ship 3x more impact with the same team - which is the whole point.

You probably won’t hit $1.4M next year. The premium exists, though, it’s real, and the gate is builder skills.

One honest caveat for managers reading this. If your PMs get 10x leveraged, the obvious question is whether you need fewer of them. The early signal from LinkedIn’s restructure is that the answer is smaller pods with broader scope, not layoffs - they’re keeping headcount and pushing each builder to own more surface area. That may or may not hold elsewhere. Worth naming, because every VP Product on this list is already thinking about it.

The failure mode

Here’s the trap: PMs read about Claude Code on Twitter, try it for a weekend, get a mediocre output, and conclude “this is overhyped.”

They skipped the first principles.

That’s the answer to Gothelf. He’s right that execution capacity was never the bottleneck. Judgment was. Judgment sharpens when you ship 12 prototypes a year instead of 1. The builder PM still talks to customers. They just ship without waiting.

That’s what the rest of this guide is going to give you.

When building is the wrong bet

Not every PM job benefits from this shift. A few honest cases where the 10-week investment doesn’t pay off:

• If you work in trust & safety, healthcare decisions, financial underwriting, or legal compliance, your job is to prevent errors, not to generate throughput. An agent that ships 12 prototypes a year doesn’t help you. An agent that proposes a new UI flow in a payments product can actively hurt you. Build evals skills instead.

• If your product lives inside a regulated perimeter and your company has a year-long procurement cycle for new tools, you’ll spend your 10 weeks waiting for IT approval. Spend the time on AI literacy - reading papers, running evals on existing outputs - rather than on personal tool setup.

• If you’re a founder with zero PMs under you, skip the “automate your PRD reviews” framing entirely. Your version is shipping real product to real customers using these same tools. The skills transfer. The PM-productivity examples don’t.

Builder PM is the right bet for most mid-career PMs at product-led companies with data portability. That’s a large slice of the market, not all of it.

2. The Builder PM Tool Stack

Three tools. Three different jobs. Using the wrong one for the wrong stage of your journey will waste weeks.

Pick based on where you are in the journey, ignoring whichever tool has the most Twitter hype this week.

n8n

n8n is a visual workflow builder. You drag components onto a canvas and connect them. That’s it.

Everyone who is deep in AI dismisses n8n as “too basic.” They are wrong. n8n is irreplaceable as a learning tool because you physically see every piece of the agent architecture as separate nodes.

In the episode, Mahesh demoed building a contract analyzer in n8n:

1. Email trigger hits when someone sends a contract

2. 2. Gmail node pulls the MSA (master service agreement)

3. Data loader converts the file to text

4. Text splitter chunks it into 1,000-character pieces with 200-character overlap

5. Embedding model converts chunks to vectors

6. Vector database stores them

7. AI agent reads the playbook and flags risks

8. Gmail node emails back the analysis

9. Eval workflow runs against ground truth

Every one of those is a visible node on a canvas. When something breaks, you see exactly where.

The limitation is real. n8n has no code mode, no version control, no test suites, and no path to production beyond a simple webhook. It stops you around 10 customers.

For most builder PMs, use n8n for 2-3 weeks, then move on. The exception is simple internal workflows with clear webhooks and no collaboration needs - those can live in n8n forever and that’s fine. The “graduate from n8n” rule is about your learning trajectory, not about n8n being bad at its job.

Claude Code

Claude Code is where you build the real thing.

The same tool works for a PM with zero coding experience building skills in English, and for a senior engineer building production services on top of that PM’s work.

Mahesh showed his PRD review setup in the episode. Here is what it does:

1. He drops a PRD into a folder

2. Claude Code reads his checklist (ruthlessly specific, encodes Amazon PR/FAQ format, includes AI-specific criteria like “is this differentiated from ChatGPT or is it a commodity AI wrapper”)

3. The agent reads the document and writes inline comments back into the .docx file, using a Python library to handle the XML under the hood

4. Comments are strategic, not surface level. Things like “What prevents Datadog or the Big Four from building this?” and “How do you handle misclassification?”

That is already useful. But here is where it gets serious.

Every 30 minutes, a second agent runs. It opens the folder of recent reviews, compares the AI’s output against the version Mahesh actually shipped, and logs the deltas to a learner.md file.

When the same correction appears 5 times across 5 days, the learner emails Mahesh: “I want to update your checklist. Here is the proposed update.”

He reviews, approves, and the checklist evolves.

Every day, the reviewer is a little better than the day before. That is the real moat. Not the initial skill. The learning loop that compounds from your judgment. We’ll go deeper on this in Section 3.

The other things to build in Claude Code:

• Competitive intelligence with subagents (3 subagents researching 3 competitors in parallel, rolling up into one report)

• Prototypes from PRDs (clone competitor screens, modify them into working products, ship to customers for feedback in days instead of months)

• Data dashboards generated from your actual production data

Use Claude Code as your daily driver for weeks 4-6 of the roadmap. By the end, you should have at least 2-3 skills running on your real work, with learner loops on top of each.

OpenClaw

OpenClaw is a pattern. The pattern matters because enterprise agents will probably work this way at scale. GCP and AWS are already shipping sandboxed-agent primitives, and the architecture maps directly.

Here is what OpenClaw adds that Claude Code doesn’t have:

Delegation through existing channels. You send the agent a WhatsApp message. It goes and does the work on a separate machine. When it is done, it sends the result back through WhatsApp. You are not sitting in a terminal watching it think.

Full machine sandboxing. Instead of granting file-by-file permissions, you install the agent on a dedicated Mac mini or a VM. It controls the entire compute environment. (Side note: Mac minis with 32GB+ are 10-18 weeks out right now, and several high-memory configs are unavailable entirely. CNN reported Apple Store employees calling them “OpenClaw machines.”)

Model agnosticism. Connect any model, including open source. You are not locked into Anthropic’s rate limits, which every heavy Claude Code user complains about daily.

For PMs at big companies asking the obvious question: Google is not going to let you install OpenClaw on your work laptop. That is true. But Google is going to offer the same pattern inside GCP. AWS is going to offer it inside their infrastructure. The architecture of sending a message to a sandboxed agent that reproduces your problem, tries a solution, and returns results - that is how enterprise agents are going to work at scale.

If you’re at a regulated company (finance, health, government, legal) or your data can’t leave the corporate perimeter, the pattern still applies but the venue changes. Your version is Claude Code or an internal agent platform running inside your SSO and VPN. NayaOne-style airgapped sandboxes exist for exactly this reason. The architecture is the same. The compliance envelope is different. Build what you can inside your perimeter and push your infra team for the pattern on the outside.

Learn the OpenClaw pattern now and you’ll recognize the shape of enterprise agent platforms when they arrive.

3. Mastering AI Agents

Tools without first principles is how PMs waste 3 weeks. Here are the first principles.

The first principles of agents

Every working agent has 4 components. Every disappointing agent is missing at least one. Before you debug a prompt, debug the architecture.

Component 1 - Intelligence (The brain)

The model is the intelligence layer. My current default: Opus 4.7 for agent orchestration and skill authoring, GPT-5.4 for fast single-turn tasks where latency matters. You can run either. The rest of the architecture matters more than this choice.

On its own, it is a genius with amnesia. Ask it about neural networks, it answers perfectly. Ask it what Trump said about Iran this week, and if you picked a cheap model, it tells you its knowledge cutoff is June 2024.

The intelligence layer alone gives you knowledge cutoffs, generic answers, and zero session memory. A model without the other three components is just a more expensive way to use Google.

Component 2 - Tools (The hands)

Tools let the agent take actions. Without them, it can think but it cannot do anything.

In the demo, Mahesh added Tavily (a search tool) to the agent. Same question about Iran. This time, the agent searched, found the answer, and responded with current information. One tool turned it from useless to useful.

The essential tools for PM agents are search APIs (Tavily, Perplexity) for current information, file processors to read contracts and PRDs, MCP servers to connect to Gmail, Slack, GitHub, and your CRM, and bash execution to run scripts. PMs who skip this layer wonder why their agent cannot do anything beyond trivia.

Component 3 - Memory (The recall)

Without memory, the agent forgets everything between messages.

The demo showed this failure instantly. The agent searched and answered the Iran question. Two messages later, Mahesh asked “what conflict am I talking about?” and the agent replied that it saw no previous mention of a conflict. Adding session memory fixed it in one click.

Memory has three layers: session memory for the current conversation, long-term memory for patterns across days and weeks, and structured memory for specific facts the agent needs to retrieve reliably. Every PM agent that feels “dumb” is almost certainly missing one of these.

Component 4 - Knowledge (Your data)

This is where your agent stops being a generic chatbot and starts being valuable.

Knowledge = your company-specific context. Contracts, playbooks, competitive intel, product specs, customer research. Without it, the agent answers from the internet. With it, the agent answers from your actual data.

The RAG pipeline is straightforward: upload your documents, chunk them into 1,000-character pieces with 200-character overlap, convert to vectors, store in a database, and query when asked a question.

In the demo, Mahesh asked about payment terms and tariff impacts on company contracts. Without knowledge, the agent gave generic legal advice from the internet. With the MSA uploaded, the agent answered from the actual contract clauses.

That difference is the entire value proposition of building your own agents vs. using a generic chatbot.

How to build self-improving agents

This is the section almost nobody is doing yet. Which is exactly why it matters.

You automated one task. Your PRD review agent works. Your competitive analysis runs every morning. Then you notice the agent makes the same mistake three days in a row. It misses the same section. It applies the wrong standard.

Static skills produce static output forever. Learning systems compound daily.

Here is the learner loop architecture Mahesh runs on his PRD reviewer:

Step 1 - Every review creates a job folder

Timestamped. Contains:

• Who ran the review

• The input document

• The AI’s output

• The version you actually shipped after your corrections

Step 2 - A scheduled subagent runs every 30 minutes

It opens recent job folders. Compares the AI’s output against your modified version.

Step 3 - Differences get logged to learner.md

What the AI got right. What it missed. What you added. What you deleted.

Step 4 - A threshold triggers a proposal

When the same correction appears 5 times over 5 days, the learner proposes a specific checklist update: an actual edited version of the checklist line.

Step 5 - You review and approve

The new checklist becomes the input for the next review cycle.

The critical design decision is that the learner never updates the checklist automatically. It accumulates evidence, it proposes, you approve. You stay in the loop. The system still compounds.

After a month, your review agent catches things it missed on day one.

After three months, your checklist has evolved from your original draft into something shaped by hundreds of real reviews and your actual judgment calls.

Inside a team, you’ll want one canonical version of each skill in a shared repo, with a light review process when someone proposes a merge. Otherwise you get skill drift, five competing PRD reviewers, and nobody knows which one is current.

Static skills are where most PMs stop. The learning systems that compound from your judgment are what separate the builder PM who gets promoted from the builder PM who watched a YouTube video.

4. The 10-week roadmap to Builder PM

You have a full-time job and maybe 5-8 hours a week to learn this. Here is the sequencing, tested with real PMs in real cohorts:

• Weeks 1-3, Foundations. n8n only. Build one agent with all 4 components, run one real evaluation, build one multi-agent system. By week 3 you can explain the 4 components to a junior PM.

• Weeks 4-6, Build. Move to Claude Code. Pick one real weekly task and automate it with a skill. Add a learner loop on top. Spin up your first subagent system (3 competitors in parallel works well).

• Weeks 7-9, Delegate. OpenClaw time. Pick one complete job (not a subtask) and delegate it via WhatsApp to an agent on a VM. Iterate on the skill until the output is good enough to forward to your team unchanged.

• Weeks 9-10, See the pattern. Read the AI tool market through this lens. Every new tool: is it solving for context, actions, or evals? Is it a variant of the agentic loop? Could you build it yourself?

The biggest failure mode is skipping Phase 1. PMs who jump straight to Claude Code hit a wall around week 3, have no mental model for debugging, and conclude “Claude Code is overhyped.” Do not be that PM.

That decomposition skill from Phase 4 is also what’s showing up in L5 and L6 AI PM interviews. Based on reports from candidates I’ve coached through Land a PM Job and notes from Blind, some loops now include live building exercises where you’re expected to open Claude Code and produce a working prototype.

Candidates who default to Figma mocks when the interviewer is looking for a working prototype have lost offers. Figma is still the right tool for design work. The signal the interviewer is looking for is whether you can ship.

For hiring managers

In 6 months every PM resume will claim builder skills. Two questions cut through it:

1. “Walk me through a skill you’ve built and how the checklist evolved.” Real builders have version history. Fakes have a one-liner.

2. “Show me the learner.md.” Real builders have a file of failures. Fakes don’t.

If a candidate says they’ve used Claude Code but can’t name the four components of an agent or explain when they’d choose n8n over Claude Code, they watched a YouTube video. That’s different from building.

[Bonus] Episode Summary

Ten weeks. Three phases of building. One phase of seeing.

At the end, you are a PM who builds AI systems that get better every day.

In 2026, that is the difference between being automated and being the one doing the automating.

Get Transcript

Where to find Mahesh Yadav

• LinkedIn

• Maven Course

Related content

Podcasts:

1. Claude Code Team OS with Carl Vellotti

2. OpenClaw + Claude Code with Naman Pandey

3. Claude Code OS with Dave Killeen

Newsletters:

1. The complete context engineering guide

2. How to use Claude Code like a pro

3. Practical AI agents for PMs

PS1. Please subscribe on YouTube and follow on Apple & Spotify. It helps!

PS2. The third cohort of my LandPMJob Program is filling up. Apply now!

Share