It’s not that people aren’t learning. There are more AI PM courses, YouTube breakdowns, and LinkedIn frameworks than anyone can consume. Most people I meet in this space are genuinely sharp.

I’ve sat across from candidates who could recite every AI concept correctly - RAG, evals, multi-agent architectures, and still couldn’t hold the room for 10 minutes on a product question.

That gap is what this series is about.

Here’s the uncomfortable part: there’s no rubric for AI PM interviews. Nobody’s handing candidates a checklist. The question types are inconsistent; the evaluation criteria shift by company. And if you’ve been practicing with random people on Exponent or paying “experts” who’ve never actually evaluated an AI PM candidate, you’re drilling the wrong thing.

So I built a rubric. I built it while at a previous company, where we were bringing people into an AI PM loop but had no standard way to evaluate them. I wrote the scoring guide. Versions of it are still in use today.

That rubric is what we used in this session. And last week, Pranav and Divya - two people from my own cohort - used it to score me.

They didn’t tell me they were scoring me until after I finished answering.

The Setup: A Dojo, Not a Lecture

Divya opened the session with one line: “Tonight is not a lecture. It’s a dojo.”

The agenda was simple - walk through the hiring manager checklist, watch a live mock with real probing, then break into pairs and practice. No slides. No theory. Just reps.

The question Pranav used to open my interview:

“It’s a lot easier in the AI agent world to copy each other’s features. You see it everywhere - Lovable, V0, Replit, all basically indistinguishable. What will you do when a competitor copies your features and offers better pricing?”

Simple question. Loaded with traps. And one which I will ask someone, that means I knew exactly what I needed to land, and still found places where a sharper interviewer could have taken me apart.

The Hiring Manager Checklist: What You’re Actually Being Scored On

Before the match, Divya walked everyone through the three dimensions every answer gets scored on. This isn’t a framework I invented for this session; it’s what interviewers at companies building real AI products are actually looking for.

Pillar 1 - AI Ecosystem Understanding: Do you know the landscape well enough to build something that matters? Can you identify what’s already been solved, who the key players are, and where the real whitespace still exists?

A strong answer: you know the difference between model providers, infra layers, and tooling. You understand open source vs. proprietary tradeoffs. You don’t pitch building a coding agent in 2025 like it’s a breakthrough.

Pillar 2 - AI Technical Concepts: Can you hold a real conversation with engineers without bluffing? Do you understand evals, inference tradeoffs, when to use RAG vs. fine-tuning, what hallucination actually means as a design constraint?

A strong answer: you explain these as product realities you’ve navigated, not vocabulary you’ve memorized. You’ve felt the pain of a 43% accuracy baseline and know what it takes to get to 55%.

Pillar 3 - Experience Building AI Products: Have you shipped? Or gone deep enough on a real project that you’ve uncovered secrets - things that surprised you, things that failed, things that only reveal themselves when you’re actually building?

A strong answer: specific metrics, real edge cases, UX decisions that built trust (citations, reasoning toggles, human-in-loop design), and a pricing philosophy rooted in value delivered, not cost of goods.

With that in the room, Pranav started the interview.

The Match - Round by Round

Round 1: The Opening

Pranav: “What will you do when a competitor copies your features and can offer better pricing?”

My play: I didn’t answer the question directly. I pivoted first.

“The journey of product differentiation doesn’t start when you’re defending your product. It starts when you’re building it.”

Then I walked through the product I built in my last role - an autonomous back office for M&A legal work. We narrowed the scope to a single vertical: merger and acquisition legal review. We handled every integration in that space - escrow platforms, law firm systems, Outlook, insurance agencies. By the time a competitor even thinks about entering, they’re already 6 months behind on integrations alone.

The principle: long horizon + end-to-end execution = moat that predates competition.

Why this move works: Interviewers don’t care about the question. They care about your product thinking. Pivoting to a concrete example you know deeply lets you demonstrate both at once. Once you create that tension - let me tell you what I did before, then I’ll answer what you’d do now - they stop tracking the question and start tracking your thinking.

Divya’s live score - Pillar 1 (AI Ecosystem): Strong. Disciplined scoping to one vertical is itself a signal. Generic is a death sentence in AI products, and he knew that.

Gap Divya flagged: He didn’t paint the competitive landscape before jumping to his story. Who else was in the M&A legal AI space? What were they doing wrong? What was the gap? When you skip the landscape and go straight to “here’s what I built,” the interviewer has to guess whether you’ve done your market research. Don’t make them guess.

Round 2: The Pricing Probe

Pranav: “Say inference costs drop 10x in a year. How does your pricing strategy change?”

My answer: “Inference is only a small part of our equation. We’re playing the value game, not the pricing game. A lawyer charges $1,000 for the same job we do for $10. Even if I drop to $1, the delta from the customer’s perspective is still enormous.”

I also named five features already in the pipeline, continuous learning, playbook encoding, and more, that would ship before a pricing change would matter.

The vulnerability I caught myself on, after the session:

“If Pranav had pushed harder - if he’d pointed out that a complex AI workflow runs thousands of model calls, not one - my inference cost isn’t $10, it’s potentially $1,000. A 10x reduction would matter a lot in that case. He didn’t catch me there. But a sharp interviewer would have.”

This is worth noting: catching your own holes in real time, unprompted, is itself a senior PM signal. It’s not a natural gift. It’s a practiced muscle.

Divya’s score - Pillar 2: Smart reframe. Value-based argument was correct. But the inference-call volume vulnerability was a real crack in the logic.

Round 3: The Technical Depth Test

Pranav: “What’s your affinity toward specific models? Any preference for the features you built?”

My answer - the buffet of models:

We don’t use one model. We use a routing engine that calls different models based on the task:

• Contract detection: Haiku - fast, cheap, doesn’t eat into TPM/RPM limits

• Reasoning and risk analysis: Opus 4 - worth the cost where accuracy matters most

• Anomaly detection: GPT-5.5 -best in class for that specific task

We started with 100–200 samples from in-house lawyers at a PE firm. Baseline accuracy: 43%. Target: 55%. We ran weekly permutations until we got there, then improved 10% month-on-month. At the time of this session, iterations are in the four digits.

When Claude Code launched, and everyone said “redlining is now commoditized,” we open-sourced our benchmark dataset and asked the question publicly. Claude Code scored 2.7 out of 5. We scored 4.6.

“Customers can copy our prompts. They can copy our UX. They cannot copy 4,000 iterations of evaluation.”

Divya’s score - Pillar 2: Strongest showing of the session. Multi-model routing with reasoning for each choice. Real eval cadence with real numbers. Public benchmark that turns a defensive claim into a documented moat. Would score this 8–9.

Gap flagged: Never addressed the open source vs. closed source decision. Why not Llama? In 2025, that’s a fair question, and “we chose closed” without reasoning is a missed chance to show ecosystem depth.

The Value-as-Product Principle

Also, I brought in a second use case here - certificate of insurance compliance for a property management company.

Before our product: 56% compliant. After: 92%. Zero manual steps in the workflow. Tenants email their insurance certificates → system checks coverage → human brought in only for exceptions → dashboard updated.

The principle I named: “We didn’t offer AI as a product. We offered value as a product.”

There’s a real difference. AI as a product means you’ve built a tool people have to come to. Value as a product means you’ve integrated so deeply into their workflow that the AI is invisible; the outcome is what they experience.

Divya’s score - Pillar 3: Strong on flywheel and impact. The NPS loop is real: contract uploaded → AI identifies risk → citations shown → reasoning displayed → lawyer adds their own reasoning → that reasoning feeds back into the system. Each iteration makes the product smarter and more locked to that firm’s thinking. A competitor isn’t just behind on features - they’re behind on months of encoded institutional knowledge.

Gap flagged: No fallback design. What happens when the AI is definitively wrong? In M&A legal, where a missed risk isn’t a bad recommendation, it’s a lawsuit - the responsible AI story is part of your moat. Audit trails, guardrails, human-in-loop not just for exceptions but for confidence calibration. Mahesh touched human-in-loop but didn’t connect it to the responsible AI argument. That’s the gap.

Round 4: Audience Q&A - The Hard Probes

Neha on data security: “M&A involves extremely sensitive information. How does the product prevent leakage?”

Three-layer answer: integration with an escrow platform so neither party’s lawyers have raw data access, on-premise hosting option for sensitive deals that can’t touch a cloud provider even under encryption, and a $60M insurance policy covering breach scenarios.

Specific. No hedging. No “we take security seriously.”

Mukul on the well-funded competitor: “Your answer assumes the competitor is a surface-level clone. What if it’s Google - equally funded, equally capable?”

“Google isn’t a law firm. They can’t iterate on M&A evaluations without access to M&A deals. And even if they ship the software, every law firm has encoded 6 months of their own reasoning into our system. To replace us, they’d need each firm to re-encode all of that from scratch. That’s the moat. Not the model - the accumulated judgment embedded in the product.”

This is the answer that separates candidates. Anyone can say “we have proprietary data.” Far fewer can explain why that data creates switching costs that survive even the best-funded competitor in the room.

The Sharpest Question of the Night - What Both Formats Usually Missed

After the interview, AK asked something that cuts to the heart of how people fail these loops:

“This question could have been answered completely without mentioning AI at all. How do you know which direction to take?”

My answer: “If you’re in an AI PM interview loop, the interviewer is looking for your AI-first thinking. You can answer a moat question generically, but you’ll be leaving a signal on the table. The title of the round tells you where to land.”

Then the line that matters most:

“The goal isn’t to have the framework memorized. The goal is for this to become subconscious - so when you’re in the room, you’re just thinking, not reciting.”

This is the entire game. The three pillars aren’t a checklist. They’re a lens. You do enough mocks that you stop thinking have I hit all three dimensions and start just... thinking about AI products well. The framework should disappear into your muscle memory.

Divya’s Honest Scorecard

What the Practice Pairs Showed

After the demo, participants broke into pairs with a version of the question: “There’s no moat in AI agents - everyone builds on the same models and it’s easy to copy. How do you build defensibility?”

Three things stood out across every pair:

The gap between knowing and doing is structural thinking under pressure. Most people understand what a moat is. Far fewer can build the argument from scratch, in 10 minutes, on a live call, with follow-up questions arriving mid-sentence. The ones who could had practiced. The ones who couldn’t had only read.

Personal examples beat frameworks every time. The strongest answers came from people who stopped trying to be comprehensive and started telling a real story, even a prototype story. One participant pivoted immediately to something they’d built in the course and walked through their own moat layers. It wasn’t polished. It was real. Interviewers remember experience. Frameworks they’ve heard before.

