Read more

Since then, we’ve added two more of my favorite tools: Speechify (which I use for dictation) and Bolt.new (which I use for building websites and prototypes).

Today, we add another. And, for many, it will be the most exciting one yet.

It’s one of the most powerful platforms out there. Let me show what it can do.

Today’s Post

I’ve put together a complete guide to Airtable for PMs and Product leaders:

1. What is Airtable

2. Intro to Airtable lingo

3. How to set up Airtable

4. Airtable vs the competition

5. How to redeem it in the bundle

6. Putting it all together into Aakash’s stack

Subscribe now

1. What is Airtable

For PMs and product leaders, the best way to think of Airtable is as a place to run your product work.

It’s like a combination of Jira, Zapier, and Notion Calendar in one place - with connected Claude MCP too.

I had on their VP of Product last year if you want to see him show you:

You might be thinking: we have sheets, we have Claude, what else do we need?

The honest answer is:

But as soon as you hit some level of scale, you’ll want to standardize things. You’ll want your roadmps in one place. You’ll want your automations centrally editable after an employee leaves.

You could maintain that all yourself, a series of vibe codes in Cowork, but there’s a maintenance cost involved.

That’s why basically every company out there eventually gets on some tool. The big one’s are Jira Product Discovery, Productboard, Pendo, and… Airtable.

2. Intro to Airtable Lingo

Airtable has its own lingua franca, so let’s clear that up.

Put simply:

• Bases are systems

• Tables are a thype of thing

• Records are rows in tables

• Fields are columns within each row

• Linked records are how you connect tables

• Views are the views you build on top of them

• Forms are how you collect outside data cleanly

• Automations are “if, then” actions powered by connectors

• Interfaces sit atop everything to give your data an app home

Here’s all that in a handy visual:

3. How to set up Airtable for Product Teams

You have two paths:

1. AI Agent

2. Templates

I recommend the AI agent. I find it pretty good:

I recommend starting with your product roadmap:

From one simple prompt, you’ll get an input of yor roadmap:

You can then start to leverage automations, like an email when a new issue is created:

Then you can start using things like the Kanban board to actually manage the work:

The final part is forms. You can create a project intake form for stakeholders, for example:

Then you’ve got a working basic product system in Airtable! Get to work getting the most out of it:

4. Airtable vs the competition

Compared to the competition, here’s where Airtable stacks up:

The short of it:

5. How to get Airtable free with the Bundle

1/ Upgrade to a yearly paid or founding member:

Subscribe now

2/ Head to bundle.aakashg.com to redeem your codes:

Get your bundle now.

3/ Use that code in your checkout window on airtable:

Airtable Checkout

6. Putting it all together into Aakash’s stack

Here’s how I’d put together all the tools in my Bundle into a proper stack:

• Front-end Prototypes: Magic Patterns

• Full-featured Prototypes: Bolt.new

• Design Inspiration: Mobbin

• Video editing: Descript

• Dictation: Speechify

• Research: Dovetail

• Tasks: Linear

• Evals: Arize

I hope this helps supercharge your work with AI. $27,467 in products for $150.

See you next week,

Aakash

I want to add more phenomenal tools to the bundle. If you work at a great tool company, please hit reply to this e-mail. I’d love to chat.

Share

They ran into the same round at both companies:

“Both had technical round where they asked me about my AI depth. How transformers work, that kind of thing.”

So then I went looking online for resources on the topic.

To my surprise, I didn’t find anything:

So then I went about the process of creating the guide for you: learning the questions they ask, solidifying the topics you need to learn, and understanding what a winning answer is.

Today’s Post

1. The technical questions PMs are actually asked

2. 🔒 The technical concepts PMs need to know

3. 🔒 What a winning answer is

4. 🔒 AI tools to practice

Subscribe now

Two quick notes before we get into today’s post

Getting AI PM Interviews

While today’s newsletter is about cracking the technical rounds of AI PM interviews, if you’re still stuck on getting interviews, join my free webinar tomorrow morning, 9AM pacific:

Join the Webinar

Our Coaching

If you want to go further than this newsletter on technical topics, you should consider the AI PM course Prasad and I teach with guest instructor Ankit Virmani:

The next cohort starts on August 3rd. Join us:

Join the Cohort

1. The Technical Questions PMs are Actually Asked

12,397 AI product jobs were posted in the US in the first 6 months of 2026.

That’s a lot of jobs, and that means there’s a lot of variability. Here’s the lowdown on reports of real questions from real companies:

• OpenAI: Define hallucinations in LLMs, You have a model with 10x the capability at 10x the cost. What do you do with it?

• Anthropic: How would you handle hallucinations in a generative AI model deployed to users?, How would you define a “redline” for a model capability?

• Google DeepMind: What AI agents have you built to make yourself more productive?, Design a high-level system for Gemini responding to a user query

• Nvidia: Explain how GPUs are used in deep learning applications, Design a RAG system on Nvidia infrastructure with latency, relevance, and cost trade-offs

• Perplexity: Explain how RAG works

• Glean: Have you built any end-to-end agentic systems?

• Microsoft: Explain trade-offs in model selection, Walk me through the system design of an AI-powered experience

• Amazon: Tell me about a time you had to go several layers deep into an ML system or AI infrastructure to diagnose and solve a problem

• Meta: Whiteboard an evaluation framework, plus human-in-the-loop feedback systems and prompt chain prototyping

I’ve combined those reports into an infographic for you to practice with:

👇 Now that you understand the questions, it’s time to learn the core concepts.

Then, I’ll cover how to structure the learnings into winning answers. And end with some AI tools to practice (worth the cost of the subscription themself).

This post was written entirely by hand:

And leverages insider knowledge from my coaching 150+ candidates over the past year.

Read more

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

Brought to you by: Arize

Trace, evaluate, and fix your AI agents before broken behavior ships to users.

Improve your agents

Today’s Episode

Eric Ries is the Lean Startup Guy. He was an early call from Dario Amodei when he was founding Anthropic.

Dario could afford that call and make the connection. But what about you?

I’m making that call for you today. Eric spent the last few years creating his next movement after Lean Startup, Incorruptible, and I get the low down:

• How to structure your company with a trust

• Governance structures you can copy

• And the underlying culture you need

He goes behind the scenes to show how he wrote Incorruptible with his AI tool Solveit and live screenshares his writing workflow with Claude.

Check it out:

Apple Podcasts

Spotify Podcasts

🎊 To celebrate, I’m giving away 10 copies of Eric’s book Incorruptible:

All you have to do is fill out this short survey on PM salaries.

🆓 I’m doing a free webinar Thursday on getting AI PM interviews. Join me:

Join the FREE Webinar

The next cohort of my LandPMJob program starts August. If you want my 1:1 coaching, sign up.

Today’s Deep Dive

I’ve written up the PM’s Guide to Governance:

1. The four dimensions of Incorruptibility

2. The Costco case study to become Incorruptible

3. How to structure your next company (if you’re a founder)

Plus, two bonus sections:

1. [Bonus 1] How Eric Ries Uses AI to write

2. [Bonus 2] The Lean Startup methodology in the AI era

1. The four dimensions of Incorruptibility

