Purpose: This guide is a practical filter for generating and evaluating P3-compatible product briefs. It is designed to be used as a lens — either by an AI system or a practitioner — to bring product thinking into alignment with P3 theory. It does not require any existing P3 infrastructure and is particularly useful when generating product briefs from raw ideas, market observations, or research findings.

A product is not an artefact. It is a vehicle for value transfer — the mechanism through which an organisation moves a specific capability to a specific beneficiary. The artefact (the software, the report, the service) is the container; the value transfer is the point.

This distinction matters because it changes what questions you ask. If a product is an artefact, the question is "did we build it?" If a product is a value transfer, the question is "did the beneficiary receive what we promised?"

Before anything qualifies as a product in the P3 sense, three questions must be answerable:

If you cannot answer all three, you do not yet have a product. You have a concept, an intention, or a technical capability in search of a purpose.

Every product is one of three fundamental types, or a combination of them. Classifying correctly prevents a common failure: building the wrong kind of thing because the team has defaulted to their preferred mode of delivery.

Theory (Knowledge): The product of understanding. What is transferred is clarity — a framework, a methodology, an analysis, a diagnosis. The beneficiary leaves with a more accurate or more complete mental model. Examples: a research report, a strategic framework, a training curriculum, a conceptual guide.

Instrument (Tool): The product of capability. What is transferred is utility — the ability to perform a task more efficiently, reliably, or at greater scale. The beneficiary leaves with enhanced operational capacity. Examples: software platforms, decision-support tools, process templates, automated systems.

Service (Outcome): The product of application. What is transferred is a result — the organisation applies expertise on behalf of the beneficiary, who receives the outcome without needing to develop the underlying capability themselves. Examples: consulting engagements, managed services, advisory programmes, implementation support.

A product can span multiple types — a platform (Instrument) that comes with documentation (Theory) and onboarding support (Service). But each type has its own success criteria and its own failure modes. Collapsing them together prevents clear governance of each.

The Tool-Obsession Warning: Organisations under technical pressure frequently convert Theory and Service products into Instruments without realising it — the research report becomes a dashboard, the advisory programme becomes a SaaS tool. When this happens, the human outcome is frequently lost in the conversion. Classify first; build second.

The most important reframing for early-maturity organisations: a product is not a trophy. It is a hypothesis made testable.

Every product embodies a claim: this capability, offered to this beneficiary in this context, will transfer the value we expect. Shipping is the moment that claim becomes testable — the beginning of the experiment, not its conclusion. The most informative version of a product is often not the most polished; it is the version that most efficiently tests the core hypothesis. Build what tests the claim. Learn from what you observe. Refine accordingly.

Apply the following filter sequentially to any product idea drawn from client materials — strategy documents, customer interviews, market research, innovation proposals, or team discussions.

Ask: what specifically moves from the organisation to the beneficiary as a result of this product?

Be precise. "Value" is not an answer. "Better performance" is not an answer. Name the capability, knowledge, or result that the beneficiary will hold that they did not hold before. If you cannot name it specifically, the product idea is not yet sufficiently defined to brief.

Ask: is what transfers primarily understanding (Theory), operational capacity (Instrument), or a realised result (Service)?

Classify the product accordingly. If it spans multiple types, identify the primary type and note the secondary types. The classification determines what success looks like.

Ask: can you name a specific type of person whose life or work measurably improves when this product succeeds?

"Our users" is not specific. "Senior engineers managing distributed deployments in regulated industries" is specific. The more precisely you can describe the beneficiary, the more precisely you can define what success looks like and what failure looks like.

If you cannot describe the beneficiary specifically, the product idea has not yet resolved from a general intention into a concrete offer.

Ask: do we have evidence that the beneficiary wants this, or are we assuming demand?

Assumed demand is one of the most common sources of product failure. A product that no one wants is not a product — it is a technical exercise. This does not require extensive market research at early maturity, but it does require at least one concrete signal: a conversation, an expressed pain point, an observable gap in existing offerings that this product addresses.

Distinguish between what beneficiaries say they want and what the evidence suggests they need. Both matter; neither is sufficient alone.

Ask: is this product competing on the same terms as existing offerings, or does it address a value space that current offerings do not serve?

