👋 Hi there,

We conducted the second live session last Tuesday. If you missed it, here is the recording of the session

1. Session recording on Youtube

2. You can find the slides (along with video) in this free course at learn.pmcurve.com

3. Finally, AI Fluency Test that this series aims to improve - https://ai.pmcurve.com/

Please let me know how you find it. The next session is scheduled on 14th April

Join the Next Session

See you in the next session!

Deepak

In the last week’s post, I shared how we are starting this series on ‘AI Fluency for Product Builders’.

We conducted the first live session this Saturday. We are sharing all the relevant links and info about this series in this post.

1. Session recording on Youtube

2. You can find the slides (along with video) in this free course at learn.pmcurve.com

3. AI Fluency Test - https://ai.pmcurve.com/

Please let me know how you find it :)

All the information about this series (including registration link for 2nd session) will be updated at this page.

Register for Next Session

See you in the next session!

Deepak

If you are looking to learn AI product management, we have built the most in-depth program that also helps you build production-ready AI products. The enrollments are open for April cohort. Please check more about the program here: https://www.pmcurve.com/program/advanced-ai-for-pms

Here is a snapshot of essential skills covered in the program

One of the key questions every product builder has on their mind is how to know they are doing enough to keep up with AI. To solve this problem, people tend to watch Youtube videos, read newsletters regularly, listen to podcasts, see product demos, etc. And even then, they keep feeling it’s not enough.

The problem arises because there is no objective way of measuring ourselves up. I started to build a self-assessment to solve this exact problem for product builders, and ended up finding solution to the whole problem - assessment to see where you are right now, and learning program to make you AI fluent no matter where you are. Both of these are free!

Assessment: AI Fluency for Product Builders

You can access the AI Fluency Assessment at this link:

https://ai.pmcurve.com/

Learning Program: AI Fluency for Product Builders

You can access the learning program at this link:

https://ai.pmcurve.com/program

Looking forward to see you in one of the sessions,

Deepak

The next live cohort is Advanced AI Product Management is going to start from 11th April. We have opened the enrollments and if you are interested in joining the program, please check it out and apply soon

Check Advanced AI Product Management

With the pace AI is changing, and changing the tech ecosystem, I find it a right time to start a regular series aimed at simplifying AI knowledge, and helping people make sense of it. My personal motive is to learn better while I write. And in that sense, this newsletter isn’t focussed on surfacing relevant news. It’s more around analysis, and application for product builders.

This is the Edition #1. Let’s start!

In this post, we will cover Cowork that is seen as a direct trigger of SaaS industry losing hundreds of billions of dollars in market cap . To be honest, it’s a combination of multiple factors coming together.

• AI agents are improving in functionality, and making the SaaS look dated

• Enterprises are reallocating IT software budget to AI. AI budgets are up 100%+ YoY, but overall IT budgets are up ~8% only [source: SaaStr]

The stock market event seems to be a reaction to the overall pace of AI and ecosystem changes rather than any single launch. That said, Cowork launch seems to be triggering this anxiety given that some of the plugins they launched like the legal plugin led to companies in this domain to lose market cap. More on the plugins later. Let’s focus on what Cowork is, and how it’s different from everything that came before.

Cowork Launch

Cowork launched on January 16 this year. Cowork is a general use agentic tool for all sort of work. And the first question you might have asking yourself is - how is it different from using Claude Chatbot?

In simple terms, you can provide access to a folder on your computer. Claude can then read, edit, or create files in that folder. For example, it can re-organize your downloads by sorting and renaming each file.

The core things that makes Cowork meaningfully different is that Anthropic released 11 open-source plugins for the tool two weeks later on Friday, January 30. From TechCrunch report,

The idea behind plug-ins is simple: They are designed to automate “specialized” tasks within a company’s various departments. Whether that function is drafting content for the marketing department, reviewing risks in documents for a firm’s legal team, or drafting responses for customer support, the plug-in is designed to use agentic automation to streamline work with a specialized focus.

The company says you can use plug-ins to “tell Claude how you like work done, which tools and data to pull from, how to handle critical workflows, and what slash commands to expose so your team gets more consistent outcomes.”

These plugins led to the anxiety in the market that we saw. For example, one of the plugins is around legal workflows. It can be used for contract review, NDA triage, etc.

We have seen this before in Claude Computer Use

Anthopic itself had launched a tool called Computer Use in October 2024. Claude can interact with computer environments (like folders) through the Computer Use tool.

Below is an example of computer use tool for filling vendor request form. To most people including me, this looks similar to Cowork in terms of functionality.

So what’s different?

As product builders, we understand that there are three fundamental things that lead to a product adoption: capability, usability, and reliability. Let me talk about it in context of a legal work.

Capability: Does the fundamental capability exist? Can Claude really take all the files in the folder, and review the contracts? This has been possible since computer use days, though the fundamental capability of the models has been improving significantly.

Usability: Is it easy to set up and use for a legal team? This is where Cowork shines. Computer use was built by developers, for developers. And it worked well with Claude Code. The interface below is way better to understand than a simple chat window.

Reliability: The most important out of the three for sensitive work like legal. Model reliability is dependent on multiple factors - model capabilities that come from pre-training and fine-tuning quality, and the user flow.

Over the last 12 months since Computer Use launched, the model capabilities have improved. We now have Opus 4.6, a much more capable model than Sonnet 3.5 that Computer Use launched with.

What about user flow? Plugins help with this immensely — they help user do the work with a consistent workflow. They help them use the right prompts, and also all of this reduces errors from user end, and hallucinations from model end.

Note that it doesn’t fundamentally makes the task hallucination-free, but for a non-technical user, this can make massive difference. Think of what happened when Apple introduced GUI and mouse, and computers moved beyond command lines.

The bet Anthropic is making is that the plugin layer, combined with a strong enough base model and simple interface, crosses the threshold of "good enough" for many routine legal tasks. Whether Cowork will get to product-market fit is something we have to see in coming months. But given that Harvey (another AI tool focussed on legal) has been able to find strong PMF, there is a good chance Anthropic will find it too.

Market investors can definitely see this creating problems for legal SaaS, and so that’s why legal-tech firms CS Disco and LegalZoom fell more than 12% and 20% respectively after Anthropic's announcement.

Implications for SaaS Product Builders

Stock of few companies falling just means that investors don’t have confidence in these companies to yield the same returns they expected in the light of new development. So it’s based on speculation, rather than a clear insight.

It’s important to note that Cowork is still AI software sold as service. It’s a different kind of SaaS. You could call it Agentic SaaS if you would like, but it’s not like it is going to be free of cost to these companies. The market share can redistribute between Anthropic, and other companies. We have seen this happening again and again in the past — every tech shift (mobile, cloud) creates value for certain companies and destroys value of others on the older model. So the stock market falling for these older companies could be due to threat of new entrants, more than anything.

Will the pricing model for SaaS change? Vey likely. AI/Agentic SaaS works differently than a traditional software in the sense that every token/usage costs the company money. So the pricing model is going to change. Clients are already requesting such changes as Thomson Reuters noted in their reports where they said that roughly 59% of firms report that clients are demanding more work for lower costs.

What you can do next if you are a product builder

If you are a product builder, the next step for you could be the following:

1. Install Claude Desktop, and learn about how Cowork and it’s plugins work. Use them to do some tasks and compare it to main Claude chat to see the differences.

2. Think about how you can change some of your existing workflows to become more efficient. For example, you can just add all of your PRDs into a folder, and search them anytime you want using Cowork. I am going to modify some of my workflows and show the results in the next post.

I would be sharing few examples from my own workflows in a future post.

This would be all for the post. Quick announcement before you leave: we launched two new programs at pmcurve. Do check them out if these interest you, or tell a friend.

1. Interviews for seasoned PMs: Develop advanced skills to crack interviews, and get connected directly to hiring managers.

2. Build your own AI Copilot and develop advanced skills to create impact

Thanks,

Deepak

A decade later, he became the most valuable player for Major League Baseball (significantly bigger than NPB). His contract is worth $700 million and he is one of the legends of the game.

The sheet that you see uses a method called Harada Method — developed by a track coach, Takashi Harada, in 1990s.

Here is the English translation of the map Shohei Ohtani made

The Harada Method

The Harada method consists of 5 steps:

1. Determine your objective or goal.

2. Mapping key competencies affecting the goal

3. Develop action plan (skills and tasks) to master in order to attain your goal

4. Figure out your strength and weakness

5. Get coaching, receive feedback/guidance to improve your weaknesses

I have been fascinated by this method. It forces you to break a larger goal into manageable tasks/ competencies to master.

So a question I asked myself was — what would a Harada Map look like for a PM trying to perfect his/her craft of product management? This post talks about just the same. It starts with

Step 1: The Objective

One of the things most good PMs get quite right is their focus on creating impact. This could be in terms of getting more users for the product, or increasing revenue, or something else. But compelling impact is the right proxy that you are mastering the craft of building valuable products

PM is unlike structured domains such as maths and computer science where how good you are at it, can be objectively judged by a peer or assessment. A good or bad product decision is often judged by whether the market or the customer like it, get value from it, and are willing to pay for it. Looking that way, product management is similar to investing or business where there is no clear, objective answer you can deduce from first principles directly.

So when you chase and create impact as a PM, everything else follows - meaning, learning, promotions, salary, reputation, etc. It’s good for your company, good for the customer, and a clear sign that you are a good PM. That makes it the right objective for the Harada map of product management.

Before we move forward, let’s make sure we understand impact a bit deeper by breaking it down.

Breaking Down Impact

We can write an equation for impact as follows:

Impact (I) = # of tasks done (X) * Impact per task (Y)

If we are looking to be better at achieving it, we can focus on increasing our # of tasks done * impact per task.

# of tasks done is directly impacted by the systems, templates, and tools that we use. AI as a tool has been the biggest contributor to productivity in recent times. It can write PRDs in 10 minutes that used to take days. It can generate competitive analysis instantly and synthesize user research at scale. The output might not be world-class, but it’s above average in majority of cases.

Let’s talk about Impact per task. The way to understand it is that as people move up, they are supposed to increase their impact per task because the # of hours one can put in is limited. For example, they are expected write updates less which is a low-impact task, and instead invest that time in launching new initiatives, thinking of new ways of building a defensible business, etc. which are high-impact tasks. In short, the higher the paycheck and title, the higher is the impact expected from you. The corollary to this is — if you can’t show higher impact in your career, your career would stall.

AI isn’t the answer

While using AI improves productivity, it can degrade your impact per task by degrading decision quality. It depends on how you use AI.

MIT research (June 2025) found that 80% of users who used LLMs to write essays couldn’t recall what they’d written in these essays. Further, the convenience came at a cognitive cost—using AI diminishes users’ inclination to critically evaluate the LLM’s output.

Reducing the struggle to do cognitively demanding tasks isn’t always a better option. For example, when you struggle to write a positioning doc, it helps you develop strategic thinking.

AI makes you faster by eliminating that struggle. But it can be detrimental to judgement, thereby reducing Impact per task (Y).

So while using AI to improve execution pace is great, it needs to be done selectively and carefully.

Now that we have understood impact well, let’s move forward to figure out 8 key skills that affect impact of a PM in a role

Step 2. Skills <> Impact Mapping

A PM job isn’t uniform across companies, or even within a company. So the skills needed to create impact at one place might be different (though overlapping to a good extent) than the one at another place. This makes it difficult to create a single map, or does it?

Stephen King, the famous author, writes about the concept of toolbox in the book ‘On Writing’

One summer when Stephen King was a young boy, he helped his Uncle Oren, a carpenter, repair a screen door on the side of his house.

“I remember following him with the replacement screen balanced on my head, like a native bearer in a Tarzan movie,” King recalled. Oren meanwhile lugged his toolbox, bulging with tools and weighing in at nearly 100 pounds, “horsing it along at thigh level.”.

‘There was a hammer, a saw, the pliers, a couple of sized wrenches and an adjustable; there was a level with that mystic yellow window in the middle, a drill (the various bits were neatly drawered farther down in the depths), and two screwdrivers. Uncle Oren asked me for a screwdriver.”

Wielding the simple tool, Oren speedily removed the eight screws that secured the broken screen and attached the new one. But King was puzzled. He asked his uncle why he’d lugged the toolbox all the way around the house “if all he needed was the screwdriver. He could have carried a screwdriver in the back pocket of his khakis.”

“Yeah, but Stevie,” he said, bending to grasp the handles, “I didn’t know what else I might find to do once I got out here, did I? It’s best to have your tools with you. If you don’t, you’re apt to find something you didn’t expect and get discouraged.”

I find this analogy pretty good to explain why a PM needs to have the entire toolbox of skills even if they aren’t using all the skills in a particular job to create impact. The problem is you will never know what you don’t know.

Here is a set of skills, most relevant to creating impact

1. Ability to identify new, strategic initiatives + getting it to product-market fit (New Initiatives and PMF)

2. Scaling a product once it achieves PMF (Product Growth)

3. Finding valuable consumers problems through research (Consumer Knowledge)

4. Data-driven product management (Analytical)

5. Solving a consumer problem well (Problem Solving)

6. Monetizing products to hit business goals, and build long-term defensibility (Business Acumen and Strategy)

7. Aligning everyone to a worthy goal and roadmap (Executive Presence)

8. AI efficacy to use AI effectively. Please note that we are using the word ‘efficacy’ and not ‘fluency’ here.

So where does product sense/ taste lies? Product sense is a combination of few competencies - consumer knowledge, problem-solving, data, strategy, etc.

Step 3. Skills <> Competencies Mapping

Let’s go after skills one-by-one. We are trying to be directionally accurate as much as possible. If we can cover 90% of product management craft in this map, we can count it as a success.

1. New Initiatives and PMF

• Get buy-in from CXOs on a new initiative

• Budgeting a new initiative

• Setting timelines and targets in a new initiative pre-PMF, which is often pretty difficult

• Identifying riskiest hypothesis and designing most efficient MVPs

• Defining initial set of users in the narrowest segment possible

• Building feedback loops in a new product for 10x learning

• Diagnosing why PMF isn’t there

• Recognize when to pivot vs persevere

2. Product Growth

• Setting achievable metric targets through growth modelling

