Product management for agentic AI breaks most of the assumptions the discipline was built on. There’s no fixed spec, because the system is probabilistic. There’s no deterministic acceptance test, because “correct” is a distribution, not a value. And a lot of the old prioritisation instinct — features, seats, roadmaps — doesn’t map cleanly onto something whose unit of value is a job done. Over building a handful of real agents — from an assistant for my own family to thinking hard about where this goes in the enterprise — a small set of frameworks keeps earning its place. These are the ones I actually reach for.
1. Start with the job to be done
Before anything technical, name the job. Not the feature, not the model — the outcome the user is hiring the agent to get done. Agentic products live or die on this: an agent scoped around a capability (“summarise documents”) drifts and disappoints, while one scoped around a job (“get me a decision-ready brief before the 9am meeting”) has a clear bar for success and a clear reason to be hired. The job-to-be-done doubles as your eval target and your pricing anchor — it tells you what “good” means, what the alternative is (usually a person, or the user doing it themselves), and what you’re actually competing against. Define the job precisely enough that someone outside could tell whether it got done.
2. Nail the ideal user — and customer — profile
Then decide exactly who it’s for, and be narrow. The graveyard of agents is full of general-purpose assistants that work for everyone in the demo and no one in production, because real users bring messy data and specific context a generic agent can’t handle. A tight profile — this role, in this domain, with this data, doing this job — is what lets you ground the agent in the right context, choose the right guardrails, and set an eval bar that reflects reality. And keep the user and the buyer distinct: the person whose job the agent does isn’t always the one who pays for it, and an agentic product has to satisfy both — the user’s trust and the buyer’s outcome. Narrow beats broad; the depth of fit is the moat.
3. Scope the authority, not just the feature
The first question on any agent isn’t “what can it do?” — it’s “what may it do on its own?” Decide, per capability, whether the agent may act or only propose. Everything with a real-world effect should become a proposal a human approves, not an action the model takes unilaterally. And for whole categories — anything that spends money or is hard to reverse — draw the line even earlier: find, surface, and hand off — never transact. Authority is the real spec of an agent. Get it wrong and no amount of model quality saves you.
4. Define “done” as an eval bar, not a spec
You can’t write deterministic acceptance criteria for a probabilistic system, so stop trying. “Done” for an agent is a score on an eval set, not a checklist of behaviours. That reframes the whole project: the first artifact isn’t a spec, it’s a set of representative cases with known-good outcomes, and the definition of shippable is a bar on that set. Build the evals before you tune anything — otherwise you’re improving by vibes, and agents are far too non-deterministic to tune by vibes.
5. Draw the deterministic / probabilistic line first
Before designing features, decide what has to be exactly right and what only has to be good. Correctness-critical work — a calculation, a rule, a transaction — belongs on the deterministic side, as a service the agent calls. Judgment, phrasing and synthesis belong on the probabilistic side. Then ground the facts and let the model phrase them — the model composes only from data a deterministic step fetched, never from memory. This single line decides how testable, how trustworthy, and how debuggable the whole product will be.
6. Prioritise by blast radius
The right first use case isn’t the most impressive one — it’s the one where a mistake is cheap. Rank candidate capabilities by the cost of being wrong, and ship agentic autonomy where the blast radius is smallest first, keeping a human gate where it’s largest. This is the same instinct that says go agentic at the thin, low-risk top of the stack before the correctness-critical core. Cheap-to-be-wrong is where you build the track record that earns you the right to automate the expensive stuff later.
7. Right-size and route — treat the model as swappable
Never write “use the best model” into a design. Match each step to a right-sized model: small, fast and cheap for classify/extract/format work; something stronger for reasoning; the frontier only where it genuinely earns it. Route by task, not by hype, and treat the model as a component you can swap when a better one lands next week. The durable product work is the harness around the model — not a bet on any one provider’s weights.
8. For sensitive data: expose the signal, protect the content
When an agent handles something private, the design question is what other people get to see. The pattern I trust: expose the accountability signal, protect the sensitive content. In the study tutor I built for my kids, a parent can see that the homework got done — the signal — but not the marks or the mistakes — the content. You see that they studied, not what they struggled with. The same split applies to any product on sensitive data: prove the fact, protect the detail, and enforce it in the data model rather than a settings page.
9. Make governance, ROI and trust design inputs — not sign-offs
The failure mode is treating governance and ROI as gates at the end — a review board an agent has to pass before launch. In an agentic product they’re design inputs from the start: an auditable record of what the agent did, what it cost, and that it was allowed, built into the system rather than bolted on. If you can’t answer “who approved this, what did it cost, and was it permitted?” from the product itself, you don’t have a governable agent — you have an incident waiting to happen.
10. Run it like production — even when it’s small
The last one is a discipline, not a feature. Agents are seductive to prototype and treacherous to operate, so the boring rigour has to be there from day one even on a tiny project: real tests, feature flags that default off, guardrails, and an operational posture that assumes the model will misbehave. I ran a family assistant with strict typing, migrations and CI — overkill, until the “incident” was my family not getting their morning briefing. The discipline is what lets you move fast on the fun parts without breaking the parts people already rely on.
The through-line
Notice what these have in common. None of them is about the model. Agentic product management is the work of designing the boundaries and the evidence — what the agent may do, where correctness is guaranteed, how you know it works, and who can see and answer for what. Get those right and the model becomes what it should be: a powerful, swappable component inside a product you actually control. Get them wrong and the best model in the world just helps you fail faster. The spec was never the feature list. It’s the authority, the evals, and the line between what’s exact and what’s merely good.
Part of the Agentic AI series
- Agents Eat the Stack Top-Down
- The Substrate War
- Buy, Build, or Orchestrate
- Service-as-Software
- The Frontier Labs Are in the Squeezed Middle of Their Own Stack
Companions: Who Advises the Disrupted? · Agentic AI Is Not Just LLMs and Tokens · A Product Playbook for Agentic AI — you are here · Why Agentic AI Transformation Is Hard · Give Your Coding Agents a Process · A Longer Leash.
Leave a Reply