For twenty years the product manager and the developer ran a relay. The PM gathered customer input, wrote the spec, and handed it over. The developer took the spec, made the technical calls, and built it. The PM checked the result against the intent. Then the baton went back.
The handoff defined the relationship. PM owned the “what.” Developer owned the “how.” Most of the friction between the two roles came from that seam: specs that missed context, estimates that blew up mid-sprint, features that shipped and then sat unused.
AI broke the seam that held the relay together.
What the relay looked like
The old model was sequential by design. A PM spent weeks turning Gong calls, Zendesk tickets, and Salesforce notes into a requirements doc. Engineering scoped it. The team built. Somewhere near the end, reality showed up: an edge case nobody flagged, a dependency nobody saw, a customer need the spec described wrong.
Then the PM adjusted scope after the surprise, not before it. The wall between roles meant each side learned what the other side knew too late to act on it cheaply.
That model ran on a constraint everyone accepted: building was slow. When a feature took six weeks, the cost of a detailed spec and a careful handoff was rounding error against the cost of the build. You planned hard because building was the expensive part.
What AI actually changed
AI compressed the build. Prototyping that took two weeks takes an afternoon. The expensive part of the old equation got cheap, and that broke the logic that justified the relay.
Developers spend less time typing code and more time framing the problem, reviewing what the AI generated, and making the technical judgment calls that AI still gets wrong. PMs spend less time writing solution specs and more time defining outcomes, acceptance criteria, and what success looks like, because the AI can fill in more of the “how” on its own.
The roles moved toward each other. The PM is shifting from owning requirements to owning intent, and the job changes again when the loop from signal to shipped fix closes in a day. The developer is shifting from implementing tickets to co-designing the thing. Both can test an idea with real users before either of them has spent real time on it.
Here is the practical version. Before, a PM wrote a detailed feature spec, waited for estimates, and rebuilt the plan after implementation surprised everyone. Now a PM and a developer sketch a rough flow together in a morning, put it in front of users that afternoon, and kill the bad direction before it costs anything. The work got more iterative and lost most of its paperwork. Claude Design pushed that loop even tighter.
The part nobody puts in the press release
Speed fixed the wrong problem.
The bottleneck was never typing. Most teams did not ship slowly because their engineers were slow typists. They shipped the wrong things because the decision about what to build came from a meeting, a loudest-customer anecdote, or a roadmap someone wrote last quarter and forgot.
AI coding tools made building faster while the decisions behind the building stayed thin. When a developer and a PM can prototype anything by lunch, the question stops being “can we build it” and becomes “should we, out of the thousand things we could build, build this one.” Cheap building means more decisions, made faster, on the same weak evidence.
So the new relationship has a new failure mode. The PM and developer work closer than ever, iterating in tight loops, shipping prototypes by the afternoon, aimed by whoever sounded most sure of themselves in the standup. And when one of those calls turns out wrong, nobody owns it.
Tokenmaxxing, and the cap that does not fix it
Watch what teams optimize for and you can see the failure mode in the numbers. Meta ran an internal leaderboard with “Token Legend” status for the engineers who burned the most. Uber spent its entire 2026 AI coding budget in four months after tying adoption to internal rankings. An AI consultant told Axios one client ran through half a billion dollars in a single month after forgetting to cap usage on its Claude licenses. Silicon Valley has a name for it: tokenmaxxing. Spending tokens with no line back to anything that matters. The same reporting found people querying frontier models to check the weather.
So everyone is rushing to token caps. A finance team sets a monthly ceiling, the dashboard turns green, and the problem looks solved. It is not. A cap limits the bleeding. It says nothing about whether the spend that stays under the line bought anything worth building. You can hit your cap to the dollar and still ship a quarter of features nobody asked for. The cap treats the symptom. Tokens were never the thing to optimize.
The transition Bagel argues for is from tokenmaxxing to impact maxxing. Tokenmaxxing measures AI productivity by volume: tokens burned, prototypes shipped, lines generated. Impact maxxing measures it by what moved: the ARR unblocked, the churn prevented, the deal closed because the right thing shipped. Yamini Rangan, CEO of HubSpot, put the counter-frame on the table when she posted that outcome maxxing beats token maxxing. Impact is the sharper version of her point, because outcomes can stay vague and impact is a revenue figure you can point at. A team can run fully tokenmaxxed, busy and green on every usage dashboard, while the metrics that pay the bills sit flat.
Making that transition is not about using less AI. It is about the layer underneath it. Impact happens when the context feeding the decision is right: organized, quantified, tied to revenue, ready before the prototype starts. So your Claude is not building a feature off the first line of a spreadsheet because that was the loudest signal in the room. Your AI sounds like it knows what is broken. It does not.
Build what moves revenue.
Bagel makes the product decision evidence-backed, so the answer is clear.
The decision is the work now
If building is cheap and the roles have merged around shared judgment, then the scarce thing is the judgment itself. Ask Claude, Gemini, and ChatGPT where the product role is headed and they disagree on the details and agree on this: AI eats the mechanical work, and what is left is the call. What deserves the prototype. Which signal across ten thousand tickets and calls points at revenue. Whether the flow you sketched this morning solves a problem fourteen accounts have or one loud account has once.
That call used to live in a PM’s head and leak out in a spec. It cannot live there anymore, because the loop is too fast and the volume of decisions is too high. The decision needs evidence behind it, the same revenue context the team would want before a six-week build, available in the seconds before an afternoon one. MCP is the protocol that closes that context gap between the agent writing the code and the customer the code is for.
This is the gap Bagel sits in. Your AI coding stack is set. Claude, Cursor, whatever your team builds in. Those tools are very good at building and have no opinion about what to build. Bagel reads every customer signal across your sources, ties it to revenue, and turns it into a scoped decision the PM and the developer can act on together, served straight into the tools they already work in through the Bagel MCP.
The PM still brings the user insight and the developer still brings the system thinking. What Bagel adds is the evidence behind the call. The wall is gone, and what fills the space where it stood is the decision about what matters, what is feasible, and what should ship next.
The teams winning right now did not just get faster at building. They stopped optimizing for tokens and started optimizing for impact. Speed without that is a very efficient way to ship the wrong thing, on budget, under the cap.