• Identifying product and marketing levers of growth

• A/B testing design and statistical significance

• Product-led acquisition

• Onboarding and activation

• Engagement and Retention

• Churn prediction and management

• Virality (and referrals)

3. Consumer Knowledge

• Human behavior model

• Human needs, desires, and compulsions

• Bias and Heuristics

• Habit formation

• Conducting primary qualitative and quantitative research

• Secondary market research

• Theory of mind/ cognition

• Sociology in product development

4. Problem Solving

• Systems thinking to see second and third-order effects

• Separate signal from noise in data and research

• Running pre-mortems and simulations well

• Understanding creativity

• Mastering methods to exercise creativity and generate non-obvious solutions

• Structured thinking and problem-solving

• UI/UX Design

• Tech System Design

5. Business Acumen/ Strategy

• Translating business goals into product goals

• Understanding good vs bad strategy

• How to build deep industry knowledge

• Moats

• Finding and building right to win systematically

• Positioning

• Monetization and Pricing

6. Data-driven Product Management

• Cohort analysis

• Conducting RCA using data

• Mapping data to research to understand why

• Segmentation and Funnels

• Attribution modeling

• NSM, guardrails, and metrics decomposition

• Data infra and tools (event taxonomy, warehousing, analytics)

• Causal inference

7. Executive Presence

• Aligning execution to vision and mission

• 10x thinking to set ambitious goals

• Building and hiring a strong org and culture

• Reliable Execution

• Conflict resolution

• Courage

• Change/ crisis management

• Speech and appearance

8. AI Efficacy

• Write system prompts that beat generic templates

• Build custom agents for your specific workflow like research, task management, etc. to create your personal productivity OS

• Evaluate LLM output quality rigorously

• Making AI reliable

• AI Prototyping

• Vibe-coding

• Building systems to use AI to help judgement, not hurt it

• In-depth knowledge of AI tools relevant for PMs

Here is a summary of all these skills:

Step 4. Strengths and Weaknesses

In this step, you can make an initial list of skills and competencies that you need to work on. We all have some blind spots, and it’s harder to figure for PMs since the objective problems are missing. The way to figure out our blind spots in the professional setting is by looking at our past performance reviews, seeking additional feedback from managers/mentors, etc.

I also find interviews a great way to figure out your blind spots. By finding the problems that can map to all these competencies, and solving those problems, you can get a reasonable idea on whether you understand a task well or not. How do you find such questions/ problems? You can get it from various PM interview sites, but if you need a more detailed answer from my end - let me save that for the next post.

Step 5. Working towards excellence

This is the final piece once you have figured out what to work on. Tools that can be helpful here are

• learning via books, papers, blogs, courses, videos, etc.

• applying the competencies on the job

• applying the competencies to produce high quality solutions to PM questions

We plan to publish questions that can help you assess various competencies/ skills well in the next post. Stay tuned!

Programs based on Harada Map

Harada Map of Product Management is the leading thesis behind the two programs we run:

1. High-impact Product Management, designed for seasoned PMs

2. PM Interviews Bootcamp, designed for seasoned PMs

Depending on where you are as a PM, you may find it quite relevant, somewhat relevant, or not relevant at all :)

Thanks,
Deepak

How is product management going to evolve in the next 3-5 years and what can we do about it?

The first part of the question isn’t that interesting, partly because speculating 5 years ahead in a world changing so fast due to AI is naive. A better thing to do is to look forward to next 12 months, and pick skills which protect you or even help you thrive in the age of AI. So what are the skills once should be focussing on? The answer depends on where you are in your PM journey.

In this post, we talk about four segments: Aspiring PMs, IC PMs, PM Managers, and Product Executives.

Aspiring PMs: The Bar Rises to Get into PM

The path to get into product management till now has been —learn frameworks, do a bootcamp, and land a junior PM role. Junior PMs roles so far were all about execution - writing feature PRDs, running experiments, updating stakeholders, sprint planning, etc. AI has made many of the execution tasks easier so that it can be done by a seasoned PM in much lesser time. Claude or ChatGPT acts like a junior PM intern for seasoned PMs to whom they can delegate mundane tasks. This has led to an overall decrease in junior roles.

But not just that, AI has also led to a change in expectations from a junior PM. Companies increasingly expect junior PMs to be AI-native because they can add value from Day 1. So if you are aiming to get into product management, you have to go above and beyond learning frameworks, do a bootcamp, and go through interviews.

Here are the top things you should prioritize:

1. Technical fluency with AI tools: You need to build comfort working with AI tools. Learn to use Claude, and ChatGPT, for research and analysis. Use Lovable and Cursor for prototyping.

2. Build a portfolio: For the first time in product management history, a non-technical PM can be a builder as well. Hiring managers are looking for builders who can recognize a pain and solve it. Ship a small AI-powered tool for personal use, or build a product to solve a need others are facing using AI prototyping tools. Create a Github profile or portfolio page and post your projects there. You can draw inspiration from your designer friend profiles where they showcase what they have designed.

3. Higher skill level: Build domain depth using deep research for companies you are applying to, have some really good questions to show your judgement. The bar for product sense/ judgement has gone up because a PM with mediocre judgement will not be able to refine AI outputs and take it to the next level.

You need to operate like someone with 2-3 years of experience on day one. Fortunately, AI products such as Claude or OpenAI can help you learn faster, and you can become a builder by using Cursor/ Lovable sort of tools.

IC PMs: Two Paths Forward

For IC PMs, two distinct paths are emerging. Both require AI fluency, but they lead to very different careers.

Path 1: Becoming a Super IC

Every PM has access to AI tools that can generate output in terms of list of features a product should build, feature PRDs, user stories, market research, product strategy, prioritization of features, etc.

This enhances the ability of a PM to generate output by 10-100x. You can write 10 PRDs in a day, whereas a single PRD used to take 10 days earlier. But LLMs aren’t reliable. They can generate very plausible outputs, but fail to judge the quality of these outputs reliably.

And so PMs have to exercise their product sense and strategy more and more on the output generated by LLMs. This fundamentally shifts a PM job from creating the entire output like a PRD or user stories or market research documents, to evaluating generated output from LLMs.

Super IC PMs use AI as their productivity multiplier. They leverage Claude, Cursor, and other AI tools to significantly enhance their output by doing work that previously required a larger team.

The core skills required to be a Super IC can be understood by looking at the Venn diagram below from a course I run.

Here are the top things you should prioritize if you are on this path:

1. Product judgment. When you can build significantly faster with coding agents, deciding what to build that creates both short-term and long-term advantage becomes necessary. A solid judgement requires deep domain knowledge and advanced knowledge of product sense, growth, and strategy. It’s not that this skills wasn’t required earlier, but the premium on the skills has increased due to AI.

2. AI Fluency: Learning basic tools and prompt engineering has become mandatory and every PM is using AI in some form or other at work. The advantage lies in how deeply fluent are you in AI. The litmus test for this is whether you have your OS consisting of AI workflows, prompt library, and more at work. Best PMs I know have created a different system of work.

Becoming a super IC isn’t going to be a choice for long, every PM has to graduate to this.

Path 2: Becoming an AI PM

AI PMs don’t just use AI tools—they build AI products. They understand LLMs architecture well, can debug hallucinations, and make architectural decisions such as model selection using rigorous evals.

This is the path that leads to AI-native companies like Anthropic and OpenAI, or to senior roles at startups building AI products.

Here are the top things you should prioritize if you are on this path:

1. Deep technical understanding of AI. Understand LLMs, RAG, fine-tuning, prompt and context engineering, model selection, etc. You don’t need to write code like an AI engineer level, but need to have ability to hold discussions around architectural decisions/ trade-offs.

2. Build AI products yourself. Ship AI-powered features or products end-to-end if you aren’t in the role yet. The learning comes from doing—understanding failure modes, UX tradeoffs, and evaluations. That’s a reason the course I run for AI product management has the Capstone where learners have to build production-ready AI products.

3. Domain expertise in AI applications: AI product sense and strategy is what a PM brings to the table. You need to build deep domain knowledge of AI products, and ability to predict where the domain is moving.

This path is for you if you’re drawn to the technical role such as a platform PM. But it’s a misconception that it’s only a technical role. The misconception exists because currently most AI companies such as Open AI/ Anthropic are operating at platform layer. That’s changing as the industry is moving to the application layer. More and more AI PM roles are going to be application-oriented. So even a consumer or enterprise PM who doesn’t want to do a heavily technical role can aim for this. An example is PMs who are building support agents in different organizations, are use-case/ application focussed, rather than being tech-focussed.

PM Managers: Might See Maximum Disruption

You can’t manage what you don’t understand. And that’s true about PM managers as well. If they don’t have any builder experience in AI, how can we expect them to manage AI products, or AI-native product teams?

That’s one of the reasons leaders in silicon valley are advocating PM managers to be a builder again, or gain some builder experience. After all, your ICs are becoming Super ICs or AI Builder PMs. If you don’t understand what they’re doing, you can’t help them do it better. And if you can’t help them, why do they need you?

The trend can be seen in middle management jobs (source)

Here are the top things you should prioritize if you are a PM manager:

1. AI fluency: You don’t need to be as deep as your AI PMs, but you need to understand enough to make sound decisions.

2. Coaching Super ICs and AI PMs/Builders: These two types of PMs will need different things from you. Super ICs need help with prioritization, strategy, removing blockers for them, etc. AI PMs need help with impact assessment, technical tradeoffs, and stakeholder alignment on AI-specific risks. You will need to manage them differently.

3. Hiring for the new archetypes: Interview loops, and evaluation criteria for a new hire needs to change to accommodate new reality. You company probably still optimizes for traditional PM skills. Update them. Look for AI fluency in hiring. Test for it.

4. Strong judgment: As teams can ship things faster, this could lead to faster disasters in lack of strong judgement. Your judgement is solid for an era when shipping speed was slower, so it needs an update. And that’s not the only area - building AI product sense and strategy becomes super important as well.

5. Building a learning culture around AI: Your team needs space and budget to experiment with AI tools. Some will adopt fast, others will resist. Set clear expectations and competencies in AI fluency. Celebrate PMs who ship using AI tools. Have honest conversations with those who won’t adapt and help them learn and adapt.

The PM managers role demand much more, and you have to master multiple skills while doing your full-time job. That’s what makes it so difficult.

Product Executives: Culture and Strategy Changes

If you’re a VP of Product or CPO, your focus is how culture and strategy needs to change in the light of AI. Here are few things to focus on:

1. Early wins: There is a good chance you understand the importance of early wins around any new strategic initiative, and AI isn’t different. The place where AI becomes different is that it isn’t deterministic like other pieces of software you have dealt with. The probabilistic nature of AI can elude impact that you are planning since it’s hard to predict impact in advance. Best way to get an early win here is to talk to multiple experts and form your thesis. This is what you have always done when entering a new domain. Treat AI as a new domain/ territory.

2. Speed vs Hit rate: AI improves shipping velocity, but that is a double-edged sword. You have to make both faster and better decisions, something which is really hard to do. In a zest to deliver many things, you might end up building wrong things. People who are telling you that it improves your impact ultimately don’t understand the nuances of product management and consumer psychology. If most of what you ship is useless to consumer, they start doubting if the product is right for them and will try alternatives. In enterprise, it’s an entirely different story. Someone with better decision making will end up winning your accounts. So your competitive advantage isn’t speed, it’s speed x hit-rate on features shipped.

3. Restructuring and change management for AI-native work: How do you restructure your team in this new era? With AI, the stack-rank of initiatives also changes. You may need to rethink team composition and headcount allocation. And this won’t be just product team. Engineering, design, and other functions are going through similar shifts. You need to lead cross-functional alignment on how AI changes ways of working. How do you tap into new efficiencies? What does a product trio look like when the PM can prototype? These are organizational design questions, and you need to answer them.

4. Managing the board, peers, and CEO: The board, CEO, and cross-functional peers are looking at CTOs and CPOs for guidance. You need to be the voice of clarity along with your CTO, and create a coherent strategy + plan together. Failing to shape the conversation can prove detrimental to both company and your career.

To be honest, this is a role (VP/CPO) where I have limited experience, but I have been fortunate to connect with many of them because of pmcurve, and these pointers are based on my personal experience as an entrepreneur running the company, and my conversations with product executives.

Wrapping it up

Regardless of where you are, AI accelerates execution and is a new skill/ set of skills to pick in 2026 and beyond.

Here’s what to focus on based on your level:

Aspiring PMs: Be AI-native, produce senior-level output, go deep in one domain/ segment, build a portfolio that proves it.

IC PMs: Choose your path—Super IC or AI PM Builder

PM Managers: Build technical fluency, coach the new PM archetypes differently, learn to hire for AI-native skills, faster and better judgment

Product Executives: AI strategy, restructuring your org, change management, managing expectations through early wins and conversations

2026 could be a significant inflection point for product management. It is also possibly the best time to reassess where you are and what you should optimize for.

—Deepak

The purpose of this guide is to help you understand how to build your first skill that you can use on a daily or weekly basis. It’s also written in a simple and helpful tone, so that it becomes easy to digest for most people out there.

Let’s start with the first question: What is Skills?

Understanding Skills

Simply put, skills are set of resources that you provide Claude to do a particular task. Suppose you want a document written in a certain format every time, you can provide a set of resources to Claude, and it will create the document in that format every time.

If you are looking for an analogy to understand skills, the closest one is a guiding document for a new hire. When onboarding new hires, we provide them a guiding document containing templates, and examples for various tasks. Product teams provide PRD templates and examples so that a new PM can write PRD, marketing teams used blog post templates and sample posts, etc. The new hire uses the guiding document can be used to do a standard task in a predictable manner, and you can given these templates to someone else as well.

Skills can contain resources such as

• general instructions

• successful examples of the task

• failed examples of the task

• coding scripts if needed

Here is an example of a skill useful for product managers — writing user stories. As you can see, the skill has

• name of the skill

• description of the skill

• purpose

• when to use

• input requirements

• output format

• process

• best practices

• examples

While all of it is easily understood, we don’t know why it’s formatted as such. Don’t worry it though, we cover it in the next section.