Your comfort zone is your trap. One pair went deep on AI concepts -model routing, evals, latency tradeoffs - but thinned out when pushed on business outcomes. Another was strong on pricing and value, but couldn’t go technical when probed on how they’d build the eval harness. Both are gaps. The checklist exists precisely because candidates naturally over-index on what they know best.

One more tactical thing Pranav shared from his own real interviews that most people aren’t doing: “I ask if I can share my screen, and I show a prototype. One interviewer asked how long it took to build. The whole conversation shifted. You stop explaining what you built and start showing it.”

The 5-Step Drill Before Your Next AI PM Interview

This is the actual prep sequence, not a reading list:

Read more

57% the real no. is even target these are one that we can track using internal slack and public channels.

That’s the percentage of people who complete this course and break into AI - a new role, a new product, a promotion, within 3 to 6 months of finishing.

Not 18 months. Not “eventually.” Three to six months.

I shared it quietly in our Week 0 welcome session last week with the 180+ people who had already committed. But I keep thinking about the people who weren’t in that room.

Why Most People Stay Stuck

They’re not stuck because they don’t know enough about AI. They know a lot. They’ve read the blogs, watched the demos, and followed the discourse.

They’re stuck because they can’t show any of it.

When a hiring manager asks, “What have you built?” - pause. When a product review asks, “How would you evaluate this in production?” - some non-sense response. When leadership asks, “What’s our AI strategy?” - some random terms(claude code/openclaw).

That pause is the gap. It doesn’t close by reading more or vibe coding your calendar app.

What the 57% Did Differently

They built things. Publicly. With structure. With people who had done it before.

By the end of Week 1, not week six, week one, you have a working backend in N8N(published as an endpoint), a frontend with Claude code on a real address www.mydomainname.com, something a real user can open in a browser. That’s production.

The weeks that follow are live workshops, every single one, built around real case studies you can walk into any interview or leadership review and actually talk through.

Week 1: AI problem framing, your first intelligent agent, vibe coding foundations, prompt engineering, building and connecting N8N backend to Claude code frontend, live in production that 100 users can use.

Week 2: RAG, Agentic RAG, Knowledge Graphs, custom knowledge connectors. The architecture underneath every real AI product.

Week 3: Evals, KPIs for AI agents, benchmarks, red teams. The stuff that separates people who’ve shipped from people who’ve only prototyped.

Week 4: Multi-Agent AI, MCP, orchestration, tools, connectors - Azure AI Foundry Labs.

Week 5: Pricing, GTM, MOAT, fine-tuning with PEFT, learning loops in Claude Code.

Week 6: Pitch Day. You present. With something you built.

Woven through all of it: a PRD built incrementally, a GitHub that fills week by week, a resume updated as you learn, stories you can tell because you lived them.

The Real Cost of Waiting

Those $30 courses teach you the AI of 12 months ago. By the time you finish, the gap between you and the field is wider, not smaller.

We tracked this. Completers were 20 to 30% faster at hitting their goals than people who dropped off. That’s 3 to 4 months of salary. A promotion cycle. In AI right now, that’s a much higher cost that you will pay.

What’s Happening Right Now in Cohort 9

First real class starts this week. Welcome session is done - if you missed it, you missed introductions and logistics. The building starts now.

Mentors inside the cohort from Salesforce, Walmart, NYC OTI, American Express, AT&T and more. Mahesh is in every class live on board with real examples and workshops. Slack community, office hours, a Build in Public framework that turns your weekly work into a public portfolio.

57% of people who’ve done this are already somewhere new because of it.

The next cohort isn’t until winter.

Join Cohort 9

If something is still holding you back, book a quick call with Team Mahesh
Happy to help you decide clearly.

Book a Call

But once class starts tomorrow, we will close completely until August.

How do I take what I’m building from a quick prototype to something in actual production?

How do I develop the technical muscle to solve real AI problems, not just describe them?

How do I build things that drive impact for my company - not just impress in a blog post or a demo?

These aren’t beginner questions. These are the questions people are asking in 2026, after two years of hype, after reading the blogs, after taking the LinkedIn courses. And they’re still stuck at the same place, knowing about AI but not knowing how to do it.

That gap is exactly what this cohort is built to close.

What We’ve Changed

Every class is a live workshop with a real case study - the kind you can walk into a hiring conversation or a product review and actually talk through. I’m in every class.

What we build this cohort:

• Backend and frontend, deployed by the end of week one, you have something live on a real domain that a real person can use. That’s not week six. That’s week one.

• Evaluation frameworks: knowing whether your AI feature is actually working in production, and adding the required observability across cost, latency, and sanity. We do that.

• Orchestration and memory: the messy problems that separate people who’ve read about AI from people who’ve shipped it, and we will show what still is not working and needs to be fixed.

  Learn more

PRDs, Frameworks to choose, execute, and price AI products, case studies, decision docs: artifacts you can show hiring managers, customers, or your own leadership.

Why Most Courses Don’t Actually Get You There

Here’s a question I get asked constantly: Why spend $3,000 on a cohort when I can learn the same thing on Udemy for $30?

Most courses are built from aggregated information that’s already 12 months behind when published, and another 6 months behind by the time you finish. By the time you’re done, you’ve learned the AI of last year.

We studied this. People who completed our course were 20 to 30% faster at achieving their goals - landing a new role, launching a product, getting to the next promotion.

That difference translates to real money. Three to four months of delayed wages. Six months of missed promotion cycles. In AI - where the window is right now - that delay costs far more than the course itself.

The $3,000 isn’t the investment. The delay is.

Reading This After May 9th?

You didn’t miss the course. You missed the welcome session, mostly logistics. Classes begin next week. You can still join and hit the ground running.

The cohort runs May 9 through June 20. Seven weeks. I’ll be there for all of it.

Check here

Maven’s 15-day guarantee means you have two weeks to decide if it’s right for you.
If not, full refund.

See you in class.

P.S. We are left with last few seats ( shh.. check the above link to get discount ;) )

Last issue in the series. And the one that ties everything together.

Five issues in: you have ground truth, accuracy metrics, a Triple-H framework, a model selection rationale, and a validated LLM judge. That’s a complete eval stack.

Now, what do you actually do with it as a PM?

The gap between having evals and leading with them.

Here’s what I see from PMs who have built solid eval frameworks but still struggle in interviews and leadership reviews:

They present dashboards. They don’t make calls.

A helpfulness score of 58% goes into the weekly update. The VP asks, “Is that good?” The PM says, “We’re working on it.” Two weeks later, 61%. Same question. Same answer.

That’s not eval-driven leadership. That’s eval-enabled reporting. And the difference shows up immediately when someone asks: “ What’s your plan to move that number, and by when?

The weekly eval review - the meeting most AI teams skip.

The teams that move their metrics fastest have one thing in common: a short weekly ritual where the eval numbers drive the conversation, not just appear in it. Here’s what it looks like:

• 5 minutes: where are our northstar and L1 metrics vs last week? Any movement above or below 5%?

• 10 minutes: for the metric that moved most - what caused it? Not a guess. A hypothesis with evidence from the eval outputs.

• 10 minutes: what are we changing this week - prompt, model, RAG config, eval criteria, and what metric do we expect to move as a result?

• 5 minutes: what’s the launch gate status? Are we on track for the next stage threshold?

That’s a 30-minute meeting. The output is one decision and one prediction. Next week, you check whether the prediction was right. Over time, the team gets better at knowing what actually moves the metrics and stops guessing.

Why quarterly targets don’t work for AI products, and what does.

Most product teams set quarterly OKRs. For AI products, that cadence is too slow. Your model behaviour can drift meaningfully in two weeks. A prompt change can tank helpfulness overnight. A data shift can change your recall score without anyone touching the code.

Weekly targets with monthly

checkpoints are the right cadence for AI eval goals. “Improve helpfulness by 20% over the quarter” breaks down to roughly 5% per month, which breaks down to a weekly conversation about what’s actually moving and why.

That granularity is what lets you catch drift early, course-correct fast, and walk into a leadership review with a story, not a dashboard.

The CV line this series helps you write:

“Improved agent helpfulness by [X]% after launch by introducing [RAG / RLHF / prompt tuning] - measured against a Triple-H framework with weekly eval reviews and staged launch gates.”

That single line tells a hiring manager everything: you set a target, built a measurement system, ran a team process, and moved the number. That’s the complete AI PM story.

Here is the flashcard:

WATCH THE FULL SESSION

Session: How PMs Should Really Evaluate AI Agents (Not Just “It Looks Good”)

Includes the full Northstar metric framework applied to a live agent with the weekly review structure walkthrough.

That’s all 6. The complete eval stack - from ground truth to Northstar metrics in six issues.

If any of these made something click, the Agentic AI PM Certification (May 9) goes much deeper - live labs, real agent builds, and all of this applied hands-on with feedback.

Lastly, the cohort is all set to start, and only last 7 seats remain.

Last issue: model selection is a PM decision- here’s the 30-minute framework.

This one: once you’re ready to scale your evals, the biggest shortcut, and the trap hiding inside it.

Here’s what bad LLM-judge automation looks like in practice.

A team ships an AI agent. It’s performing well internally. They automate their evals using an LLM judge - it’s fast, cheap, scalable. Metrics look green. Confidence is high.

Three weeks after launch, customers start flagging wrong outputs. The team digs in. Their judge was agreeing with outputs the domain expert would have rejected - 28% of the time. For a month, they’d been optimizing their agent against bad feedback.

The problem wasn’t the automation. It was that nobody measured the judge before trusting it. They skipped the one test that would have caught this, and built an entire optimization cycle on top of a broken signal.

The three places LLM judges fail - that precision/recall won’t always catch.

• Domain specificity: a general LLM judge doesn’t know your business logic. It may correctly identify that an answer is fluent and relevant, and completely miss that it violates a compliance requirement only your legal team would catch. Your ground truth must include domain-specific edge cases, not just general quality.

• Confidence miscalibration: LLM judges are often overconfident on ambiguous outputs. They’ll score a borderline answer as a clear pass when a human expert would flag it for review. Watch for outputs that cluster suspiciously around 90%+ scores, that’s usually a sign the judge isn’t discriminating enough.

• Distribution shift: a judge validated on last month’s outputs may degrade as your agent evolves. Re-run your judge validation every time you meaningfully change your agent or your prompt. Precision and recall aren’t a one-time check.

