Phase 4ADLC course

Phase 4. Requirements: the agent turns pain into a backlog

We have three artifacts: a value hypothesis, a marked-up discovery report, and a GTM plan full of promises to the market. Time to turn all of it into something buildable: formalized requirements, a PRD, a backlog with acceptance criteria and priorities. The phase where fuzzy pain becomes a checkable spec.

Requirements are traditionally written by a human — a product owner or analyst — and this work is rarely called creative, but it's often called "requiring contextual understanding." That understanding is exactly what the role's defense leans on: between pain and requirement sits common sense that can't be formalized. This article argues that most of that path is rule-based tracing, and the un-formalizable remainder is smaller than it looks.

The human role today

A product owner or business analyst: turn discovery pains into a PRD, cut it into epics and stories, write acceptance criteria, set priorities. Classically this is manual document writing, backlog grooming, arguments about what "done" means, and bargaining over release scope.

Broken down, the work splits into two unequal parts. The larger, mechanical one: take a pain, derive a requirement from it, formulate an acceptance criterion, link it to the source. The smaller, political one: decide what we cut for the deadline. The first is tracing; the second is a value choice under constraint. The first is what automates first, and it's the bulk of the work.

What we hand to the agent

The agent holds the role of requirements owner. From discovery-report and gtm-plan it synthesizes the PRD, cuts it into epics and stories, writes acceptance criteria, sets priority against a given model, and — critically — holds the trace "pain → requirement → promise to the market." Every story in the backlog knows which discovery pain it grew from and which gtm-plan promise it fulfills.

The agent also makes the "what's in scope, what isn't" call — with justification. It doesn't ask "what's more important to us"; it derives priority from decisions already made upstream: if the gtm-plan made payment the foundation of the positioning, payment can't be in v2, and the agent derives that rather than negotiates it.

Agent architecture

Phase state-machine

Inputs

discovery-report (phase 2), gtm-plan (phase 3), opportunity-brief (phase 1).

The agent holds the role

Tools: PRD synthesis; story decomposition; acceptance-criteria generator; prioritization (RICE / MoSCoW against given weights); "pain → requirement → promise" tracing.

Artifact

prd + backlog — stories with acceptance criteria, priority, and traces to the pain and to the market promise.

Handoff: prd/backlog → Architecture (non-functional requirements) and Planning (stories → tasks). The trace isn't bureaucracy — it's a defense against the phase's main disease: a product built against something other than what was promised to the market. In humans, the "promise → requirement" link tends to snap between the marketing deck and the dev backlog. The agent holds it as a graph edge: remove a promise from the plan and orphaned requirements light up; add a requirement and it must point to a pain, or it's someone's whim, not a need.

Inputs: discovery-report (phase 2), gtm-plan (phase 3), opportunity-brief (phase 1).
Tools: PRD synthesis; story decomposition; acceptance-criteria generator; prioritization (RICE / MoSCoW against given weights); "pain → requirement → promise" tracing.
Artifact: prd + backlog — stories with acceptance criteria, priority, and traces to the pain and to the market promise.
Trigger: completed discovery-report and gtm-plan.
Handoff: prd/backlog → Architecture (non-functional requirements) and Planning (stories → tasks).

The trace isn't bureaucracy — it's a defense against the phase's main disease: a product built against something other than what was promised to the market. In humans, the "promise → requirement" link tends to snap between the marketing deck and the dev backlog. The agent holds it as a graph edge: remove a promise from the plan and orphaned requirements light up; add a requirement and it must point to a pain, or it's someone's whim, not a need.

Where it breaks

Scope decisions with political weight. "What we cut for the deadline" isn't optimization — it's a choice with a cost and someone who pays it. The agent will derive the model-optimal scope, but the prioritization model itself carries weights that came from the principal. At the border of "hit the date vs. do it right," the deciding factor is risk appetite, not arithmetic.

Implicit domain requirements. Some requirements never get said out loud in discovery because they're self-evident to the person feeling the pain: "well, obviously the receipt should arrive." Domain common sense is knowledge that may not exist in any interview. The agent derives what was said; the unsaid-and-obvious is a blind spot.

Conflicting stakeholder requirements. When two stakeholders want incompatible things, the agent tends to look for a compromise that smooths over both. Sometimes the right move is to pick a side — and that's a decision with political weight the agent doesn't hold.

What stays human

Approving release scope and arbitrating value conflicts. A candidate for compression: the mechanics — synthesis, decomposition, criteria, tracing — go to the agent entirely. The durable remainder is the scope decision under deadline and money pressure, and it, like everything in the course, traces back to the principal (phase 14).

human remainder ≈ 73%

Provocation / thesis

A PRD is a trace from pain to decision, run by formal rules. Once pains are digitized and marked up (phase 2), and market promises are explicit (phase 3), requirements are derived, not written. The common sense conventionally used to justify the analyst's indispensability is either domain knowledge (which can be given to the agent explicitly) or a scope choice (which is a decision about money, not about requirements). The only argument left is about scope — that is, about time and budget, not about what to build.

Running case

Vitrina in this phase

The agent takes Vitrina's discovery-report and gtm-plan and unfolds them into a backlog. The pain "the customer wants to order and pay online" becomes epics: storefront builder, product catalog, cart, payment capture, order notifications. Every story carries its trace: "payment capture" points to a pain from the interviews and to the "payment in an hour" promise from the gtm-plan — and so it gets top priority automatically, not by request.

The contradiction resolved in phase 3 ("design vs. payment pipe") plays out here: the agent cuts the rich design builder into v2 — not because "the founder likes it less," but because no discovery pain points to it and no plan promise requires it. The scope log gets: booking, sales analytics, custom domains — all pushed to future releases, with justification traced back to source.

Artifact → Vitrina's prd/backlog. Notice: the "design or payment" argument, which with humans would drag through calls and politics, is closed here by a graph edge — no pain points to design. What's left is a single human decision: does the founder agree to cut design into v2. That's the scope call that needs a signature.

In practice

How it actually works — engineering breakdowns

Standalone howto from practice, showing this phase on real code and a working artifact.

Spec Kit as Engineering Discipline: Spec Before Codespecify → clarify → plan → tasks: turning a vague ask into a backlog, not code on the first prompt.
Clarify Gate in Jira: Intake to a Mature TicketTask admission by quality of the statement — a prototype of acceptance criteria.

Building AI-driven delivery in-house?

Designing the ADLC loop: where the agent holds the role and where the human principal remains — for your team and product.

Email me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →