Start with the product's reason to prepare.
A Digital Product Passport is an electronic product record, accessed through a data carrier such as a QR code. The EU's Ecodesign for Sustainable Products Regulation provides a framework for introducing passports across product groups. Product-specific legislation determines the required information and compliance date. The Commission's working plan identifies groups for assessment; inclusion alone creates no passport obligation. European Commission FAQ.
For a UK manufacturer with several EU-facing lines, preparation may therefore have different purposes. One family may have an applicable legal requirement. Another may face a dated customer request. A third may appear only in the working plan. Record which signal applies before allocating the same effort to all three.
Where a firm product-specific obligation exists, its scope and deadline belong in the compliance programme. The selection method below is for a bounded readiness pilot where the company has discretion over where to learn first. A customer request can justify preparation, but should be described as a contractual or commercial requirement.
The useful output is a tested route from a product fact to its supporting record: who supplies it, who checks it, where it is stored and how a change reaches the people using it. Those dependencies can be examined while the final passport field list is still developing.
Follow the records across the range.
A product can have a complete-looking data sheet while its material evidence remains with suppliers, its version history sits in engineering and its customer declarations sit in sales. A pilot that checks only the finished document can miss the work needed to keep the record current.
The Commission describes a system in which detailed product information is held by businesses or their service providers. The central registry links identifiers to that information. That architecture leaves the business with an ongoing evidence task. Commission explanation of the registry.
Choose a product family that exercises dependencies shared by other families. Count the families that use the same relevant supplier records, material evidence, source systems or change-control process. Name those dependencies so the transfer claim can be checked. Similar appearance or a shared catalogue category provides little evidence that the pilot's lessons will transfer.
Also identify an unresolved evidence dependency worth testing. If every record is already complete and easily maintained, the exercise may teach little. If the necessary supplier will not participate, it may consume the whole timebox without answering the company's question. The pilot needs a problem it can investigate within the agreed effort.
Set the selection rules before comparing products.
The product-data owner and commercial lead should first agree the comparison period, a minimum EU exposure and a minimum number of other families that could use the lessons. Calculate each candidate's EU revenue as a share of total company revenue over the same period. Count other beneficiary families using the same definition for every candidate.
Set a maximum effort in staff-days and identify the staff and supplier participation needed to stay within it. These are company planning choices. The figures in the example below have no regulatory status.
Apply the following sequence:
- Retain candidates with a documented legal-development signal or a dated customer requirement, and an unresolved evidence dependency to investigate.
- Exclude candidates below either the agreed EU-exposure floor or the learning-transfer floor.
- Exclude candidates whose estimated effort exceeds the timebox or whose required participants have not confirmed availability.
- Among the remaining candidates, select the one benefiting the greatest number of other product families. Break a tie by higher EU exposure, then lower effort. If every value remains tied, the product-data owner records a selection and reason before work begins.
A company with no passing candidate should record the failed condition and review it when the relevant source, demand or availability changes. It should commit no pilot effort under this selection. Any binding compliance work continues through its own deadline and owner.
A pilot choice with a real trade-off.
The following illustration uses invented company figures. The company has set an EU-exposure floor of 15% of total annual revenue, a transfer floor of three other families and a ten-staff-day timebox. Each family has a dated customer data request, a supplier-evidence gap and confirmed participants.
| Candidate family | EU revenue share | Other families using the tested dependencies | Estimated staff-days | Result |
|---|---|---|---|---|
| A | 26% | 4 | 6 | Passes, retained as an alternative. |
| B | 18% | 7 | 9 | Selected, greatest learning transfer. |
| C | 31% | 2 | 8 | Below the transfer floor. |
Family B takes more effort than A and has less EU revenue exposure than C. Its supplier and change-control work reaches seven other families, which is the company's stated priority once exposure and feasibility clear their floors. Reordering the rows produces the same selection.
If B's supplier becomes unavailable, B fails the participation condition and A becomes the selected candidate. If B's estimate rises above ten staff-days, the owner must reduce and confirm the scope or rerun selection. A promising transfer claim cannot override the agreed resource limit.
Record the choice and the test you will run.
Use one selection record per comparison. Keep the candidate inputs beside the result so another colleague can reproduce it.
| Record field | What to enter |
|---|---|
| Comparison basis | Revenue period, EU-exposure floor, transfer floor and staff-day limit agreed before comparison. |
| Candidate evidence | Product family, dated preparation signal, unresolved dependency, EU share, named beneficiary families, effort estimate and participant confirmations. |
| Selection trace | Failed conditions, passing candidates, ranking values and any recorded final tie decision. |
| Accountable owner | Product-data owner, with the commercial lead confirming exposure and engineering or procurement confirming the dependency. |
| Pilot result to produce | A retrievable evidence trail for the chosen dependency, its update test and the families to which the tested process can transfer. |
| Review and stop | Review at the timebox end and when a selection input changes. Stop expansion if participation fails, effort exceeds the limit or the claimed shared dependency proves absent. |
For the illustration, enter B as selected, nine staff-days as the estimate within the approved ten-day limit, and the seven named beneficiary families as the transfer test. The product-data owner starts by tracing the chosen supplier record into the current product version, then tests how an updated record would reach the other families.
Keep any unverified transfer claim open at the review. Expand the process only to families for which the pilot has established the shared dependency and a workable update route.
AI disclosure: This article was generated with the assistance of AI systems and checked against cited public sources.


