IESE AI Club

Role playbook

AI for product managers.

Product management is a bandwidth problem: more user calls, every ticket, better specs and data before decisions. AI does not make you better; it removes the time excuse.

This assumes you have the base. Start there if not

The job

What this role actually does.

Six things every week. Model releases do not change them; this page should still hold in three years.

01Discovery 02Prioritisation 03Specs 04Engineering 05Launch 06Usage analysis

Most examples are vendor customer stories. Their self-reported, unaudited numbers show something was built and used—not a benchmark to expect.

01

Discovery and user research

Synthesis
The use case
Turning raw customer signal (interviews, tickets, reviews, sales-call notes) into a small number of trustworthy themes with the quotes still attached.
Job to be done
When I have more customer evidence than I can read, I want the recurring problems surfaced with their sources, so I can decide what to build from evidence rather than from the loudest meeting.
Value to the business
Fewer features built for a customer who does not exist. Discovery stops being rationed to whoever had time to read.
How to evaluate it
Share of roadmap decisions traceable to cited evidence, and time from question to a defensible answer. Spot-check the quotes: if the citations do not hold, the speed is worth nothing.

What AI does here

AI reads interviews, tickets, call notes, reviews and community threads at once. Ask what is said, how often and by whom; ask it to argue against its theme and quote the source lines.

Workflow map

  1. InputGather interview transcripts, tickets, reviews and segment labels around one research question.
  2. AI-assisted processCluster recurring needs, retrieve supporting quotes and flag disagreements between segments.
  3. Human checkpointRead the cited evidence, challenge the themes and judge business importance.
  4. OutputA traceable insight brief with themes, evidence, open questions and next interviews.

What is still yours

Decide which problems matter. Forty requests may come from your worst-margin plan or a loud CEO friend. Frequency is not importance.

02

Prioritisation and roadmap

Analysis
The use case
Assembling the inputs to a prioritisation call (reach, effort, strategic fit, what is already in flight) out of systems that do not talk to each other.
Job to be done
When I prepare a roadmap decision, I want the scattered signal collected and the trade-offs laid out, so the meeting argues about the call rather than about the numbers.
Value to the business
Shorter planning cycles, and a roadmap you can give people the reason for.
How to evaluate it
Planning cycle length and the proportion of roadmap items with a written, checkable rationale. Watch for prioritisation drifting toward whatever is easiest to quantify.

What AI does here

Put sales, support, strategy and engineering inputs together. AI finds conflicts, double-counted requests and unowned priorities; rank by stated criteria and explain where it diverges from your judgment.

Workflow map

  1. InputCombine candidate ideas with customer evidence, strategic goals, effort estimates and scoring rules.
  2. AI-assisted processNormalise duplicate requests, calculate a first-pass ranking and expose conflicts or missing assumptions.
  3. Human checkpointTest the ranking against commercial timing, dependencies and the decision criteria leaders accept.
  4. OutputA prioritised roadmap with rationale, trade-offs and decisions to revisit.

What is still yours

Make and defend the call. Roadmaps are political as well as planning documents. Prioritisation is where strategy meets organisational reality; it does not outsource.

03

Specs and requirements

Drafting
The use case
Turning an agreed decision into the artefacts around it: the spec, the edge-case list, acceptance criteria, the announcement.
Job to be done
When the decision is made, I want the writing-up done quickly and consistently, so the team starts building sooner and nobody re-litigates scope from memory.
Value to the business
Less lead time between deciding and starting, and fewer defects traced back to an ambiguous requirement.
How to evaluate it
Time from decision to spec, and the rate of clarification questions raised during build. A longer spec is not a better one.

What AI does here

Give AI the rough intent and ask for uncovered cases: empty states, permissions, offline behaviour, repeats and error messages. Draft in team format and generate the awkward review questions early.

Workflow map

  1. InputStart with the problem, users, constraints, existing flows and the intended outcome.
  2. AI-assisted processDraft the team’s PRD format and enumerate edge cases, dependencies and unclear acceptance criteria.
  3. Human checkpointProduct, design and engineering remove invented detail and resolve the questions that affect scope.
  4. OutputA concise, reviewable specification linked to its evidence and release criteria.

What is still yours

Know what to leave out. Long specs are not a virtue. Cutting scope, shipping the ugly version and learning from use are your risk and time judgments.

04

Working with engineering

