Ask why a commerce launch slipped and you will hear about development. Look at the actual critical path and, more often than not, the code was waiting on the data. The catalog import ran clean on the fifty hand-groomed test products and fell over on the real twelve thousand. Half the technical attributes needed for faceting exist only in a PDF the manufacturer sends yearly. Translations are "in progress" in the sense that an intern has the spreadsheet open.

None of this shows up in an engineering estimate, because it is not engineering work. It shows up in the engineering timeline, because the storefront cannot be finished — not styled, not tuned, not tested — against data that does not exist yet.

Why the demo lies

Every platform demo runs on curated data: complete attributes, pretty images, clean categories. Real catalogs have products with three parents, attributes whose meaning changed in 2019 without anyone renaming them, and a "colour" field containing values like blue/darkblue (new). The storefront features that sell the project — faceted search, comparison tables, rich variant switchers — are exactly the features that quietly degrade into empty boxes when the attributes behind them are 60% filled.

That 60% is the number to chase down early. Pick the twenty attributes your storefront design actually depends on, measure fill rates across the real catalog on week one, and put the number in the steering meeting. It reframes the conversation from "when will dev be done" to "when will the data be launchable", which is the true question.

What a PIM actually buys you

Teams reach for a PIM — Akeneo, in most of the projects I see — expecting it to solve data quality. It does not. What it solves is data workflow, which is upstream of quality:

  • One place where enrichment happens, instead of the ERP for logistics fields, a spreadsheet for marketing copy, and the shop's admin for whatever was forgotten. The shop stops being an editing surface, which is the single biggest simplification available.
  • Completeness as a first-class number. Akeneo's completeness model — required attributes per channel and locale — turns "is the catalog ready" from an opinion into a dashboard. Product families below threshold do not export.
  • Translations as a process, with locales that inherit and fall back, instead of column pairs in a spreadsheet named FINAL_v3_reviewed.

What it cannot buy you is the enrichment itself. Somebody still writes the copy, sources the images, and decides whether blue/darkblue (new) is one value or two. A PIM makes that work visible and assignable. It does not make it happen. Budget the people, not just the licence.

The import pipeline is production code

The connector between the PIM and Spryker gets built as a throwaway script surprisingly often, considering it runs every night for the life of the platform. It deserves the same engineering as checkout:

  1. Validate at the boundary, reject loudly. A product with a broken category reference should land in an error report with a reason, not silently vanish from the shop. Silent drops get discovered by the sales team, weeks later, one SKU at a time.
  2. Import deltas, but rehearse the full load. The nightly delta keeps the day-to-day cheap. The full re-import is your disaster recovery and your go-live path, and if it has not run in three months it does not work.
  3. Make throughput a tested number. Spryker's data import and Publish & Sync machinery is batch-friendly, but a naive per-product loop with an event storm behind it will turn twelve thousand products into a nine-hour night. You want to know that in week four, not on cutover weekend.

Sequence the work honestly

The planning mistake is treating data as a workstream that runs "in parallel" with the build, which in practice means nobody looks at it until the storefront needs it. The sequence that works inverts the usual order: model the catalog and stand up the real import in the first weeks, against the ugliest data you have, and let the storefront be built on top of real products from day one.

It feels slower, because the first sprint produces importers instead of pages. It is faster, because the alternative is discovering the catalog's actual shape during the final integration phase — which is the most expensive possible moment — and because every screenshot after week three shows the client their own products, not lorem ipsum in a hoodie.

The launch date is not set by the last feature merged. It is set by the day the data is fit to sell with. Treat that as the deadline and staff it like one.