The PM’s New Unit of Work: Business Intent Specs, Fidelity Allocation, and a Roadmap That Can’t Round Up 

How the product manager's operating model changes when agents, not people, consume the backlog - and what an enterprise AI foundation has to provide for that model to hold.

Thirty tickets. Thirty green checkmarks. Every acceptance criterion satisfied to the letter, every card closed on time. That sprint can still precede the worst release of the quarter, and increasingly it does.

The reason is structural. When a team moves to Specification-Driven Development - a workflow where a versioned, structured specification, rather than a ticket or an ad hoc prompt, is the artifact the agent derives its plan, code, and tests from - the reader of the backlog changes. A developer who hits an ambiguous line in a ticket raises a hand at standup. An agent doesn't raise a hand. It fills the gap with something plausible and keeps going, at the scale the ticket describes.

We made the engineering case for this in a previous article on this blog: Spec-Driven Development is governance, and undocumented intent in a regulated environment is a control gap rather than a documentation problem. This piece is the other half of that argument. If the reviewed specification is the artifact an auditor reads, someone has to write it, decide which items deserve one, and keep it true over time. That someone is the product manager.

Below is the operating model that replaces the ticket, and the parts it must carry to survive contact with an actual enterprise.

Why the ticket broke

The ticket didn't fail because product managers wrote it badly. It failed because it was never designed to be a complete specification in the first place.

Ron Jeffries described the story card back in 2001 as a promise of a conversation:

1. card;
2. conversation;
3. confirmation.

Three separate steps. The card was a ticket to a discussion, not a requirements document. Incompleteness was the design, and it worked, because the model assumed a human reader who would close the gaps through dialogue.

Agents don't meet that assumption. Research on defect recognition in task descriptions suggests that GPT-4-class models detect ambiguous requirements only moderately well - among the better performers tested, and still well short of reliable. A model that doesn't recognise a requirement as ambiguous has no reason to ask about it. It proceeds.

So the PM's artifact map splits into three columns:

What you write. Business Intent Spec, non-goals, measurable acceptance criteria, the value definition, the roadmap.

What you review. The functional spec, strictly for intent alignment. Nothing else.

What you no longer touch. Task decomposition, implementation choices, the code.

The shift is qualitative, not quantitative. The artifacts move from disposable to durable, from human-readable to machine-processable. Intent and roadmap become product state, versioned alongside the system. Sprints and individual agent runs are flow.

The Business Intent Spec: five fields, one sentence each

A caveat first: "Business Intent Spec" is a pattern name, not an industry standard. There's no certified template. What exists is a shape that independent practitioners keep converging on, and the convergence is the argument, not the label.

Five headings, one sentence of instruction under each, committed to the repository next to the code. That's the whole template.

The difference from a PRD is not formatting. A PRD tolerates ambiguity because a human closes gaps with judgement. A Business Intent Spec can't, because the executor has no judgement, only literal execution. Acceptance criteria stop being descriptive ("as a user, I want to see my cart") and become boundary conditions that can run as a test.

Non-goals are a safety boundary, not documentation hygiene

The most important field is the one PMs skip most often.

Models have a well-observed tendency to expand scope: to add things nobody excluded, because nobody thought to exclude them. A widely circulated anecdote describes a multi-hour production outage caused by an agent that concluded "delete and rebuild" was the shortest path to its goal. Treat it as an unverified industry legend, because that's what it is. The mechanism holds without the anecdote: an agent optimises for the path to the goal, and anything you don't forbid is a permitted path.

This is where the stakes rise sharply in an enterprise setting. A code-generation agent with a missing non-goal produces a bad pull request. An operational agent wired into ERP, CRM, ticketing, and internal databases with a missing non-goal takes actions in systems of record.

Which is why the non-goals field and the governance plane are two halves of the same control. Agents built in Jeen Agent Factory operate within the boundaries set in Jeen Admin: SSO, role-based access control, and explicit knowledge-access policies that determine which agent may retrieve or act on what, with every execution state, prompt-context chunk, and tool call written to an immutable audit ledger. The spec states what the agent is not supposed to do. The platform enforces what it can't do and records what it actually did. Relying only on the first is a choice most regulated organisations can't make.

Prioritisation becomes fidelity allocation