---
name: user-story-writer
description: Creates user stories following [Company] standards with acceptance criteria, technical notes, and story point estimates
---

# User Story Writing Skill

## Purpose
Generate well-structured user stories that follow [Company]’s format and include all required elements for engineering handoff.

## When to Use
- Breaking down epics into implementable stories
- Converting feature requests into structured requirements
- Creating technical stories for infrastructure work

## Input Requirements
- Feature description or epic
- Target user persona(s)
- Known technical constraints
- Priority/timeline context

## Output Format
[Include your template here]

## Process
1. Clarify the user outcome
2. Identify persona(s) affected
3. Break into atomic, testable stories
4. Add acceptance criteria (Given/When/Then)
5. Document technical dependencies
6. Estimate complexity

## Best Practices
- One user story = one testable outcome
- Acceptance criteria must be objective
- Include API/integration dependencies
- Flag security/privacy considerations

## Examples
[Include 2-3 complete examples]

Format of a Skill

Claude Skills are stored in a .md file extension, which represents markdown files. Markdown is an easy-to-use markup language. Markup languages are used to format and display content on web pages and in documents.

The above format should now be understandable now. A markdown file can be converted to html if needed by using software and output can be rendered on a website easily.

Putting the above markdown file for user story in an app like markdowntohtml.com converts it to the following:

As you can see, a single # represents Heading 1, ## represents Heading 2, etc. But you don’t need to remember the notation since LLMs do a pretty great job at creating markdown files from other documents.

So now that we understand the Skills format, let’s understand why Claude needed to build Skills.

Is there a need?

You don’t need to create a guiding document if you need to do a task only once. Similarly, a skill isn’t useful for one-off tasks. You need it in case of repetitive tasks.

Another key question around the need is — why can’t I store all the instructions, examples, and more in a word document, and upload it whenever I need to use the skill. The answer to this question is that you can do that to save time for repetitive tasks, and there is a good chance the results will be identical. After all, the instructions to the LLM are the same.

So where does it become useful? To answer that, you will need to first understand how to create and use a skill. It becomes way easier to explain the need once you understand that.

Building a Skill

To build a Skill, we are going to start with writing a simple prompt in Claude Sonnet. You would need a Pro account to access Skills.

Help me create a skill for writing user stories. Our format includes:
- Title: As a [persona], I want to [action] so that [benefit]
- Context: Background and why this matters
- Acceptance Criteria: Given/When/Then format
- Technical Notes: Dependencies, APIs, edge cases
- Story Points: Fibonacci scale estimation

Claude starts working, and does tons of things under the hood to create a skill as you can see in the screenshot below. But the best thing is - you don’t need to do much to create your first skill.

Next Steps

1. You can download the skill with the CTA, or save it. I would recommend saving it directly if you are happy with the skill and plan to use it in future.

2. If you have downloaded the skill, and modified the instructions or examples manually, you can add the skill by going into settings > capabilities and uploading it there

Let’s go back to the need question — one core problem that Skills solve is that they reduce all the manual effort to find and upload the right document. I can just write the prompt simply and it will fetch the skill.

There is another benefit of Skills, we can combine multiple Skills on-the-go to get a task done. For example, here is a simple workflow of launching a new feature. Note that Claude can’t automatically chain these skills into a workflow - you’d need to manually invoke each one.

Workflow: Launch New Feature
├── 1. market-research skill → Competitive analysis
├── 2. prd-writer skill → Product spec
├── 3. user-story-writer skill → Engineering stories
├── 4. go-to-market skill → Launch plan
└── 5. metrics-dashboard skill → Success metrics

Another key benefit of Skills is that it can work in sync with other capabilities of Claude like Computer Use, or MCP.

Architecture of a Skill

We will skip the architecture of a skill since it’s useful when you start using Anthropic APIs to build Skills in AI products. But if you are interested, you can read this engineering blog by Anthropic team:

https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

I would want to pay attention to the following while you go through documentation around Architecture:

1. Understand how progressive loading works in skills

2. Understand how you can optimizes token costs using Skills

Making a Skill Useful

The user-story-writer skill that we built using Claude Sonnet is useful but has limitations in real-life.

First of all, it needs to adhere to guidelines of a product org. The good thing is you can either ask LLMs to make the specific changes or download it yourself and modify.

Second, it lacks the context of a product or org. Context can again be added by modifying the file.

Third, a skill is as good as the person creating it. If a PM doesn’t know how to write excellent PRDs, they can’t judge whether AI is able to write a mediocre PRD or excellent one. In absence of this judgement, they would get mediocre results and feel good, whereas the reality is that AI could have generated much better output if they had strong product sense/ judgement. The skill becomes a “garbage in, garbage out” multiplier for those without a strong product sense.

A Skill can be made useful through rigorous evaluation. You can generate different versions of PRDs by modifying the skill, and compare them to arrive at the best version of the skill.

Conclusion

Claude Skills is a terrific product for the end user. It can have high impact on output and productivity of a team. Even better is that it looks and feels simple, which is essential for high adoption. It is another useful addition to the suite of products Claude has launched in last year - Claude Projects, Computer Use, MCP.

From a strategic lens, it allows Claude to increase the switching cost of the product. Once sufficient number of skills are built, the end user will find it hard to move out of Claude. On the other hand, Claude allows you to down the skills, and we might see other apps like ChatGPT supporting import of such Skills. So the switching cost isn’t very high.

If you are interested in building or managing AI products, you would find this cohort-based program I run useful. Do check it out:

https://www.pmcurve.com/program/advanced-ai-for-pms

This would be all for this post,

Deepak

Check Out The Program

You can also check what PMs like about the program here

The future is already here, it's just unevenly distributed. In AI product management, this couldn't be more true. The question isn't whether product teams will need the AI skills - it's whether they acquire them before or after the competition does.

With this in mind, I conducted an 80-minute session of the topic ‘Complete Roadmap to AI Product Management in 2025’ last week. In this post, I share key themes covered and the link to the session recording.

Key Takeaways

• The bar for PMs has risen dramatically: 80% of AI PM is still traditional PM, but the bar in these traditional skills have risen up 10x. Discovery that took 3 months now needs to happen in 7-14 days.

• Engineers are ahead: As per Andrew Ng, Software engineers are embracing AI faster than PMs. The demand for AI-savvy PMs is moving up while traditional PM roles are declining.

• Building AI products beats understanding and learning about AI: Level 3+ proficiency (hands-on building) is now essential for AI PMs. You need to prototype and build AI products, not just understand concepts.

• AI adoption is mainstream: ChatGPT hit 700M weekly active users → Customer expectations have been shifting as more adopt new AI products.

Evaluate Where You Stand: The 5 Levels of AI Proficiency

1. Level 1: Heard the terms, can't explain them

2. Level 2: Can explain AI concepts, speak comfortably with engineers

3. Level 3: Can build prototypes and write advanced prompts

4. Level 4: Shipped AI features to production

5. Level 5: Building AI strategy for a product line

The UT-FRAME Method for AI Products

Learn and build AI products in this order:

• Use case: Find biggest user frustrations AI can uniquely solve

• Technology: Choose between traditional ML vs GenAI

• Foundation: Test prompts and models with basic evals

• Reasoning & Resources: Add RAG, fine-tuning if needed

• Agentic AI: Evaluate if autonomous decision-making adds value

• MVP: Get functional version to alpha users

• Evaluation: Run extensive evals before production

Critical AI PM Skills for 2025

AI knowledge isn’t enough, here is an exhaustive list of areas to master:

AI for PMs:

• AI prototyping with no-code tools

• Deep research using advanced prompts

• 28+ prompt engineering techniques beyond basics

Finding the Right Use Case:

• ROI calculation with API cost projections

• Traditional AI vs GenAI decision framework

• Edge case and hallucination management

AI Product Design Patterns:

• New UI language (gradients, modern fonts, purple/blue themes)

• UX patterns: Human-in-the-loop, graceful degradation

• Trust and safety integration

AI Product Strategy:

• RICE-AI framework (adding AI capability & stakes)

