The Roadmap to Becoming a Product Builder, with Ankit Shukla

Context

Ankit Shukla founded HelloPM and analyzed 12,500 product management job descriptions with Claude and GPT to see what companies are actually hiring for. The episode starts from LinkedIn replacing its Associate Product Manager program with an Associate Product Builder program, then asks whether that title reflects a real market shift or just fresh branding. For PMs, the useful question is not whether every company will rename the role. It is whether AI is changing which product skills get paid for, especially around discovery, prototyping, and judgment.

The Big Idea

The new premium is on product judgment plus hands-on building. PMs who can pick the right AI use case, turn it into a working prototype, and audit what the agents produced are worth more than PMs who only hand off specs.

AI changes the bottleneck more than the job title. When delivery gets cheaper, the PM's leverage moves upstream into choosing the right problem and downstream into reviewing cost, quality, edge cases, and production risk.

Key Insights

Product builder demand is real

• Ankit used Claude and GPT to analyze 12,500 PM job descriptions.
• His conclusion was that more than 30% of PM postings already ask for meaningful AI capability.
• The title "product builder" has not spread everywhere yet, but the requirements have. A PM can miss the shift by waiting for job titles to catch up.

Judgment earns the premium

• Across the job descriptions, Ankit says the most valuable AI skill was not RAG, prompt engineering, or agentic AI.
• The skill companies paid for was deciding which use cases deserve AI and which ones do not.
• That helps explain the pay data he cites: roughly 15 to 20% more than non-AI PM counterparts in the US and Europe, and 30 to 50% more in India.
• In Ankit's US sample, the median AI PM salary was $195,000, and senior roles ranged from $250,000 to $560,000.

AI lowers delivery gatekeeping

For years, delivery was the expensive part of product work. That forced teams to gate ideas heavily before engineering touched them, which pushed PMs toward safer bets because nobody can prove an idea will work in advance. Ankit's argument is that AI lowers the cost of delivery enough that PMs can prototype and test more ideas themselves, before asking for full engineering bandwidth. The result is not just faster shipping. It is a different quality of decision making, because more ideas can be validated with something real.

Start with possibilities first

Traditional product thinking starts with user problems. Ankit argues that AI partially inverts that sequence, because some painful constraints were never framed as problems at all. Teams assumed they were just reality. He recommends first mapping what AI can do, then revisiting company problems with that broader view. His simple capability lens is understand, transform, generate. If a workflow contains one or more of those steps, AI may create leverage.

POW before any tools

Ankit's strongest process point is that the real product work happens before tool selection.

• Possibilities: research what AI can do in your industry and nearby industries.
• Opportunities: identify high-value company problems where AI could create real ROI.
• Workflows: map the exact steps people follow today, including where time is spent and where judgment matters.
• Only after those three should a team pick an engineering approach such as Google Gems, Claude Code, n8n, or Make.

His warning is simple: starting with tools makes teams retrofit workflows to whatever the tool can do, which is how low-value AI automation spreads.

Review becomes the job

Ankit's email-platform example shows where PM judgment moves once agents can build.

• HelloPM was paying roughly $550 to $700 per month for a third-party email layer, on top of about $100 to $120 for Amazon SES itself.
• Ankit wrote rough requirements in plain language, had ChatGPT expand them into a markdown spec, then used Claude Code plus an AWS MCP connection to plan and build a replacement in Node.js and TypeScript.
• The first infrastructure plan came back at about $420 per month.
• Because Ankit knew enough AWS basics to question the machine size and ask why Fargate was needed, the revised plan dropped to about $110 per month.

The PM lesson is that AI can create the first version fast. The human still has to judge whether the system is too expensive, too fragile, or too risky for production.

Mental Models & Frameworks

Three-stage product work

Ankit reduces most product jobs to three stages:

• Discovery: understand customers, data, and the market well enough to decide what to build.
• Delivery: turn the idea into something real.
• Distribution: get the product to customers so it actually gets used or paid for.

Use this model to spot where AI changes the constraint. Ankit's view is that discovery gets faster and delivery gets cheaper, which means more decisions can be tested before they become roadmap commitments.

UTG capability lens

Ankit's quick way to spot AI opportunities is to ask whether the workflow needs AI to:

• Understand information, such as transcripts, tickets, or documents.
• Transform information, such as rewriting, summarizing, classifying, or structuring it.
• Generate new output, such as code, content, or draft artifacts.

Use the UTG lens when a team is staring at a workflow and unsure whether AI is actually relevant.

Five building levels

Ankit describes a practical maturity ladder for building with AI:

• Level 0: one-off prompting in a chat window.
• Level 1: reusable prompts through Google Gems or custom GPTs.
• Level 2: skills and connectors, where tools can pull the right instructions only when needed and connect to systems like Slack, Gmail, or analytics.
• Level 3: vibe coding, when a PM wants a simple interface or standalone tool.
• Level 4: AI workflow tools such as n8n or Make for backend automations with more explicit control.
• Level 5: production builds using coding agents plus infrastructure integrations such as AWS MCP.