For a decade, the scarce resource was hands to write code. That constraint has loosened considerably. What became scarce instead is the PM's own capacity to produce unambiguous intent.

Most of a PM's week goes to coordination and status chasing rather than roadmap or strategy work. This isn't new, and SDD doesn't cause it. SDD exposes it, because there is suddenly nowhere to hide underspecified intent behind someone's "I'll get it done this sprint."

"A wealth of information creates a poverty of attention." - Herbert Simon

Simon named the problem half a century before it became operational for product teams. When execution cost approaches zero, the only budget left is the attention of whoever decides what gets executed.

Hence a reframing of the priority question. Instead of "what do we build and what do we cut," the question becomes: what do we refine into an executable contract this week, and what stays a deliberately cheap sketch?

Engineering already has a version of this. Our previous article framed it as a sizing decision made task by task: vibe coding for throwaway work, lightweight SDD once a task spans days and files, full SDD when a public contract or an audit trail is involved, with the most common mistake being full SDD applied to tasks that needed the light version. Fidelity allocation is the same judgement moved up a level, from one task to a whole backlog, and made by the person who owns the intent rather than the person about to implement it.

Reading it this way also settles the waterfall objection before it gets raised. Waterfall is not "we wrote a spec." Waterfall is a feedback loop stretched to weeks, where you spec everything before implementing anything and discover the wrong assumption after building on it. A backlog where two items are executable contracts, and eighteen are one-line sketches is the structural opposite of that. The whole point of allocating fidelity is that most of the backlog stays deliberately unspecified until the moment specifying it pays.

Items don't get deleted. They wait in a spec backlog as one or two low-resolution sentences until they earn promotion. The rough allocation rule is unglamorous:

• Maximum fidelity now: compliance-critical items, security-critical items, anything with cross-team dependencies.
• Cheap sketch: experimental and discovery items, until the hypothesis is validated.

The waste on the other side of this decision is premature precision: hours poured into an exhaustive spec for an idea whose business value nobody has validated. Refining a sketch into an executable contract is a commitment, and commitments belong at the last responsible moment.

There is a second, less discussed reason to allocate fidelity rather than maximise it: over-specified instructions can degrade model performance. More words are not monotonically better. Fidelity allocation exists partly to avoid that failure mode, not only to protect the PM's calendar.

Where the cost becomes visible

Fidelity allocation is easier to argue in the abstract than to defend in a planning meeting, because the cost of the alternative has historically been invisible. Nobody had a number for what an over-refined spec, or an agent looping on an underspecified one, actually consumed.

That changes when consumption is instrumented. Jeen FinOps sets budgets per user, per agent, and per department, and enforces them with real-time throttling and deterministic runtime quotas rather than a reporting dashboard someone reviews monthly. Once a specific agent's cost is a number with a ceiling, "which backlog items deserve executable fidelity" stops being a philosophical question and becomes a budget line with an owner. It also surfaces the failure mode directly: an agent burning tokens in retry loops is usually an intent problem wearing a cost problem's clothing.

The counterargument you shouldn't skip

Here is the part that spoils the clean story, and leaving it out would be dishonest.

A large empirical study (Hill, 2026) covering more than 100,000 pull requests across 119 open-source repositories, with author fixed-effects controls, found no measurable effect of spec quality on rework (p = 0.997). The mere presence of a spec correlated with higher revision rates. The authors read specs as a proxy for task complexity rather than a lever for quality. It's an SSRN working paper and, not yet peer-reviewed, which doesn't invalidate the finding but is worth stating.

The honest position: fidelity allocation is a tool for managing the PM's scarce attention. It is not a proven lever for reducing rework. The empirical picture is genuinely contested, and anyone selling you certainty here is selling something.

Note what the finding does not touch, though. The enterprise case for specs was never primarily about rework velocity. It is about producing a reviewed, durable, access-controlled artifact that answers what the intended behaviour was, who approved it, and what evidence exists that the system does what was approved. A spec could fail to speed up a single sprint and still be the only thing standing between an organisation and an audit finding. Those are separate claims, and only the second one is load-bearing here.

The roadmap as a living spec

Marty Cagan has estimated that roughly 95% of roadmaps are output roadmaps rather than outcome roadmaps: decks describing what ships, not what changes for the customer.

