Chapter 12: Which Frameworks Still Hold
There is a journey map on a wall somewhere, and it is beautiful. Swimlanes in three colors. Every touchpoint, every emotion, the dip at the moment of friction and the recovery after, annotated with quotes from real interviews. Someone spent two weeks on it and the work is good. It is also describing a journey the user no longer takes, because the agent takes it for them now. The user states an intent and a resolution arrives. The middle of the map, the part with all the craft in it, is a record of a path that has been automated out of the user’s hands. The artifact is excellent. It informs no decision anyone is going to make.
This chapter is about the moment you notice that, and about not letting it happen to the rest of your toolbox without noticing.
A note on what this is not. There is a sibling discipline, adapting the classical frameworks to design the agentic product itself, bending Jobs to Be Done or the product lifecycle until they fit a system that acts. Real work, and not this chapter’s. That discipline serves the product. This one is about you. The question there was how do I adapt this framework to build the thing. The question here is which of the tools in my own head still produce a decision when I reach for them, which produce a confident-looking artifact and no decision at all, and how do I run a standing review on my own kit the way I run one on the agent’s instruments. The first is product design. The second is self-curation, and nobody on the org chart owns it, which by now is a familiar problem.
The assumption every framework was hiding
The classical PM frameworks were built across two decades and they share one buried assumption that none of them states, because in the world they were built for it was too obvious to state. The assumption is that the human is the senior party in the workflow. The software waits. It waits for the click, the sprint, the deployment window, the business to decide what it wants. The human moves and the system responds, and every framework is organized around what the human does next.
The journey map assumes the human walks the journey. The product lifecycle assumes a human-paced loop where the observe phase can be the weak link, compressed into retrospectives and a thirty-day survey, because the product sits still between observations and nothing compounds while you are not looking. The discovery framework assumes you are learning what a human wants so a human can decide whether to give it to them. The acceptance criterion assumes a system that does what it is told. All of them, underneath, assume the human is upstream of the action and the system is downstream, obedient, waiting.
Agentic systems invert exactly that. The agent does not wait; it acts. It does not walk the journey; it collapses it. It does not sit still between observations; it keeps deciding, compounding its last-known configuration forward while nobody is looking, which turns the observe phase from a quality problem into a safety problem. The senior party is no longer reliably the human. Which means every framework you own has to be checked against the one assumption it was built on and never examined, because the assumption is the thing that quietly stopped being true.
The sorting rule
You do not need a taxonomy of frameworks. You need one question you can ask of any tool in your kit, fast, and the question is this: what does this framework assume the human does next?
Ask it and the tools sort themselves into three piles.
If the framework assumes the human does the thing the agent now does, walks the journey, executes the steps, makes the per-case call, then the framework is describing a role that has moved, and the artifact it produces is a portrait of a worker who is no longer there. That is the journey map on the wall.
If the framework assumes the human decides something the agent still cannot decide, what the user is really trying to accomplish, where the boundary of acceptable behavior sits, what the product should refuse to become, then the framework survives, because the decision it structures is still a human’s. It may need its inputs changed, but the tool still produces a decision.
And if the framework produces an artifact whether or not the decision underneath it still exists, if it will happily generate a beautiful deliverable that no longer connects to any choice anyone makes, then it is a deceptive survivor, the most dangerous pile, because it does not announce its obsolescence. It keeps producing, and the production feels like progress.
That is the whole sorting rule. What does it assume the human does next. Run it on each tool you reach for and notice which pile each one falls into. The rest of this chapter is what the piles look like in practice.
Survivors, with modification
Some tools survive because the decision they serve is still yours; only the inputs changed.
Jobs to Be Done is the clearest survivor. People still hire products to get a job done. The four forces that govern whether they switch still govern it. The job did not change. The doer did. Where Jobs to Be Done used to point you at a human who would take your feature and decide what to do with it, it now points you at a human who hires an agent to take the whole job off their hands, and the design question becomes what the agent must accomplish on the person’s behalf and where it must hand the job back. The framework holds because it was always about the job, not the journey, and the job is the durable thing. The mistake is to keep using its outputs to design a flow when the user no longer flows. Keep the job. Drop the journey it used to imply.
The product lifecycle survives with one phase rebuilt. Discover, define, design, build, launch still work. The observe phase, always the weak link, has to be promoted from afterthought to load-bearing, because an unobserved agent does not stagnate quietly the way an unobserved SaaS feature does; it keeps acting on a configuration that has drifted, and the cost compounds. Picture the cautionary case: an agent that processed orders for six months, hundreds of transactions all marked confirmed, while the supplier called asking about orders that never arrived. The completion metric was real and the work was not, and the lifecycle did not catch it because the observe phase was never built. So the lifecycle survives, but its center of gravity moved from launch to observation, and a PM still treating observe as a retrospective bullet is using a survivor as if it had not mutated.
And the journey map has a successor rather than a death. Where the user no longer walks a path, the question that produced the journey map, what is the sequence of steps and how does the user feel at each one, gives way to the question that produces a boundary map: where is the line between what the agent does alone and what returns to a person, and what happens on each side of it. The craft you used to spend on the dip-and-recovery of the emotional curve moves to the seams, the approval moment, the handoff, the case the agent must refuse. The boundary map is the journey map’s heir, built for a user who states an intent and inspects a result rather than walking from friction to resolution. Same instinct for the user’s experience. Different object, because the experience now happens at the boundary, not along the path.
The deceptive survivors
The dangerous pile is the one that keeps producing artifacts after the decision underneath has left.
The journey map is the obvious member, but it is honest in its obsolescence once you look; the wall makes the mismatch visible. The truly deceptive survivors are subtler, because their artifacts still look like decisions.
The detailed user-flow diagram is one. It produces a clean, reviewable, shippable-looking deliverable, and for an agentic product it often encodes a sequence of steps no human takes and no agent reliably follows, because the agent does not walk steps; it sits at decision points and chooses. The flow diagram looks like a specification and functions like a fiction. The tell is that nobody ever makes a decision by looking at it; they admire it and then go decide some other way.
The persona deck is another, in a specific way. Personas still matter for who the product serves, but the persona deck built around behaviors, how this user navigates, what they click, where they hesitate, is describing navigation the agent absorbed. The part of the persona that survives is what the person needs decided on their behalf and what they will not tolerate being decided wrong. The part that does not survive is the click-path the deck spent its pages on.
The feature-prioritization matrix that scores against a roadmap of human-paced releases is a third, where it quietly assumes the unit of work is a feature a human will use, rather than a behavior an agent will exhibit across a distribution of cases. It will rank your backlog beautifully and rank it for the wrong unit.
The test for a deceptive survivor is brutal and simple. Produce the artifact, then ask what decision it changed. If the honest answer is that it informed a conversation and felt like progress but no one did anything differently because of it, you have found one. The artifact is not evidence of work. It is the residue of a habit. The most expensive frameworks to retire are the ones that still feel productive, because the feeling is doing the work the decision used to do.
Your toolbox is a versioned thing
Here is where this chapter parts company with the product-adaptation chapter for good. The frameworks in your head are instruments, and instruments have a half-life. A monitoring instrument calibrated to one model, one configuration, one moment, drifts as the world it measures moves; a roughly eighteen-month useful life is the working assumption for the agent’s dashboards. The argument applies to the mental tools too. The instruments you reason with decay exactly as the instruments you monitor with do, and for the same reason: the world they were calibrated against keeps moving while your confidence in them holds steady.
Which means your toolbox is not a fixed possession you acquired in your training and now own. It is a versioned thing, and it needs the same standing review you give the agent’s instruments and the same one you give your own judgment in the proficiency regime. Once or twice a year, lay out the frameworks you actually reach for, the ones that run automatically when you sit down to a problem, and run the sorting rule on each. What does it assume the human does next, and is that still true in the workflows you work in now. The ones that still produce decisions stay. The survivors that mutated get their inputs updated, journey to boundary, observe-phase promoted, persona refocused on what gets decided rather than how the user clicks. And the deceptive survivors get retired, named, and crossed off, because a tool you keep reaching for out of habit is worse than no tool, since it produces the feeling of rigor without the substance.
This is uncomfortable in a way the product chapter never was, because these are not the product’s frameworks. They are yours. They are how you think, and some of them are how you built your reputation, and retiring one feels like admitting a part of your skill expired. It did. That is what a half-life means. The practitioner who treats the toolbox as a fixed inheritance is the same practitioner the first part of this book described, confident and uncalibrated, except now the decay is in the tools rather than the judgment, and just as invisible from the inside.
The one I retired was the journey map, and I remember the meeting where it died for me. We were designing around an agent that resolved a request end to end, and someone put a beautifully built journey on the wall, every step and every emotional beat annotated. I caught myself about to give the feedback I had given a hundred times, and realized there was nothing to give, because the user no longer walked any of those steps; the agent had taken them. The artifact was excellent and it informed no decision in the room. What we actually needed was nowhere on the wall: where the line sat between what the agent did alone and what came back to a person, and what happened on each side of it. I had been reaching for the journey map out of habit long after the thing it described had stopped existing, and the boundary map took its place that afternoon.
How to evaluate the next one, including mine
You will be sold a new framework next quarter. Someone always has one, and in this cycle there are more than usual, because the ground moved and everyone is selling the map. So the last tool in the kit is the one that evaluates the others, and it is the sorting rule pointed forward instead of back.
When a new framework arrives, do not ask whether it is clever or whether it produces a nice artifact. Ask the same question you ask the old ones. What does this framework assume the human does next, and is that assumption true in the workflow where I would use it. A framework that assumes the human still executes the thing the agent now executes is selling you a journey map in new colors, however current its vocabulary. A framework that structures a decision that is still a human’s to make, the boundary, the suitability call, the when-wrong specification, the gate, is worth its weight, and you can tell because using it forces a choice you would otherwise have made by default or not at all.
Apply this to my frameworks too, including every tool this book has handed you. The two-brief split earns its place because it forces a decision, who owns the wrong outcome, that no single document held. The gate owner’s five questions earn their place because each one changes what you sign. The proficiency regime earns its place because it produces a number you act on. If any framework of mine ever stops forcing a decision in your hands and starts producing an artifact you admire and file, retire it, including the ones with my name on them. The sorting rule does not exempt its own author. A framework that has become a habit is a habit whatever its pedigree, and the whole discipline of this chapter is refusing to let a tool keep its seat on reputation after it has stopped doing the work.
Your kit, sorted and versioned, is part of the same record this book has been building, not as a new artifact to file but as the sharpened set of instruments the next two parts of your career run on. Tools sorted. The room is where you use them, and the room has its own craft, because being right with the right tool is not the same as being heard. Two product managers are about to raise the same correct concern in the same review, and only one of them will still be in the conversation a week later.