4.2 Focus on Products

The Product Focus

Focus on products means a PRINCE2 project is defined by the outputs it must deliver — products with agreed quality criteria — not by the activity spent producing them. A project that plans only tasks and milestones risks delivering something the customer did not want, on time and on budget. PRINCE2 inverts this: agree what good looks like first, then plan the work to get there.

Product-based planning

PRINCE2 uses product-based planning, which has three core artefacts:

1. Product Description — a written specification for a single product covering its purpose, composition, derivation, format, and quality criteria (with quality method and tolerance where relevant).
2. Product Breakdown Structure (PBS) — a hierarchical decomposition of the project's products into sub-products, showing what must be produced.
3. Product Flow Diagram (PFD) — a dependency network showing the sequence in which products are created, from which the project plan and stage plans derive their dependencies.

The Project Product Description sits above these as the top-level specification for the project's final output, agreed in Starting Up a Project and refined in Initiating a Project.

Product Description contents

A Product Description must contain, at minimum:

• Purpose — why the product is needed and what it enables.
• Composition — what the product consists of (components, sections, parts).
• Derivation — what the product is built from or derived from (source materials, inputs).
• Format and presentation — the form the product takes (document, software build, physical object).
• Quality criteria — the measurable tests the product must pass to be accepted, with the quality method and responsibilities.

Without these, the people building and checking the product have no shared standard of done.

Quality expectations up front

Quality expectations are captured early. In Starting Up a Project, the Project Product Description records the customer's quality expectations and acceptance criteria at a high level. In Initiating a Project, these are refined into testable quality criteria. This is the opposite of leaving quality to the end: the customer agrees what acceptable means before significant work begins.

Why product focus matters

A shared product understanding reduces ambiguity across the Project Board, Project Manager, teams, and suppliers — particularly important where a supplier builds to a specification the customer never fully agreed.

Worked example — a Product Description

Consider a project delivering a "Customer Onboarding Pack". A well-formed Product Description for it would contain:

Every quality criterion is measurable: "brand check passed" is binary, "≤12 pages" is numeric, "reviewed by 3 pilot customers" is countable. Vague criteria such as "looks professional" fail the test because they cannot be verified consistently by different reviewers. The quality method (inspection, peer review, pilot) and the quality responsibility are recorded alongside each criterion so that the people building and checking the product share one standard of done.

PBS and PFD — keeping them distinct

Candidates often conflate the two diagrams. The Product Breakdown Structure answers what is produced: it decomposes the project product into sub-products in a hierarchy (like an org chart of products). The Product Flow Diagram answers in what order: it shows dependencies between products (arrows from precursor to dependent product). A complete product-based plan needs both — a PBS without a PFD leaves sequence undefined; a PFD without a PBS is not grounded in a defined product set.

For the onboarding pack above, the PBS would show the pack as the parent of five sub-products (welcome letter, checklist, FAQ, security guide, contact card). The PFD would show the brand template feeding into each sub-product, and the legal-approved FAQ text feeding into the FAQ, before the five are assembled into the final pack. The schedule and stage plan dependencies are then derived from the PFD, not invented in a Gantt chart first.

Quality criteria and tolerance interaction

Quality criteria also carry tolerance. If a quality criterion is "≤12 pages", a tolerance might permit up to 13 pages before the deviation must be reported — a quality exception under Manage by Exception. Linking the two principles is a favourite exam angle: a product that fails a quality criterion within its quality tolerance is accepted; one that forecasts breaching quality tolerance triggers an Exception Report to the level above. This is why Focus on Products and Manage by Exception are interdependent — agreed quality criteria make quality tolerance monitorable, and quality tolerance makes quality exceptions escalate correctly.

Common exam traps

• Activity language as a product. "Conduct training" is an activity, not a product; the product is "Trained staff" or "Training materials". If a scenario describes a plan built around activities with no products listed, Focus on Products is breached.
• Missing Project Product Description. The top-level specification is agreed in Starting Up a Project; a project that reaches Initiation without it has skipped a mandatory product-based planning step.
• Quality criteria agreed after build starts. Agreeing criteria late is the same defect as having none at build time — rework is almost guaranteed.
• No quality method assigned. A criterion without a quality method (who checks it and how) is not testable; the Product Description is incomplete even if the criterion itself is measurable.

Common exam scenarios

Exam questions test whether you can identify a missing Product Description, recognise what a Product Description must contain, or distinguish product focus from activity focus. A scenario where the team starts building before quality criteria are agreed breaches Focus on Products; a scenario where a PBS exists but no PFD has been drawn leaves dependency planning incomplete, even though the product set is defined.