The deeper flaw is mechanical. A completion percentage on a slide comes from an estimate given in a meeting, and no one can verify that kind of estimate, including the person who gave it.

A living roadmap replaces the slide with a chain of links:

1. A roadmap item points to a Business Intent Spec.
2. That spec's acceptance criteria generate automated tests.
3. Those tests run continuously in the pipeline.
4. The roadmap queries the pipeline and reports the share of passing tests linked to those criteria.

Call it traceability-derived status: a percentage computed from a link graph rather than reported by a human. If the roadmap says 40%, exactly 40% of the criteria in the intent work in the code. You cannot raise the number without raising it in the tests.

This isn't speculative. Spec-driven tooling already builds task dependency graphs and reports status against specific requirements in real time. Regulated industries have run requirements traceability matrices for decades - DO-178C in avionics, IEC 62304 in medical devices - precisely because coverage has to be computed from the graph rather than declared in a meeting.

The condition under which it still lies

A roadmap like this can absolutely lie. It lies when the links go stale, and the spec drifts from the code.

Teams working across hundreds of Markdown spec files describe how small discrepancies accumulate, degrading both human and machine understanding of the system. After enough rounds of drift, the code and the spec only superficially resemble the same thing, and the computed percentage becomes exactly as fictional as the estimated one, just formatted more convincingly.

This is a maintenance cost, not a refutation. A PM who proposes a living roadmap is also volunteering for the discipline of keeping the spec files clean.

It's also where deployment topology stops being an IT detail. If the traceability graph is the source of truth for regulatory coverage, the graph, the specs, and the retrieval layer that reads them have to sit inside the compliance boundary. Jeen's platform is deployable in cloud, on-premises, hybrid, and air-gapped configurations, with SOC 2 Type 2 and ISO 27001 certification, which is the reason the on-prem and air-gapped options exist at all for defence, healthcare, and government buyers. A living roadmap for a regulated product is not much use if its evidence chain lives somewhere the auditor can't follow.

The new rituals

Backlog refinement leaves the calendar. So do status meetings.

Spec review replaces them: a structured, cross-functional review of the Business Intent Spec before it enters the factory. Three checks. Does the spec match product intent? Are the non-goals right? Can the acceptance criteria actually run?

The standard objection is that PMs don't have time to write specs. That's a misdiagnosis. PMs have always written specs, just in the worst available format - scattered across tickets, Slack threads, and issue comments where no agent and few humans can reconstruct them. What changes is where the effort lands, not whether it exists.

Discovery changes shape too. Instead of weeks at a whiteboard, the PM works with an assistant that turns a one-sentence customer pain point into a list of business-logic conflicts and analytical gaps. This only works if the assistant can actually read the organisation: past specs, support tickets, contracts, policy documents, prior decisions. A general-purpose chatbot with no access to internal knowledge produces generic intent, and generic intent is the thing this whole model exists to eliminate.

That's the role Workspace plays in Jeen's platform. Enterprise chat grounded in the organisation’s own documents, with conversation context retained and the ability to call into agents the organisation has published. And for teams whose requirements originate in conversations rather than documents, Talk captures, transcribes, and analyses voice interactions, which is often where the unfiltered version of the customer’s problem actually lives.

One more architectural point worth making explicitly. If the spec is the durable asset, it has to outlive any particular model. Prompt-level craft tuned to one vendor’s model is a depreciating asset. Our own architecture research puts production LLM accuracy decaying regardless of vendor - to roughly 85% of baseline at six months and to a failing 60% by eighteen - though we should hold that number to the standard this article has applied elsewhere: it comes from our internal deployments, it isn’t independently replicated, and you should treat the direction as the claim rather than the decimal. The direction is not really in dispute. The model underneath your roadmap will change, whether you plan for it or not.

A structured intent layer doesn't depreciate that way, but only if the platform lets you swap what sits beneath it. Jeen is multi-LLM by design - the customer picks the model, and the governance layer stays put when they switch. That is what keeps the acceptance criteria, the traceability graph, and the roadmap percentage meaningful across a model migration instead of resetting with it.

The definition of good product management work has quietly changed. It is now: intent the factory can consume without needing to ask for clarification.

Related reading: Spec-Driven Development Isn't Waterfall. It's Governance. - our engineering-side case for the same argument.