If you start studying the world’s most lasting companies, the first thing you’ll learn is that:

Most spectacular startup collapses were governance failures, not product failures.

So how do you avoid them? Four things:

2. The Costco Case Study

Let’s talk about Costco for a second. It’s one of the best performing companies of all time:

How has Costco had such longevity? Well, it actually starts with disappointment. You see, Costco was co-founded by a guy named Sol Price.

Sol originally created FedMart. It became a very successful company, but he gave control to investors. Eventually, the board wanted growth while Sol would do things like tell customers to go buy from a competitor down the street if they had a cheaper price.

So, the board locked Sol out of his own company. It didn’t work well for them. By 1982, FedMart was in liquidation.

Sol, and his mentee Jim Sinegal, didn’t want to follow in FedMart’s footsteps. So when they built Costco (a merger of their two companies), they built a governance fortress, with staggered board, poison pill, fiduciary hierarchy, and a cultural fortress:

The cultural fortress is perhaps the hardest to capture part. How do you build an Incorruptible culture like Costco?

Eric takes inspiration from Jim Sinegal:

Compromising is "literally like taking heroin," one small price increase, stock goes up, you get hooked. Now it's baked into the forecast, so you have to do it again next quarter.

You have to avoid “financial gravity.”

3. How to structure a company from day one

Dario Amodei called Eric when Anthropic was still figuring this out.

Here’s the advice you can get from that call - without the access:

Seed Stage

1. Convert to a Public Benefit Corporation. Write the corporate mission directly into the charter. It is a legal structure that gives directors permission to pursue purpose even when it conflicts with shareholder value.

2. Designate a mission guardian. Someone with the authority and responsibility to keep the company on course. At Answer.AI, the founders hold that role.

Series A-B

Like Anthropic created and defended a Long-Term Benefit Trust, you will have to do the same.

Investors may want to change the terms. Hold the line.

Series C+

At larger companies, a mission lock vehicle can take the role of mission guardian:

This is what Answer.AI, Eric’s company did, and what Anthropic did.

Just remember, structure isn’t everything.

So that covers it on our short tour through governance for PMs. Now, two bonuses.

Bonus 1: How Eric Ries uses AI to write

The thing to avoid in the AI era is being called slop. How does Eric do it?

The book Incorruptible was written inside Solve It, the AI platform from Answer.AI. The approach is fundamentally different from prompting.

How it works:

1. Three block types. Notes (raw markdown you write), prompts (LLM instructions), and code (Python). You mix and match freely.

2. Context control. The LLM only sees messages above the current one. You choose what it knows.

3. Direct editing. If the model writes something wrong, instead of saying “try again,” you replace what it said with what it should have said. The model learns from the corrected version, reducing the mistake-correction cycle.

4. The writing style guide. A document loaded into every session listing phrases to avoid, patterns to follow, and the author’s specific voice characteristics. The generic AI gets banned before it starts.

Eric then took it to the next level. He had 600+ test readers leave structured comments, which the tool helped him organize and do months of daily turns on.

Bonus 2: The Lean Startup methodology in the AI era

No. But you have to understand what it actually is.

Build, Measure, Learn is a principle for operating under uncertainty. Its essence is:

• Learn as quickly as possible

• Turn every iteration into feedback

• Shorten the time between building, measuring, and learning

• Repeat faster than everyone else

The framework has been used on power plants, cancer therapies, even the long-term stock exchange. It works in the AI era too.

What matters is whether you can go faster than the convention in your industry.

If everyone else in your space takes 18 months between major iterations and you take 12, you have the advantage.

Claude Code is emerging as a standard partly because Anthropic’s product organization has unparalleled velocity.

Shipping velocity does more than accelerate learning. It compounds trust through two effects:

1. The cooking effect. When a company is shipping consistently, getting better visibly, you start to feel safe building on top of their platform. Your app will magically get better over time because their platform keeps improving.

2. The standardization effect. Once enough developers choose a platform, everyone else has an incentive to do the same. Enterprise customers sign multi-year contracts. Partners build around it. Hiring shifts toward it. Over time, the platform becomes the default choice.

And how does Claude Code ship so fast?

And that’s how we come full circle.

Get Transcript

Finally, here’s a one-sheeter you can print on governence:

Where to find Eric Ries

• LinkedIn

• Incorruptible

• Answer.AI / Solve It

• Long-Term Stock Exchange

• Lean Startup

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

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

“I don’t prompt Claude anymore. I have loops running. My job is to write loops.”

That was Boris Cherny, the creator of Claude Code.

Peter Steinberger, who built OpenClaw also said something similar on X:

These two are arguably the best AI product builders in the whole world. So I’ve had a big question on my mind:

That’s the question we answer today.

Today’s Post

Today’s post is the result of 5 weeks of testing loops to figure out what the alpha really is for PMs:

1. What a PM loop actually is

2. 🔒 The 6 pieces of a great PM loop

3. 🔒 12 heavily tested PM Loops you can steal

4. 🔒 A skill to generate 6-piece loops that work easily

5. 🔒 How to maintain loops over time

Subscribe now

Before we get into the long deep dive, here’s a quick summary of what you need to know.

1. What a PM loop actually is

Loops fit the PM work you repeat:

• Weekly business review

• Weekly Sprint prep

• Monthly user interview themes

These are the types of things you may have built into Relay.app or Lindy before. Now they can run straight out of Claude Code or Codex.

Real Loop Example

Here’s an example. Most PMs in B2B companies only hear about sales deals in a Quarterly Review with sales. So they can’t react in time.

That’s the perfect use case to set up a Sales Monitoring loop with a simple prompt to Claude Code or Codex:

That’s it. That’s what a basic PM loop is. You’ll get a basic AI output like this:

I find that you don’t really ‘get it’ till you do that. So go build a loop now (use my prompt above or your own) before we go any further so you really grok it.

What should be a Loop

Ask yourself 4 questions. If the answer to all 4 is yes, you can make a loop:

Here are my suggestions:

That’s everything you need to build basic loops.

2. The 6 pieces of a great PM loop

What you’ll quickly run into with a basic loop like those in section 1 is:

1. The output could be better

2. It doesn’t have memory

After months of testing to solve these 2 problems, I’ve learned each loop needs 6 elements:

Read more

Google is so different. They have case interviews and specific rounds, but literally nowhere else I have interviewed has them.

That’s one candidate I’m coaching, who’s interviewed at leading companies like Roku, Amazon, and Snapchat.

And the craziest part? Google’s PM interviews have just been updated.

I talked to 6 people: 1 candidate who has recently completed the Google process, 1 currently in the process, 2 current hiring managers, and 2 former hiring managers.

Then, I sat down with one of them, Gal Eshel, to put together the ultimate sequel to my Google PM interview guide.

Gal spent six years as a PM at Google and now coaches PMs through the process.

Today’s Post

We’ve recorded a full video for you all (complete with mock interview):

And written up an even more comprehensive deep dive:

1. What the 2026 Google PM loop actually looks like

2. How to crack the Google PM interview

   • What Googleyness actually is

   • The 1 skill that decides the offer

   • How to nail “Tell Me About Yourself”