• Build vs buy vs fine-tune decisions (99% don't need fine-tuning)

• Creating moats through switching costs (memory, workflows)

AI Knowledge

• Foundation models vs traditional models

• RAG, reasoning, fine-tuning, etc.

• Advanced prompt techniques

• Agentic AI

• Evals

Resources

Essential Reading - Tech and AI

• Tech Simplified - System design for PMs (2-day read)

• ByteByteGo Newsletter - Engineering concepts

• Andrew Ng's courses on Coursera

• Research papers

Product and design thinking

• Thinking in Systems by Donella Meadows

• Alchemy

Tools

• Claude Pro ($20/month) - for serious PMs and builders as a thinking partner

• Lovable/Cursor - AI prototyping

• $5-10 in API credits for testing

Here is the session recording

This would be all!

Thanks,

Deepak

Check Out The Program

You can also check what PMs like about the program here

So I recently conducted the second episode of "How to X with AI" series. The series is focused on teaching PMs how to achieve product tasks/ outcomes with AI. The first episode was about vibe-coding basic apps and is available here.

What We Covered in The Session

The session was focused on vibe-coding full-stack and AI apps. We showed the frameworks and principles to build these apps focusing more on interviews. The example that we picked to demonstrate was building a full stack Q&A app, and adding AI features to it.

While sharing the recording of the session with subscribers, I usually provide a summary of the session. But summaries are boring, counterintuitive insights aren’t.

So I wrote the insights out to share them with you. Here we go:

Product Thinking

1. Writing The v1 of PRDs Manually

In my previous stints, I have always requested PMs to remember the metrics/ numbers for the products they manage, rather than relying on dashboards. From my experience, PMs who remember key metrics without relying on dashboards think more critically and connect data points faster. Apply the same principle to PRDs: draft the first basic version manually to exercise and show product intuition, then refine with AI.

2. AI Apps Need to Manage Stakes/ Risks

In high-stakes domains like education or healthcare, unchecked AI output can mislead users. A safer approach is routing it through experts first—for example, in our EdTech Q&A app, instructors review AI answers before students see them.

Product Execution

3. Bug-Fixing Skills and PMs

Prototypes break when you are building them during the interviews, and the response matters more than the resolution. Here is the recommended approach:

Articulate the troubleshooting framework: "This issue has appeared before. The approach would be systematically testing hypotheses, starting with the most probable causes. Then we will do …"

Interviewers evaluate problem-solving skills and understanding of tech/ issues, not debugging when it comes to PMs.

4. Functional Prototypes Don't Mean Production-Ready Code

An audience question that appeared towards the end of the session led to this - ‘How much can we scale the AI prototypes?’

When it comes to AI prototypes, the scaling is the easy bit. The core problems are around tech debt, security, compliance, etc. AI-generated code requires full audit and security review. Even expert-written code undergoes security audits through bug bounty programs in large companies.

5. More Patience with LLMs Prevents Failures

Another audience question we discussed around this is - ‘how do I make sure that the tool is just modifying what I told it to and nothing more?’

The answer is patience. When modifying requirements, we need to follow a two-step process:

Step 1: Ask it to describe the changes it will implement. No coding in this step, just chat.

Step 2: Review the plan carefully, then only authorise changes.

This prevents unintended feature breakage during modifications. If you go for speed by doing it all in a single step, it can often result in more time spent fixing bugs.

6. Sequential approach > 1-shot

You can develop an urge to put the entire MVP requirements in these tools, and ask them to code it. There are two problems with that:

1. Attempting to build the whole thing at once increases bugs/failure probability.

2. When the failure happens, it becomes hard to figure out the reason.

I recommend a sequential approach:

1. Start at the core functionalities.

2. Add the AI features

3. Build the adjacent layers next, such as authentication layer

Testing after each layer reduces bugs while minimising overall development time.

Career Growth

7. Have an Annual Learning Investment

"How many tools do we pay for to learn? It’s quite expensive.”

Have a $300-$500 per annum budget for the next two years. Here is why:

• Tool subscriptions average $20/month. You can always cancel subscriptions you don’t like.

• The flux in job roles and responsibilities is really high right now. Consider this professional development investment. Market leaders who navigate technological shifts capture disproportionate rewards.

After all, the best investment you can make today is in your skills, body, and mind!

This would be all for now. You can watch the complete session here

Thanks,

Deepak

Check Out AI Program

Just wrapped up a live session on "How to Vibe-Code in PM Interviews with AI" last Saturday and wanted to share the key insights.

For context - this is the first episode of my "How to X with AI" series. You can follow updates by subscribing to this newsletter.

Here are the key insights from the session:

Certain aspects of PM role are changing fast

Google's recent shift from "writing-first" to "building-first" culture isn't just a Google thing. It's happening everywhere.

Vibe-Coding is now a core PM skill

Think of it like user segmentation or success metrics - it's becoming table stakes. Companies aren't testing if you can use tools like Claude or Lovable. They're testing if you can think like a PM while building these prototypes.

The Framework for Vibe-coding

Jumping straight into prototyping is a mistake, both in full time role and in interviews. Here's the framework we discussed in the session, it’s pretty similar to product sense/ design problems:

Most PMs miss this. They go straight to building the prototype ("creating a feedback form") without asking WHO it's for or WHY we're building it.

Being Tool Agnostic

You need 2-3 diverse tools in your arsenal. For example,

• Lovable for building end-to-end apps

• Claude for reasoning and creating clean UI

• Replit for AI agent development of apps

But I would ask you to remember that you shouldn’t get caught up in things like prod vs testing environment, or specific features. That’s is what the interviewer is testing you around. That’s easy stuff. They care if you can show product sense, build quick prototypes, focus on what matters, and debug when things go wrong.

Most Prompt Engineering advice is shallow for PMs

Most prompt engineering advice comes in the form of "give it a persona" - “be clear and specific” - “add examples”. PMs have to get complex things done. The advice here is to go deeper. Read the actual research papers on techniques such as Chain of Thought, Tree of Thought, etc.

Show Thoughtful PM Skills, Not Speed

The best signal you can give to the hiring manager isn’t how many features you know of a tool. Comment on your design choices while building. Fact-check LLM outputs. Show how you handle when AI goes haywire.

When I showed how to solve the design problem “Build a feedback form that dynamically adapts to user feedback”, I spent time critiquing the LLM's output - "too many response options", "users won't understand the term 'order fulfillment” etc. That's what separates good PMs from prompt copy-pasters.

The session recording is available here

Summary

Vibe coding interviews are about testing if you can 3-4x your productivity as a PM. Not if you can build pretty UIs.

Master the fundamentals - product sense, technical system design, RCA skills. Then layer AI tools on top. Not the other way around.

Next session in the series drops next week. You can register here: Next session in the series drops next week. You can register here: https://maven.com/p/af7cd0/how-to-vibe-code-in-pm-interviews-part-2-of-2

You can learn the AI prototyping end-to-end by attending this free course: https://www.pmcurve.com/program/prototyping-with-ai-for-pms-founders

---

If you want to go beyond how to use AI as a PM, and build actual AI products as a product leader, do check the advanced AI program: https://www.pmcurve.com/program/advanced-ai-for-pms

Thanks,
Deepak

16,000+ smart, curious folks have subscribed to the growth catalyst newsletter so far. To receive the newsletter weekly in your email, consider subscribing 👇

Subscribe now

Let’s dive in the topic now!

RCA is short for root cause analysis. It is a structured analysis to find the root cause of a problem, and solutions to fix the root cause.

RCA problems are pretty similar to everyday problems that PMs face on the job. And that’s also a reason the technical PM interviews have started adding RCA problems in the problem-solving/ execution rounds.

RCAs can be both technical and non-technical. Here is a non-technical RCA,

“Imagine that you are a PM at Youtube, and you have seen the watch time going down by 20% yesterday. What would you do?”

A technical RCA would look like this:

“Imagine that you are a PM at Youtube, and you have seen the buffer time going up by 20% yesterday. What would you do?”

We would focus on technical RCA in this section! Understanding what it takes to conduct RCA gives PMs a deeper understanding of what engineers do when they face an issue.

Two Approaches to Conduct RCAs

When it comes to conducting RCA for an issue, there are two methods we can employ. The first one is taking a hypothesis-driven approach and the other one is going layer-by-layer to figure out what’s happening. Let’s talk about hypothesis-driven approaches first!

Hypothesis-Driven Approach

This approach starts by forming hypotheses (educated guess) about what might be causing the issue, then systematically testing each hypothesis.

Suppose that there is an increase in failures in the checkout flow for the CC payment method. In the hypothesis driven RCA, we map out possible reasons/ hypotheses for the failure. For example, the failures in the checkout process might be happening because of

1. a software bug in payment gateway integration

2. network timeouts

3. database connection failures

For each hypothesis, we need to get data/evidence that could prove or disprove it. For example, we can monitor network latency and # of timeouts to validate network timeouts hypothesis.

Layer-by-Layer Approach

This method systematically examines each layer of the system, from user interface down to the infrastructure. It's like peeling an onion where we examine one layer at a time to find where the problem originates.

For our checkout failure, we'd examine UI, application, service, DB, servers, etc. one by one to figure out where the problem originates from.

The key difference between these two approaches is their starting point. Hypothesis-driven starts with working hypotheses and works to prove/disprove them. Layer-by-layer methodically examines each component. So the obvious question arises – which one do we choose?

The better approach among these is usually situation dependent. We can use Hypothesis-driven RCA when we have a strong understanding of the system and the issue, and therefore have strong hypotheses. This approach is also time-efficient as compared to Layer-by-layer approach, so we should use it in time critical situations.

We can use the Layer-by-layer approach when we are new to the system and don’t have a good understanding of the system to figure out the initial hypothesis.

Many times, we combine both methods: we start with quick hypotheses to save time, and then fall back to Layer-by-layer analysis if initial hypotheses don't pan out.

So most of the time (especially interviews), hypothesis-driven RCA is what comes handy because this is where we start. Hypothesis driven RCA is also where PMs contribution can come in because of their understanding of system design and other external factors. So let’s look at how to do it in detail.

Hypothesis-Driven RCA

In the popular literature, one of the key approaches to do RCAs comes from the manufacturing industry, and is called 5 Whys.

The approach was developed by Japanese car manufacturers. The 5 Why method suggests you to keep asking ‘Why’ repeatedly to reach the root of the problem.

For example, assume that there is water leakage in pipe A. You can ask 5 Whys and see where it leads

1. Why is there water leakage in pipe A? → It can’t support the water pressure

2. Why can’t it support the water pressure? → The pipe isn’t adequate to support water pressure in the area. Note that different areas such as hilly vs planes can have different water pressure owing to their unique requirements.

3. Why isn’t it adequate to support water pressure in the area? → The pipe was changed 2 weeks ago and the pipe wasn’t checked to see if it could support pressure in the area

4. Why weren't the specifications checked? → The standard check for correct functioning wasn’t completed.

5. Why was the standard check not completed? → The worker changing the pipe wasn’t trained on how to do standard checks.

We now come to know that lack of training is the root cause of water leakage. Here is a visual representation of the same!

5 Whys is a pretty useful method in manufacturing processes because there is

• Clear physical cause-and-effect

• Direct access to people involved who observed the process

• Visible physical evidence

All of this makes it easier to arrive at the root of Why the problem occurred.

But when it comes to solving technical RCAs, the approach doesn’t work that well because there are:

• Complex interdependencies due to system design

• Multiple parallel systems running concurrently that interact with each other

• Lack of direct humans involved in the chain who have observed the process

• Lack of physical evidence

And so 5 Why isn’t enough to do RCAs in case of technical failure. We need a new framework and that’s what we will discuss next.

Before we move ahead, quick announcement — I would be conducting a live session on ‘How to Vibe-Code in PM Interviews’ this Saturday. Please register for the Maven session if interested.

Register for The Session

RCA Framework - CHASoL

To solve the technical RCAs, we would recommend you a 5-step process:

Step 1: Clarify the problem and its context (C)

Step 2: Generate plausible hypotheses (H)

Step 3: Get data to accept hypothesis to arrive at root cause (A)

Step 4: Suggest short-term solutions that would fix the issue immediately (So)

Step 5: Suggest long-term solutions to fix the root cause (L)

Let’s take a problem we started with, and see how it can be solved using CHASoL.

“Imagine that you are a PM at Youtube, and you have seen the buffer time going up by 20% yesterday. What would you do?”

Step 1: Clarify

Clarifying the problem and its context is the most important step of the RCA because it defines the boundaries of the issue.

To understand the problem well, we need to understand the keywords used in framing the problem, boundaries of the problem, and the broader context of the problem like its implications on users and business.

Let’s talk about keywords first. Do we understand what the buffer time means for Youtube, and how we are measuring it? Most of the time, PMs know these keywords well, but if you don’t, don’t hesitate to clarify them.

Clarifying the problem also involves defining boundaries of the problem. Suppose the interviewers (or your devs) tell you that the buffering problem is limited to Youtube long-videos. That will help you narrow down the hypotheses set.

Lastly, it’s important to talk about the implications of this problem, i.e. what it implies in terms of user experience, business, etc. Discussing implications goes on to show that you as a PM can look at the problem more strategically and prioritize.

For example, buffer time increase may lead to lesser watch time, which in turn can lead to lower ad revenue. So buffer time increase affects both business and users in a negative way. These implications can help the problem get prioritized quickly.

The last bit that can be useful to look at is the impact of the problem. Scale and severity are two components of the impact. Scale determines how much users or business is affected. A popular feature will have a higher scale. Severity determines how much worse the problem is. Multiplying these two gives us the overall impact of the problem.

In the above buffering problem, suppose that the buffering issue is happening in 20% of video plays. Further, buffer time is 10% of overall watch time (overall watch time is sum of actual watch time and buffer time), which means that if a user watches a 9-minute long video, they also get 1-minute buffer time. This makes the issue high severity since the impact of UX is pretty high.

So now, we have a buffering problem which is limited to Youtube long-form videos, and affects 20% of views. Further, it impacts UX severely. All of this knowledge makes it a high priority issue.

Let’s move on to the next step now!

Step 2: Hypotheses Generation

We discussed earlier that understanding the system design is essential to generate hypotheses.

Along with system design, we also need a structured way to generate hypotheses so that we don’t miss any critical factor that could lead to an issue. MECE is a useful method for structured hypothesis generation. MECE stands for mutually exclusive, collectively exhaustive. It means covering all the factors exhaustively while also ensuring that these factors don’t overlap much with each other. Here is a good example of MECE where we break down the population by age. The groups are mutually exclusive, while collectively exhaustive.

As an example, while listing down the hypothesis for the Youtube buffer problem, we can say that it could be either an internal or an external issue. This sort of classification is MECE because

• It covers all factors (internal + external) and is therefore exhaustive

• The parts (internal, external) are also mutually exclusive.

To do RCA, MECE needs to be applied at multiple levels. This is where tree diagrams come in. Here is an example of a MECE tree diagram with two levels.

It’s called a tree diagram because it resembles a tree that can have two branches, and those branches can have multiple branches further. Tree diagrams help us break down the issue deeper without missing anything important.

Let’s apply system design and MECE to generate hypotheses for the Youtube video buffer problem.

MECE

We can start by saying that the issue could be because of internal or external factors.

Internal Factors: System Design

Buffering can happen because of any of these points in the system failing to deliver. The video request data flows from

User device → ISPs → CDNs

If the video isn’t available in the CDN, the request can go from

CDNs → load balancers → Youtube servers (Ads + Video)

Post request processing, the data flows backward. The issue could be at any point of the system in that flow as well.

The internal factors could be related to

1. App issues (say a bug that got introduced due to recent app/web release)

2. Infrastructure issues like issues with CDNs, load balancers or servers (Ads + Video)

3. Configuration issues

External factors: The external factors could be

• User device, browser, or OS causing problems

• Issue with ISPs

• Local networks like mobile data providers not working properly

Step 3: Accepting/ Rejecting Hypotheses

To validate hypotheses, we need to look at the right data that helps us select or reject a particular hypothesis.

We need to look at three sets of data while validating hypotheses:

1. Strong correlation between an event related to hypothesis (an internal event like app release, or an external event like sudden traffic surge) and the issue

2. Do metrics that we are logging support the hypothesis?

Let’s look at hypotheses one by one and accept/reject them. We will use brackets to provide answers to help us understand whether to accept or reject the hypothesis.

App issues

• Have we done a recent release that coincides with the buffer issues? (Yes, we looked at the deployment logs, and noticed that a new major app update was rolled out yesterday on mobile. The timing broadly matches when the buffer time starts increasing)

• Do metrics that we are logging support the hypothesis? (We can next look at the buffer time of other app versions yesterday. These versions would be available on user devices who didn’t have the latest version. Suppose we don’t find a buffer issue on those versions, we can be almost sure that this is the likely cause. Next, we have to just go through the checklist to ensure there aren't any additional problems)

Infrastructure issues

• Have we made any changes in the infrastructure layer that coincides with the buffer issues? (No)

• Have we seen any metric uptick/downtick in the infra monitoring dashboard? Specifically, have we seen a significant traffic spike because it can lead to buffering problems. Or have we seen any other abnormalities in the CDNs, load balancers, or server metrics? (No, we can reject this hypothesis)

Configuration issues

• Have we made any changes in the config that coincides with the buffer issues? (No, we can reject this hypothesis)

User device, browser, or OS

• Is there a user device, browser, or OS where this problem is worse? (No, except we have seen this buffer time increase on mobile devices only which supports the app update hypothesis)

ISPs and Local Networks

• ISPs are local to certain geographies. Have we seen this problem concentrated in certain regions? (No, we can reject this hypothesis)

ROOT CAUSE: By now, we have confirmed that the mobile app update introduced the issue. We asked the team what it was about and got to know that we had changed the video pre-loading logic for long-form videos. Video pre-loading logic is essentially the logic using which a video player loads a portion of the video content before it's actually played. We can further see the logs to check when exactly the buffer time is increasing in a user session. We find that it happens at the beginning of the video.

Step 4: Solutioning

In real-life product development, we tend to figure out how to resolve the issue immediately first. We should do that when we talk about the solution in interviews as well.

Immediate actions here would be to roll back the mobile app update

Step 5: Long-term Solutions

Long-term solutions would focus on how to avoid this problem entirely:

• Implement stricter performance testing before the release

• Monitoring for buffer time anomalies

• Implement staged rollouts so that the impact isn’t very high on UX

Further Reads: Real-World Issues and How Teams Solved Them

So now that you have understood RCAs well, where do you go next? You can read and understand real-world issues if you would like. Learning about real-world issues helps you in two ways. First, it builds the confidence that you can understand real-world RCAs well. Second, it expands your knowledge around technical vulnerabilities which over time can help you avoid these for your own products.

Rather than creating a simplified write-up, I would like you to go directly to the blogs written by the teams at companies like Meta, Stripe, Netflix and read them. Use AI and the internet to understand what you don’t. Afterall, no one understands every technical term/issue on the planet, not even the best engineers.

Meta, 2021

When Facebook experienced its massive outage in October 2021, it wasn't just Facebook that went dark - all of its family of apps including WhatsApp, Instagram, and Oculus became inaccessible simultaneously. This six-hour outage affected billions of users globally and cost the company approximately $100 million in lost revenue. The scale and severity were unprecedented, with a complete service unavailability across all platforms.

A good way to gauge how far you have come in doing RCAs is to read their blog and see how well you can understand it -

Update about the October 4th outage - Engineering at Meta

Stripe, 2019

On 2019-07-10 from 16:35 to 17:02 UTC, and again from 21:14 to 22:47 UTC, the Stripe API was severely degraded. A substantial majority of API requests during these windows failed.

Here is an RCA written by the Stripe team. Go through it and see for yourself how a well-written RCA looks like:

https://stripe.com/in/rcas/2019-07-10

Netflix, 2012

On Christmas Eve 2012, Netflix's streaming service went down for customers across the Americas for about 12 hours. The timing was particularly problematic as it occurred during what is typically one of their highest-usage periods.

Here is an RCA written by the Netflix team. It is a good example of what an infra failure looks like:

A Closer Look at the Christmas Eve Outage | by Netflix Technology Blog

This would be all about conducting RCAs. As mentioned earlier, this is an excerpt from one of the modules of ‘Advanced Tech and AI program’ I run. Applications are now open for September Cohort. Do check it out!

Advanced Tech and AI Program

Thanks,

Deepak

16,000+ smart, curious folks have subscribed to the growth catalyst newsletter so far. To receive the newsletter weekly in your email, consider subscribing 👇

Subscribe now

Let’s dive in the topic now!

It’s been a while since companies changed how to conduct PM Interviews. The usual rounds of PM interviews are product sense, analytical, technical, and behavioural rounds. For more senior roles, we add strategy, growth, and leadership on top of these skills, though they don’t result in separate rounds. Product sense becomes product sense and strategy, analytical becomes growth, and behavioural becomes leadership. This format is what we can expect more or less across companies.

So when a candidate posted that he had gotten into a vibe-coding round for the Google AI PM role on Reddit PM community , it caught the PM community by surprise.

I had two unrelated thoughts that I shared last week on LinkedIn also. First, the post shouldn’t be treated as truth. The hiring manager rounds happen at Google for team matching, and aren't a part of initial set of 4-5 rounds. They happen after the candidate has cleared the initial rounds. Google recruiters are pretty consistent about telling you what to expect in interviews. So maybe it’s true, maybe not.

The second thought I had is vibe coding will inevitably become a part of PM interview process. It’s already happening for AI PM roles as few folks in the AI live cohort that I run told me, and it will happen for even traditional PM roles eventually. The reason is pretty simple - for the first time in the history of product management, we don't have to rely on subjective questions to see what a candidate can do. A vibe-coding round can reveal their technical know-how of the candidate, their design sensibilities, and decision-making.

So the question we should be asking ourselves should be — WHEN companies will adopt it, not WHETHER they will adopt it. And that’s where this post seemed relevant to write. In this post, we cover

• what’s vibe-coding

• relevance of vibe coding for Pms

• key concerns PMs have around vibe-coding round,

• skills required to master this round,

• key categories of questions and motivation behind them,

• a set of 40+ questions that are being asked/ can be asked in this round

• evaluation criteria

• interview formats

• framework to use in this interview

As for how to solve these problems, I believe that live session is a better way to teach that. So I would also be conducting couple of live sessions around ‘How to vibe-code in PM Interviews’. With this post, and the upcoming sessions - you should be able to master the round. You can checkout the session here

Checkout the Live Session

So let’s start with the first question — what’s vibe coding.

What’s Vibe Coding

Vibe-coding is a term coined by Andrej Karpathy, a popular AI engineer who has been part of Tesla, OpenAI, etc. Here Karpathy explaining it —

In simple terms, vibe coding is coding an app via natural language such as English. You put a prompt in a coding agent tool such as Lovable, Replit, Cursor, etc. and the coding agent writes the code. At times, it does everything perfectly, starting from design to code to QA. At other times, it fails by encountering an error, or can’t debug the code issues.

The important thing is that you can give instructions in plain English and it will be able to write code around the instructions. That means PMs can do it, and so could 90-year olds.

Relevance of Vibe Coding for PMs

Given the capability we have at hand, companies expect PMs to prototype an idea using these AI tools. The prototype could be a simple static design, or a dynamic app with a fully functional backend. Prototyping an idea quickly has major benefits - you could show it to customers and get feedback, show it to leadership to get buy-in, and present it to cross-functional teams like business and marketing in the roadmap session. That’s why when it comes to PMs, we prefer to refer it as AI Prototyping, rather than vibe coding.

If it’s so useful, are many PMs aware of this and working towards this? DEFINITELY! 3 months back, I created an entire free AI Prototyping course for PMs and Founders around it and more than 3,000 PMs have completed this course. That tells you that many PMs are learning this skill, and applying it. You can access the course here

Key Concerns

The first concern that is re-surfacing for tons of PMs — Do you need to learn to code? The short answer is No. A better questions to ask would be — Do you need to understand how technical systems work, how bugs get resolved, etc.? The answer to this question is YES!

To elaborate, you need to understand how to define database schemas, commons bugs and how to debug them using AI prototyping tools, etc to be good at this skill. I come from a non-tech background, and over time, I have also started reading the code while building these prototypes. I wouldn’t recommend you to read the code when you are starting, but I definitely see you graduating to it organically. If you don’t know where to start, start by going through the free course I mentioned earlier, read this post thoroughly, and join the upcoming live sessions.

Once people become comfortable with ‘learn to code’ question. The next set of questions are around —

• what skills do I need to crack this round, and how to acquire them?

• what kind of questions do we get asked in this round?

• can we get a set of questions being asked so that we can practice?

• what framework do we need to follow for these interviews?

These questions is where we are going to focus on next in this post.

Skills and How to Build Them

The skills that you need to crack this round is — AI prototyping, technical system design, and root-cause analysis.

You can learn fundamentals of AI prototyping from the course I mentioned earlier. It will arm you with sufficient skills on how to use various tools like v0, Lovable, Replit, etc.

Technical system design has been part of technical rounds for PMs for a long time. If you lack the foundational knowledge, please read the book Tech Simplified. You can also go through another post I wrote about this round a while back on how to crack technical round of PM interviews.

Root cause analysis is finding the reasons behind a bug, and fixing them while vibe-coding. This is the hardest skill to master among the three, and should be focussed on once you have done the first two. We will show how to do it in the upcoming Maven sessions.

Now that we understand the core skills, let’s move to types of questions that can be asked in this round.

Question Categories and Motivation

Questions that can surface in these interviews are of 3 kinds. It is quite important to understand the intent behind these questions to answer them well:

1. Design a product (UI only): This question can be asked at junior PM levels to gauge their design sense. We can see this happening in product sense interview rounds.

2. Design an AI prototype for a fully functional product (UI + Backend): We can see this happening in technical rounds for both junior and senior PMs. It let’s the interviewer see if the person can do quick prototyping, system design, and RCA.

3. Design an AI prototype for a fully functional AI product (UI + Backend + APIs from LLMs): We can expect to see this happening in AI PM interviews. It let’s the interviewer see if the person can build AI products - quick prototyping, system design, API integration, temperature adjustment/ context engineering and RCA.

All PMs need to focus on category 1 and 2. AI Product Managers need to focus on the category 3 as well.

So what kind of questions get asked in this round? We are still learning, but I will share a set of questions you can expect based on both primary and secondary research we have done.

We would be running 3rd cohort of AI Product Management, starting September. We help PMs learn and build production-ready AI apps in this program. The applications are open now. Please check the program and apply if interested,

Advanced AI for PMs

Sample Questions

If you are looking at for a question bank of real questions around this, it doesn’t exist yet. But we can be reasonably sure they look like the ones below. I would recommend you to focus on skills first, and solve 3-5 questions of each kind to be well-prepared. Note that some of these questions are of advanced levels and for senior PMs, and you should start simple and gradually move towards those.

Category 1: UI-Only app (Design)

Tools: Lovable, v0, Bolt, Claude Artifacts

Landing Pages

• Create a landing page for a meditation app like Headspace that converts users to sign up

• Build a pricing page for an AI SaaS product with 3 tiers and feature comparison

• Create an onboarding flow for a travel booking app such as Agoda

• Build a signup form for an eCommerce portal

Interactive UI and User Flows

• Build a task management software interface home page

• Design a settings page for a D2C brand

• Create the home page of an e-commerce site

• Create a multi-step checkout process for an online store

• Build a user profile creation flow for a social media app

• Design a search interface for an ed-tech marketplace

• Create a feedback form that adapts based on user rating

• Build a dashboard for a fitness app showing progress metrics

Category 2: Full-Stack app (UI + Backend)

Tools: Replit, Cursor, Lovable, etc.

General Apps

• Build a simple CRM system where I can add, edit, and delete customers

• Create a expense tracker that categorizes spending and shows monthly totals

• Build a book library management system with search and borrowing features

• Design a project management tool where teams can create and assign tasks

• Create a restaurant reservation system with availability checking

Real-Time Apps

• Build a chat application with real-time messaging

• Design a voting/polling app with live results updates

• Build a live comment system for a blog or article

Transaction apps

• Build a marketplace where users can list and purchase items

• Design a food delivery app with restaurant listings and order tracking

• Build a booking system for services with calendar integration

API Integrations

• Connect your app to a weather API and display current conditions in a location

• Integrate with a payment provider to process transactions

• Build a news aggregator that pulls from multiple RSS feeds

• Create a social media scheduler that posts to multiple platforms

• Integrate with Google Maps APIs to show nearby locations

Category 3: AI Products (Full-Stack + LLM Integration)

If you are a traditional PM, you should skip this section unless you are preparing for an AI PM role.

Tools: Replit, Bolt, n8n, etc.

AI Applications/ UX

• Build a customer support chatbot that can answer FAQs and escalate to humans

• Create a content generation tool that helps users write marketing copy

• Build a personal finance advisor that provides budgeting recommendations

• Create a language learning app with AI-powered conversation practice

• Create an AI-powered job matching platform that scores candidate fit

• Build a travel itinerary generator that creates custom trip plans

AI Workflows

• Build a meeting summary generator that extracts action items from transcripts

• Create a content moderation system that flags inappropriate text or images

• Build a prompt template generator for different social media platforms

• Create an AI writing assistant with different tone and style options

• Design a data analysis tool that generates insights from uploaded CSV files

Advanced AI Apps

• Build a multi-modal app that can process both text and image inputs

• Build an AI-powered A/B testing framework that optimizes experiments

• Create a smart inventory management system that predicts demand

Before we get into the framework, it’s useful to talk about what sort of evaluation criteria such interviews have.

Interview Evaluation Criteria

While it may feel like vibe coding rounds are about flawlessly using the tools, that’s isn’t the truth. The skills that interviewers are evaluating are technical knowledge and execution, product sense, and communication.

Technical knowledge and execution

• Can they translate broad requirements into working prototypes?

• Do they understand basic system design?

• Can they debug and iterate when things don't work?

• How well can they structure their prompts and commands?

Product sense

• Do they ask clarifying questions before building?

• Can they prioritize features for an MVP?

• Do they understand user experience nuances throughout the process?

• Can they make intelligent assumptions and validate them through prototype?

Communication

• Can they explain their thought process while building?

• How do they handle ambiguity and make trade-offs?

• Can they present their prototype effectively?

• Can they present their prototype effectively? In interviews, this is akin to keeping interviewer in the loop on whatever you are thinking, and asking for explicit permissions at times.

To judge candidates on this evaluation criteria, companies conduct this round in various formats.

Interview Formats

Format 1: Live Building Session (45 mins)

"Use a tool of your choice to create X feature" in real-time. You really need to master a tool before appearing for these rounds.

Format 2: Take Home Assignment (1-2 days)

Candidate gets it as a take home assignment. The assignment could be a complex multi-feature application. Once done, they can share it to the recruitment team. In this case, it becomes a screening criteria.

Format 3: Take Home Assignment + Real-time Presentation (1-2 days)

This is similar to case studies that companies ask candidates to work on, and present to a panel. In this case, they can gauge your strategic thinking and technical depth, along with your presentation skills.

Personally, I love both formats 1 and 3.

So now that you know almost everything there is to know about this interview, let’s talk about the framework

Framework for Vibe-Coding Interviews

We don’t have to re-invent the wheel when it comes to vibe coding interviews. It’s the same process we follow in detail while we are doing it at the job.

1. Clarify: Ask clarifying questions about users, goals, and constraints

2. User segments

3. Prioritising a segment and their needs

4. Solution: Narrate the solution/ core features, and list nice-to-haves

5. MVP System Design: Explain technical decisions. Take feedback on system design.

6. Coding MVP: Build the MVP by using one of the AI tools. Talk about it while building, gather feedback, etc.

7. QA: Do a comprehensive QA, and debug systematically.

8. Success criteria: Define the success metric and guardrails of this product (optional)

This is already a long post, so this is where I want to wrap up this post.

In the Maven session, we will show you how to solve 1-2 of such problems with the tools. You would also be able to understand nuances of this framework. Go through the post again before joining the session.

Register for The Live Session

Thank you for reading the post. See you next week,

Regards,

Deepak

This post is about providing the framework to help you assess and build deployment-ready AI products. But first, let’s talk about why AI pilots fail.

Why AI Pilots Fail

Suppose you launched a website for selling a software product (like Zendesk selling support software) worth 1000s of dollars. Since the cost of this software is high, you hired few sales people. You turned on the marketing campaigns and asked your sales team to start calling people who fill the interest form on the website.

What do you do when your website generates more form submissions (also known as leads) than your sales team can handle? Businesses have struggled with this question since long before websites came in. The sales team in the offline world used to identify and prioritise leads based on their likelihood to convert into paying customers. This way, they could get more ROI from their time.

We do a similar thing when it comes to website leads. We look at user profile data (how many employees, revenue, etc.), and their activities on website (clicks, time spent, etc.) to gauge interest. We have built AI models for lead scoring, which provide a high score for leads that have higher probability to convert. Salespeople are supposed to call leads with high scores only. You might mis-score some leads, but your productivity savings by not calling bottom x% can exceed the cost of mis-scoring.

While lead scoring works in many situations, it doesn’t work in situations where cost of mis-scoring > productivity savings. Now, this can happen in high stakes situations where software you are selling costs >$10,000. This can also happen in situations where the bottom x% that you are confidently rejecting isn’t high enough to get good productivity gains.

The above example shows how the same AI model that’s useful and reliable for one product can be problematic for another. So how do we classify which tasks to solve using AI, and in what way? Enters AI Capability Matrix.

AI Capability Matrix

AI Capability Matrix has 2 dimensions on which you have to evaluate every task — output verifiability, and task complexity. Let’s discuss them one-by-one:

1. Verifiable Output: Output verifiability means that either machine or humans can confirm the answer quickly, cheaply, and with high confidence. Addition of two numbers like 2+2 has a verifiable output (4). But predicting the features that will work for a particular product isn’t.

2. Complexity of Task: The second dimension is the complexity of the task. A more complex task is harder to perform. We define task complexity wrt human because it directly correlates to productivity gains. Classifying an email as spam vs non-spam is an easy task. Writing code to create an app is a hard task. So if the machine write code to create an app, it can lead to high productivity gains.

Before we apply this matrix, we need to separate high stakes vs low stakes tasks. A high stakes task is the one where the downside of mis-calculation is high. An example of a high stakes task is diagnosing critical illnesses. You can think of it as the 3rd dimension of the matrix, but for the ease of understanding and application, we will classify the tasks into high vs low stakes, and then apply the 2x2 on complexity and verifiability.

Low Stakes

Let’s take some low stakes tasks that can be done by AI, and try to put them on the 2x2 matrix

1. Classify email as spam/ no spam: This is easy to do for humans, and easy to verify as well.

   

2. Code to convert markdown to PDF: This is hard to do for humans because they have to learn how to code, but easy to verify whether the conversion has gone well by just looking at the final output.

3. Writing email subject line: This is easy to do. However, it’s hard to verify if the email subject line will lead to higher open rate.

4. Planning a two-day vacation itinerary: Hard to do for humans since it’s time consuming. It is also hard to verify whether you have the most optimal plan without actually experiencing it. Since it’s a two-day trip, we have put it in low-stakes situation. A two-week trip with a toddler is what we can call a high-stakes situation.

   

How to Apply AI in Low Stakes Situations

Let’s talk about how to apply AI in these situations

1. Classify email as spam/ no spam - easy to do and easy to verify: Such tasks can be done by machines (Gmail does it for you) with occasional inputs from human evaluators to check if the AI model we built for this is working well.

2. Code to convert markdown to PDF - hard to do, easy to verify: Such tasks should be delegated to machines because they can lead to good gains. Let AI do the task, and put human to review the final output and accept.

3. Writing email subject line - easy to do, hard to verify: Using AI here can assist humans in reducing their cognitive load. So we can go for a maker-checker flow here. The AI creates a subject line, and humans verify and accept it. Below is what Copy.ai generated when given a prompt/ description — ‘email to newsletter subscribers on how to assess AI projects’

   

4. Planning a two-day vacation itinerary - hard to do, hard to verify: Humans need to spend a major amount of time redoing and verifying such tasks, so AI can get started on the task but co-piloting and verification is necessary throughout the task.

   

So by now, we have seen that even in the low stakes situation, the design choices of a product like a ‘Spam filter in Gmail’ can be significantly different from ‘Subject line generation in Copy.ai’ because one is easy to verify and the other isn’t. The major gain here is in situations which are hard/ complex for humans to do, but have an easily verifiable output. This is why single-click Landing Page Generators are all the craze :)

Let’s talk about high-stakes situations now.

High Stakes

In high stakes situation, let’s cover each quadrant one-by-one

1. An AI that highlights missing signatures in standard loan documents: This is easy to do and easy to verify task. We need to always have a human-in-the-loop because a rejected loan due to absence of signature would affect an individual gravely, without a mistake of their own. Further, if the system passes a loan document that doesn’t have a signature, the company stands to lose in a dispute in future. Using AI here acts more like a 2-factor authentication, and reduces human errors.

2. Building an end-user MVP product using coding agents: This is hard-to-do and easy to verify. It can be tested easily by both humans and machines. Because it’s easily verifiable, you can get maximum productivity gains here by deploying AI. This use-case is so popular that we have a new name for it ‘vibe-coding’, thanks to Andrej Karpathy :)

