The Anatomy of a Requirement
Generating a requirement has never been easier. With tools like Claude and ChatGPT, a product manager can produce a page of well-written, plausible requirement content in minutes, and it will touch all the areas a requirement is supposed to touch. It has also made a particular mistake easier: treating the moment the content appears as the moment the job is done.
It is not. A freshly written requirement, however complete it reads, is a hypothesis: a claim that a specific persona, at a specific point in their journey, needs a specific capability to reach a specific outcome. Nothing about generating that claim makes it true. The job of a product manager is not to write requirements. It is to prove them, and to pass to engineering only the ones that hold up.
That is the discipline this article describes. It has three movements: state the hypothesis in a well-formed way, test it, and hand over only what has been validated. The anatomy of a requirement exists to serve all three.
A well-formed hypothesis is born, not written
The chain is fixed: Idea, Concept, Persona, Task, Journey Map, User Journey, Requirement. An idea becomes a concept worth pursuing. Personas are built around the concept. A persona performs a task, expressed as a user story and decomposed into an ordered set of journey steps. Each step maps one to one to a requirement, and the task becomes the parent requirement that groups them.
This lineage is what makes the hypothesis well formed. A requirement detached from a journey is a claim with no subject: nobody can say who it serves, what it follows from, or what outcome would prove it right. If you cannot trace a requirement back through a journey step to a task, a persona, and the concept they serve, you have an assertion, not a hypothesis you can test. And because the concept's context flows down the chain by inheritance, two journeys with identical steps but different concepts behind them are different requirements, testable against different outcomes.
The anatomy states the claim
Open a requirement in THREADS PM and you are looking at 27 fields. Nobody should memorize 27 fields. They group into eight parts, and each part makes one piece of the hypothesis explicit enough to be challenged:
Lineage says who it is for and where it came from: the linked step, the parent, the persona, the source. Identity says what it is: a title specific enough to stand alone, a description in user terms, what the system must deliver, never how. Classification says what kind of claim it is: functional, non-functional, hygiene, or strategic, which drives how it will be scored, batched, and anchored. Boundaries say when it begins and what is assumed, inherited from the journey: the trigger, the preconditions, the verifiable exit state, the platforms in scope. Accountability names who answers for it: the source who raised it, the sponsor who champions it, the product owner who shepherds it. Priority says why now, through RICE+, Kano, and the Motivation model. Proof says what evidence would validate it: acceptance criteria seeded by the exit state, and test scenarios. Lifecycle records where it stands and, when it is deferred or rejected, why, so the decision survives the meeting it was made in.
Written this way, a requirement is not a wall of prose organized by the author's instincts. Every claim sits in a known place, which means every gap is visible, and everything in it can be interrogated by the people who will test it.
The prototype is the test
Text states the hypothesis. It cannot test it, because stakeholders cannot react to a claim they have to imagine. This is what the prototype is for, and why it is part of the requirement's anatomy rather than a nice-to-have that follows it.
The journey narrative carries the why and the boundaries. The interactive prototype carries the behavior: the states, the branches where a condition is true or false, a payment succeeds or fails, an approval is granted or sent back. Walking a stakeholder through a working prototype of the journey, branch by branch, is the difference between asking "does this requirement look right" and watching whether the journey actually produces the outcome the concept promised. Personas react to it, subject matter experts correct it, unhappy paths surface in it. Every correction flows back into the journey, and because requirements are derived from the journey, the requirements update with it.
The prototype does not replace the text requirement. It is how the text requirement gets falsified or confirmed while correction is still cheap.
The requirement lives with product until it is proven
This is where the discipline most often breaks down: writing a requirement does not queue it for engineering. A requirement stays with product through its validation life: tested against the prototype, challenged by stakeholders, refined as the journey sharpens, scored and prioritized against everything else competing for the release, its outcomes defended.
Experienced product managers will push back here: the draft is not a guess, it is their expertise, so why elongate the process to back up what they already know. But the process does not test the expert, it arms them. Expert judgment carries disproportionate weight inside it, and what comes out is judgment converted into evidence: something that holds the line when the loudest voice in the room wants to reorder the release, transfers cleanly to people who think differently, and scales past what one person can carry. Being right is not enough; being right with the evidence attached is what wins the argument.
Only when the requirement fully represents what we intend to build, validated, prioritized, refined, with its acceptance criteria testable and its rationale defensible, does it cross the line. Requirements that fail the test are deferred or rejected with their disposition recorded, which is not waste. A hypothesis cheaply disproven in product is the economic argument for doing this work before engineering gets involved rather than after.
What engineering receives
When a validated requirement syncs to Jira, the whole anatomy travels. The task and its journey become the Epic; each step becomes a Story. Title maps to summary, description to description, status flows through a mapping table with Jira's workflow mirrored back read-only. The Epic description carries the journey's contract: the user story, the trigger, the preconditions, the exit state, and any constraints linked at the journey level.
A requirement does not contain everything it depends on. Entity models, architecture decisions, and cross-cutting business rules live in their own documents, and the requirement points at them through its reference fields. The completeness test is not whether the requirement holds it all, but whether everything it depends on is reachable from it: in THREADS PM through Links, in Jira through the references carried on the Epic. And one rule keeps the handoff honest: THREADS PM owns requirement content, Jira owns delivery workflow. When a constraint changes, the source changes first and the Epic is re-pushed.
Engineering, in other words, does not receive a draft to interpret. They receive a claim that has been tested, with the evidence attached.
The readiness test
Before a requirement crosses to engineering, it must answer five questions without you in the room: who is it for, why does it exist, when does it begin, what does done look like, and why now. And it must pass one condition the questions cannot capture: it has been tested. Someone has walked the journey, watched the prototype, challenged the claim, and the requirement standing at the end is the refined version, not the first draft.
Generating the first draft is now the easy part, and it will keep getting easier. The value of the product manager is in the proving.