3. How to crack Google AI PM roles specifically

4. A “Google Hiring Manager” AI agent you can use to practice

Subscribe now

Do you want deep coaching to crack Google? The fourth cohort of my Land PM Job program goes through everything:

1. PM Interviews and Job Search Mastery ($6,000 value)

2. AI PM: From Evals to Prototyping ($3,000 value)

3. PM Fundamentals + Leadership ($2,000 value)

Join the Cohort

Here’s the most important takeaways from the article in an infographic. Save it. Print it:

Share

1. What the 2026 Google PM loop actually looks like

Everyone disagrees about what is tested in the Google PM Interview. I wrote a post saying they ask vibe coding interviews, then a Google Director commented they don’t. Some took this as proof I was wrong.

So I went and asked a Google AI PM Director, Satyajeet Salgar. Here’s what he said:

We used to put all PMs through a standardized interview process. Now, there are two ways into Google PM.

One is through that standardized process, which has no vibe coding round, and is followed by a team matching process.

The other is a specialized process, where the hiring manager has control of the process. Hiring managers in my org have used these rounds for vibe coding.

Turns out we were both describing real loops. Google’s standard process has no vibe coding round. But hiring managers control specialized loops, and some have used those rounds for vibe coding.

As for the standard process?

For instance, you know what you won’t encounter? Technical interview questions. I myself got a technical round in 2017: “How would you improve page load of Google Search?”

But that isn’t asked anymore.

I’ve got my hands on the official Google PM prep materials being distributed right now. Let’s take a close look:

Read more

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

Brought to you by: Hyperagent

Turn your recurring PM work into reusable agents now.

Start here

Today’s episode

If you’ve got an enterprise Claude subscription, you have access to one of the most powerful tools ever invented.

But at the same time, many PMs report using AI but not feeling any more productive.

Here to help is Jyothi Nookula. She just used Claude Code to beat 30 teams at her company’s hackathon. She’s getting productivity out of Claude that’s measurable.

And today she breaks down everything.

I’ve done plenty of advanced guides on PM OS, Team OS, and company OS. I’ve also broken down Claude Code for non-technical PMs and the Claude ecosystem.

Today’s piece is the first principles, bottoms-up explanation of everything Claude:

Spotify

Apple Podcasts

Want to Become an AI PM?

Let me help get you there live. The upcoming cohort of the Land PM Job program includes a full AI PM course:

Join Us

Newsletter Deep Dive

As a thank you for having me in your inbox, here is the full workflow, aligned to the five layers of the Claude Ecosystem.

1. Models - when to choose which

2. Surfaces - when to use which

3. Knowledge - how to build it out

4. Integrations - how to manage them

5. Agents - the one’s to build

   • How to build an AI Chief of Staff

Subscribe now

The 5 Layers of the Claude Ecosystem

Claude has a dizzying array of features and surfaces. You can think of the Claude ecosystem as a stack of 5 layers:

1. Models at the bottom. These are the raw intelligence.

2. Surfaces sit on top of models. These are things like the the web app, desktop app, mobile app, or Chrome extension you actually type into.

3. Knowledge sits above that. This is your projects, skills, memory, and custom instructions.

4. Integrations comes next. Your MCP connections to Slack, Drive, and Jira; plus, your own files.

5. Agents and orchestration sit at the top.

You want to move up the layers one by one.

Layer 1 - Choosing the right model for the job

This is the first skill: knowing when should you which of the three models.

Here’s what Jyothi recommends:

She walked through each in detail:

Haiku is your speed machine. Cheapest, fastest, best when you need volume over depth. Triaging a pile of docs, tagging, quick classification, generating fifty variants of something. In the episode, Jyothi runs her scheduled automations on Haiku specifically to save tokens.

Sonnet is where ninety percent of PM work lives. The best ratio of quality to cost. PRDs, user research synthesis, competitive analysis, stakeholder briefs, roadmap thinking. Start here for almost everything.

Fable/Opus for the high-stakes reasoning. Genuine trade-off analysis, contradictory research, long-horizon planning where you need second and third order implications.

Layer 2 - Picking the right surface for the task

So you know the model. Now, what surface? Here’s what Jyothi recommends:

• Chat on the web is your thinking-out-loud surface.

  Quick questions, a smarter replacement for a Google search.

• Desktop is where the real work runs, because it can touch your files, your connected systems, and your scheduled tasks.

  Cowork and Claude Code both live here.

• Mobile is for kicking off a run and checking on it from a walk.

• Chrome Plugins is for computer use.

  Competitive research, pulling from sites agents cannot otherwise reach, and user testing where you tell Claude to behave like a real person and report back where your product confused it.

• Claude Design for decks and prototypes.

Upload your brand guide, a Figma file, or a GitHub link, and everything it generates matches your company’s colors instead of looking like a generic template.

It also has a real visual editor built in. You can mark up a slide, drop a comment the way you would in Figma, and Claude executes the edit (as shown in the above image).

In the episode, Jyothi mentioned that she built a CEO-level deck in the hour before a meeting that looked like it took her all day. For a quick design, Claude Design is enough.

• Claude Code when you want a clickable app that real users can poke at and give you feedback on.

Layer 3 - Build out your knowledge base

This is the layer Jyothi says PMs underinvest in most, and I agree.

It’s what turns Claude from a generic chatbot into something that actually knows your world.

We need to cover three pieces: projects, skills, and memory.

Projects are your folders

You want one project per role. A project should hold all your context through memory and custom instructions.

If you want to run three different things at once, make three projects, each carrying its own context as project instructions.

Skills beat prompts

A prompt is a one-time instruction. A skill is a saved playbook Claude reaches for on its own.

Jyothi’s customer interview synthesis skill is the template to steal. It has a when-to-use trigger, a checklist, and numbered steps: inventory the inputs, extract observations with citations so it hallucinates less, use the speaker’s own words, and keep behavioral observations separate from stated preferences.

Since early this year, skills can be multiple files. If your main skill file is one giant markdown doc pushing past 500 lines, you’re doing it wrong.

Two more things Jyothi flagged:

1. Write your skills yourself. Her read of the research: AI-written skill files underperform human-written ones. Draft with Claude, then layer in your domain knowledge, your template, your structure.

2. Update on drift. Review skills when your domain changes or when output quality slips. Declining output is your cue that the playbook went stale. Quarterly is a fine default.

The highest-value skills to build first: prioritization, PRD writing, customer interview synthesis, and turning support tickets into Jira issues.

Memory is the compounding piece

If you’re using projects in Claude web, then tell the project all of your context and tell it to commit to memory:

Here’s my context. Commit this to the project’s memory:

1. My role:

2. My company:

3. Our strategy (attached doc)

4. Our OKR attainment last quarter (attached doc)

5. The big features we’re going after:

If you’re using Claude Code, grab this memory system I built for you.

It captures as you work, with every claim traced to its source and conflict markers.

Layer 4 - Integrations

MCP is how Claude connects to the systems your work lives in. Slack, Drive, Jira, Gmail, your CRM, your analytics.

Two types:

1. Remote MCPs are the ones you click to connect. Customize, connectors, hit the plus, authenticate. Done.