One thing that actually improves judge accuracy: better prompts.

Most teams give their LLM judge a vague rubric - “score this on helpfulness from 1-5.” The judge has no idea what 3 means versus 4. Neither do you.

The fix is the same as Triple-H: binary questions. Instead of “is this helpful?”, give the judge: “Does the response include the specific contract clause the user asked about? Yes or No.” One question. One answer. Measurable.

The more specific your judge’s criteria, the higher its precision and recall will be. Vague rubrics produce vague judges. Precise criteria produce precise ones.

Here is the flashcard:

▶ WATCH THE FULL SESSION

Session: How PMs Should Really Evaluate AI Agents (Not Just “It Looks Good”)

Includes a live walkthrough of running an LLM judge, measuring its precision/recall, and the exact prompts used.

Last issue next: Setting Northstar Metrics - how to turn your eval framework into goals your team can actually build against.

Book Call

She manages IFRS16 audits - basically making sure every lease obligation shows up correctly on the balance sheet. Her team was manually going through hundreds of contracts every quarter. No extra headcount. No budget for a vendor tool. Just her and a pile of PDFs.

I told her I could build something for that.

She was skeptical.

40 minutes later - working app. Upload a contract, click Analyze, get structured key terms extracted and formatted for the audit. Live URL she could share with her team that afternoon.

No code written. 3 prompts. 3 tools.

That’s what I walked through live in one of our previous Friday session, and this post is the full breakdown so you can do the same.

TL;DR AI can now run tasks autonomously for 10+ hours. Building is no longer a developer’s job. In this post: why 2026 is different, the exact 3-prompt workflow I used to ship a working app live, and a framework for figuring out what to build. Plus the best Q&A moments from the session.

Let’s get into it.

Why 2026 is the year you have to build (not just plan)

We started with a question that I get challenged on a lot:

“Mahesh, I thought these models can only predict the next word. How can AI actually build things?”

Fair question. Here’s the short answer:

• 2023: LLMs could predict next words. Good at chat. Terrible at multi-step tasks.

• 2024: Reasoning models (chain-of-thought) let AI plan before it acts. Better, but still limited to 1–2 minute tasks.

• 2025: Long-horizon capabilities started unlocking. Jobs that took humans 15 minutes, AI could now do in hours.

• 2026: Claude Opus 4.6 can now run a task for 10+ hours with a 50%+ success rate.

The key insight? The time horizon is doubling every 4 months. (Source: METR benchmark)

That’s why Anthropic used parallel Claude agents to build a full C compiler. That’s why OpenAI used Codex to write ~1M lines of code. That’s why Cursor ran a background agent for 25 hours straight to build a design tool from scratch.

This is not theoretical. It’s happening now.

What this means for your job (honest take)

CEOs are falling over each other claiming AI writes X% of their code. The real number? Around 26-27% of production code is AI-written today. It was 22% just one quarter ago.

That trend line is steep.

But here’s the nuance most people miss:
AI-assisted ≠ AI-generated ≠ AI-autonomous. Those are three very different things.

What’s actually changing in teams:

• Senior engineers are becoming Agent Orchestrators - 40–50% productivity gain

• Junior engineers are seeing lower leverage (15–25% gain), and their roles are being cut first

• A new role is emerging: AgentOps - the person who monitors, trains, and governs your agents

For PMs specifically, the news is good. PM demand is at a 3-year high with 7,300+ open roles trending up 20%. AI PM roles specifically? 688 open roles paying $286K–$569K.

The PM role is evolving from: Spec Writer → Constitution Writer → Agent Orchestrator

Engineering is evolving from: Code Writer → Output Evaluator → Agent Director

The only 3 technical concepts you need to understand

Before we got into building, I gave everyone a quick grounding, because you can’t prompt agents well if you don’t understand what you’re asking them to build.

Frontend = the restaurant. What the customer sees, touches, and orders from.

Backend = the kitchen. Messy, complex, where the real work happens.

Database = the accounting system. Every order, every transaction, stored so you can query it later.

That’s it. Front-end, back-end, database + SQL to query it. If you understand these three things, you can prompt any AI tool to build anything. The agents figure out the rest.

The 3-prompt build: how I built a working AI product live

The example I used: a lease compliance tool for IFRS 16 audits.

(If you’re not in finance, IFRS 16 is a recent update that requires companies to report all their lease obligations. Most companies are drowning in contracts, manually extracting terms. Classic AI-solvable problem.)

Step 1: Generate the frontend with Claude Code

Start with a PRD (Product Requirement Document). You can write one yourself or just ask Claude to generate it from your meeting notes.

Then in Claude Code, attach your PRD and use a prompt like: “Build a functional interactive prototype that demonstrates the core product experience, covers the main user journey end-to-end, includes UI states (loading, empty, success, error), keeps the design minimal and modern.”

That’s it. Claude Code reads your PRD and generates a complete working frontend. In my case, a lease portfolio dashboard with contract upload, analysis tabs, and a playbook section. All from one prompt.

Step 2: Connect to Supabase (your database)

Once your frontend is ready, you need real data behind it. Add Supabase as a connector in Claude Code (it’s just a search + authenticate flow in the Connectors directory).

Then prompt Claude Code to:

• Create the database tables (e.g., contract_playbook)

• Seed it with dummy data

• Wire up full CRUD operations so the frontend reads/writes in real time

Everything syncs automatically. No SQL you have to write yourself.

Step 3: Build the backend agent in n8n, connect via webhook

This is where the AI magic actually lives. n8n is a no-code/low-code backend tool — think of it as your messy kitchen, except you build it by connecting visual blocks instead of writing code.

For this build, I created a multi-agent workflow:

• Webhook trigger: receives a contract PDF + user intent

• Extract from File: converts the PDF to readable text

• Orchestrator Agent: detects intent, identifies contract type (NDA vs MSA vs lease)

• Contract Playbook Agent: fetches rules from Supabase, filters by contract type

• Key Term Extraction Agent: uses contract text + playbook rules to extract structured JSON output

• Respond to Webhook: sends it back to your frontend

The bridge between frontend and backend? A webhook URL. n8n gives you a URL. You paste it into Claude Code with: “Send a POST request to this webhook URL when the user clicks Analyze.” Done. Frontend and backend now talk to each other.

Step 4: Deploy with Netlify

Add Netlify as a connector. Prompt Claude Code to deploy. It handles build settings, environment variables, CI/CD automatically. Publish your n8n workflow. You now have a live public URL.

Total prompts used: 3. Total coding I did: zero.

Watch the full session

What should you actually build?

A useful framework here comes from two axes:

Y-axis: Cost of errors - What’s the consequence if the AI gets it wrong? (Low = minor inefficiency. High = legal liability or reputational damage.)

X-axis: Type of knowledge - Does this task require explicit documented information, or tacit human judgment?

Start in the low cost of error + explicit knowledge quadrant. That’s where compliance tools, document summarization, structured data extraction, and reporting tools live. Low risk if it makes a mistake. High structured information available to train it on. Easy wins.

As you build confidence, you move toward higher-stakes problems, and that’s where the real moat is.

Q&A highlights

“Why n8n instead of just building the backend in Claude Code?”

Great question that came up live. The short answer: debugging. When your backend fails (and it will), n8n shows you exactly which node broke, what the input was, and what the output was. With Claude Code-generated backend code, debugging becomes an engineering exercise - and that’s where most beginners give up. n8n removes that barrier. Once you’re comfortable, you can always export the n8n JSON and ask Claude Code to write the equivalent backend code, so it’s not either/or.

“What about building inside organizations that restrict AI tools?”

This comes up every session. My advice: learn on n8n first. It’s open, cheap, and extremely well-documented. Then whatever internal tool your org allows - Azure AI Foundry, AWS Flow, Vertex Agent Builder - is basically a clone of n8n. The concepts port over directly. The time you invest learning n8n will transfer immediately. Claude Code is also getting adopted broadly inside organizations, so that’s a safe bet to learn.

“What is AgentOps exactly?”

Think of it as the operations layer for your AI workforce. You’ve built 5 agents. Now someone needs to make sure they’re secured, running correctly, monitored for quality week over week, able to flag problems and bring in humans when needed, and continuously improving. That full loop - that’s AgentOps. It doesn’t exist as a defined role yet. Which means if you start building this capability now, you’re early.

“What’s this ‘harness’ concept I keep hearing about?”

The harness is everything around the model: the knowledge layer, memory/signals, tools it can use, and guardrails. Before 2026, if you wanted to build an AI product, you built all of that yourself. That’s what took 2 years. Now, with the Agentic SDK from Anthropic, the harness comes with the model. You define input, output, and where your knowledge lives. The framework handles embeddings, retrieval, evaluation loops, guardrails, all of it. That’s the biggest disruptor of 2026.

Key takeaways

Three things I want you to walk away with:

1. Start building. Code is becoming a solved problem. Building today means learning by doing, and that’s the fastest way to move.

2. Learn Claude Code + n8n. These are the two tools that make full-stack AI products accessible to non-coders. Claude Code for frontend and orchestration, n8n for backend workflows. Both have free tiers and good tutorials.

3. Build something you’d actually use or sell. If you can show someone a working product in 4–5 hours - that’s the job security, the income multiplier, the leverage that matters in 2026.

Watch the full session

The full session recording - including the live build where you can watch the app go from a blank folder to a deployed URL in real time - is linked below.

Watch here

See you next Friday.

One question before then - what's the one problem in your work right now that you keep thinking "someone should build a tool for this"?

Reply and tell me. Best answers could become the next session.

Last issue: how to make subjective AI output measurable using the Triple-H framework.

This one is about the decision that happens before any of that - choosing what powers your agent in the first place.

The conversation most PM teams aren’t having.

Here’s what model selection usually looks like in practice: an engineer Slacks you and says “We’re thinking of using GPT-4o, thoughts?” You say “sounds good.” They build.

Six months later, costs are three times what you projected, latency is killing the UX, and a competitor just shipped the same feature on DeepSeek R1 at a fraction of the price.

The problem wasn’t the model. The problem was that nobody defined what “right” meant before the choice was made. And that’s a PM failure, not an engineering one.

Model selection is actually three decisions, not one.

Most teams treat it as a single call - which model do we use? But it’s three separate decisions that require three different inputs:

• The capability decision: can this model actually do what we need? This is where context window, retrieval accuracy, and task-specific benchmark scores matter. You don’t pick based on the model’s general reputation, you pick based on its performance on your specific task type.

