Product data specialist: the role, when you need one, and a job description that works

Watch this role done well and the week splits into three recurring blocks. The first is structural: designing well-built attribute sets, which means understanding two things deeply: what each sales channel needs, and what the incoming data actually looks like. That is preparation-heavy work, and it never fully finishes, because channel requirements keep shifting. The second block is running data through the pipeline: new products in, enrichment applied, channels fed, and the structure adjusted where it pinches. The third is fixing errors, and adjusting the structure again so the same error stops recurring.

Notice what is missing from that list: typing product details into a system all day. Data entry happens, but it is the output of the role, not the substance. The substance is that after the data has been through the pipeline a few times, the structure starts to stabilise, and that stabilisation is the moment the rest of the team can be pulled into the work. One person builds the rails; then others can run on them.

Operators are arriving at this role by experience rather than design. It shows up under different titles (product data specialist, catalogue manager, product enrichment specialist), usually after a team has tried distributing data responsibility across channel teams and watched it fail. Belgian product-data consultant Glenn Dhooghe compresses the underlying truth into four words: "PIM is a verb". The work exists whether or not you buy software for it, and someone has to do the verb.

The clean way to draw the role's border is by what each neighbour actually optimises for. The product data specialist is about structure and keeping things tidy. Channel managers are specialists in a channel: how to sell on Amazon or bol or the webshop, which is a selling discipline, not a data discipline. Marketing sells the product. Both of those roles consume product data for commercial reasons; the specialist is the one who makes it consumable. And the border on the technical side is the same one that separates commercial from operational work everywhere in the stack: the specialist owns what the buyer sees, not the integrations, the platform configuration or the stock.

When this split is missing, the symptoms are familiar: every channel manager keeps a private spreadsheet, the same product is described three different ways, and nobody can say which version is right. The deeper team-structure argument is in why organising your ecommerce team by channel makes everyone do the same job twice.

There is no SKU count that answers this, and we would be inventing one if we gave it. Every case differs. The honest test has two parts. First, time: how many hours per week does your team already spend managing product information, spread invisibly across people whose actual job is something else? Add those hours up and the full-time role is often already there, unstaffed. Second, intent: have you decided to serve your customers by improving your product data, rather than passing along whatever the supplier delivered? That decision, treating product data as a competitive edge, is what creates the role. Complexity and volume of work make the case. Volume of SKUs, by itself, does not.

A practical corollary: the first "hire" is often not a new person but a formalisation. Someone on the team is already doing half of this badly-supported work; giving them the mandate, the time and the title is frequently the right first move. If the enrichment side of the role is the part you are scoping, we have a closer look at what a product enrichment specialist does.

The one hiring mistake that undoes everything: bringing someone in to push data through an unstructured catalogue without the mandate to restructure it. Skip the cleanup and the structural work, and you end up, in the words we use internally, moving forward with a rubber band tied to your back. It works for a while. Then you hit a plateau, and the band pulls you right back to the start, with an even bigger mess to handle than the one you postponed. People multiply structure the same way tools do: given good structure, a specialist accelerates everything downstream; given none, and no permission to build it, they just produce inconsistency faster.

So the job description below leads with structure ownership, not throughput. The throughput follows.

A good first specialist does not start by enriching products. They start by studying the data: what exists, where it lives, what shape it is in. Then they map the gaps against what the channels need. Then they build structure version one, and work out the workflows that will run through it. Almost always this is reshaping work rather than blank-page design, because the catalogue already exists and the business is already selling; the structure has to be surfaced from the data that is there and then deliberately reshaped. Expect version one to be wrong in places. That is what the stabilisation passes are for, and it is why the role needs patience from its manager in the first months: the visible output starts after the invisible structure.

Steal this skeleton and adapt it.

Responsibilities:

1. Own the product data structure: design and maintain attribute sets per product type, informed by channel requirements and incoming supplier data.
2. Run the enrichment pipeline: take new products from raw supplier data to channel-ready, and adjust the structure where it fails.
3. Own data quality: find and fix errors, and change the structure so the same error cannot recur.
4. Prepare the catalogue for channel expansion: know what the next channel needs before the business commits to it.
5. Bring the wider team into the workflow once the structure stabilises.

Skills that actually matter:

1. Eye for detail, because the job is spotting the wrong value in row four thousand.
2. Resourcefulness in hunting down product data: from suppliers first, from the wider web when needed.
3. Supplier relations, because the best fix for bad incoming data is upstream.
4. The habit of asking colleagues who know the products better; the specialist owns the data, not all the product knowledge.

KPIs, both deliberately relative:

1. Products listed per week, compared with the rate before the role existed.
2. Time from a known SKU to live (or ready-to-be-live) on the website, tracked as a trend.

On salary: it varies too much by market and seniority for a published number to help; scope the role with the skeleton above and price it against data-adjacent roles in your region.

However you fill the role, the order of operations is the part to protect. One person builds the rails. Then everyone else gets to run.