2. Local MCPs run on your machine. This is how Jyothi’s chief of staff knowledge base works. We’ll build it below.

Which ones do you need? Look at the tools you already touch daily. Email, calendar, Slack, meeting transcripts, your Jira board, your analytics.

Jyothi’s most exotic connection at work: NVIDIA’s BioNeMo model for drug prediction.

Layer 5 - Build out agents to do things for you

There are three parts to agents that you want to build:

1. Automations that kill your busywork

2. Self-improving agent loops

3. A chief of staff

Let’s talk about each.

Agent Category 1 - Automations that kill your busywork

Start with Cowork. You need the desktop app and at least a Pro plan, around twenty+ dollars a month, and you can schedule Claude to run on its own.

Jyothi recommends a few standing automations:

• A morning brief at 9am wired to Calendar, Gmail, Drive, and Jira. It pulls the day’s meetings with attendees and attached docs, the inbox threads that need her, and the Jira items on her plate, then hands her the top three things to focus on.

• An end-of-day wrap at 5pm that reads the morning brief, checks what actually happened, and previews tomorrow. What shipped/missed, what is new.

• A standup brief on the active sprint. Done since yesterday, in progress, blocked, new, and sprint health, rendered as a clean dashboard.

Two things to know before you build.

These automations only run when your laptop is on, so time them for when you are actually working.

And this quietly replaces the Relay, Lindy, Gumloop, and n8n flows where one failed node kills the chain.

Agent Category 2 - Self-improving Agents

This is the ceiling, and it is where Jyothi’s hackathon win came from.

She went up against 30 engineering teams and won with one idea from an Anthropic blog post (Adversarial agents).

The idea comes from an older AI technique called GANs. One AI creates something. A second AI tries to find everything that's wrong with it. The feedback goes back to the first AI, which improves its work. The cycle repeats until the output is good enough.

Now apply the same idea to agents. One agent builds, another looks for flaws, and the first agent keeps improving until it passes your quality bar:

The promp to kick it off looks like this:

Agent Category 3 - Your AI Chief of Staff

Connect Claude to your sources and it can read your calendar and act on your Jira. What it still does not have is a model of your world.

It does not know who your allies are, which relationships are load bearing, or which message is too sensitive to send before you loop someone in.

A chief of staff closes that gap.

Jyothi built a personal agent that reads every meeting transcript and learns her org over time.

After one meeting, chief of staff told her to make a particular colleague an ally because they were strong in an area she was trying to grow into.

Another time it stopped her before she sent something and told her who to inform first. That’s not possible with just connectors, you need a knowledge graph of your working life.

How to Build It

The shape is straightforward:

• A context KB, structured into folders for people, meetings, documents, company, your priorities, and the patterns it spots over time.

  

• A set of extraction templates so a person profile captures how they operate and what they care about, and a document gets its metadata, key points, and relevance to you.

• Then an MCP server on top, so you can talk to the whole thing from the desktop app instead of digging through files.

Feed it so it compounds

The system is only as good as what you put in it. Rank your inputs by signal density and feed the richest first.

• Meeting transcripts are the richest source. Pushback, reactions, who went quiet, what got decided. Wire an automation so every new Granola or Google Meet transcript that lands in your inbox auto-logs to the KB.

• Key strategy docs you write and receive.

• Slack threads, where a surprising amount of real context lives.

There is a fair objection here - Log every email and every transcript and you will burn tokens.

That’s true.

The payoff is a knowledge base rich enough to connect dots you would have missed, and you can throttle it to only the sources that carry real signal.

Get Transcript

[Bonus] Takeaway

Here’s the things to remember to use Claude better. Print it out:

Share

Where to find Jyothi Nookula

• LinkedIn

• NextGen Product Manager

Go Deeper

1. To get access to my AI tool stack - Airtable, 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.

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

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: Arize

Trace, evaluate, and fix your AI agents before broken behavior ships to users.

Improve your agents

Today’s Episode

Meng To is one of the world’s leading AI design thought leaders, with 170K+ followers on X and 16K+ on Instagram. He told me something wild:

I barely use Claude anymore.

What does he find is more powerful? Codex. So today’s episode is a masterclass in designing with Codex.

I’ve covered the Codex harness, PM use cases, and design basics already. Today’s episode goes the next layer deeper:

I hope you enjoy the episode as much as I did.

Apple Podcast

Spotify

Want My Coaching?

You should know the story of Sourav Yadav from my Land a PM Job course. He closed 5 offers in 2 months and became Head of Product at Times of India.

I’m starting my next cohort next month. We’re teaching three courses:

1. AI PM ($3000 value)

2. PM fundamentals ($2000 value)

3. How to get a PM Job ($6000 value)

Here’s the syllabus:

This cohort features two 1:1s with me (first time ever).

So, what’s stopping you?

Apply now

Want a taste of the course? I’m putting on a free webinar on behavioral & AI PM interview mastery next Thursday. Sign up.

Newsletter Deep Dive

Now, thanks for having. me in your inbox. Here’s a complete guide to AI Design for PMs.

1. How to Setup Codex for AI Design

2. The AI Design workflow that works

Subscribe now

If you don’t have time for the full deep dive, here’s the most important takeaways.

Share

1. How to Set up Codex for Great Design

Codex is ChatGPT on Steroids

What makes Codex ChatGPT on steroids? Three things:

a. Context
b. Skills
c. Connectors

If you cover these correctly, you get a much more powerful harness for AI. So let’s briefly cover each.

1a. You need to build out great context

If you’re using my PM OS, you know this already. If you don’t, here’s what you need to do:

We recommend 1 folder per project, grouped under a single parent directory:

This works because you don’t have to re-explain yourself to AI all the time: what you do, what your company is going after, what your team’s product strategy is.

It all loads in for free.

Now here’s the trick: it’s a Goldilocks problem.

Too much undifferentiated context and the AI burns tokens figuring out what matters before it even starts the task you asked for.

Too little context and you spend forever iterating on the output when a bit more upfront context could’ve one-shotted what you want.

So get really good at managing that context. Even ask Codex:

1b. You need to enable it with the right skills

I’ve been talking about skills a lot. So you probably already know they are a lightweight MD of instructions. And you should have them for everything.

To design AI that’s not slop, you should know about this taste skill that has 60K+ stars on Github:

Also install the Playwright skill to take screenshots of UI for GPT to iterate on itself.

1c. You need to connect it to the right tools

You’ve heard about MCPs for the last year. Use all of the MCPs! PostHog, Linear, etc.

Designing for AI with Codex has two nuances when it comes to connectors:

1. You want to use plugins (not MCPs) to connect to Figma and Slack.

2. You also want to install ChatGPT Atlas so Codex can use computer use on websites for tasks that don’t have an API (eg browse LinkedIn).

How these three features come together

Context + Skills + Tools suddenly transforms your LLM into an agent harness that is much more powerful.

And two new Codex features make this more powerful than ever:

1. Codex Mobile sits inside your ChatGPT app and connects to whatever is running on your desktop, so you can check in on a build from a taxi or a coffee line.

2. The screenshot shortcut (cmd + cmd) lets you select any window and drop it straight into your current chat as visual context, no separate upload step required.

