One Framework for the Agentic PM

I’ll own up to something: I have been a framework hoarder. Across years of managing multiple products and platforms I collected them the way travellers collect souvenirs — personas, user stories, roadmaps, prioritisation matrices, opportunity trees, a different canvas for every occasion — and I’d reach for a fresh one whenever a problem felt stubborn. Each earned its place in a world where a feature was a screen a person operated. What I’ve come to realise, watching agents start to do the work, is that most of that machinery loses its object, and that I need far less of it than I thought. One framework and two guardrails get a product manager remarkably far, and the framework is the oldest one on the shelf — the one I should have trusted all along.

Why jobs to be done fits so well

Jobs to be done starts from a simple reframing: customers don’t buy products, they hire them to make progress in a situation. Clayton Christensen popularised the idea; Tony Ulwick’s earlier outcome-driven work added the discipline of breaking a job into steps and attaching measurable outcomes to each. Neither was written for agents, and both fit them almost eerily well, because an agent has exactly the shape of something you hire.

Features describe how a person operates a tool. Jobs describe the progress the person wants. When the tool starts operating itself, the feature list is the first thing to go stale and the job is the only thing that doesn’t. A well-stated job is also, usefully, a good brief for an agent: it names the situation, the desired outcome and the constraints.

The method on one page

1. Write the job. “When [situation], I want to [outcome], so I can [progress].” No features, no screens, no technology. For a collections team: when an invoice is thirty days overdue, I want the customer to pay or tell me why, so I protect cash flow without damaging the relationship.

The same sentence shape travels across industries and functions:

• Manufacturing plant: when a production line starts drifting out of tolerance, I want the cause found and the line corrected before scrap builds up, so I protect yield and delivery dates without stopping the shift unnecessarily.
• Retail outlet: when a fast-selling item is running low on the shelf, I want it replenished before the gap shows, so I don’t lose the sale or over-order and mark it down later.
• Software SaaS product: when a customer’s usage falls for two weeks running, I want to understand why and act before renewal, so I keep a healthy account without flooding them with generic nudges.
• Sales: when a qualified buyer goes quiet after a pricing conversation, I want the right follow-up sent at the right moment, so the deal keeps moving without the rep chasing by hand.
• Financial services: when a new customer applies, I want the account opened or the exception flagged within the day, so I onboard legitimate customers quickly without letting risky ones through.

Notice what each one leaves out: no screen, no feature, no mention of AI. Each names a situation, an outcome and a constraint — which is also exactly what an agent needs to be briefed on.

2. Write the outcome as something measurable. The share of overdue invoices resolved within a week, with no complaint. If you can’t measure it, you can’t hold an agent to it — and you can’t tell whether a change helped.

3. Map the steps using the four layers from What a Workflow Really Is: the carrying steps, the decisions, the exceptions. Mark which the agent takes, which it proposes, which stay human.

4. Set the authority — the first guardrail.

5. Set the bar for done — the second guardrail.

Guardrail one: authority

Jobs to be done tells you what to build and is silent on how much freedom to give the thing you’ve built. That is the gap. For each action in the job, decide which rung of the trust ladder it starts on — suggest, propose, act with undo, act unattended — and what evidence moves it up. Bound it by blast radius: how bad is it if this is wrong, and how cheaply can it be undone? A collections agent that can send a reminder is a different product from one that can offer a discount, and the difference is authority, not capability.

Guardrail two: an eval bar, not a spec

A specification describes what you intend. An agent is probabilistic, so what you need is a test of what it actually does. Express “done” as a set of real cases with known-good outcomes and a threshold — an eval set — and treat it as the acceptance criterion. Product management in an agentic world looks a lot more like running an experiment than signing off a document: the job defines the target, the evals tell you whether you’ve hit it, and the authority decides what you’re allowed to do when you have.

What this replaces

The persona deck becomes the situation in the job. The feature list becomes the steps the agent takes. The user story becomes the outcome. The acceptance criteria become the eval set. The roadmap becomes a sequence of authority upgrades, each earned by evidence. Prioritisation becomes which job is most painful and most automatable. You haven’t lost rigour; you’ve concentrated it where an agent’s risk actually is.

It is also a framework that survives the next model release, which most feature-centred plans don’t. If a smarter model arrives, the job is unchanged, the eval set tells you immediately what improved, and the authority you grant simply moves up where the evidence supports it. I made the same argument about architecture in A Product Playbook for Agentic AI; the product-management version is simpler still.

The one-sentence version

Know the job, measure the outcome, bound the authority, and let evidence — not enthusiasm — decide how far the agent goes. Everything else a product manager used to do is either a way of doing that or a way of avoiding it.

Nobody Wants a Form — a five-part series on the interface in an agentic world

1. Nobody Wants a Form
2. The Trust Ladder
3. What a Workflow Really Is
4. The Interface That Remains
5. One Framework for the Agentic PM — you are here

Companions: Why Agents Still Fail at Real Workflows.

Related: A Product Playbook for Agentic AI — The Frameworks I Actually Use · What a Good Eval Set Actually Looks Like.