3. AI Therapist: It’s hard to provide good advice as therapist. And it’s also hard to verify whether it’s the right advice for an individual. What makes it even harder to verify is that such transcripts are confidential. High stakes and hard to verify situations is where we should be highly skeptical of AI. It can only be used as an assistant to a professional, like an assistant to therapist but can’t work on it’s own even with some verification. Even if AI Therapist apps are working now for some, regulators are going to disallow such use-cases because of the inherent risk. We can see some studies coming around it already

3. Transcribing verbal drug doses: This is easy to do and hard to verify task since it’s hard for anyone else other than the doctor to catch a mistake in transcription. So such problems needs a multi-layered approach. AI transcribes it, but doctor has to review and sign it. Another example of this is Grammarly spelling-and-grammar check. Having such mistakes in high stakes situation like a book going out for print, or crucial emails can be problematic.

The entire matrix can be summed up as follows:

To summarise the recommendation, what we realise is that in high stakes situations, we need humans to either take a lead when verification is hard, or still verify as 2-factor authentication) when verification is easy.

Final Note

In both high stakes and low stakes situation, the tasks that easy to verify are being solved by AI. The reward is high in cases where the task is hard to do — multiple coding agents like Cursor, Replit, Copilot, etc. valued at $1-10B are a proof of this.