2. The AI Design Workflow to Avoid Slop

So now that you have the setup, here’s the workflow:

1. Plan with context

2. Build with the taste skill

3. Iterate with a human touch

It sounds simple but the power is in the nuance.

Step 1 - Plan with context

You’ve probably heard of plan mode. Use it!

The fastest way to lose an afternoon with Codex is to skip straight to building, since it commits to a direction within seconds and rarely doubles back on its own.

Plan mode forces a pause between your request and the AI’s first action.

Read that plan the way you’d read a junior PM’s spec before a kickoff. If something is missing, ask before approving. “Can we expand on this part” or “what if we add this constraint” costs you thirty seconds.

Give it the right context

Screenshots are the highest leverage form of context you can give the AI, more useful than a paragraph of typed description.

Two things are worth knowing here.

1. Simply select a window, hit the screenshot shortcut (Press both Command keys at the same time), and the image drops straight into your chat as the thing to fix or match.

2. If you have an app on different devices, run the app in a simulator, capture every screen in the flow, sign in, payment, editor, and hand the AI the full set so it can validate the design end to end instead of one screen at a time.

A screenshot tells the AI what you mean in one shot. A paragraph of description tells it what you think you mean, and those are not always the same thing.

Step 2 - Invoke the taste skill

The model matters less than the taste layer you give it. Use the taste skill from 1b and then look at the outputs.

Usually the skill will give you several - soft, brutalist, etc. If it doesn’t for whatever reason, prompt it:

Once you have a design you like, the next decision is output format:

• HTML is the fastest and most controlled option, the default unless you have a specific reason not to.

• Figma takes longer and assumes Figma fluency, but it’s the right call when a designer needs to pick up your file and keep iterating.

• Keynote or PowerPoint only makes sense when the final deliverable has to literally be a slide file someone opens in that app.

The rule of thumb is to keep your blast radius small. Every extra tool you add is a subscription, a login, and a context switch the AI cannot do for you.

Step 3 - Steer it mid-flow and iterate

One of the coolest features of Codex vs ChatGPT is once the build is running, you are not locked out!

You can steer mid-task, queue a follow up command while the current one finishes, or interrupt with new direction the moment you see it heading somewhere you didn’t intend.

So do that. And then iterate more on the AI output. The difference between slop and tasteful design is typically found in this final 20% of iterations.

And that’s it - now you’ve got design that isn’t slop!

Get Transcript

Downloadables to Take Away

1. Taste Skill - The Anti Slop Frontend Framework for Al Agents (60k+ stars)

2. The 15 tools running Meng To’s Al Workflow

   

Follow Meng Online

• Design+Code

• LinkedIn

• YouTube

• Aura

• X

Go Deeper

Tools:

1. To get access to my AI tool stack - Airtable, 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.

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

Podcasts:

1. How to Design with AI - YouTube | Spotify | Apple

2. How to Use Codex Like an OpenAI PM - YouTube | Spotify | Apple

3. The Ultimate Guide to ChatGPT Codex - YouTube | Spotify | Apple

Newsletters:

1. OpenAI’s Codex is the Best Way to Use ChatGPT

2. I spent 100s of hours building a PM OS for you

3. How to build product strategy in the age of AI

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

Refer a friend

Last month, your Claude setup worked perfectly.

This month, it feels like the AI is actively gaslighting you. It ignores your skills details and writes docs so lazy you end up rewriting them yourself.

If you’re like me, you find yourself scrolling through past chats, desperately trying to find that one version of a prompt that actually worked a few months back.

Where did it go? What skill version was it? Did I accidentally overwrite it when I updated my CLAUDE.md yesterday?

This is the exhausting reality of AI workspace drift.

When you don’t track your AI infrastructure, a single word shift can completely break your OS’s behavior. Top product managers are stopping this bleeding by moving their workspaces to GitHub.

Introducing Shubham Saboo

Shubham is a Senior AI Product Manager at Google and the mastermind behind Awesome LLM Apps - an open-source powerhouse with over 120 production-ready templates covering everything from multi-agent teams and MCP configurations to complex agent skills.

If his name sounds familiar, it’s because I recently wrote an entire breakdown piece on how his Github got him hired at Google. His repository has crossed an absurd 115,000 GitHub stars.

Today’s Post

Hannah Stulberg and Sidwyn Koh wrote an excellent GitHub 101 for non-engineers. My Ship Your First PR piece teaches the code PR workflow. Today, we are opening up the critical infrastructure layer that sits directly underneath both my PM OS and Team OS frameworks:

1. Three repos that cover 90% of PM work

2. The daily workflow: pull, branch, commit, push, review, merge

3. Four version control workflows for PM artifacts

4. The practice repo and your Monday move

Subscribe now

New to Claude Code? Quick glossary: skills are reusable instruction files for Claude Code tasks. CLAUDE.md is the persistent context file Claude reads every session. Eval criteria are scoring functions. These files change constantly. Managing them is what the rest of the piece covers.

If you’re new to GitHub entirely, I put together the web’s first guide on PM Githubs.

1. Three Repos, One PM

Imagine your laptop dies tonight. How will you access your important files?

You’ve got a CLAUDE.md. You’ve got skills. Maybe eval criteria, prompt templates, project configs. They’re scattered across your machine. Some in the PM OS folder. Some in project directories. Some are in Downloads because you grabbed them from Slack two weeks ago.

If you’re not careful, all of that effort goes down the drain. This is why you need GitHub repos. Here are three repos that cover your whole PM workflow.

You won’t need all three when starting. You only need Repo 1 if you’re just a beginner. Repo 2, when you have skills worth sharing. Repo 3, when you’re shipping code with the PR workflow.

Your Workspace (Repo 1)

This is your private workspace containing everything that requires your personal context. This is where your PM OS lives.

Inside this repository, you store your personal CLAUDE.md (pre-loaded with your specific stakeholder list, company strategy, and communication preferences), your private skills/ folder, and your autoresearch configurations. When you open Claude Code inside this folder, your PM OS architecture boots up instantly, making every single custom skill available on launch.

Why GitHub instead of just a folder on your machine?

Backup. Machine dies, you clone the repo on a new one. Back to full setup in 2 minutes. Same repo across machines, zero reconfiguration.

History. Every change to every file is tracked. When your CLAUDE.md was working better last month, you can see exactly what changed. When a skill breaks after a tweak, you restore the previous version in one command.

Phone access. Claude Code on the iOS app can read from your GitHub repo. You can start agents from your phone that read your CLAUDE.md and run tasks against your project files. Requires the files to be on GitHub, accessible from anywhere.

Your Shared Tools (Repo 2)

This is where your Team OS plugins live. It houses the skills, templates, and configurations that other PMs can fork, adapt, and run inside their own workspaces.

The core difference from your private workspace is simple: shared tools have all personal and company-specific context completely stripped out.

Hannah’s shared repo - her Team OS at DoorDash - has nested CLAUDE.md navigation files, shared skills (customer-call-summary, decision-log-entry, feature-launch-gate), analytics templates, and team context that any engineer, designer, or PM can query.

When her strategy partner started contributing, she cloned the repo and had the full team toolkit in 30 seconds.

