PRINCE2 Project Developing New Products
July 2023

Do You Have a Project Developing New Products?

For organisations that develop commercial products — software products, manufactured goods, regulated products — the PRINCE2 quality planning approach sometimes raises a question: how does the Project Product Description relate to the organisation's existing product definition documents, such as a Functional Requirements Specification or a Design Brief?

The Project Product Description (PPD) Is High-Level

The Project Product Description is not a Functional Requirements Specification, a Design Brief, or a Technical Specification. It operates at the project governance level — defining, in summary terms, what the project will create and how it will be accepted by the customer.

The PPD answers three questions at a high level:

  1. What will the project produce? (the overall output, described in plain terms)
  2. What quality characteristics must it have? (the quality expectations)
  3. How will we know it is acceptable? (the acceptance criteria)

These are governance-level questions. The PPD is created during Starting Up and approved as part of the Project Brief — before the project's detailed requirements are worked out. It establishes the "contract" between the commissioning organisation and the project team at a level the Project Board can understand and agree.

Detailed Product Definitions Come Later

The detailed requirements, design specifications, and functional definitions are specialist products in their own right — created during the project's delivery stages, not during initiation. They will have their own Product Descriptions, quality criteria, and review processes.

In a regulated product development context, for example, a Design Input document (as required by ISO 13485 or FDA 21 CFR Part 820) would be a specialist product produced by the project — it would have its own Product Description defining its required content and quality criteria.

The Hierarchy

Think of it as a hierarchy: the PPD sits at the top and defines overall acceptance; below it, individual Product Descriptions define each component's quality requirements; below those, the organisation's domain-specific documentation (requirements specs, design documents, test reports) provides the technical detail. PRINCE2 provides the governance layer — the domain methodology provides the technical layer.

See Does Design Input Replace Product Description? for how PRINCE2 quality planning works in regulated product development environments.