When it comes to tasks with no clear verification loop, AI does well in helping users reduce cognitive load by providing preliminary research. Like ChatGPT is a much better version of search, which helps people browse information across the Internet. AI can act as a great assistant when you have expertise in an area.

But when the stakes get high in unverifiable tasks, we should avoid relying on AI entirely since the downside is simply too high. A bad advise from LLMs in medical diagnosis can be disastrous.

The key takeaway here can be that many problems can be solved reliably if we deploy a human-in-the-loop. Some problems require an expert-in-the-loop as well. And few problems shouldn’t be solved by AI, even if AI provides a plausible solution there.

I hope the post helps you with some clarity on a topic most companies are struggling with.

If you are wondering how product management tasks fare on AI Capability Matrix, Subscribe to get the next post around it in your inbox!

Subscribe now

Thanks,

Deepak

As a part of this exercise, the next logical step is to look at broad areas of product management - Growth, Product Sense, Strategy, and go deeper into it. In this post, let’s look into how Growth PM gets affected by advances in AI.

In case you missed our last email, here is the complete AI Prototyping Course for Free (10+ hours recording of live sessions)

Free AI Prototyping Course

Skills of a Growth PM

Growth is a loosely defined function in product management, in that it could mean various things — getting users to the product, managing churn, monetisation, etc.

All of it requires a set of growth skills. To understand how we can use AI to grow products, we can start by listing down these skills and then see how AI impacts/ enhances these skills.

1. The first skill is getting a product from 0 to 1 — attaining product market fit. This includes defining PMF, measuring PMF, and improving it consistently to get to a strong PMF

2. The next skill is understanding how to get users on the product using product. For example, referral is a good example of getting users on the product through existing set of users.

3. Once the user is on the product, they need to experience the value that the product offers quickly and in the right way. We call this step activation. Activated users (users who have experienced value once) tend to stick to the product longer, and hence this becomes a focus area for the team if the metrics down the funnel like retention, and monetisation, aren’t healthy.

4. Once you get the users activated, you as a Growth PM need to figure out how to get them back to the product again and again. Retaining users, or strong retention is the hallmark of a good product. This is where core product teams working on the product offering also get involved. These core product teams can work with Growth teams to move retention up.

5. So far, we have only talked about the user. Another stakeholder of product teams is the business. We need to monetise the product to create a sustainable business. It’s a common myth that monetisation happens after retention. In many education products like Unacademy, Reforge, etc, the monetisation happens upfront before access to the course is provided.

6. Beyond the five skills we have listed above, there are few skills which are horizontal in nature, i.e. they can be applied across. Designing experiments, or A/B testing is an important skill for any growth PM. It helps the team move faster and gain quick wins.

7. Data is a another super important skill of Growth PMs. Data informs your experiments, help you track the progress, and also helps you predict growth.

8. The last skill is building a coherent growth strategy and roadmap, which is needed when to move to product leadership roles. A subset of this skill is Growth prediction through mathematical models.

AI’s Role in Growth

Now that we have listed these skills, let’s look at how AI impacts these skills. Collating the impact across skills can tell us the role of AI in growing products. Note that I don’t cover the impact exhaustively in this section, but I plan to do it in a live session next week. The link for the live session is available at the end of this post.

1. Product-market fit: AI lets you prototype quickly. This means that iteration cycles can be extremely fast. A fast iteration cycle allows you to test multiple ideas and hypothesis quickly. You can also use AI to analyze user feedback and identify pain points faster.

2. Product-led acquisition: As building products becomes easier with AI, we will see many companies offering sophisticated features for free as an acquisition strategy. We will also see AI-led or assisted content strategies.

3. Activation: Activation is where AI can play a transformative role. Think about an AI assistant that guides users through onboarding, which adapts experience in real-time based on user behavior and preferences. AI can also identify friction points in real-time to resolve them. All of this can dramatically increase activation rates compared to static onboarding flows.

4. Retention: Engagement is a leading indicator of retention. AI can be helpful by increasing velocity of features or content to engages users more. This, in turn, will increase retention. AI can also be useful in conducting and summarizing user research around churn.

5. Monetisation: Monetisation models are many, and what works for a business doesn’t work for another. Sometimes, an innovation in monetisation model can disrupt an entire industry like subscription did with SaaS. While AI can’t take monetisation decisions with conviction, it can be useful in brainstorming novel pricing models. It can also help you quickly gain understanding of similar industries and help you cross-transfer learnings.

6. Experimentation: AI excels at hypothesis generation by analysing user behaviour or user research documents. It can also help prioritize which experiments to run. While Growth PMs need to make the final decisions, those who leverage AI for experiment design may be quick in testing more ideas with higher success rate.

7. Data: Natural language to query translation is available now as a technology. Growth PMs can now ask sophisticated questions about retention cohorts or conversion funnels in plain English and receive instant visualizations and insights. This faster data exploration and analysis means more informed decisions.

8. Growth roadmap and strategy: Domain research in the AI era has changed. AI can synthesise competitive insights, market trends, and user trends. It can help you identify gaps in the market that competitors haven't gone after. AI can also help in sophisticated forecasting. All of this can make you more confident in growth strategy and roadmap.

Live Session: Using AI to Grow Products

In the session, I plan to cover how AI impacts these various skills, and what to do about it. The session assumes that you have broad familiarity with product management and broad familiarity with growth terms. If you didn’t struggle understanding this post, the session will be useful to you.

Here is the registration link for the Maven session

Register for the Session

This would be all for this post!

>1000 people have accessed the course recordings since we made it live. Many folks have already built prototypes after completing this program.

About the Course

Aimed at helping non-coders build functional prototypes using AI, the course covers the following:

Session 1: How to build a UI-only app

Session 2: How to build a full-stack app

Session 3: How to build an AI chatbot

Session 4: How to build AI agents

Each session is 2-3 hours long. The tools that we use in the course are Lovable, v0, Chatbase, Replit, LangGraph

You can access the full-course here: https://www.pmcurve.com/program/prototyping-with-ai-for-pms-founders

Thanks,
Deepak

Andrew Ng wrote about AI product management in one of his recent essays,

The demand for good AI Product Managers will be huge. In addition to growing AI Product Management as a discipline, perhaps some engineers will also end up doing more product management work.

The Gap

The skills of an AI product manager are quite different from a traditional PM. While a traditional PM role is focussed on user research, roadmap planning, and success metrics, the AI PM roles requires additional skills on top of these traditional PM skills.

These additional skills is what we are going to cover in today’s post. We will also talk about tools that are relevant for AI PMs. These skills and tools are directly borrowed from the course I am building around AI product management starting next month.

Check the AI Program

Skills and Tools of an AI PM

To understand the skills needed for an AI PM, we need to understand the process of building AI products, and how it’s different from building usual software products. On a broad level, the lifecycle can still look like the usual cycle of plan-build-deploy, but the nuances are pretty different for each task.

Let’s look at various skills and tools.

Technical Proficiency

Before diving into AI-specific skills, you need to understand how complex technical systems work together. Remember that you aren’t just talking to front-end and back-end developers anymore. You are also talking to data scientists, AI engineers, and data engineers, etc. You would be able to effectively collaborate only if you are technically proficient in system design, RCA, etc.

The next thing you require is foundational knowledge of AI/ML. This includes different approaches in machine learning like predictive vs generative, supervised vs unsupervised, the subclasses like deep learning, etc. You also need to have a decent understanding of limitations of these techniques.

The technical proficiency also helps you read papers in the field of AI. The field is evolving fast, and those who can stay updated by reading these papers have a distinct edge.

Discovery and Prioritisation of AI Use-cases

PMs are good at discovering general problems of a user, but determining whether AI is the right solution requires specialised knowledge. As we discussed in the last section, having the foundational knowledge of AI/ML can be useful. Beyond that you would also need to assess data availability, ROI calculation for AI projects, broad implementation details, timelines, capabilities needed within the team to finalise what you need to build.

The prioritisation will also require impact calculation of such projects, and benchmarking of impact from similar projects across industries.

Some of the tools that you could find useful in this stage are tokeniser like this one from OpenAI, pricing calculators for compute and storage, AI-specific industry reports like this one from Stanford, etc.

AI Product Design

AI products have specific challenges when it comes to design. For example, the generative AI products may hallucinate and provide misinformation to the end user. This could be pretty risks in some situations if not handled well. For example, a Texas A&M University-Commerce teacher gave his entire class a grade of "Incomplete" because when he asked ChatGPT if the students' final essays were AI-generated, the tool told him they all were, even though detecting such text is outside.

So we need to design interfaces that that handle hallucinations, uncertainty, etc.

We need to understand how surface these features, how to help people write effective prompt, handle errors gracefully, etc.

This area of AI product design is still evolving. Leading companies such as Google, Microsoft, etc. keep publishing stuff as they learn. Here is design.google sharing few tips/concepts — https://design.google/library/people-ai-research

AI Engineering

AI engineering covers designing the right model and architecture for a use-case and deploying it. While you aren’t expected to do it yourself, you need to be actively involved in the entire process. Just as a PM needs to sit through architecture discussion in usual software development, you need to sit through discussions around model selection, architecture, and cost implications of the choices.

Let’s take model selection for an example. To shortlist few model initially, you need to give few relevant prompts to different models and evaluate their responses. A PM can do this job better than most since they have broader context of customer needs, business needs, etc. If a PM isn’t involved in model selection process, they will be limited by the model that team chose. And since they don’t have an understanding of other options, they will fail to see what could have been an optimal choice today or in future.

Some tools and concepts that PMs needs to explore in this stage are Scale Spellbook, RAG implementation using Langchain, Vector databases, multi-modal UX, etc.

AI Agents

Agentic AI is where you don’t need to think and guide with continuous prompts for AI to work for you. An AI agent can take a broad instruction, create an execution plan, and implement it by itself without much human supervision.

An AI PM needs to understand how agents work, and the process of building them.