On the public side, this category is exploding:

• Garry Tan’s gstack: 23 specialist skills

• Pawel Huryn’s pm-skills: 100+ skills across 8 plugins

• Carl Vellotti’s claude-code-pm-course: interactive Claude Code course

My Steal 6 Skills piece shows what shareable skills look like.

Your Projects (Repo 3)

These are projects you are currently working on.

PLANNING.md for the feature. Eval scoring criteria from the experimentation piece. The code. One repo per initiative because different projects have different collaborators and different lifespans.

When the project ships, the repo is the complete record of what was built, why, and how it was measured. PLANNING.md revisions, eval criteria updates, prompt iterations, tracked in the commit history.

The Decision Guide

How This Connects

Coming from PM OS? You already have the folder structure: skills, context library, templates. Git is what keeps that folder managed over time. The /upgrade-to-team-os command from the Team OS starter kit scaffolds the team structure around your existing PM OS, and it assumes your PM OS is already in a git repo. The setup in Section 2 gets you there.

Coming from Team OS? You know the architecture: shared context, shared queries, shared discipline. The GitHub mechanics underneath are what make it work. Team OS says, “push to GitHub so you have version control,” and “I’ve had to revert my own CLAUDE.md multiple times after changes degraded performance.”

The pruning workflow in Section 3 is exactly that revert process. Team OS’s Phase 2 (the team contributing shared skills via PRs) runs on the same PR workflow taught here. When Hannah’s strategy partner submitted her first PR, she was committing a skill change with a descriptive message, getting it reviewed, and merging it so the whole team got the update.

Team OS is the architecture. The workflows below are the plumbing.

2. The Daily Workflow

Seven steps. The same rhythm every time you change a PM artifact.

Every command works by talking to Claude Code in natural language. No git syntax to memorize.

Pull

Before you start working, get the latest version. If a teammate updated the shared repo overnight, you want their changes before you start editing.

Claude Code: “Pull the latest changes from main.”

Branch

A branch is your own copy of the files. Changes on your branch don’t affect anyone else until you merge.

Name it after what you’re doing.

Claude Code: “Create a new branch called improve/prd-reviewer-v7.”

For solo work on your private workspace, you can skip branching and work directly on main. Branching matters most when you’re sharing a repo with your team (Team OS).

Edit

Make your changes. Update the skill file. Add a line to your CLAUDE.md. Modify the eval criteria.

The actual work happens here.

Commit

A commit saves a snapshot of your work with a message explaining what you did.

The message matters. “Update” tells you nothing in three months. “Add behavior contract check to PRD reviewer” tells you exactly what changed and why.

Claude Code: “Commit my changes with the message: add behavior contract check to PRD reviewer.”

Commit after every meaningful change. Not after every keystroke. Not after a full day of work. After each change you’d want to be able to roll back to individually.

If you’re unsure, commit more often.

Push

Upload your commits to GitHub. Until you push, your work exists only on your machine.

Claude Code: “Push my changes.”

After pushing: backed up, accessible from other machines, visible to teammates if the repo is shared.

Pull Request (PR)

A PR says: “Here are my changes. Please review before they become official.”

For PM artifacts in a shared repo, the review is about quality, not syntax. Does this skill improvement actually produce better output? Does this CLAUDE.md change follow team conventions?

Claude Code: “Open a pull request.”

Write a short description of what changed and why. The CONTRIBUTING.md in the practice repo has a template.

For your private workspace, you can skip PRs and push directly to main. PRs matter when the repo is shared.

Merge

Reviewer approves. You click merge on GitHub. Your changes are now part of the official version. Delete the branch.

Working solo? Merge your own PRs. The PR still serves as a record of what changed and why.

Seven steps, same rhythm every time. Pull, branch, edit, commit, push, PR, merge.

Hannah’s GitHub 101 goes deeper on each step with screenshots and troubleshooting. Ship Your First PR applies this cycle to code changes specifically. The four workflows in the next section build on top of this rhythm.

🔒 Below, you’ll read:

• Loop Engineering for your workspace asset
• The exact repo structure Aakash uses
• Four version-control workflows that save hours every month (skill rollback, CLAUDE.md pruning, autoresearch tracking, eval criteria versioning)
• A practice repo you can fork today
• The PM GitHub starter kit

If you’re serious about building a long-term AI operating system, the rest of the guide is for you.

Read more

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

Brought to you by:

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

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

3. Pendo - The #1 software experience management platform

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

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

Today’s episode

I’ve written about building a PM OS and Team OS in Claude Code. They are my top two most popular pieces of 2026.

Today is the upgrade: a company OS that enables even CSMs at your company to ship to production.

And this isn’t theoretical.

Jiaona Zhang “JZ” is the CPO at Laurel - which raised a $100M Series C - and her company actually runs on a Company OS. They have run into the problems and kinks. They’ve ironed them out. Now, they’re showing what works.

JZ is not some “AI purist.” She has led product at Airbnb, Dropbox, Webflow, and WeWork. She’s an AI realist.

And in this episode, she doesn’t hold anything back:

• The Company OS that enables it all

• How PMs go from product idea to shipped feature with agents

• How she conducts AI PM interviews in this era, and how to ace them

This is one of the densest episodes I’ve ever recorded.

I hope you enjoy watching it as much as I did recording it.

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

Welcome to the web’s first guide for how product leaders can create a Company OS to accelerate Claude Code adoption across their org:

1. How to build your Company OS

   • How to spread AI adoption beyond engineering

2. The new role of the PM in an AI-native team

3. How to get hired as an AI-native PM

Subscribe now

1. How to build your Company OS

A company OS can unlock productivity across your organization. It takes the power of a concept like a PM OS beyond single PMs or product teams.

At Laurel, even CSMs are shipping to production.

Here’s how to build your own:

The architecture is simpler than you think

One GitHub repo. Every team in the company has a folder. Every folder maps to the activities that team does. Every activity has a skill file. The skill files go directly into Claude’s organization settings. Anyone who opens Claude already has the right skill loaded.

During the demo, JZ screenshared Laurel’s full GitHub structure live. Customer success, data science, design, engineering, finance, legal, marketing, all of it:

There are three layers to build your own.

Layer 1 - Start with ontology

PMs build the OS and then wonder why nobody uses it. They got the order wrong.

Start with the ontology like JZ. Map every function’s work to categories, then to tasks within each category. What should sales be doing? What should CS be doing? What should product be doing? This work map is what informs the folder structure. The OS is built from the ontology:

At Laurel, the ontology sits alongside the OS. For each function, it shows which activities should go up (more human time) and which should go down (automated away). For product, competitive analysis write-ups, stakeholder briefs, and research synthesis are in the “stop doing manually” column. Feature work, QA, and direct customer contact are in the “spend more time here” column. Color-coded. Visible to every leader.

This is the part most companies skip. They install tools before deciding what work actually matters.

Layer 2 - The skill file architecture

Once you have the ontology, build the skills.

A skill file is a Markdown document that encodes how to do a specific piece of work. Not just a generic prompt. A specific, opinionated guide that reflects how your company does that thing. How do you write a renewal email at your company? What does a good feature request look like when it comes from a CS rep? What questions do you ask before triaging a support escalation?