• The infrastructure decision: where do we host it, and what does that mean for our team? A 2-engineer startup running GPT-4 through the OpenAI API and a 20-engineer enterprise running the same model through Azure are making very different bets on reliability, security, and cost structure.

• The trajectory decision: what does this model look like in 12 months? AI shifts every 3–6 months. The model you choose today should be one you can migrate away from without rebuilding your entire eval stack. Lock-in is a product risk, not just a technical one.

Most PM-engineering conversations only address the first. The second gets handled ad hoc. The third rarely gets discussed at all.

How to actually use leaderboards, the part nobody explains.

The leaderboard mistake: going to a site like artificialanalysis.ai and sorting by the top overall score, then picking that model.

The right approach: filter by your task type first. A contract extraction agent is a retrieval and Q&A task. Sort the leaderboard for retrieval performance specifically - not overall intelligence. The top model on the general leaderboard may rank 6th on retrieval. That’s the model you were about to choose.

Then cross-reference with Azure AI Foundry (if you’re going enterprise) or the provider’s own benchmark docs. Screenshot the comparison. Put it in your requirements doc. Now, when your VP asks why you chose Model X over Model Y, you have an answer that isn’t “the engineer suggested it.”

The two screenshots every PM should have before model selection:

1. Leaderboard filtered by your specific task type (retrieval, Q&A, reasoning, tool use)

Read more

Issues 1 and 2 covered ground truth, accuracy, precision, and recall - the quantitative side.

This one is about what to do when “correct” isn’t a yes/no answer.

Here’s the problem with subjective AI output.

You ask three lawyers what the indemnification clause means. You get three different answers. One says your agent’s response is great. One says it’s missing the insurance component. One says it’s too verbose. All three are right, and now you can’t measure anything.

That’s not an evaluation problem. That’s a definition problem. And the fix is to turn subjective opinions into objective questions.

What actually happens when you skip this.

Most teams ship without a Triple-H framework. They launch, get customer complaints, and then do what one founder told me last month: they “fixed the one thing the customer pointed out.” Three weeks later, another complaint. A different thing. They fix that too.

This is reactive evaluation. You’re letting customers find your failure modes for you - which is the most expensive way to build a product. Your CAC goes up, trust erodes, and you never have a clear picture of whether you’re improving or just patching.

The teams that ship well do it differently. They define what “good” looks like before a single customer touches it. Then they measure against that standard systematically - not because a complaint came in, but on a schedule.

How to build your question bank - the practical version.

Here’s what the process actually looks like, not the theory:

• Start with one domain expert, not three. Consensus is a later problem. First you need one clear, documented standard.

• Give them 5 real outputs from your agent. Ask them to mark what’s wrong - not rate it, just mark it. The marking becomes your question.

• Convert every complaint into a binary question. “Too verbose” → “Does the response stay under 150 words?” “Missing the insurance detail” → “Does the response include the insurance component?”

• Run 10 more outputs through those questions. If your expert can fill the yes/no columns in under 5 minutes, your questions are well-formed. If they’re pausing to think, the question is still subjective - rewrite it.

• Add questions as you learn. Your question bank should grow every sprint. Every customer complaint is a new question.

The launch gate mistake most teams make.

Teams set a helpfulness threshold - say, 60%, and then don’t know what to do when they hit 58%. Do they ship anyway? Wait another week? Ship to a smaller cohort?

The answer:

your launch gates should have three levels, not one.

Internal alpha (team only) → Helpfulness > 40%

Beta (1–5% of users) → Helpfulness > 60%, Honesty > 70%

General launch → Helpfulness > 80%, Honesty > 85%, Harmlessness < 5%

Each gate unlocks the next stage. Engineering always knows exactly what they’re building toward. And you always know where you are - instead of making a gut call at launch time about whether 58% is “good enough.”

Here’s the flashcard:

▶ WATCH THE FULL SESSION
Session: How to Set Evaluation for AI Agents & Scale Them

If you want to see how these ideas play out with real examples, the full session walks through it step by step.

Learn more

Last issue: “it looks good” is not an evaluation - ground truth is the foundation.

This one: once you have accuracy, why is it still not the full picture?

Here’s a scenario I walk through in almost every eval session.

A lawyer tells you a contract has 10 key terms. Your agent extracts 12. All 10 of the lawyer’s terms are in there - plus 2 extras. Your accuracy on the correct terms is 100%.

Is your agent good? Not as good as you think.

Those 2 extra terms are false positives. Your precision is 10/12 - 83%. The agent is cluttering the output with information the expert didn’t need. In a legal context, that erodes trust fast.

Now flip it: your agent only extracts 8 of the 10 terms, and gets those 8 exactly right. Accuracy on what it found: 100%. But it missed 2. Recall is 8/10 - 80%. The agent is underfetching - silently leaving risk on the table.

Why this matters in practice: accuracy tells you whether what you got is right. Precision tells you whether you got too much.

Read more

We had a really good session last Friday - on Cracking technical rounds for AI roles using vibe coding. A lot of you showed up, cameras on, and the Q&A at the end was the highlight of the session.
Sharing the key takeaways here for those who missed it (and for those who want a refresher).

What’s actually changed in the last year

Between March 2025 and now, three things happened quietly but decisively:

One - AI coding agents went from “good for prototyping” to writing production-level code. Tools like Claude Code are now being used by PMs to send actual pull requests. Not a joke, not hype.

Two - New models ship every single month now, including coding-specific ones. There’s even a model focused specifically on catching security vulnerabilities in AI-generated code.

Three - CEOs are coding. Sundar Pichai submitted a CR at Google in 2026. Satya Nadella went on stage and built a live app at Microsoft Build last year. If CEOs are doing it, your manager is expected to. And if your manager is expected to, so are you.

The conclusion? The Builder PM is the new PM. Your PM skills (UX, execution, business thinking) are still the foundation. But now you need to layer on the ability to build.

Vibe Coding vs Velocity Coding - what’s the difference?

People mix these up, so here’s the simple version:

Vibe Coding = you describe what you want in plain English, and an AI tool builds it for you. No coding knowledge needed. You iterate with more English prompts until you get what you want. Tools: Lovable, V0.dev, Bolt, Replit, Google AI Studio (which is free, by the way - good starting point).

Velocity Coding = you’re working inside an existing codebase. This is where most companies actually are. Nobody’s going to hand you a blank slate at Intuit - they’ll hand you TurboTax. Velocity coding tools help you understand existing code, add features to it, and move fast. Tools: Cursor, Claude Code, GitHub Copilot, Codex.

Agent Builders = if you want to build your own custom agents (like one that reads your emails and creates tasks automatically), this is the category. Tools: n8n, Make, Zapier, AWS Bedrock Agents, Azure AI Foundry, OpenAI Agent Builder.

The recommendation: master one tool in each category. One vibe coding tool, one velocity coding tool, one agent builder.

The 4-Layer Skill Stack for Builder PMs

Think of it as a pyramid you build from the bottom up:

• Layer 1: Product Thinking: Problem discovery, user understanding. Your existing PM bread and butter.

• Layer 2: AI Literacy: Understanding models, embeddings, RAG, fine-tuning. Knowing enough to evaluate, price, and design AI products.

• Layer 3: Agent Design: Tool use, memory, loops, orchestration. How agents actually work.

• Layer 4: Vibe Coding: Rapid prototyping with AI coding assistants. The top of the stack, and where interviews are now testing you.

Most PMs have Layer 1 down. The gap is Layers 2, 3, and 4.

Watch the Full Session

The contract analysis case study - how a vibe coding interview actually works

In the session, we walked through a real case study that hiring managers use. Here’s the setup:

70% of consumers sign contracts without knowing what’s in them. Small businesses are uncomfortable, and enterprises spend too much time reviewing contracts and slowing down their sales cycles. Build an AI agent that identifies risk in a contract before signing, and extracts key terms after.

Before jumping in and building, the right first move is to ask clarifying questions. Participants in the session asked great ones:

• Can I see a sample contract to understand complexity?

• Are we building for consumers, SMBs, or enterprises?

• What’s the acceptable accuracy threshold - are we aiming for 70-80%, or lawyer-level precision?

• What does success look like - time saved per contract? Number of contracts processed?

These questions aren’t just good PM hygiene. They show the interviewer you’re not going to build the wrong thing.

Once scoped (enterprise only, NDA/MSA/employee agreements, 70% accuracy is acceptable), you build in iterations:

Iteration 1: Basic app - upload a contract, extract key terms (indemnity, liability, payment terms), flag risks. Get the core functionality working.

Iteration 2: Add human-in-the-loop - let users edit extracted values, add AI explanation for how it arrived at each risk. This is where you’re showing you understand trust-building in AI products.

Iteration 3: Add a metrics dashboard -

track contracts processed, clauses found vs. not found, time saved per contract. This is where you land your PM skills inside the prototype itself.

What hiring managers are actually looking for:

• Do you understand the tool landscape?

• Can you build a working prototype and talk about it in PM terms?

• Do you know the path from prototype to production? (Security, SOC2, GDPR, red teaming, scaling)

Tips to succeed + mistakes to avoid

Do this:

• Break down the problem before touching any tool

• Build iteratively - functionality first, then trust/transparency layer, then metrics

• If you get stuck on a bug during an interview, don’t spend 30 minutes debugging. Say “assume this is built” and keep moving. Land your product skills.

• Write detailed prompts - role, goal, instructions, guardrails. This shows prompting maturity.

• At the end, lay out your roadmap: “if I had more time, I’d add X, Y, Z”

Avoid this:

• Jumping straight to building without scoping

• Writing a two-word prompt like “build me a contract app”

• Getting sucked into the code tab and becoming a developer for 30 minutes

• Only prepping with product frameworks and ignoring the build altogether

Q&A highlights from the session

Q: Can you use an iterative prompt approach - start small, instead of giving a huge prompt at once?

Yes, but in an interview context, a more detailed initial prompt signals prompting maturity to the interviewer. If time is short, set that expectation out loud and trim to the top 2 items in each section (role, goal, instructions, guardrails).

Q: Do interviews have a tool preference?

Generally no strict preference, but companies often buy a license for a specific tool (like Bolt or Lovable) and will ask you to use that. If you have your own subscription, most interviewers are flexible - just talk to them.

Q: Does the success metric for the agent need to tie to the metrics dashboard?

Yes. Don’t build an agent and not measure it. If you can’t build the dashboard in time, say so and describe what you’d track. Losing that layer hurts you if your competitor in the interview loop included it.