Code
The use case
Prototypes, throwaway code and technical exploration that let a product manager show an idea instead of describing it.
Job to be done
When I am unsure an idea is worth engineering time, I want a rough working version quickly, so weak directions die before anyone commits a sprint.
Value to the business
Engineering capacity aimed at things that survived contact with a user first.
How to evaluate it
Directions killed before a sprint was spent on them, and time from idea to something clickable. Label prototypes as disposable, or one will quietly become the production path.

What AI does here

Use a coding assistant to see what a change touches. Build a rough prototype instead of describing one in a document. Something clickable moves a planning conversation further than a spec.

Workflow map

  1. InputShare the proposed user change, repository context, constraints and a small test case.
  2. AI-assisted processExplain affected components, draft a thin prototype and translate technical findings into questions.
  3. Human checkpointEngineers validate architecture, security, maintainability and whether the prototype represents the real problem.
  4. OutputA jointly understood implementation slice, prototype or engineering-ready decision.

What is still yours

Trust, and saying when you do not understand. Generated jargon destroys engineer credibility faster than admitted ignorance. Use tools to ask sharper questions, not feign answers.

05

Launch and go to market

Drafting
The use case
Producing the launch surface (release notes, docs, in-product copy, enablement material, FAQ) from one set of source material.
Job to be done
When a feature is ready, I want every audience's version written from a single truth, so the launch does not slip because nobody had time to write the docs.
Value to the business
Fewer launches delayed by content, and less drift between what the product does and what the material claims.
How to evaluate it
Launch content lead time and the number of post-launch corrections. Track the support tickets caused by the launch material itself.

What AI does here

A launch is the same content in many registers: release notes, in-app copy, sales, support, FAQ, post and email. Write one canonical source, then derive the rest with positioning and tone rules.

Workflow map

  1. InputApprove one positioning statement, audience definition, feature facts and launch constraints.
  2. AI-assisted processAdapt that source into release notes, sales enablement, support guidance and channel-specific drafts.
  3. Human checkpointOwners check claims, tone, legal requirements and whether each audience can act on the message.
  4. OutputA coherent launch kit with a maintained source of truth and approved variants.

What is still yours

Decide what the launch is about. Most messages describe a feature; find the sentence that makes a stranger care. Generated copy defaults to description, not persuasion.

06

Usage analysis and iteration

Analysis
The use case
Reading behaviour after a release (analytics, support volume, verbatims, session data) and turning it into what to change next.
Job to be done
When a release is live, I want the signals across systems synthesised quickly, so I can act inside the same cycle instead of two weeks later.
Value to the business
Faster iteration loops, and problems caught while the team still remembers the code.
How to evaluate it
Time from release to the first evidence-backed change, and whether that change moved the metric it targeted. Confirm the pattern in raw data before shipping a fix for it.

What AI does here

Hand AI an export and ask where the funnel breaks, which cohort differs and what changed when the number moved. Make it show its work and state data assumptions; check them.

Workflow map

  1. InputDefine a decision question, metric definitions, comparison cohorts and a governed data extract.
  2. AI-assisted processGenerate and explain analyses, surface funnel breaks and compare changes across cohorts.
  3. Human checkpointVerify the query logic and decide whether the pattern is causal enough to change the product.
  4. OutputA documented insight, follow-up experiment or explicitly rejected hypothesis.

What is still yours

Ask the question that matters. Most requested numbers are noise. Know which metric changes a decision, then ignore the rest.

Start this week

  1. Take your last ten customer calls or fifty support tickets, put them in one place, and ask for the three themes with direct quotes attached. Compare that against the themes you would have named from memory.
  2. Set up one project holding your positioning, tone rules and product glossary, so you stop re-explaining your own product every time you draft anything.
  3. Prototype the next feature you intend to argue for, instead of writing the document about it.

Where it fails in this role

  • Deciding. It will produce a confident recommendation for any option you name, and an equally confident one for the opposite option thirty seconds later. It is a thinking partner with no stake in the outcome.
  • Knowing your customer better than you do. If you have not spoken to a user in three months, synthesising last year's tickets gives you a beautifully written description of the past.
  • Political judgment. It cannot read a room, and most roadmap decisions are ultimately read in rooms.

Other playbooks

All nine playbooks Sales Marketing Venture capital Operations Consulting Forward deployed engineer Founder / entrepreneur AI product manager

Now do it somewhere real.

A playbook is a map. The Industry Fellowship is the terrain: a term spent talking to professionals who are implementing AI in one industry, working out where it actually creates value, and building a working prototype against what you find. Most fellows start as beginners.

Explore the Fellowship Apply for the Class of 2028