The skill file answers all of this. Upload it to Claude’s organization settings and it becomes available to everyone. The skill is called when needed. With this simple set up now one person’s best workflow becomes everyone’s default.

Layer 3 - The delivery layer

At Laurel, every customer facing team member gets a daily morning message in Slack. Calendar, meetings, check-ins, onboarding sessions, all surfaced. And embedded alongside each item, the skill to use. You have a renewal call at 10am. Here is the renewal skill. You have an onboarding session at 2pm. Here is the onboarding skill. The OS meets people where they already are.

How to spread AI adoption beyond engineering

When AI adoption is everyone’s responsibility, it is no one’s responsibility. The person who was going to build the CS workflow is also running renewals, handling escalations, and onboarding three new accounts. The workflow never gets built. Leads to a huge gap.

The fix ↓

Step 1 - Dedicate a person to it

At Laurel, this role is called AI Operations. One person, full-time mandate, whose entire job is finding efficiencies, building workflows, and spreading what works to every function.

JZ describes it as the new BizOps:

AI ops is the new BizOps. Before, BizOps were doing really meaningful things, but often it was very high level, all the different hats, a lot of like market level stuff. Now, if you repurpose this idea of having BizOps, which is really again a Swiss Army knife in many ways, to finding people who are insanely curious, tinkering with the latest technology, and relentless about finding efficiencies, that’s the DNA I really look for.

Laurel started with one person, Sasha. Within months, every other function wanted their own Sasha. That demand is how you get budget. You demonstrate value with one person, then let the pull happen naturally.

If you are reading this as a leader who cannot yet hire for this role, the person closest to it already exists on your team. They are the one who figured out the Slack automation nobody asked them to build. Find them. Give them the mandate officially.

Step 2 - Run a companywide hackathon

The assumption that blocks AI adoption in non-technical functions is simple: you have to be technical to build something.

One hackathon breaks that assumption faster than any training program.

Laurel ran a companywide hackathon at their offsite roughly three months ago. Every team participated. Not just engineering. The explicit goal was to show that anyone can build. When a Customer Success manager ships something in a day, the story spreads. That story does more for adoption than any top down mandate.

If a full offsite feels out of reach, a single afternoon works too. Pick one function. Give them four hours and a clear problem to solve. Keep a low bar, make it like even a working Slack automation counts. A prompt template that saves 30 minutes a day counts. The goal is the first win over the perfect solution.

Step 3 - Make the culture visible

Some companies have a value on a slide that nobody reads after the presentation is done.

Laurel turned their “unreasonable hospitality” value into a workflow. When a Customer Success manager has a check-in coming up and has not had an in-person touch with that customer in a while, the OS surfaces it. Pulls from Gong transcripts what the customer loves. Suggests the gesture. Handles the logistics. If you can see, now the value is not just a slide anymore.

That is the part most leaders miss. Culture spreads through systems that make the right behavior the default behavior. You do not need everyone to be intrinsically motivated to show hospitality. You need a system that makes it easy enough that everyone does it anyway.

2. The new role of the PM in an AI-native team

There is a version of this conversation happening on Reddit right now. A PM asking if their job is going away. Getting 200 replies, half of them panicked and other dismissive. Tbh, neither group is right.

The job is not going away. The shape of it is changing faster than most people want to admit.

Here is what the new shape actually looks like.

The captain model

Forget the old handoff chain. PM writes spec, sends to designer, designer sends to engineer, engineer sends back, designer says that is not what they designed. That loop is going down in AI-native teams.

The replacement is a captain model. Every feature has one person who owns it end-to-end.

The captain is whoever has the most important skill for that feature’s hardest problem:

• Engineering captain - Architectural changes, system overhauls, anything where the codebase risk is the biggest variable.

• Design captain - Interaction heavy features where the experience is everything and the engineering is straightforward.

• PM captain - Features where customer understanding plus business context is the hardest thing to get right. Empty states. Onboarding flows. Anything where the content and the user insight matter more than the code.

That’s the full model.

Two track product reviews

Speed without alignment is just running in circles. The captain model needs guardrails.

At Laurel, there are two tracks:

Track 1 - Fast.

Small features, single captain, end-to-end ownership. Goes through the Ask Devin reviewers Slack channel. An engineer reviews the PR. A designer checks if needed. No formal product review meeting.

Track 2 - Full review.

Radical changes to core user interactions, architectural decisions, system level thinking required. This is what JZ calls a product strategy review. “Are we sure this is the right direction for the whole product?” Plus a separate architectural review - “Will the system actually support where we want to go?”

The question most teams get wrong is which track a feature belongs on.

The test is simple. If the change affects a core user interaction that touches the whole product, it is Track 2. If it is scoped to one workflow and the hardest problem is execution, it is Track 1. Temporary initiatives, despite being a frontend and backend feature, was Track 1. A redesign of how Laurel surfaces time across the entire day would be Track 2.

I covered the mechanics of PMs shipping to production in my PM guide to shipping your first pull request. The captain model is what makes that shipping sustainable at scale rather than a one-off experiment.

As an ending note, I would say…

3. How to Get Hired as an AI-Native PM

Ask someone on your team if they use AI. Everyone says yes. Ask them to show you. That is where the answer changes.

There is a framework that cuts through the noise immediately. Four levels. Every person, every team, every company sits somewhere on this scale.

Level 1 - Chat mode.

You open Claude or ChatGPT. You type a question to get a specific answer.

This is AI as a slightly smarter Google. Most people are here. If you are closing the tab after every session and starting fresh next time, you are Level 1.

Level 2 - Workflow automation.

You stop doing a task manually and build something to do it for you.

A Slack automation that triages feature requests. A template that auto-populates from your CRM. A morning briefing that pulls your calendar and surfaces priorities. One workflow. That is the entry point. If you’re not familiar, I covered how to start building these in my AI Agents for PMs guide.

Level 3 - Building apps.

You identify something tedious enough to deserve a real tool, and you build an app.

Something with a UI, logic, and state. This is where builder PMs live. Mahesh Yadav broke down exactly how to get here in our episode on becoming a builder PM.

Level 4 - Shared apps and shipping to customers.

You are building things other people use. Your Customer Success team ships a feature. Your PM submits a PR that goes to production. You are in the full product lifecycle. This is where AI-native teams operate.

In most organizations, the engineering team is split between Level 2 and Level 3. Sales and Customer Success are mostly Level 1. Finance and legal are often at Level 0, which is not even on the scale.

The screen-share test

Here is how JZ uses this framework in practice. In every interview, she asks the candidate to screen share.

Within 60 seconds you know exactly where someone is. A Level 1 person has a bunch of Claude chat tabs open with one-off questions. A Level 3 person has a folder structure, a set of saved workflows, maybe an app they built last week.

Here’s the most important takeaways in 1 infographic:

Get Transcript

Where to find Jiaona Zhang

• LinkedIn

• Reforge

• Laurel

Related content

Podcasts:

1. How a VP Uses Claude Without Producing Slop - YouTube | Spotify | Apple