Q: Which tool category best supports continuous learning?

Vibe coding tools don’t really support continuous learning pipelines. Velocity coding tools have some capability but it’s limited. Agent builder tools (n8n, AWS flows) are the right category for that - but this opens up a big ML/infrastructure conversation that’s risky to get into during an interview. Unless specifically asked, don’t go there.

Q: Is tracking hallucination rates possible inside the prototype itself?

Hard to do well in real time. The practical answer: build the dashboard with a hallucination metric placeholder, flag it as an open item, and describe to the interviewer how you’d measure it (LLM-as-a-judge is one approach). Don’t lead with it, but don’t ignore it either.

Q: Why reverse-engineer an existing product instead of building something fresh?

Because reverse engineering gives you a target. If you build from scratch, you’ll settle for “good enough.” If you’re rebuilding something like LegalZoom or Legora, you know exactly what the finished version looks like, and you’ll discover what vibe coding can and can’t do in that context. That gap is exactly what you need to understand as a Builder PM.

Q: I’m a complete beginner. Where do I start?

Start with Lovable. Pick a product you’ve worked on before or one you use every day, and try to rebuild it in 2 days. You’ll quickly find out what works and what doesn’t. Write it down. That list of limitations is as valuable as the prototype itself - it’s what you talk about in interviews.

Daily cadence: 30 minutes reading, 30 minutes planning, 1 hour building. Do that for 2 months and you’ll be in a fundamentally different place.

Your next steps

Pick one tool in each category and start building this week.

The path is: Lovable → Claude Code → (optionally) learn one programming language if you hit ceilings.

Watch the Full Session

YouTube:

What’s Next?

Early bird seats with 25% off are now open for our most in-demand, core program - Agentic AI PM Certification and if you’ve been thinking about stepping into AI PM, this is your moment.

Cohort 8 didn’t just “learn AI”, it created an army of builders. Over 70+ real AI products shipped. People didn’t just prepare, they became ready for the Q2 hiring and promotion wave.

Now, Cohort 9 is our only cohort for Q2 2026 - upgraded with the latest tools, workflows, and systems you actually need to become an AI PM or AI entrepreneur.

While most people are still thinking about it, you can spend May–June actually building, learning, and getting ahead.

If you don’t want to be left behind - this is your signal.

👉 Early bird seats are now live. Secure your spot.

Secure my spot

Starting something new this week - a 6-part Eval Flashcard series.

Evaluating AI agents is one of the most asked-about topics I get - in interviews, from engineering teams, from people building their first agent. And it’s also one of the most misunderstood.

One card per issue. The mistake, the learning, the fix. No fluff.

Quick note before we get into it: this first flashcard is free for everyone. The remaining 5 in this series - plus the end-to-end guides, labs, and exclusive content coming soon - are for paid subscribers only.

If you haven’t upgraded yet - $25/month or $240/year. You don’t want to be one issue in and miss the rest. This is the content I’d normally keep for paid cohorts.

Give a gift subscription

Here’s something I hear constantly from PMs who’ve just shipped their first AI agent:

“We tested it. It looks good.”

That’s not an evaluation. That’s a feeling. And the difference between those two things is exactly what separates products that scale from products that surprise you the moment a real customer uses them.

What evaluation actually means: how good is your agent at doing what it claims to do - measured against a standard you defined before you shipped, not after something broke.

The foundation is three things:

• Ground truth — what does the correct answer actually look like? Defined by a domain expert, not your team’s gut feeling.

• A comparison mechanism — a way to check your agent’s output against that ground truth systematically.

• A repeatable number — accuracy, precision, recall - something your team can track week on week and improve against.

Without ground truth, you have no evaluation. You have demos. And demos are not the same as products that work reliably at scale.

Here is the flashcard:

▶ WATCH THE FULL SESSION

Session: How to Set Evaluation for AI Agents & Scale Them

The full walkthrough - live examples, Q&A, and the frameworks applied in real time.

Next issue: Precision, Recall & Why Accuracy Alone Misleads You.

Best,

Mahesh

P.S. The Agentic AI PM Certification cohort ( 25% off ) starts May 8 - this is core curriculum, not optional extras.

Learn more

Not in theory. Not with a list of 50 things to do. But with a real, honest no-BS plan.

Here’s everything we covered, including the live Q&A.

The Market Right Now (And Why It’s Both Hard and a Huge Opportunity)

AI PM jobs are growing fast - 40 to 50% year-on-year since 2023, and there are currently ~7,300 open PM roles in AI. The demand is real.

But here’s the thing nobody talks about: it’s taking companies 3 months to fill these roles. Not because the candidates aren’t smart - they are. But because hiring managers can’t find people who check all three boxes:

1. They understand how the tech actually works (ML literacy, agentic systems, RAG, etc.)

2. They can demonstrate that they’ve built something - not just describe it

3. They have the behavioral alignment to the company’s mission

The PM job market has gone K-shaped:

The K-shape is real. Which lane are you building toward?

• Top of the K → AI-specialized PMs, earning 35%+ premium. Talent shortage is real here.

• Middle of the K → Traditional generalists. This lane is disappearing fast.

• Bottom of the K → Builder PMs, platform PMs, domain-specific PMs. Also in demand, but fewer roles.

If you’re a generalist PM right now, this is your sign to move.

What Hiring Managers Actually Want (The Real Signals)

Mahesh talked to a lot of hiring managers and this is what they keep saying they can’t find:

LLM experience is now a top-3 hard skill in PM job descriptions. If you’ve taken anything to production using an LLM, you are three times more likely to get hired than someone who hasn’t.

They want demonstrators, not describers. When an interviewer asks “have you used RAG?”, they don’t want a textbook definition. They want to hear: what you built, where it broke, how you fixed it, and how many people are using it.

“AI fluency” is table stakes now. Knowing the difference between Claude Code and Copilot, understanding how these tools work - that’s the baseline. If you can’t talk about it fluently, you’re not getting in.

And the big one: most MAANG companies and startups now do a live prototyping round. They will hand you a one-pager and say: build this in front of us. Right now.

The AI PM Stack (What You Actually Need to Learn)

There are three layers, and all three are must-haves:

All three layers are must-haves. Most people only have one.

Layer 1 - ML Literacy (Foundation) Not coding. Literacy. Things like: how prompting works, how knowledge management works, how multi-agent systems work, RAG, fine-tuning. If you don’t understand the concepts, you can’t use the tools to their full potential.

Layer 2 - Prototyping with No-Code AI Tools Tools like Lovable, v0, Claude Code, OpenClaw. You don’t need to be an engineer. You need to be able to ship a prototype, break it, document what happened, and iterate. That’s the expectation.

Layer 3 - Agentic AI Patterns Understanding how agents work: tools, memory, planning, orchestration, evaluation. This is the frontier, and it’s what separates the PMs getting hired at the top of the K from everyone else.

On the question “do I need to code?” - Mahesh’s answer: Not yet. But you should be able to use tools like Lovable or v0 to build prototypes, and fix basic things in Claude Code. Nobody expects you to ship production features. But you can’t be a bystander anymore.

Proof of Work: What You Must Actually Show

This is the section that sparked the most conversation in the chat.

A certificate alone means almost nothing. A PRD sitting in a Google Doc means almost nothing. What matters is the proof of work hierarchy:

Certificate → Case Study → PRD → Prototype → Live Demo

The top of that pyramid is what gets you hired. A strong AI PM portfolio has:

• 1 working prototype - live, linkable, with real users (even if it’s 10 family members)

• 1 real PRD with trade-offs - AI-first, includes evaluation criteria, responsible AI, roadmap

• 1 AI system design write-up - shows you understand the architecture, not just the UI

The single most important rule: it must be live and linkable. If a hiring manager asks to see your work, you need to be able to open a browser and show them something that works.

A certificate alone doesn't get you hired. A live demo does.

Project ideas that actually get attention:

• AI RFP Automation Agent : automatically scans government RFPs, checks your company’s eligibility, and creates a first draft. One of Mahesh’s students built this and got promoted internally.

• AI Compliance for Accessibility : an agent that scans websites for EU/UK accessibility compliance violations, generates a report, and proposes fixes.

• Agentic OKR Tool : helps teams track and update OKRs through an AI workflow.

• Red Teaming Agent (Robinhood) : attacks other agents for security, safety, harmfulness, and generates a report card. (Mahesh is actively collaborating with USC’s AI Trust Lab on this one.)

And Mahesh’s note: don’t just build a chatbot in 2026. A basic RAG chatbot is table stakes now. Go a level deeper.

Watch the Full Session

The AI PM Interview: What’s Actually Being Tested

Here’s the full loop at companies like OpenAI, Meta, Google, and Anthropic:

AI Product Sense → AI Execution → Technical → Behavioral → Presentation/Live Prototype

And the pro tip that Mahesh kept emphasizing: behavioral is still 70% of the weight. Don’t neglect the fundamentals.

What AI Product Sense actually tests:

1. Does your AI actually solve the problem - and how does it differentiate from what already exists?

2. Is your product building trust or eroding it?

3. How do you evaluate AI output? (This one trips most people up.)

4. How will it make money? The ROI problem in AI is real, and companies want PMs who can think about GTM.

The 3-Week Roadmap

Three weeks. One goal: get interview-ready with something live to show.

Week 1 - Build your literacy Take ML fundamentals (DeepLearning.ai or MIT’s free course), analyze 5 AI products deeply, study one company’s AI strategy end-to-end, and learn the 6 interview formats. If you’ve done Mahesh’s cohort, you’ve already done this.

Week 2 - Ship something Build 1 prototype using Lovable or v0. Write 1 full PRD. Document what broke. Get at least 10 people (family, friends, colleagues) to use it and give you feedback. Then iterate. Build your portfolio page.

Week 3 - Interview ready, applications live Do at least 3 mock interviews covering all round types. The key insight from Nancy (one of Mahesh’s guest speakers): successful candidates spend 6 hours analyzing each mock, not just doing more mocks. Fill the gaps you find. Tailor your resume per company. Apply with your portfolio link front and center.

Mahesh’s honest take: “I promise you it will take 3 months, but you will get there.”

Common Mistakes (Don’t Do These)

1. Studying AI without building with AI Coursera courses ≠ experience. Hiring managers want to hear: “I did X, it failed on Y, I found Z as a workaround, and shipped to N customers.” If you can’t tell that story, you’re waiting 3 months for a callback.

2. Applying before your portfolio is live Don’t apply to jobs without a live project, a system design writeup, and a PRD that you can walk someone through. The chance of getting hired without this is “single digit.”