The useful takeaway is not that every PM must reach level five. It is that most people stall far too early and never move from prompting to reusable systems.

Plan execute evaluate loop

Once a team goes past one-off building, Ankit recommends thinking in loops, not tasks. The agent should plan the next step, execute it, evaluate the result, and repeat. That is how a coding agent can keep moving through slices of work while a human sleeps, only stopping when it needs new credentials or a product decision. Use this model when the task has clear checks and can improve through iteration.

Empathy at scale

Ankit gave a useful non-coding example from HelloPM.

• HelloPM collected about 200 intro-call transcripts from people entering its program.
• Ankit fed those transcripts into Claude and asked it to create representative personas.
• When making later decisions, he asks Claude to walk the decision through those personas and explain who benefits or loses.

The point is not that AI replaces user research. The point is that AI can help a PM preserve customer context across many more decisions than memory alone allows.

Decision Principles

Principle: Pick leverage first

• When: choosing a first AI use case inside a team or company.
• Why: small, infrequent annoyances rarely create meaningful ROI. Ankit recommends looking for repeated workflows with real volume, clear pain, and measurable savings.

Principle: Prototype before roadmap

• When: a team is debating whether an idea is worth real engineering time.
• Why: a rough prototype now costs far less to create than it used to. A prototype gets user feedback faster than a debate over a hypothetical feature.

Principle: Challenge agent spending

• When: a coding agent proposes infrastructure, vendors, or architecture choices.
• Why: models are optimized to make the system work, not always to make it economical. Ankit's AWS example shows that basic review can cut recurring cost dramatically.

Principle: Stop tool debates

• When: choosing between Claude Code, Codex, Cursor, or similar tools for ordinary product builds.
• Why: Ankit says the tools behaved similarly across common website builds. For about 90% of use cases, the bigger mistake is over-optimizing the tool instead of the workflow and review process.

Trade-offs & Nuance

Possibility first needs discipline

Starting with AI possibilities can reveal opportunities that a classic problem-first approach would miss. But possibility-first work can also drift into novelty demos if the team never comes back to business value, frequency, and ROI. Ankit's sequence only works when the possibilities scan is followed by a hard opportunities filter.

Speed still needs safeguards

AI makes it easier for a PM to build and deploy something without waiting on a full engineering cycle. That is useful for learning, but Ankit still recommends security checks and internal review before customer-facing production release. Faster building changes who can start the work. It does not remove the need for production standards.

PM autonomy changes ownership

A PM can now build a prototype that used to require a separate engineering project. That does not mean the PM should always own the last mile. Ankit agrees with Aakash that the final 10 to 20% often shifts to bug fixing, edge cases, and hardening, which many companies will still want engineers to own.

Not every PM ships AI

Ankit sees three levels of PM AI use:

• improve an internal team's workflow
• improve the PM's own speed and decision quality
• build AI into a customer-facing product

Every PM can benefit from the first two. Not every PM role needs the third.

Common Mistakes

Mistake: Starting with tools

Many people try to become a product builder by opening n8n, Make, Claude Code, or another tool first. Ankit thinks this is backwards. Without a clear view of possibilities, opportunities, and workflows, teams end up learning software instead of solving a valuable problem.

Mistake: Mistaking information for knowledge

Watching videos and reading about AI tools creates confidence quickly, but Ankit argues that it is often false confidence. Interviews expose the gap fast. His fix is to build real projects and speak to people already doing the job, because knowledge only becomes usable after practice.

Mistake: Picking tiny use cases

Ankit warns against starting with one small redundant task just because it is easy to automate. A low-frequency problem can still produce a polished demo and almost no ROI. He recommends looking at the whole workflow first, then choosing the bottleneck that matters.

Mistake: Trusting first output

The first agent-generated answer, architecture, or cost estimate should not be treated as final. In Ankit's own example, the first AWS plan was much more expensive than necessary. Review is not optional. Review is the work that makes agent output valuable.

Practical Application

Review real job descriptions

Pick 25 to 30 AI PM or AI-heavy PM postings and read them manually. Do not start by asking AI to summarize them for you. Make your own skills map first: what product, domain, technical, and stakeholder strengths do you already have, and which gaps show up repeatedly across the postings.

Map one workflow deeply

Choose one recurring workflow in your current job, such as competitive research, ticket review, onboarding analysis, or sprint reporting.

• List the exact steps people follow today.
• Mark where the workflow asks someone to understand, transform, or generate information.
• Estimate time spent, frequency, and business impact.
• Only then decide whether the workflow deserves a Google Gem, a Claude skill, a coding prototype, or a backend automation.

Build transcript based personas

If your team has onboarding calls, sales calls, or user interviews, put a real transcript set into Claude or ChatGPT and ask for representative personas. Use the resulting personas in later product discussions by asking the model to evaluate a decision across each persona. This is a practical way to keep customer context present when the team cannot talk to every user on every decision.