Understanding tools like AutoGPT, OpenAI Operator, Semantic Kernel, n8n, etc. can be pretty useful in building agents.

Evaluation and Improvement of AI Products

PM needs to evaluate when a particular AI product or feature is working as intended. In software, it’s done using acceptance tests. For AI products, the evaluation process isn’t so simple and we need to design comprehensive evaluation frameworks for the product we are building.

Besides testing the product, evaluation process helps in identifying improvement areas for AI products. The improvement in AI products can be made in various ways - by managing dataset quality and bias, providing human feedback via rating, or by providing sample answers written by humans. A PM needs to work with the AI engineering team to evaluate cost and benefit of these different options. For example, getting sample answers written by humans can be pretty time and money intensive.

Relevant tools in this stage could be OpenAI Evals, Huggingface, Arize AI, etc.

AI Safety

A major part of evaluation process is making AI safe, unbiased, and ethical. Evaluation process also helps in identifying these safety risks.

Relevant tools in this stage could be AI Fairness Checklist from Microsoft, responsible AI papers from leading companies such as Google, Anthropic, etc.

Pricing and Positioning of AI Products

AI products have unique characteristics that significantly impact how we think about their value and pricing structure. For example, when you use a traditional word processor, it works the same way every time. But an AI writing assistant might improve as it learns from user interactions, making it more valuable over time. So how do you price in this additional value and charge your customers when most b2c traditional word processors are free (most)?

Understanding cost structure, pricing models, pricing research strategies, and consumer willingness to pay is key to build pricing strategy for an AI product.

Positioning is crucial for AI products, as it helps the users understand the value proposition of your product. This requires you to understand the value metrics, and use segmentation + differentiation to craft a clear positioning.

Product Growth and Strategy

Lastly, any product without growth in initial stages will not service. Your AI products and features needs to grow, and the growth strategy need to use special features of these products such as novelty, community, etc.

The AI product also needs a long-term strategy to build moat, keeping in mind that the AI landscape is emergent.

This would be all for the post. As I mentioned earlier, the Advanced Tech and AI course is starting next month. The first cohort will only take 40 students, and I plan to be pretty involved (1:1) for this cohort. The first shortlist goes out tomorrow evening. So please apply if the program feels right for you

Check Advanced Tech and AI Program

Thanks,
Deepak

Here are some apps that learners have built

https://ai.pmcurve.com/

Ankit built a landing page for his new company, and I love it

Sambhav built this bedtime tale generator!

And Archit built this game

You can see all the apps here — Here is What I Built

The best part is that I built this page using AI. You can showcase your own products by submitting the form on the same page.

Next Session Registration

You can register for the next session here: https://lu.ma/shap8ufk. It’s scheduled on 19th Feb (Wednesday, 9 PM IST).

Session Recordings

In the second session, we covered evals and used lovable.dev to build an app with both front-end and backend.

The recordings can be accessed here on our custom learning platform —

Get the Session Recording

Hope to see you in next session,

Deepak

Both of these modes are extreme and counterproductive. What one needs is measured, selective engagement with AI by focusing on the developments relevant to our work.

The next question becomes: how do we adopt such measured approach for our professions? This post is written with an aim to answer this question for product management professionals.

Answering this question is difficult because of two reasons. First, AI is a rapidly emerging field. Every week, we are hearing about novel developments. So even if we can create a list of things that AI can do/help today, it won’t be valid probably next quarter. Second, the context of the organisation matters when using AI professionally. This is because each organisation has a different level of reception of AI. Add to that, the effectiveness of AI is uneven across topics and domains.

We would like to focus on solving the first problem — how do we create and maintain the list of things AI can help with? Once we solve the first problem, I have confidence that PMs can apply it in their organisation because they understand those complexities/hurdles well.

To create a list, we will start with a simple task classification framework. This framework can help us assess how to look at tasks in context of AI. As a step 2, we can take most of the tasks that PMs are supposed to do, and show how we apply this framework.

While the list of tasks will be long, going through them one-by-one will give you the confidence to apply it yourself. One clue that you have become comfortable in applying the framework is if you start getting bored towards the end. That means, you are able to predict what I am going to write for the next task and the task after that :)

Advanced AI for PMs Course

Lead-Edit Framework

One of the concerns that PMs have around AI is whether it is going to replace them. It’s a legit concern, but doesn’t take us anywhere since we can’t predict the future. What we can do today is focus on how AI can enhance PM skills by performing tasks relevant to a skill. To know which ones it enhances, doing a task by task analysis is useful.

A simple classification framework that I would propose is Lead-Edit Framework. All tasks can be classified based on whether the PM has to lead the task (and AI can assist), or edit the task mostly done by AI.

There are four categories in this lead-edit framework:

1. PM-led tasks (AI-assisted): These are the tasks where AI can help PMs become more productive. The primary control lies with humans. For example, to create a product roadmap, we need to combine the org knowledge, market research, and product context. While AI can assist in market research, competitor research, etc, it can’t bring various context together to create a roadmap. So roadmapping is a PM-led, AI-assisted task.

2. PM-edited tasks (AI-led): These are the tasks where AI can lead the way, but would require humans to do the final validation. PMs work as an editor in these tasks. For example, if we provide the goals of the user research to AI today, it can create a comprehensive research script. PMs need to review and refine it. See this sample script generated for Flipkart Minutes to Claude Sonnet 3.5 when we gave it this prompt. Adding part of the script below for you to see how good it gets!

   

3. PM only tasks: These are the tasks that only PMs can do, such as resolving a conflict between team members.

4. AI only tasks: These are the tasks that AI can do on its own, like generating a daily status report of all tasks based on project management tool.

   Join a curious community of 13,000+ PMs and Founders, and receive it in your inbox

Classifying Tasks

To classify tasks, we need to create a list of tasks. We can divide the tasks into two parts — one is the set of tasks expected from Junior PMs, and the other is the set of tasks expected at senior levels. At junior levels, you are expected to research, ship, and iterate features/ products. At senior levels, you are expected to manage a product or suite of products, their strategy, roadmap, and growth. As you move up further, you are expected to hire and build an org + contribute to company strategy.

If you confused by what Junior vs Senior implies, below is a good set of skills and their bifurcation to help you.

The tasks, by no means, cover everything but they do a reasonable job of covering 80% of what you are expected at these roles.

The classification will help you in 2 ways:

1. It helps in identifying opportunities to be more productive as PMs through AI assistance

2. It highlights which PM skills become redundant, which ones stay relevant and which ones require deeper knowledge.

List of Tasks

Classification of Tasks in Junior Roles

The Tools I used to perform tasks and gauge AI effectiveness are mostly chat tools and APIs from leading foundation models: Claude Sonnet 3.5, ChatGPT-4o, Claude Developer console. Agents automate tasks, but the ability/ skill level can be seen through the chat interfaces only! In addition to doing these tasks by myself, I also relied on industry papers around what sort of tasks can LLMs execute and to what efficiency.

Here are few generalisations that we have seen so far:

1. Code-related tasks like writing queries, executing queries, etc. can be increasingly handled by AI only. We have tools where you can write natural language queries such as ‘show me sales volume in USD from Jan’25’ and they can write/execute queries on your behalf to bring you numbers.

2. Social interactions and relationship management can be handled by Human only

3. Complex decisions like roadmapping requires you to utilise knowledge from multiple areas - data, business, marketing, etc. While AI can assist humans in this, such tasks right now are human-led.

4. Summarisation, documentation and other activities where the stakes are lower can be handled by AI for the most work. They just need humans to validate the output. This is where PMs would work like an editor. Such tasks will be classified into AI-led, PM-edited.

In a future post, I will cover how to use prompt engineering to be more effective at understanding how well can AI assist PMs. But for this post, let’s stick to looking at these tasks and classifying them. If you don’t understand/agree with few of these tasks classified as such, feel free to ask questions in comments.

Discovery (user research)

1. Creating a research goal and plan: The goals of a research must align with business or user problems. Setting a research goal is high-stakes and also complex problem, that’s why it has to be PM-led, AI-assisted.

   Let’s talk a little about how AI can assist you. AI can be helpful if you write good prompts sharing context. The output of AI can improve further if we add business and product documents for context. But more of this in a future post around prompt engineering. we can’t fully rely on it, since a mistake at this level can be costly!

2. Creating a research script/ survey: AI-led since once we have provided goals and plan to AI, AI is pretty good at generating script with questions. PMs need to act as an editor here.

3. Recruiting users: Recruiting users for research requires reaching out to TG, filtering the right users for research, and defining incentives for them. For offline recruitment, this task is PM-led. For online recruitment, AI can do a reasonable job but PM judgment might be needed for final selection.

4. Conducting interviews: The moderator needs to improvise in real-time often to gain insights. The conversation also needs to feel natural. AI can act as a note-taker here. While AI can conduct interviews even now, we aren’t certain it can repeatedly do this job well without hallucinating. For this reason, conducting interviews online is PM-led. Conducting interviews offline is PM-only.

5. Generating insights from interviews and reporting: AI is pretty good at going through numerous transcripts and filtering novel, important insights. AI also excels at pattern recognition in interview data, so it can note down the patterns that occur more frequently. This is why summarisation, insight generation, and reporting can be done by AI. PMs need to act as editor here.

PMs need to lead overall research process but it can be significantly enhanced by AI. In the follow up tasks, I would not elaborate much in task classification unless necessary because by now you would have gotten a good sense of how this classification works.

Shipping a feature/product

Shipping a feature requires orchestrating various moving parts.

1. Exploring solutions to a problem: AI can generate solutions, but evaluating it needs human judgment. A lot of times, the solutions generated by AI are suboptimal, so PMs still need to devote a significant time coming up with the solution. Since this is a high-stakes situation and we are also not sure about AI’s output, this would be PM-led, AI-assisted.

2. Writing PRD: With all the context of discovery, problem, and solutions, writing a PRD can be a AI-led activity. AI can draft detailed PRDs, PMs can act as the editor.

3. Convincing different stakeholders: Human only because we need to manage relationships, understand motivation of various stakeholders and manage them. Though at times, I have personally found AI advice to be pretty useful when stuck around how to handle a particular scenario.

4. Prioritising feature: PM-led, AI-assisted since it is a high-stakes activity and AI might not have the full context of feature reach, impact, effort, strategic goals, etc. That said, I do see AI making strong progress in prioritisation as it gains better context.

5. Early prototyping: Tools like Replit, Cursor, Lovable, Bolt, etc. help you create quick high-fidelity, early prototypes. These early prototypes can help PMs communicate the requirements well with designers and other teams. Early prototyping is an AI-led activity, and one that’s becoming increasingly important for PMs to learn for efficiency.

6. Sprint planning: PM-led activity since it requires understanding team capacity, dependencies, prioritisation, etc.

7. Tracking the status of the task: AI-only since it is a pure data tracking task.

8. Defining success/ failure of the feature: AI can do it reasonably well today for products similar to popular products (FAANG portfolio). But it can’t do well where you are building something novel. For that reason, I am going to classify it as PM-led.

9. Tracking the metrics: AI only

10. Sending a status update after launch: If success criteria is defined well, a status update can be sent by AI only.

11. Partying with the team on a successful launch: Human only.

12. Conflict resolution: Human only as it requires emotional intelligence and relationship management. That said, AI can be a good listener and help you figure ways to resolve conflict.

Iterating the feature

1. Finding areas to improve upon using data and user research: PM-led, AI-assisted

If we are being honest, most of the work that Junior PMs are doing can benefit heavily from AI, and those who make use of it would get a lot done. It kind of feels like we are binning to see the birth of 10X PMs.

Let’s see how AI redefines senior product roles.

Classification of Tasks : Senior Roles

Product strategy and growth

1. Product vision and long-term goals: Setting up product vision and long-term goals is a human-only activity today since humans can retain context over years and can assimilate the context of everything around them - economic, social, legal, ethical, moral, etc.

2. Competitor analysis: AI can gather, analyse, and track competitor movements. PMs need to systematically analyse what AI throws at them, and make decisions. Competitor analysis is AI-led for this reason.

3. User needs and preference: Understanding needs and preferences of other humans requires empathy. AI can process research data and identify patterns, but understanding deeper needs and behaviours requires human insight. Such human insight also becomes a key competitive advantage. That said, many PMs I meet haven’t spent enough time in human psychology and behavioural economics. It’s high time they should start investing in these areas.

4. Critical and creative problem solving: Competitor research and user research point towards the business or user problems that need to be solved. PMs are way better than AI in this particular aspect. AI can be useful in brainstorming and can bring case studies to inspire some solutions here.

5. Creating roadmap: Roadmap requires prioritisation and alignment with overall org strategy + product vision. AI can help with useful data for prioritsation, but can't lead this strategic exercise. Roadmap, for near future, is going to be a PM-led activity.

6. Finding GTM/channels to grow the product: Product growth is more of a science which utilises data around budget, CTRs, conversions, etc. Finding channels to grow the product is something AI can do really well, and just needs PMs/ marketers as editors. Where PMs need to focus on is novel areas such as product-led growth.

7. Product-led growth: Product-led growth is fundamentally merging product development, strategy and growth.

8. Pricing: AI-led since AI can analyze market data, competitor pricing, and suggest optimal price points. It can also use some pricing research tools. PMs can act as an editor and orchestrator here since it is a quite collaborative activity.

9. Positioning: Product positioning requires deep understanding of user psychology and brand values. AI can assist with competitor analysis and market data.

Leadership

1. Setting goals (OKRs): PM only

2. Adjusting goals: PM-led, AI-assisted. AI can help in tracking goals and suggest adjustments based on historical data and patterns in current data.

3. Financial planning and resource allocation: PM-led, AI-assisted because financial planning and resource allocation requires complex decision making.

4. Cross-functional alignment: PM only

5. Technical strategy: PM-led, AI-assisted since AI can provide case studies/ how other companies have done their technical strategy.

Hiring and building a strong team

1. Interviewing and hiring PMs: PM only since it requires nuanced evaluation in hard skills, soft skills, and cultural fit.

2. Onboarding PMs: AI can help with good onboarding by managing the onboarding process with right documents. Human mentorship is crucial for PMs to be effective in the early stages. So we will classify it as AI-led.