3. Treating behavioral interviews as less important than AI rounds Especially at Anthropic - Mahesh has seen multiple candidates who cleared everything technically but got rejected because they couldn’t articulate why Anthropic specifically, not just “AI safety in general.”

Live Q&A Highlights

Q: Are there certifications you recommend over others?

Mahesh: “Mine, obviously.” Jokes aside - he genuinely recommends the MIT Deep Learning open course (free, includes labs, and the MIT brand matters). His honest take: “No certification, including mine, makes much of a difference on your CV unless you can actually demonstrate the concepts deeply. What differentiates our course is how much you build.”

Q: I struggle with evaluation. Is there a step-by-step process?

Yes - Mahesh’s 3-step eval framework:

1. Define what “good” looks like across 3 angles: helpful, honest, harmless

2. Get subject matter experts to do manual evaluation with ground truth

3. Figure out which parts of that manual process can be automated as you scale

Q: I want to transition from People Analytics / People Ops to AI PM. What projects should I build?

Mahesh’s answer: you’re actually in a stronger position than you think. You already have the data and technical muscles. What you’re missing is product sense. Build something that tracks human-in-the-loop behavior - for example, an agent that drafts something (an email, a recommendation), the human edits it, and your system learns from those edits over time. That kind of RLHF-flavored project is very compelling in 2026.

Q: Can you give guidance on multimodal evaluations?

Mahesh is actively working on an audio-specific evaluation framework with someone from the Alexa team - watch for that. Video evaluation framework will come after June. Text-to-slides evaluation isn’t on his radar yet because the demand and monetization aren’t there.

Q: A live role-play happened around “Why Anthropic?” - here’s what Mahesh said he would actually say:

The "Why Anthropic?" question has a wrong answer and a right answer. Here's the difference.

Don’t just say “safety.” Ground it in specifics: Anthropic uses constitutional training, which costs 2x more than standard training - that’s a real, costly commitment. They’ve drawn hard red lines with the Pentagon (no fully autonomous weapons, no mass domestic surveillance). They’re advocating for auditable AI transparency laws - they want every lab to be required to publicly disclose failures. And they built computer use (bash and file system access) with so much trust-by-design that it asks for human confirmation before every action. “If there’s a future where machines take on most of the work humans do, I want to join the company doing it the right way and paying the cost.”

Watch the Full Session

YouTube:

If you're starting your 3-week sprint this week, drop a comment below with what you're building in Week 2 - I'll read every one.

What’s Next?

Early bird seats with 25% off are now open for our most in-demand, core program - Agentic AI PM Certification and if you’ve been thinking about stepping into AI PM, this is your moment.

Cohort 8 didn’t just “learn AI”, it created an army of builders. Over 70 real AI products shipped. People didn’t just prepare, they became ready for the Q2 hiring and promotion wave.

Now, Cohort 9 is our only cohort for Q2 2026 - upgraded with the latest tools, workflows, and systems you actually need to become an AI PM or AI entrepreneur.

While most people are still thinking about it, you can spend May–June actually building, learning, and getting ahead.

If you don’t want to be left behind - this is your signal.

👉 Early bird seats are now live. Secure your spot.

Secure your spot

Last one in the series, and probably the most useful one to read the night before an interview.

Most candidates walk into Al PM interviews optimising for answers that feel complete. The probl…

Read more

Issues 1 and 2 covered what happens once you’re in the interview - system design and portfolio signals.

This one is about something to lock in before you even apply.

One of the fastest ways to signal you don’t really understand Al product is to prep generically for “AI PM interviews” as if they’re all the same.

They’re not. And the difference isn’t subtle.

The three verticals - and what each one actually tests:

• Consumer Al - you’re building for end users. Interviews test UX instinct, trust design, how you handle hallucinations in a customer-facing context, and how you explain Al limitations to people who don’t care about the tech. Think: how do you make Al feel reliable when it isn’t always?

• Developer tooling - you’re selling to builders. Interviews test API design thinking, developer experience, adoption metrics, and how you reason about technical tradeoffs at the product level. Think: what makes a dev tool worth switching to?

• Research infrastructure - you’re working with Al researchers. Interviews test your understanding of training pipelines, eval frameworks, compute tradeoffs, and how product thinking applies inside a research org. Think: how do you ship when your users are also building the thing?

A generic prep strategy - frameworks, metrics trees, product sense cases - gets you to a 6 across all three. That’s not hired territory at most Al-first companies.

What actually moves the score: knowing the ecosystem players, the user persona, and the specific technical vocabulary for your vertical. That specificity is what makes your answers sound like experience instead of preparation.

Practical test: for your top 3 target companies - can you name their Al vertical, their main product, and one specific technical challenge they’re navigating right now? If not, that’s the gap to close before anything else.

Here is the flashcard:

WATCH THE FULL SESSION

Session: Inside Product Interviews: How Are You Getting Evaluated by Hiring Managers?

YOUTUBE LINK: ​​

If you want the full picture - the examples, the live walkthroughs, the questions from real candidates - this is where to go.

Next issue: Interview Scoring Has a Rubric. Know It.

Lastly, if you’re serious about AI PM roles, this is exactly what we built the bootcamp for.

Inside, we help you build real AI projects using OpenClaw + Claude Code, turn them into a portfolio, and prepare for actual AI PM interviews - not generic PM interviews.

If you’re planning to apply in the next few months, don’t miss this cohort.
Also, I don’t usually do this, but here’s a special discount just for those of you reading this - the biggest one we’re offering for this cohort.

Get the OFFER

If you want more details about the course, the curriculum, or just want a walkthrough of how the bootcamp works, you can book a call with us here: Here

Book a Call

P.S. Forward this to a PM friend prepping for Al roles - this is the stuff nobody tells you before the interview.

Last issue: system design rounds now test Al-native architecture, not classic infra.

This one is about what goes into your portfolio before you even get to the interview.

I ask this in almost every mock interview:

“Can you show me s…

Read more

And the same thing keeps happening.

Great candidates. Solid experience. Wrong preparation.

So in last week’s session, I pulled together everything I’m seeing, the patterns, the mistakes, the stuff nobody is telling you, and laid it all out. Here’s the full breakdown.

The market is moving faster than most people realize

Let me start with a number that surprised even me.

AI PM openings went from under 10,000 in 2023 to 33,604 open roles as of February 2026. That’s 298% growth. And AI PM roles are growing at 2.75x the rate of regular PM roles.

The opportunity is real. But so is the competition.

One more thing worth knowing: the average time-to-hire is now 45 days - up 95% since 2019. These processes are long. Which means if you’re not already preparing, you’re already behind.

How top companies are actually interviewing AI PMs right now

Let me give you the insight nobody is writing about.

Building is becoming trivial. The tech stack is table stakes. So what are companies actually testing for now?

AI security. And not in the way most people think.

When I say security, I don’t mean responsible AI checkboxes or adding a disclaimer to your product. I mean - can you have a real conversation about how AI agents should be built with constitutional qualities? Do you understand how to think about diffusing AI into the economy responsibly, at speed, without extracting more than it creates? If you can’t discuss this fluently, you lack the concepts needed to survive in 2026 interviews.

Here’s how this plays out at each company:

Anthropic runs a 5-stage process with a unique structure most candidates don’t know about - there’s a dedicated User Experience round AND a Security round. And here’s the thing nobody tells you: failing the security round is disqualifying. It doesn’t matter how well you did everywhere else. This isn’t a soft culture-fit conversation. They will ask you how you think about Constitutional AI, how agents should be governed, and what your actual position is on building AI that the economy can absorb safely. Avg comp: $425K–$545K. Process: ~19 days, faster than you’d expect.

OpenAI has added something entirely new in 2026 - a Vibe Coding interview. You’ll be asked to prototype an AI feature live using Cursor, v0, or Replit. But don’t misread what they’re evaluating. It’s not your coding speed. It’s whether you instinctively build with safety guardrails, add disclaimers without being prompted, and think about failure states in real time.
They want proof you can build and think like a responsible AI PM simultaneously. Avg comp: $350K–$500K+.

Meta has kept their standard PM rounds but layered on a GenAI product design round and a metrics round specifically for AI features. The question they keep coming back to: how do you measure success for a non-deterministic system? Most candidates fumble this because they’ve never actually thought about it. Avg comp: $450K–$650K.

The through-line across all three: the bar has quietly shifted from “do you understand AI?” to “do you understand what responsible AI deployment actually looks like at scale?” A working demo and a framework aren’t enough anymore.
They want your point of view, and they want it to be specific, defensible, and informed by what’s actually happening in the field right now.

If you can’t walk into a room and talk about constitutional AI design, agentic governance, and economic diffusion of AI without flinching - that’s the gap. And that’s exactly what we’re building in the bootcamp.

Watch the session

What you actually need to show in your portfolio

Most portfolios I see are stuck in 2024. Here’s the honest breakdown:

The minimum bar for any AI PM interview is 1–2 working prototypes with LLM integration, a GitHub profile with documented AI projects, and evidence of iteration - showing what broke and how you adapted.

For FAANG and frontier labs, you need a RAG pipeline, an agent with tool use, an evaluation framework, and a multi-agent system with orchestration logic and failure handling.

The top 5% of candidates have a safety spec they wrote themselves, production-grade considerations baked in, and cross-domain prototypes.

Most people skip the safety spec. That one thing alone can separate you.

The skills that actually matter now

Your core PM skills - customer empathy, prioritization, stakeholder communication, these still matter. They haven’t gone anywhere.

But there are new skills that didn’t exist a few years ago that interviewers are now explicitly testing for:

• Evaluation framework design

• Probabilistic UX design (designing for non-deterministic outputs)

• Responsible AI fluency

• Integration-first design - in 2026, your AI product needs to connect into existing workflows like Slack, Jira, your enterprise systems. A standalone app isn’t enough anymore.

If your answers in interviews don’t reflect these, you’ll score a 5-6 at best when the bar is 9-10.

The Q&A - questions from the community

We had some really good ones this session.

Q: “How do you answer the AI safety question at Anthropic without sounding like you’re just reciting their mission statement?”

The answer is: form an actual opinion. Don’t memorize their blog posts - read them, then push back on them in your head. What would you do differently? What tradeoff would you make? Anthropic wants judgment, not loyalty signaling.

Q: “Is a vibe coding interview something I need to code from scratch?”