2. How to Build a Team OS in Claude Code - YouTube | Spotify | Apple

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

Newsletters:

1. I spent the last week building an OS in Claude Code

2. I spent 100s of hours building a PM OS for you

3. How to build product strategy in the age of AI

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

Refer a friend

Marty Cagan made the product operating model famous.

But if you look at how the top AI companies are operating, it is quite different:

• Anthropic engineers prototype hundreds of solutions and ship without ever consulting a product manager or designer.

• OpenAI’s new hot product Codex started with just two PMs, one designer, and about 40 engineers, collectively responsible for 10 to 12 distinct product surfaces. At any traditional company, each of those surfaces would get its own squad of 15 to 20 people.

• Cursor operates with 40 engineers, one PM, and scaled past 4 billion dollars in ARR faster than almost any company in history.

This new way of working is not the product operating model of old gen.

This new way is the “AI product operating model,” and over the coming decade, most companies will move to it.

Over the past three years, I have been working to define the AI product operating model. After 150+ podcasts - and countless deep dives on the topic - today, I’m ready to present everything.

And I didn’t do all the work myself.

Introducing Rohan Varma of OpenAI

I’ve partnered with someone at the epicenter of this revolution - Rohan Varma. He’s a Product Manager on Codex at OpenAI. Earlier, he was the first PM at Cursor. He also runs the top-ranked AI PM Certificate on Maven at Product Faculty:

I took it all the way back in 2024 and learned a ton. It’s great if you’re starting your AI PM journey. Use my discount code AAKASH550C7 to get $550 off:

Join the Cohort

Why This Matters

Recall what Sam Altman said in 2024:

We’ll see the first one-person billion-dollar company within our lifetimes, possibly very soon, powered entirely by AI agents doing what used to require hundreds of people.

It’s REALLY happening…

Matthew Gallagher built Medvi, and in 2025, he did $400M+ on his own. He has now hired his brother, and in 2026, they’re projected to do $1.8 billion.

Not to mention the crazy rise of OpenClaw: Peter Steinberger single-handedly built one of the most useful AI personal assistants and scaled it so massively that it became a household name worldwide is insane. Again, just one person with a bunch of agents.

If you showed these numbers to a VP of Engineering at any large enterprise, they’d tell you these companies are running on borrowed time. That you can’t sustain quality and growth at this scale without proper resourcing. And for most of the last 30 years of software history, they would have been completely right.

But something has changed massively in the past 3 years, and most organizations have still to come to terms with it.

Codex ran a hackathon with a large enterprise recently: the kind of company with thousands of developers and a mature engineering culture. They scoped a modernization project at 10 engineers, 12 months.

Two engineers with Codex completed it in JUST THREE DAYS.

So the question worth sitting with is:

Today’s Post

We have curated the full structural logic of how AI-native companies are organized: the people model, the process model, the tool model, the economic model, and what it looks like to start rebuilding in that direction from wherever you are today.

1. The Belief That’s Holding Companies Back

2. Inversion of Product Development

3. What EPD Looks Like Now

4. The AI-Native Workflow

5. The Real Problems You’ll Encounter

6. How to Start - The AI Leverage Playbook

Plus 4 downloadable resources, including: an AI Native Team Diagnostic Worksheet, an AI workflow decomposition skill, and more.

Subscribe now

1. The Belief That’s Holding Companies Back

Every decision your product organization has ever made traces back to a single belief:

Writing code is hard, and engineers are your scarcest resource.

Pull on that thread and watch how much unravels.

The org chart you’re running right now is an accumulation of the fossil record of every time your company ran into this belief - across people, process, and tools:

Let’s start with people.

The whole org is oriented around engineers. They’re expensive, so you can’t afford to waste a sprint building the wrong thing. So you hire layers to coordinate them: EMs, TPMs, scrum masters. You hire a PM to prioritize ruthlessly.

You hire specialists at every layer (QA, security, platform, data) because the work becomes too complex for generalists. Then you hire people to manage the specialists

Almost 30 to 50 percent of the total effort in any traditional team right now is pure coordination overhead.

Then move into the process.

Sprint planning exists to make sure engineers build the right thing before they start, because changing course is expensive. Backlog grooming exists for the same reason.

Code review exists because every human-written line needs another human to verify it before it touches production. QA, staging, feature flags, phased rollout, on-call incident response: every checkpoint exists to protect expensive engineering time from waste.

Finally, let’s talk tools.

The IDE is a precision instrument for one engineer writing code character by character. Jira exists to coordinate humans across a slow-moving pipeline where work takes weeks.

Daily standups exist because when work moves slowly, and dependencies are everywhere, people need regular synchronisation just to stay unblocked.

The question that should be sitting uncomfortably in the back of your mind right now: if you were starting your product organization from scratch today, with the tools available today, would any of this exist in its current form? Would you run two-week sprints? Write 30-page PRDs before a line of code is written? Hire dedicated QA? Staff each product surface with a squad of 15?

AI-native companies built in this era might be our best guide for what the answer looks like. And the answer, almost universally, is no.

That gap is precisely the opportunity and the threat hiding inside every product organization in the world right now.

🔨 How do you know whether your team is actually AI-native? We created a markdown diagnostic worksheet that you can complete yourself or work through with Claude/Codex. It will help you identify your team’s biggest bottleneck, assess your AI-native readiness, and map the operating model you’re running today versus the one you’ll likely need tomorrow.

Grab it here

2. Inversion of Product Development

When coding agents started appearing a few years ago, most engineering leaders filed them under ‘productivity tools’: the same mental category as a better IDE, a smarter autocomplete, a faster CI pipeline.

But the tools didn’t stay there. In just two years, they evolved through three distinct phases: autocomplete assistants like GitHub Copilot and Cursor Tab, to task-level CLI agents like Claude Code, to fully agentic systems like Codex that take complex work, iterate, and ship results on their own.

In a traditional product process, you build late. The build is expensive, so you front-load everything else: research, discovery, spec writing, design reviews, technical scoping, stakeholder alignment.

But when building becomes cheap enough that you can build first and evaluate second, this logic collapses. At Codex and Cursor, entire phases of the traditional SDLC have collapsed or disappeared:

• Code review as a separate stage? When agents verify their own work at the point of generation and humans review outcomes rather than line-by-line diffs, the traditional review process is redundant.

• Elaborate sprint planning? When building the wrong thing costs thirty minutes of agent time instead of two weeks of engineering time, you can afford to build first and evaluate second. Which is exactly what Codex does.

• The build/decide sequence? Completely inverted. The question is no longer “should we build this?” asked about a spec. It’s “ I had this idea based on XYZ. We built this - should we ship it?” asked in front of a working product that an agent put together overnight.

This one inversion changes the entire epistemology of how product decisions get made, because you’re no longer deciding based on reasoning about what something might be, you’re deciding based on direct experience of what it actually is.

🔒 That was the structural logic behind why AI-native companies are winning. Below:

• The exact way the PM, engineer, and designer roles are being rebuilt from scratch

• The complete AI-native workflow that replaces sprints and PRDs

• The full AI Leverage Playbook for wherever you are today (startup to enterprise)

+ 4 downloadable resources.

Read more

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