3. Performance management: Managing performance requires human judgment, empathy and mentorship. A lot of conversations around performance management happen offline and require deeper relationships between the manager and the team.

Corp strategy

1. Pitching for new initiatives

2. Pitching for investment in existing product lines

3. Product portfolio management

4. Build vs buy vs partner decisions

All of these tasks are PM-led or PM-only. AI can help in market analysis, brainstorming, etc.

What can PMs do?

If you look through all the tasks that PMs do currently, you will realise two things.

First, AI can easily make a PM 2-3x effective today. PMs need to start using AI as a productivity multiplier. But it shouldn’t be limited to just writing simple prompts and asking ChatGPT or Claude questions that come to their mind. They have to build new systems and processes for themselves that make them more effective. This includes, but is not limited to,

• Writing effective prompts for AI tools

• Use it in documentation, analysis, research

• Automate routine tracking and monitoring

• Create explorations in design

For product leadership, this means helping the team setup these systems and processes. The leadership also has to start pushing teams in the areas where PMs can add lots of value in the AI edge. This could mean creating new guidelines for AI usage, performance management, etc. If you are not doing it, your competitors are and that becomes their advantage.

The second realisation is that AI is increasingly doing a lot of tasks better. What it means for PMs is that they have to focus on strengthening the Core Competencies that AI can't replace. A proxy for that are areas which are inherent weakness of AI

• Product strategy and Corp strategy

• Stakeholder management and relationship building

• Critical problem-solving

• Creative thinking

• Team leadership

• Conflict resolution

• User empathy

• ..

As AI progresses, I will keep re-doing this exercise of re-evaluating tasks. Do subscribe to stay updated!

Prototyping with AI is a slightly complex topic because it needs you to use prompt engineering, technical understanding, and design sense together. At the same time, it is quite useful for PMs. I would be doing a live 2-hour workshop (open to all) on this topic on 6th February, 9 pm - 11 pm IST. You can register for the free workshop here

Prototype with AI

This would be all for this edition!

Thanks,
Deepak

Unlike my other posts which focus on a singular idea and get into the depth of it, this one is written as an overarching view. The reason for it is simple — I wanted to start with covering the broader spectrum using which companies can fill in the blanks in their process. Focussing on a singular aspect can come later.

The first question on one’s mind could be — every company has a process to hire PMs. So why do we need a separate post around it? The main reason for writing this post is because I get this question quite a lot of times, both from founders and product leaders. While there is a set process that every company follows, many people have burnt their hands in making few bad hires even after following that process. In this post, I aim to talk about how to make the process more foolproof while ensure you don’t propose too many changes to your current org. The post is quite useful for companies in Growth stage where processes are still being formed (say 5-200 PMs). It’s also useful for early stage startup founders (0-4 PMs), but their problems are more acute around sourcing, shortlisting, and hiring the right candidate for the stage the company is in! We will cover it in a future post, but not her

So how does the usual hiring process usually look like? Let’s start with that.

The Usual Hiring Process

Hiring a PM is a pretty diverse process across orgs, but follows this structure broadly:

1. Identify the set of skills you want your PM to have. This can vary across the type of company. For example, Stripe and OpenAI would want PMs with strong technical skills, while marketplaces such as Amazon and Airbnb want PMs with strong business/ product marketing skills. This is also why Meta, Google, Microsoft all have different rounds for PM interviews, and so should your company.

2. Evaluate PMs by creating interview rounds around skills. This one is straightforward. You get mid-to-senior folks to evaluate PMs on the skills you listed in step 1.

3. Regroup and discuss to make a decision on hire or no-hire. The discussion includes everyone who has interviewed the candidate, including the hiring manager and HR. They make this call of hire/maybe/no-hire in this meeting.

When you follow the usual process, you would be able to hire some good PMs, and some bad ones. The key reason you get mixed bag of PMs is Step 2 — evaluation on different skills. It’s easy to improve step 2, no matter whether you are a startup or a large company. So how do we do it?

A Better Hiring Process

There are three tactics to make the usual hiring process better, both focussed on Step 2 - evaluation.

Tactic 1: Interviewer <> Skill Mapping

Every product has few strong skills. The first tactic is to figure out which interviewers are best suited to evaluate what skill. Assign a specific set of skills that every interviewer has to evaluate for all candidates. For example, interviewer A would evaluate product sense and strategy, whereas interviewer B would evaluate analytical thinking.

One caution you should exercise while implementing this is you shouldn’t treat the mapping as sacrosanct, and keep assigning interviewers to gauge skills they aren’t mapped to 20-30% of times. Such flexibility ensure you don’t create bottlenecks by relying on only few interviewers for a skill and there are always backfills available.

Tactic 2: Interview notes while taking the interview

While most of the companies have the policy for interviewers to take notes, it doesn’t get followed. Many leaders create notes post interviews and share them. This creates two problems:

1. They rely on their own memory, which can be deceiving at times

2. They can slow down the process by not sharing the notes quickly, thereby making the HR/ other interviewers wait

Given the advances in GenAI, I do believe that taking notes has been much easier than earlier. So if you request people to use an AI generated meeting summary to create their notes (even post the interview), can be pretty reliable in recent times.

Tactic 3: Using the same questions

Daniel Kanhemann, Nobel Prize winner for his work in behavioural economics, created the recruitment process for Israeli Defence Force in 1955, which is still followed today. Here is what he writes about recruitment in his book ‘Thinking Fast and Slow’

If you are serious about hiring the best possible person for the job, this is what you should do. First, select a few traits that are prerequisites for success in (the) position. Don’t overdo it – six dimensions is a good number. The traits you choose should be as independent from each other as possible from each other, and you should feel that you can assess them reliably by asking a few factual questions.

Next, make a list of those questions for each trait and think about how you will score it, say on a 1 to 5 scale. You should have an idea of what you will call ‘very weak’ or ‘very strong’.

These preparations should take you half an hour or so – a small investment that can make a significant difference in the quality of the people you hire.

To avoid halo effects, you must collect the information on one trait at a time, scoring each before you move on to the next one. Do not skip around.

To evaluate each candidate, add up the six scores. Firmly resolve that you will hire the best candidate whose final score is the highest, even if there is another one whom you like better – try to resist the urge to change the rankings.

A vast amount of research offers a promise: you are much more likely to find the best candidate if you use this procedure than if you do what people normally do in such situations, which is to go into the interview unprepared and make choices by an overall intuitive judgment such as ‘I looked into his eyes and liked what I saw’.

In 1955, Kahneman instructed his Army colleagues to concentrate on scoring each trait as accurately as possible.

The new interview procedure proved to be a substantial improvement over the old one: the sum of the individual trait ratings predicted a soldier’s performance far more accurately than the interviewer’s overall judgement.

After Kahneman won his Nobel prize he returned to Israel and paid a visit to his former army base. He discovered they were still using the same interview process he had designed forty-seven years earlier, now with decades worth of data proving its effectiveness in predicting the combat performance of soldiers.

So how is it useful for PM hiring process? Ask the interviewers to ask the same set of questions to all candidates. While these questions can be periodically refreshed because candidates may share this info in the broader market, they can be same in a short period of 4-8 weeks. If possible, you should also create a product problem yourself that’s not popular in product circles.

When you ask the same/similar questions to multiple candidates, it helps you rank them well. But when you vary the question for every candidate, it’s quite difficult to assess them relatively.

If you follow the three tactics — skill<> interviewer mapping, asking interviewers to take notes while interviewing, and having standard question for every candidate for the role — you would have a better filtering process than most.

The last thing to improve continuously in the hard part of interviewing process.

New Product Sense Live Cohort is here (and 60% full)

The 3rd cohort of Product Sense and Strategy program is around the corner. The program is exclusively for experienced PMs and founders. Loved by 150+ alumni from startups and FAANG alike, this program is going to start by 18th January’2025. The program covers everything that’s need to master product sense and strategy.

You can check more about the program and apply from here

Check the Program

Hard Parts of Hiring PMs

The hard parts are the one which are difficult to master and need continuous improvement. And two category of people face this challenge most — first time hiring managers, new interviewers, and founders!

Here are the 7 hard parts of PM hiring and what to do about them

Assignments

I have never been a great fan of assignments because most of them feel like a screening criteria. Good candidates already in great jobs might not even have time to do assignments. So you need to make a conscious call of whether to include assignments or not.

Assignment can be great if you use them an opportunity to see how the candidate displays the skills needed to succeed in your environment. For example, Uber wants to see how the candidate presents and defends a product strategy. I have been through the process, and loved every bit of it. Good assignments also challenge the candidate in ways that they feel good after completing the assignment.

Bias

Companies have done all sorts of experiments to remove bias in the interview process. The best one to follow is Google. Google doesn’t allow interviewers to peak into each other notes to avoid bias transfer. This is something every good process should do. Google also does other things to remove bias. For example, it has a hiring and compensation committee different than the interview panel, but that’s something that only larger companies can do imo.

Making of a good interviewer

How will a new interviewer know whether they are good or need improvement in their interview style? They won’t if there is no shadowing. Shadowing is where the trainee interviewer wishing to improve their interviewing skills observes another talented/respected interviewer conducting an interview. But just shadowing isn’t enough. So there comes reverse shadowing where a senior/talented interviewer joins the interview to assess how the interview is being conducted and share notes around improvement areas for the interviewer.

The Bar Raiser

Bezos and Jobs both agree on getting the first set of hires right in order to build a world class team.

Bezos said about bar raisers in the 1998 Amazon Shareholder Letter:

It would be impossible to produce results in an environment as dynamic as the Internet without extraordinary people. Working to create a little bit of history isn't supposed to be easy, and, well, we're finding that things are as they're supposed to be! We now have a team of 2,100 smart, hard-working, passionate folks who put customers first.

Setting the bar high in our approach to hiring has been, and will continue to be, the single most important element of Amazon.com's success. During our hiring meetings, we ask people to consider three questions before making a decision:

Will you admire this person? If you think about the people you've admired in your life, they are probably people you've been able to learn from or take an example from. For myself, I've always tried hard to work only with people I admire, and I encourage folks here to be just as demanding. Life is definitely too short to do otherwise.

Will this person raise the average level of effectiveness of the group they're entering? We want to fight entropy. The bar has to continuously go up. I ask people to visualize the company 5 years from now. At that point, each of us should look around and say, The standards are so high now -- boy, I'm glad I got in when I did!

Along what dimension might this person be a superstar? Many people have unique skills, interests, and perspectives that enrich the work environment for all of us. It's often something that’s not even related to their jobs.

So as a founder or hiring manager, if you made the first hiring decision in product sub-optimal, you can mathematically induct that the team is going to be sub-optimal.

Self-awareness

The last point is more relevant for founders. Most founders are great at 1-2 things, but not all. So unless you are a key product founder, you are likely not great at it. And your judgement when it comes to first product hire will be sub-optimal.

So how do you solve it? Find people who have great reputation as PM and let them hire for you. Or even better is finding product founders who have been through your journey of building product teams, and seeking their help.

Projects

Elon musk is proponent of drilling a candidate in one of the projects they did. His typical question is “Tell me about some of the most difficult problems you worked on and how you solved them.” He believes that the people who really solved the problem know exactly how they solved it. They know and can describe the little details. Usually, someone who really had to struggle with a problem, they really understand the details, and they don’t forget.

Focussing on one or two projects can particularly useful in PM interviews. Though it is usually hard to get into details of projects for most interviewers. A hack that works there is to focus on projects where you have some domain knowledge. For example, if you have worked on a platform product, you can drill the candidate on a platform product they built. This creates a better conversation with the candidate because you are highly engaged in the discussion. Add to that, your knowledge makes you assess the details better.

Reference Check

Checking reference of a candidate when the references were provided by the candidate is a wrong strategy. Such reference checks alone would almost always be good since candidate has already asked for their permission to share their details.

So what do you do to perform a good reference check?

One, reference checks should be relied only if the candidate has worked in a similar work setup. For example, a startup hiring a PM shouldn’t take a reference check from a manager in large company. It’s known that a startup PM needs different set of skills and mindset than a large company. So such reference check can be misleading because it doesn’t tell you how the candidate is going to perform in your setup, i.e. a startup.

Two, reference checks should be done across multiple companies the candidate has worked on. A strong PM may have one bad experience. Similarly, a not-so-strong PM may have one very strong reference.

Past is the biggest predictor of future for most people, and so reference checks are valuable if done well.

That would be all for this post. Happy hiring, and see you next week,

Deepak

PS: Thanks to Debanjoli Sinha, Piyush Mayank, Sorabh Vij, Ankit Kulshreshtha, Uday Vansh Malik for reading drafts of this and providing inputs!

Welcome to another edition of the Growth Catalyst Newsletter. I wanted to cover one of the most important aspect of building AI products this week — defensibility. With thousands of AI products launching every month, defensibility will determine which ones will survive.

To cover this topic, creating a video around it seemed like an apt way to do it. It talks about

• Why defensibility is important to think about in AI products?

• Thin vs Thick Wrappers

• Attributes of thin wrappers and why they are weakly defensible

• Attributes of thick wrappers and why they are strongly defensibly

• What to do if you are building a thin wrappers?

• Where does thin wrapper succeeds?

Go through the video and like/comment if you found this useful.

Free Session on Product Growth

I have another 2-hour session on Product Growth coming up tomorrow, 11 AM IST. Around 300+ folks have registered for it. You can check and register here if the topic interests you — https://lu.ma/rw0aqbp2

Last but now the least,

The 2nd Cohort of Product Sense and Strategy is Here!

Brimming with all the love we have gotten so far, the 2nd cohort of Product Sense and Strategy would commence on 17th August :)

The program is explicitly for experienced PMs and founders. It would be the last live cohort on the topic this year.

We have received highest applications ever for this cohort. The final shortlist goes out this weekend along with details around next steps.

We have 25% spots left, so this would be a good time to apply! If you aren't applying, tell a friend who will appreciate it.

Apply here — https://9y9647f1j0n.typeform.com/to/F7juz3PJ

Check the program here — https://www.pmcurve.com/product-sense-for-pms-and-entrepreneurs

This would be all for the week. Thank you for reading and see you next time,

Deepak