A product that is marginally better than an existing alternative at the same price point is in a Red Ocean — competing for existing demand in a crowded market. A product that addresses unmet need, serves an underserved beneficiary, or combines value in a way no current offering does is moving toward Blue Ocean — creating demand rather than capturing it.

This is not a binary judgement. But when multiple product ideas are under consideration, this filter helps prioritise those most likely to generate differentiated value.

Once a product idea has survived the filter in Section 2, the following six-part brief structure provides the minimum information needed to evaluate it, design it, and govern its delivery.

1. Beneficiary Statement
Who benefits, and what changes for them?
Describe the specific type of beneficiary and contrast their situation before and after the product succeeds. Be specific — "our users" is not sufficient.

2. Value Exchange Statement
What capability is transferred, and in what form?
Name the specific thing being transferred (understanding, capacity, or outcome) and classify it as Theory, Instrument, or Service (or a combination).

3. Core Hypothesis
What claim does this product make that shipping will test?
State the hypothesis explicitly: if the beneficiary uses this product in the expected context, what outcome do we predict, and how will we know if we were right?

4. Probe Design
What is the smallest version that tests the core hypothesis?
Describe the minimum viable version — not the complete vision, but the version that generates the most informative test of the core claim. Constrain scope explicitly.

5. Done Criteria
What stakeholder-facing signal confirms the hypothesis test is complete?
Define what the beneficiary must do, say, or experience for the organisation to consider this probe complete. Done is a stakeholder claim — it depends on the beneficiary's response, not the organisation's effort.

6. Validity Marker
What confirms that the product is what it claims to be?
Identify the minimum traceability check: can the product's key design choices be connected to a stated principle or governing commitment? If a critical component were challenged, could you explain why it exists?

Done and Valid are different claims, and conflating them is the most common source of product governance failure at early maturity.

Done is a stakeholder claim: the beneficiary has accepted the product, the acceptance criteria have been satisfied, and the delivery event is closed. Done is subjective — it depends on stakeholder judgment. It is necessary but not sufficient.

Valid is a system claim: the product maintains the integrity of its own design commitments. Valid is objective — it can be checked against structural properties. A product is valid when its elements are traceable to governing principles, its structure reflects the approaches that composed it, and evidence exists that those approaches were correctly applied.

The gap between Done and Valid is where failures hide. A door plug can be certified Done by paperwork while the bolts are missing. A software release can be stakeholder-accepted while the security assumption it relies on was never verified. Done without Valid is a warranty without substance.

Apply these three questions to any product at the moment of delivery — or at any point during development when the product's integrity is in question.

Question 1 — Anchoring
Can you trace this product's key design choices to at least one governing commitment?
If yes: the product is anchored. If no: the product is unmoored — it exists without connection to the principles that should govern it.

Question 2 — Pattern Legibility
Could someone examining this product identify the approaches that were applied, and why?
At early maturity, this does not require formal documentation — it requires that design choices are visible and explicable. Opacity is a validity risk.

Question 3 — Evidential Warrant
Does evidence exist that the governing commitments were actually satisfied?
Evidence is the warrant for the product's validity claims. Assertion is not evidence. "We followed our security process" is not evidence. A record of what was checked, by whom, against what standard, with what outcome — that is evidence.

A practical early-maturity test: if this product were to fail in the field, could the organisation identify why within 48 hours? If yes — the product is sufficiently traceable to be Valid in the minimum viable sense. If no — the product lacks sufficient traceability, and future failures will be opaque rather than diagnostic. Opaque failures cannot be systematically corrected; they can only be patched.

When applied to client materials, this guide should be used as follows:

Ideas that do not survive Step 2 are concepts or capabilities without a defined value transfer — valuable as inputs to further thinking, but not yet products. Do not generate briefs for unresolved concepts; document the gap and flag for further clarification.

A product brief that is honest about what it does not yet know is more useful than one that fills all six fields with assumptions. Name the unknowns. They are the probe design for the next stage of discovery.

This guide is a pre-P3 reference document. It does not assume any P3 governance infrastructure. It is designed to create the conditions in which P3-compatible product governance can subsequently be built.