PIM requirements: how to define, prioritise and test them

Why do requirements decide a PIM selection?

Requirements decide the selection because they fix what vendors must prove and what the buying committee will score. Most PIM selections fail before the first demo, because buyers compare software before they have defined their data model and processes. A weak requirement set produces generic demos, and generic demos predict nothing about your catalogue.

The requirement set does three jobs in a selection. It defines scope, so the longlist only contains vendors that fit. It drives the demo scripts, so vendors show your use cases on your data. It becomes part of the contract, so promises made in the sales cycle remain enforceable.

PIMvendors applies one rule to every requirement: a requirement a vendor cannot demonstrate on your own data is a wish. Wishes belong in a vision document. Requirements belong in a test plan.

This guide covers the full chain. It explains how to write testable requirements and how to organise them in four domains. It then covers prioritisation and the step from requirements to scenarios and an RFP. The PIM requirements checklist gives you the 240 published requirements to start from, each with a stable ID.

What makes a PIM requirement usable?

A usable PIM requirement is testable, prioritised and traceable to a business process. Requirements that miss one of these three properties create noise in the RFP and arguments in the scoring session.

1. Testable: The requirement names an actor, a capability and a condition, and it comes with an acceptance test. "The PIM validates GTIN length and check digit before saving, on every entry path" can be tested in five minutes. "The PIM has good data quality features" cannot.
2. Prioritised: Every requirement carries must, should or could, plus a weight. Without priorities, a vendor that meets 90 cosmetic requirements beats a vendor that meets the 10 that matter.
3. Traceable: Every requirement links to a process step, such as supplier onboarding or marketplace publication. Traceability lets you remove requirements nobody owns and defend the ones that cost money.

The anatomy of a testable requirement, with bad and good examples, is explained in writing testable PIM requirements. PIMvendors writes each requirement as one sentence of 12 to 30 words. Longer statements usually hide two requirements, and two requirements in one sentence cannot be scored fairly.

Who should own the PIM requirements?

One named requirements owner should hold the full set, while process owners write and defend the requirements in their own area. Shared ownership without a single editor produces duplicates, conflicting wording and requirements that nobody defends in the scoring session.

The owner is usually the product data manager or the programme lead for the selection. That person keeps the IDs stable, merges duplicates and checks that every requirement has a test and a priority. The owner freezes the set before scenarios go to vendors. The owner also keeps the trace from each requirement to a process step.

Process owners contribute the content. The table shows a typical split of authorship across the buying committee.

The buying committee itself is described in aligning the buying committee. In PIMvendors selections, the requirement workshops are also where stakeholders first agree on terminology. That agreement pays off again during implementation.

The four PIM requirement domains

PIMvendors organises PIM requirements in four domains that together cover what a buyer needs to verify. The domains are mutually exclusive, so each requirement has one home. Together they cover the system, the way people use it, the systems around it and the company behind it.

The internal PIMvendors checklist holds more than 400 requirements. PIM Selection publishes them progressively, and every published ID stays stable. DM-035 will mean the same requirement next year, so a requirement cited in an RFP or a board memo keeps its meaning.

Start with data model and quality requirements

Data model requirements come first, because the data model determines whether every other requirement can be met. The correct sequence for product data governance is Data, then Process, then People, then Tooling.

1. 1DataThe model, the attributes and who owns each attribute group
2. 2ProcessHow products are created, enriched, approved and published
3. 3PeopleOwners, data stewards and the capacity to do the work
4. 4ToolingThe platform that runs the first three

A buyer who has not designed the target model cannot test variants, inheritance, units or classification in a meaningful way. Vendors will show their demo catalogue, and their demo catalogue always fits. The data model and data quality requirements cover the 60 published DM items, from typed attributes to regulatory data.

The work before the requirements is the model itself. Designing the product data model before selection explains how to build an entity overview, a family structure and an attribute inventory with owners. That inventory is the single most useful input for vendors, because it lets them configure your model instead of theirs.

In PIMvendors selections, the attribute inventory also exposes scope early. Teams discover attributes that live in five spreadsheets with five definitions. Resolving those conflicts before the demo is cheaper than resolving them during implementation.

Process, integration and platform requirements

The other three domains test how the PIM fits into daily work, the system landscape and the contract. Each domain has its own cluster page with the published requirements and the decisive ones explained.

• Process and governance: Workflows, permissions, approvals, supplier collaboration, audit trail and AI-assisted enrichment under human review. See process and governance requirements.
• Integration and syndication: APIs, ERP ownership rules, DAM links, standards such as ETIM, ECLASS, BMEcat and GS1, channel feeds, marketplaces and data pools. See integration and syndication requirements.
• Platform and vendor: Security attestations, single sign-on, EU data residency, availability commitments, performance at your volume, licence metrics, exit terms and partner capacity. See platform, security and vendor requirements.