Prototype from plain language

Take one product idea that is stuck at the slide stage. Write the requirements in plain language, ask an LLM to turn them into a tighter markdown spec, then hand that spec to Claude Code, Cursor, or Codex to build a rough version. The goal is not production code. The goal is to make the discussion concrete enough that real feedback becomes possible.

Use a review checklist

When an agent finishes a build or proposes an architecture, review it with the same checklist every time:

• cost to run
• security exposure
• obvious edge cases
• handoff documentation
• whether the problem is important enough to keep iterating

That checklist is where product judgment now shows up.

Questions to Consider

• Which recurring workflow in your team is painful often enough, and expensive enough, that AI could create real ROI instead of just a clever demo?
• Where is your team still gatekeeping ideas because delivery used to be expensive, even though an AI-built prototype could now answer the question faster?
• If a coding agent proposed a production stack tomorrow, would your team know enough to challenge the cost, security, and architecture choices instead of accepting the first answer?
• Are you spending more time learning AI tools in isolation, or building a portfolio that proves you can choose a good AI use case and ship a concrete prototype?

Bottom Line

The product-builder shift is less about a new title and more about a new distribution of work. Judgment is the scarce skill: knowing where AI creates real leverage, building enough to make the idea real, and reviewing the last 20% hard enough that faster building turns into better product decisions instead of faster mistakes.

Case Studies Mentioned

LinkedIn's program switch

LinkedIn replaced its Associate Product Manager program with an Associate Product Builder program. Ankit treats that as a market signal, not definitive proof on its own. The larger point is that job descriptions across companies are already asking for hands-on AI building even when the titles differ.

HelloPM's email rebuild

HelloPM wanted to replace a third-party email platform layered on top of Amazon SES.

• Amazon SES itself cost about $100 to $120 per month for roughly 1 million emails.
• The third-party layer added about $550 to $700 per month.
• Ankit wrote a rough feature list, expanded it into a spec with ChatGPT, then had Claude Code build and help deploy an internal replacement on AWS.
• The first AI-generated infrastructure plan was too expensive, and the revised version cut the monthly estimate from about $420 to $110.

The lesson is not just that AI can code. The lesson is that a PM can now get to a serious internal tool quickly, then apply judgment where cost and production trade-offs appear.

Transcript personas at scale

HelloPM recorded about 200 member introduction calls and turned the transcripts into representative personas in Claude. Ankit then uses those personas as a decision aid, asking the model to explain how a product or content choice would land for different user types. The lesson is that AI can preserve qualitative customer context at a scale that would be hard to hold in memory alone.

Fintech underwriting acceleration

Ankit described fintech teams where underwriting used to require manual checks such as reviewing credit scores and other approval inputs. He says AI tools now handle much of the repetitive analysis, reducing a file that once took 3 to 5 hours of human work to roughly 20 to 30 minutes. The useful product lesson is that internal workflow bottlenecks can be high-value AI use cases even when the end customer never sees the AI directly.

Tools & Products

People to Follow

Ankit Shukla

Ankit Shukla is the founder of HelloPM and the guest driving the episode's analysis. He brings a practical operator lens rather than a purely theoretical one, combining job-market research, portfolio advice, and a detailed build example to explain what "product builder" actually means in practice.

Experiments to Try

Experiment: Persona review assistant

• Hypothesis: transcript-based personas can improve product decisions by making customer trade-offs more visible during planning.
• Change: load a set of onboarding, research, or sales transcripts into Claude or ChatGPT and generate 3 to 5 representative personas.
• Test: use the personas in the next three roadmap or feature discussions and ask the model to predict reactions from each persona.
• Measure: whether the team surfaces better objections, clearer target users, or different priority calls than it would have made without the persona pass.

Experiment: Prototype before escalation

• Hypothesis: a rough AI-built prototype will resolve roadmap debates faster than a document-only pitch.
• Change: pick one idea that would normally go to engineering as a spec and turn it into a rough interactive version first.
• Test: show the prototype to internal stakeholders or a small set of users before asking for full engineering investment.
• Measure: time to decision, quality of feedback, and whether the team changes scope or direction before formal roadmap approval.

Experiment: Morning metrics brief

• Hypothesis: a natural-language AI summary of core product metrics will reduce dashboard-checking overhead and speed up team awareness.
• Change: connect an analytics source such as Mixpanel, Amplitude, or Tableau to an AI workflow and have it send a daily summary.
• Test: run the summary for two weeks alongside the team's normal dashboard routine.
• Measure: time saved, number of follow-up questions answered by the summary, and whether important metric changes are noticed earlier.

Notable Quotes

"RAG, agentic AI and prompt engineering, they were not the number one skill. The number one skill was identifying the right use case for AI." (Ankit Shukla)

"Please do not start with engineering." (Ankit Shukla)

"Learning is course correction." (Ankit Shukla)