No. They’re not testing your ability to write production code. They want to see how you think through product decisions while building. Can you scope it down? Can you articulate what you’d iterate on next? Can you add a safety disclaimer without being prompted? That’s what they’re watching for.

Q: “My portfolio has 2 prototypes but no evaluation framework. Is that disqualifying?”

For most roles, yes - at the frontier lab level. The prototype shows you can build. The eval framework shows you understand that AI outputs aren’t guaranteed, and that you’ve built a way to measure quality. Without it, you’re showing V1 thinking. They want V3 thinking.

Lastly, since a lot of you asked what you should actually do with all of this - how to prepare, what to build, how to structure your prep - we decided to turn this into a 3-week cohort that starts on April 4th.

Not another “learn AI” course. This is specifically about closing the gaps we talked about above.

So the cohort is built around three things:

Week 1 - Foundations that actually matter now
How agents actually work, RAG, evaluation frameworks, multi-agent systems, fine-tuning - and you’ll build your first LLM system with tools, memory, and workflows.

Week 2 - Real portfolio projects
You’ll build a full Q&A system (RAG + agent + tool use) and a multi-agent system with orchestration, memory, and code - the kind of projects that actually move your portfolio into the top tier.

Week 3 - AI PM interview prep
We cover the 21-question framework across Product Design, GenAI System Design, Behavioral (AI-adapted), Technical Knowledge, and Safety/Alignment - the exact areas companies are testing now.

The goal isn’t to overload you with content.
The goal is simple: by the end of three weeks, you should be able to build, evaluate, and talk about AI products like someone who has actually shipped them.

Because that’s the bar now.

If you want to join us, the cohort starts April 4th.
If not, no worries - just make sure you’re building, not just reading.

Either way, the window is open right now. But it won’t stay open forever.

Join the bootcamp

That’s the session. Everything above came from what I’m seeing in real interview loops right now - not frameworks from 2023, not generic advice.

If this was useful, share it with someone who’s preparing. And if you have questions, drop them in the comments - I read everything.

Watch the full session here:

See you soon!
P.S. Flashcard #2 will be out this weekend, don’t miss to check your inbox.

Starting something new this week.

I’m running a flashcard series - one Al PM interview pattern per issue, with the mistake, what it costs you, and the exact fix. A new card drops every few days, so keep an eye on your inbox.

These are patterns from real interviews, not theory. Save them. First one is below.

Here’s a pattern I see constantly in system design rounds.

A candidate walks in prepared - classic systems fundamentals, solid.
The interviewer asks them to design an Al contract risk tool. They open with the AP! gateway. Database schema.
Caching layer.

The interviewer is waiting for the orchestration layer. How agents coordinate. What happens when the model hallucinates. How you’d know the system is even working.

It never comes. The candidate doesn’t move forward. They have no idea why.

What actually changed: Al PM system design is no longer about infrastructure. It’s about Al-native architecture - and that requires a completely different mental model going into the room.

What interviewers are testing:

• Orchestration — which agent does what, when, and in what order Memory — how agents share state across steps without losing context

• Guardrails — what your circuit breakers look like when the model fails (not if)

• Observability — how you actually know the system is working once it’s live

• User outcomes — every single component tied to a reason that matters to the customer

The move that separates a 6 from an 8: start simple, introduce tension (a real failure mode or constraint), then iterate with justification. Interviewers score your reasoning, not the final diagram.

The move from 8 to 10: bring up failure modes before you’re asked. Candidates who proactively say “here’s where this breaks and here’s how we designed around it” signal they’ve actually shipped - not just studied.

Here is the flashcard:

WATCH THE FULL SESSION

Session: Al Product Sense: How Al PM Interviews Actually Work in 2026

If you want the full picture - the examples, the live walkthroughs, the questions from real candidates - this is where to go.

Next issue: Vibe Coding Is Now a Portfolio Signal.

Best,

Mahesh

P.S. The cohort starts on April 4th - if you want to go beyond flashcards and actually build AI systems, run live mocks, and leave with a portfolio, details are at:
OpenClaw-Claude Code Mastery by Building your AI P.A. & Acing AI PM Interviews

Week 1 you build a real Al system with Claude Code so you have something to walk through in interviews. .

Learn more about the cohort

P.P.S. Forward this to a PM friend prepping for Al roles - this is the stuff nobody tells you before the interview.

Instead of starting with slides, I launched a job-search agent live, and while I was talking to 300+ of you on Zoom, it was quietly working in the background:

• Scanning LinkedIn, Indeed, Glassdoor, and Bullhorn

• Finding 10 job matches based on my profile

• Clicking “Apply Now” on each one

• Filling out forms, uploading my resume, skipping dead links

All without me touching a thing. One of the jobs it applied to was Salesforce Director PM.

By the time I finished presenting, it had filed 3 applications and flagged 7 others as no longer available. Not perfect - but it ran while I talked. That’s the point.

The question everyone had was the same: how is this actually possible? So let’s get into it.

The shift that changed everything

Before late 2025, building something like that job agent required serious engineering work. Your team had to write everything custom - the orchestration layer, the memory management, the context retrieval, the verification logic. All of it. That’s why companies were paying for tools like Spellbook or Harvey, or hiring consultants to stitch it all together.

What changed: Anthropic packaged all of that into what they call the Agent SDK - and it runs on one simple loop:

Gather Context → Take Action → Verify Work → repeat

This is what powers Claude Code. And Claude CoWork is Claude Code with a UI layer on top, so you don’t need to touch the terminal to use it.

Three things make this loop genuinely new:

1. File system access — agents can now read and write to your computer. This sounds small, it’s not. It lets Claude run bash commands to find relevant context the way a real developer would — and it runs on your own CPU, so it doesn’t eat into your token budget.

2. Flexible actions — beyond calling APIs, Claude can write scripts, generate code at runtime, use browser tools, and connect to any MCP server (Slack, Google Drive, GitHub, Asana) without custom integration code.

3. Built-in verification — define rules in plain English, use visual feedback like screenshots, or spin up an LLM-as-a-judge subagent to evaluate output quality automatically.

Before, you were paying engineers to build all of this. Now it comes out of the box.

I let an AI apply to 10 jobs for me. Here’s the setup.

Now that you understand the loop - here’s exactly what the job agent was doing.

The setup was simpler than you’d expect. Three files in a folder:

1. My resume

2. A job strategy doc (plain text - my target roles, cities, what I’m optimizing for, what to avoid)

3. A CSV of jobs I’d already applied to so it didn’t repeat them

That’s it. I pointed CoWork at that folder, gave it a prompt, and it took over. It read the files, planned its approach, opened a browser, and started working through the list. Dead link? Skipped. Form to fill? Used my resume. Done with a batch? Saved the output back to the folder.

The whole thing ran while I was presenting to you. That’s the world we’re in as of March 2026.

Watch the full session

What’s actually running under the hood

If you want the full technical picture, this is it.

Everything in this diagram used to be your team’s custom code. Context gathering, orchestration, tools, permissions, verification - all of it had to be built, maintained, and debugged in-house. Now it comes packaged in the SDK.

This is also why Claude Code is winning against tools like Cursor and GitHub Copilot, even though it came to market two years later. Cursor and Copilot built their own custom orchestration on top of OpenAI’s models - solid work, but it’s their black box. Claude Code is built by the same people who own the model AND the infrastructure, which means tighter integration, better file system access, and a faster iteration cycle.

The other difference, and this one matters more than people realize - is the claude.md and skills.md ecosystem. Cursor never taught developers how to build and store their own context. Claude Code did. That gives users far more control over how the agent behaves, which brings us to the next point.

The fastest way to go from good to great

Out of the box, Claude CoWork will give you roughly 70% quality. Good enough to explore, not good enough to rely on.

The way you get to 90%+ is by creating skills.md files - custom instruction files that teach Claude how your organization works. Code review guidelines, legal redlining rules, job search criteria, formatting standards - whatever your workflow looks like, you can encode it.

When a user says “review my code,” Claude reads the skill file automatically and applies your team’s standards. No extra prompting. No repeated corrections.

This is the new system prompt. And right now, most companies don’t have one - which means whoever builds this library first gets a real edge over everyone else still relying on defaults.

The real threat to SaaS

This is where it gets interesting from a product and business perspective.

A legal team I spoke to last week had subscriptions to Harvey and Spellbook — both expensive, vertical-specific tools. They switched to a $25 Claude subscription and are now doing insurance negotiations and contract analysis they couldn’t do before, because they’re no longer locked into what one tool was built for.

That pattern is repeating across industries. CEOs are already sending memos: “everyone gets Claude Code, automate 30% of your work, or…” - you can fill in the blank.

When CoWork connected to Microsoft Excel and PowerPoint, it wasn’t just a feature announcement. It was a signal that the agent can now do the work a human does inside the tools a human already uses. Custom software that existed purely to gather context, take actions, and verify output? That entire category is being rethought. That’s why you’re seeing some SaaS stocks down 40-50%.

Q&A from the session

Q: “How do I keep my API keys and secrets safe when Claude has file system access?”

Two threats to manage: whether Anthropic sees your data at all, and prompt injection through web browsing that could expose your keys to a third party.

For the first: use the enterprise agreement or route through Azure/AWS/GCP - they sign indemnification contracts so you’re legally covered if data leaks.

For the second: keep your .env files outside your code folder. Never give Claude access to that directory. Better yet, create a company-level claude.md rule - “never read or transmit .ini or .env files.” Make it a guardrail before it becomes a problem.

Q: “As a PM, where do I add value if the agentic plumbing is now automated?”

The plumbing is automated. The quality bar isn’t. Someone still has to define what good looks like, run human evals, and know when the system is at 70% vs 90%.

Two areas where PMs own the next frontier right now:

• ROI measurement - companies are spending real budget on Claude tokens. Next quarter, someone’s CFO is going to ask what they got for it. Build the dashboards before that question arrives.

• Context management - the skills.md files, the strategy documents, the structured folders. How you provide context to these agents determines how well they perform. That’s a product decision, not an engineering one.

Q: “I have multiple complex pipelines, where do I even start?”

Don’t try to automate everything at once. Map your workflows into a simple quadrant: low-risk vs. high-risk, well-defined vs. fuzzy. Start in the low-risk + well-defined corner, get one workflow running cleanly, then expand from there.

And give Claude more than just inputs - give it a strategy file. Not just your data, but actual instructions: what you’re optimizing for, what to avoid, what a good result looks like. That file does more work than most people expect.

Q: “CoWork burned through my tokens fast - is there a smarter way?”