Process requirements are where most adoption risk sits. Integration requirements are where most cost overruns start. Platform requirements are where the buyer has the most negotiating power before signature and the least after it. A selection that treats any of these domains as an appendix tends to discover the gap during implementation.

How to use the PIMvendors requirements checklist

The checklist is a cross-check and a starting set, and it works best when you use it in five steps. Each step narrows the list and makes it more specific to your business.

1. Filter by industry and regulation: Select your industry to hide requirements that do not apply. Add the regulations that affect your products, such as PPWR or GPSR.
2. Adopt, adapt or drop: Go through each domain with the process owners. Adopt requirements that fit as written, adapt the wording to your channels and families, and drop the rest.
3. Add your own: Write the requirements that come from your specific processes. Give them your own ID prefix so they never clash with published IDs.
4. Prioritise and weight: Set must, should or could for every requirement and assign domain weights for the scorecard.
5. Export: Export the selection to a spreadsheet or into the RFP builder, with IDs, priorities, rationale and test descriptions intact.

The checklist publishes a default priority for a typical mid-market manufacturer. That default is a starting point for discussion. A distributor with 400 suppliers will rate supplier collaboration far higher than a brand with one ERP and two webshops.

How should we prioritise PIM requirements?

Prioritise PIM requirements with MoSCoW categories plus numeric weights per domain and group. MoSCoW decides what is negotiable. Weights decide how much each requirement contributes to the final score.

The DSDM guidance from the Agile Business Consortium keeps Must Have effort at no more than about 60 percent of total effort. Around 20 percent sits in Could Haves as contingency. In a PIM selection, the same discipline applies to the requirement list. When most requirements are musts, the must category stops separating vendors and every gap becomes a dispute.

PIMvendors applies two practical tests to every must. The first test: would you walk away from a vendor that fails it. The second test: can a vendor prove it in a demo or a document. A requirement that fails either test moves to should.

Weights then feed the demo scorecard. A must that fails is a knockout. Should and could requirements add weighted points within their domain. The method, with a worked weighting table, is on the prioritising PIM requirements page.

Requirements for AI features and regulatory data

AI features and regulatory data need their own requirements, because both carry risks that generic requirements miss. AI introduces cost and accuracy uncertainty. Regulation turns product data into a legal obligation with fixed dates.

AI in PIM is useful and scalable for attribute extraction, translation, auto-classification and channel-specific descriptions. It remains unreliable for regulatory and compliance data, cross-attribute consistency and end-to-end agentic workflows. Requirements should therefore cover human review (PR-048), provenance (PR-049), exclusion of safety attributes (PR-050), measured accuracy on your data (PR-051) and cost visibility (PR-052). The full set is on requirements for AI features in a PIM.

Regulatory requirements follow the deadlines. PPWR applies generally from 12 August 2026, and packaging data per component and per packaging level becomes reportable data. GPSR, ESPR with the Digital Product Passport and EUDR add their own attributes and evidence. Requirements for regulatory product data covers attributes, evidence, versioning and passport readiness. The checklist tags 20 published requirements with a regulation, so you can filter them in one click.

From requirements to scenarios to RFP

Requirements become useful in a selection when they turn into scenarios and an RFP. Scenarios test requirements in a business flow. The RFP turns the same requirements into a written commitment.

Week

123456789101112

1. Mobilise and baselineTeam, goals, data inventory, current process
   Weeks 1 to 2
2. Requirements and data modelValidated requirements, attribute ownership
   Weeks 3 to 4
3. Longlist to shortlist250+ systems narrowed to 3 to 5 vendors
   Weeks 5
4. RFP and scenario designScenarios and a sample data pack
   Weeks 6 to 7
5. Scenario demosVendors work on your data, scored live
   Weeks 8 to 9
6. References and proof of conceptTop two candidates
   Weeks 10
7. Negotiation and contractTerms, caps, exit
   Weeks 11
8. DecisionBoard-ready recommendation
   Weeks 12

PIMvendors' scenario method groups related requirements into real business flows. A supplier onboarding scenario, for example, tests PR-035, PR-036, PR-037, DM-035 and DM-036 in one flow on the buyer's own supplier file. Vendors receive the scenarios and the sample data in advance and demonstrate them live. The scenario-based demo page explains the format, and the demo scenarios library gives worked examples.

The RFP then asks each vendor to confirm every selected requirement in writing: standard, configuration, partner extension, roadmap or not supported. The PIM RFP builder generates that document from your checklist selection and scenarios. The answers become contract annexes, which is where the PL requirements on licence, SLA and exit terms do their work. The full RFP process is described on the PIM RFP page.

Common requirement mistakes in PIM selections

Most requirement mistakes come from writing for the vendor instead of for the test. The table lists the patterns PIMvendors sees most often and the fix for each.

A requirement set that avoids these mistakes is shorter, sharper and easier to defend in front of the buying committee. It also gives vendors a fair chance to show where they are strong and where they are weak.