Yes - and it’s a real tradeoff worth understanding:

More abstraction = more tokens = easier to use. If cost is a real constraint, look at OpenClaw - an open-source alternative built on the same Agent SDK that lets you swap in cheaper or local models. Same agentic architecture, a fraction of the cost.

Q: “Can you adjust guardrails and get a human in the loop for critical tasks?”

Out of the box, CoWork already asks for permission before browsing or accessing new folders. Beyond that, your skills.mdfile can explicitly list the situations where the agent should pause and check with a human - you define the list, it follows it. You can also go the other direction and override defaults for fully automated pipelines. The control is yours.

Watch the full session + do the lab

We built a hands-on lab for this session where you can set up Claude CoWork, build the job search agent from scratch using the exact three-file setup I showed, and extend it to market research, bug fixing, dashboard creation, and more.

Watch the session here:

Access the lab here: Build a Job Assistant Using Claude Cowork

What’s next?

This Friday I am breaking down the most common mistakes candidates make right now, and how to avoid them.

What’s IN:
• Turning your AI knowledge into something interviewers can actually see - a working product or portfolio
• How to showcase AI agents instead of just talking about AI ideas
• Using frameworks like OpenClaw to demonstrate real product workflows
• A smarter strategy for targeting AI PM roles and positioning your experience

What’s NOT:
✘ Not generic PM interview tips
✘ Not theory about AI products without real examples
✘ Not advice that assumes hiring managers only care about strategy

If you’re aiming for AI PM roles in 2026, this session will help you avoid the mistakes that quietly eliminate strong candidates.

📅 Session Title: AI PM Interview Mistakes to Avoid in 2026
🗓 Date: 20th March 2026, Friday
⏰ Time: 9 AM PST

Register here to get free zoom link : AI PM Interview Mistakes to Avoid in 2026

See you soon!

Here’s something that caught me off guard when I first realized it: in the age of AI, a lot of interviews aren’t happening in a formal room with a whiteboard. They’re happening over lunch. In a casual catch-up. While someone’s just “checking in.”

I shared a quick clip about this - how top companies like Google use informal settings to quietly assess you. And the trap most people fall into? When asked something like “what do you think about OpenClaw?” off the cuff, they freeze and give a surface-level answer instead of a real insight.

The fix isn’t to memorize more. It’s to actually play with the tools.

On that note - this Friday, I’m running a free lightning session on AIPM Interview Mistakes to Avoid in 2026. If you’re prepping for PM roles, you won’t want to miss it.
Time: 9 am PST

Register here: AIPM Interview Mistakes to Avoid in 2026

Want free invites to these sessions?
Fill out the form and we’ll send you a weekly invite - covering what matters, so you don’t fall behind in the AI CHAOS.
Fill the form : https://forms.gle/sRNjXnsurNxNAUQW7

And we’re kicking off our next cohort starting on March 29th 2026 - this one has a dedicated expert track where we go deep on Claude Code, OpenClaw, and building your own 10x AI assistant through hands-on labs.

Very different from anything we’ve done before.

Enroll today

More on that soon.

I walked everyone through OpenClaw (also called Clawbot - the creator keeps renaming it every time a bigger company comes after him, which honestly tells you it’s onto something). Here’s a summary of everything we covered, plus the Q&A at the end.

Why is this even possible now?

Before diving into what OpenClaw is, I wanted to give everyone the “why now” context - because this question comes up a lot in interviews and casual conversations.

There’s a benchmark that tracks how long AI agents can autonomously handle software tasks at a 50% success rate. A couple of years ago, that number was 6 minutes. In 2025, it crept under an hour. In just the last three months, Claude Opus pushed it to 11 hours of uninterrupted work without human intervention.

That’s the unlock. Long-horizon jobs - tasks that run for hours without you touching them - are the big bet for 2026. If you’re a PM or anyone building in AI, this is the trend to watch.

So what is OpenClaw?

Think of it as a personal AI agent that lives on your machine (or a VM) and takes jobs from you via WhatsApp, Telegram, or Slack.

I showed it live - I sent it a WhatsApp message asking for tips to run a better Maven session, and within 30 seconds it responded. While we were on the call.

Here’s what makes it different from your typical chatbot or cloud-based agent:

It has access to your shell. That means it can browse files, run code, install software, create dashboards - basically anything a human sitting at your terminal could do. No previous agent framework had this.

It lives on your machine. Not in the cloud. This is a huge architectural shift. It means it can interact with your local file system, run long jobs autonomously, and stay active 24/7 (as long as your machine is on).

It connects to your apps via MCP. Gmail, Notion, Outlook - all pluggable through MCP servers.

The Architecture (simplified)

Here’s the mental model:

• Channels (WhatsApp/Telegram/Slack) → send a message

• Gateway (port 18789, always listening) → receives the message

• Intelligence layer → your chosen model (OpenAI, Llama, others)

• Tools → file system, shell, browser, MCP integrations

• Memory management → handled automatically, summarizes past conversations

The webhook, the memory summarization, the tool routing - all of it is set up for you. If you’ve built any of this in N8N before, you’ll recognize the architecture immediately.

How to Install It

The setup isn’t complicated - it’s mostly just time (mainly because macOS download takes ~3 hours at home on a slow connection).

Recommended approach: Create a virtual machine inside your Mac using UTM. This keeps the agent sandboxed away from your personal files, passwords, and API keys. You do NOT want this thing running on your main machine with root access - more on that below.

Steps:

1. Download the macOS image matching your current OS version

2. Install UTM, create a VM (4GB RAM, 50GB storage is fine)

3. Run the OpenClaw install command - it installs Node.js and sets up the gateway automatically

4. Choose your model provider (I used GPT-4o mini - cheap and good enough to start)

5. Choose your channel (WhatsApp, Telegram, or Slack)

6. Scan the QR code to link your device

7. Start the Web UI dashboard - you’re done

The dashboard shows you sessions, token usage, cost tracking, active channels, cron jobs, and logs. It’s genuinely useful and gives you real visibility into what the agent is doing.

Scroll down for the lab link.

Watch the session here

Real Use Cases I’m Running

• Email routing: It watches my Maven emails and forwards them to the right team - sales, logistics, mentors. If something important comes in, it summarizes and pings me on WhatsApp. I check email every 3 hours instead of every 30 minutes.

• Team standup enforcement: My team in India has a deadline for daily updates. If they don’t post by the time, the agent reminds them. If they still don’t respond, it calls them. And if they do post, it cross-checks against GitHub commits and asks them to explain any gaps.

• On-call automation: This is the big enterprise use case. Most on-call pages are resolved by following a simple runbook - restart this, check this port, reboot that. OpenClaw can run through all 10 debugging steps for you. If it fixes it, you never even get woken up.

Scroll down for the resource link.

Security: What You Need to Know

This is the part people skip, and they shouldn’t. I covered 4 real risks:

1. Command misinterpretation There’s a Reddit story about someone telling it to “clear the logs” - and it deleted every file with “log” in the name, including system files. Use the --dry-run flag before running any destructive commands. It simulates the job without actually deleting anything.

2. Credential exposure Your API keys end up in logs. To protect against this: use encrypted secret storage, enable log sanitization in settings, and store credentials in a .env file that’s never checked into GitHub.

3. Privilege escalation Researchers showed that if OpenClaw is misconfigured with root/sudo access, it can create hidden folders, encrypt its own files, and resist deletion. Always run it as a non-root user with minimum necessary permissions.

4. Runaway API costs AI loops are real. Give it a task, it gets stuck, and your bill hits $200 before you notice. Set hard limits in the config file: max retries, max tokens, max API calls per session.

Best practices summary:

• Never run as root

• Encrypt everything

• Sanitize your logs

• Review audit logs daily/weekly

• Don’t give it sensitive personal data

• Back up your VM regularly

Q&A

Why did OpenAI acquire the OpenClaw developer instead of just building their own?

Short answer: They were late to the party. Claude moved early with Claude Code, got shell access, and now has an advantage in long-horizon jobs. For $25/month, users are getting more ROI from Claude than from ChatGPT. OpenAI saw that, and when the OpenClaw developer got into a legal conflict with Anthropic over naming, OpenAI swooped in. It’s not just about the tool - it’s about the usage data, the mindshare, and the signal of where the market is going. Meta’s in the game, Microsoft announced Copilot can now do things, Claude is leading. Long-horizon, on-machine agents is the territory everyone is fighting for. It’s trillions of dollars of economy.

Does OpenClaw support Windows or other platforms?

Not really - it’s built and tested for ARM-based machines (ideally Apple). The developer is a small team or possibly one person. Their trade-off is: spend time making it cross-platform, or spend time making it smarter and connecting more tools. They chose the latter. Microsoft will eventually port it; that’s what big companies with engineering armies are for. The cool work is building new capabilities, not making it run on Windows 10.

What’s the difference between OpenClaw skills and Claude Code skills? And how would enterprises use this?

Skills are just tested, refined prompts stored as markdown files that do a specific job - competitive analysis, writing a PRD, generating release notes. The concept is the same across OpenClaw and Claude Code, and you can port skills between them.

For enterprises: the real unlock is replacing all the coordination work. The person who pings people for status updates, takes meeting notes, routes emails, schedules follow-ups - that’s OpenClaw. A manager with a $500 Mac Mini and an agent now has an extra team member who works 24/7. Over time, teams will be a mix of humans and hardware.

How important is the intelligence layer if the agent is misinterpreting commands?

It’s the most critical piece, and that’s exactly why the model labs are investing so heavily in long-horizon job performance. You’re giving this agent access to your file system and shell - the most complex, consequential systems on your machine. The intelligence bar has to be extremely high. The reason dedicated teams at Anthropic, OpenAI, and Google are all working on long-horizon jobs right now is because without better intelligence, you can’t trust agents with real work. They’re not building this out of academic curiosity — they need the token consumption that comes with agents doing real, long-running jobs. Better intelligence → more complex tasks → more tokens → bigger valuation. All three are true simultaneously.

Want to go deeper?

🔬 Try it yourself — Step-by-step installation lab (no experience needed): ClawBot Installation Guide → Notion

💡 10 real-world use cases — What people are actually building with ClawBot: ClawBot Use Cases →

📺 Watch the full session:

That’s it for this week. One more thing I’ll leave you with: knowing how to speak intelligently about OpenClaw matters more than people realize.

Your next informal “let’s grab lunch” conversation at work might already be an interview. Having a Level 2 understanding of what’s possible - and what the risks are - is what makes you memorable.

See you friday !