It isn’t because they don’t care that most product teams avoid structure work. They keep it at arm’s length because they’ve seen what happens when you “fix” the taxonomy:
- Filters collapse
- Reporting lines break
- Feeds to marketplaces mis-map and get rejected
- Teams lose trust in the system, and stealthily revert to ‘good old spreadsheets’
And so it goes. The catalogue stays as it is: irregular category trees, ad hoc attribute sets, and a growing sense that any attempt to change it will just make things worse.
That’s the real problem behind stalled PIM projects and seemingly never-ending data clean-ups: Why? Because fear of redesign blocks progress.
The route through this challenging environment isn’t to strive for an absolutely perfect structure. What you want is a structure designed to allow for low-risk evolution.
Counterintuitively, “perfect structure” is a trap
A “perfect” product structure assumes you can define the world up front:
- every category you’ll ever need
- every attribute that will matter, forever
- every channel requirement
- every supplier format
- every future initiative (AI, sustainability, new marketplaces, new regions and so on)
“Perfection” is not a feasible goal. Even if you somehow got it right today, a structure degrades as the business changes. Think of common variables:
- New assortments arrive
- New compliance fields become mandatory
- Channel templates shift
- Teams reorganise
- Suppliers change their files
The PIM industry analysts, Gartner, highlight hierarchy management and data modelling as core capabilities, alongside governance features like versioning and auditability. This is because structure isn’t a one-off design task. It’s an operational reality.
So, the real goal becomes a structure which can adapt and pivot to new circumstances without it becoming a high-risk event.
What “structure for change” actually means
A change-ready product structure should possess three characteristics:
1) It separates what is stable from what is variable
Some things should be durable:
- the concept of a product family vs SKU
- the rules for variant modelling
- core identifiers and naming conventions
- what “completeness” means for each category
Other things will always be a moving feast:
- categories and subcategories
- channel-specific attribute requirements
- claims, sustainability fields, regulatory details
- seasonal and regional differences
A structure that’s built for change makes this explicit and doesn’t pretend everything is equally permanent.
2) It can evolve safely
In practical terms, that means you can:
- introduce new categories without reclassifying the entire catalogue
- add attributes without forcing every product through a rebuild
- deprecate fields without losing history or breaking downstream mappings
- migrate structure in phases (with parallel running where needed)
Gartner explicitly flags the key roles of hierarchy versioning and audit trails as part of effective hierarchy management. Businesses that want to be viable need recovery, traceability, and controlled changes, not just a neat-looking tree diagram.
3) It is owned and governed
If a structure is “owned by the IT system”, it’s not going to evolve securely. Product structure changes are directly influenced by business decisions that impact on operational effectiveness. Things like:
- Search
- Navigation
- Syndication
- Reporting
- Compliance
- Team workflows
This is why a PIM system is positioned as a foundation for consistent product information across channels, and why it’s often paired with wider elements of the operating model (for instance, ownership, workflow, onboarding, and stewardship).
Fear of redesign is rational (and also fixable)
When structure work goes pear-shaped, it’s usually because teams take the ‘big bang’ route to change:
- a full taxonomy rewrite
- a full schema rebuild
- mass reclassification
- new naming conventions everywhere
- immediate enforcement, no transition
It’s an approach with a high risk of creating systemic fragility and internal political resistance. People push back against wholesale, instant change when they think they’re protecting the business from disruption.
A more mindful approach, with change preparedness built into the equation , assumes the opposite:
- the first version will be incomplete
- you will learn by running it
- you will iterate safely and prudently
- governance is developed as a set of underlying principles, not tacked on as an afterthought
This aligns with how “high-quality” product data should be framed more broadly: USABILITY, not perfection: a philosophy which is baked into your broader SEO strategy.
The design principles behind an evolvable taxonomy and schema
Principle 1: Model relationships, not just lists
A taxonomy isn’t only “where products live”. It’s a control surface:
- it drives inheritance (what applies to a whole branch)
- it governs attribute applicability
- it shapes navigation and filters
- it defines reporting rollups
One useful pattern is taxonomy-driven inheritance: Shared attributes cascade logically down the hierarchy, and changes can be made at the right level. That approach is referenced in delivery work where inheritance models were designed to support complex catalogues and precise compatibility rules.
Principle 2: Treat attributes like contracts
If you’re addressing change, define “data contracts”:
- what the attribute means (definition)
- allowed values / units
- which categories it applies to
- how it maps to channels
- who owns it, and what quality looks like
Without contracts, attributes become a free-for-all: duplicated fields, inconsistent naming, wrong units, and unpredictable completeness. ( a “messy” data problem doesn’t cover the half of it; fundamentally, you have an unstandardised model and weak enforcement.)
Principle 3: Design for multiple endpoints from day one
A structure that only works for your website will break as soon as you syndicate.Modern PIM use cases include multichannel publishing and contextualisation. You’re creating multiple formats of product information optimised (and compliant) for channel, market, and segment, but without duplicating products. All this only works if the underlying structure is designed precisely for these variations.
Principle 4: Make change a workflow, not a workshop
Workshops create diagrams. Workflows create reality.
If structure changes are not routable (that is, submitted, reviewed, approved, versioned, and measured), then the only way to change structure is the ‘high-drama’ project and the ensuing fears it provokes.That’s why workflow, hierarchy management, and data stewardship must sit in the “mandatory/core” capability set for PIM-class solutions.
Principle 5: Prefer additive change over destructive change
Add new structure alongside old structure wherever possible, then migrate.
Examples:
- introduce a new category branch and progressively reclassify only the ranges that need it
- add a new attribute and backfill for priority products first
- keep old attributes as ‘deprecated’ until downstream mappings are updated
This reduces risk because it avoids forcing everything to move at once.
What ‘safe evolution’ looks like in real organisations
You don’t need to start from scratch to reduce the risks attached to redesign. Many teams create momentum by auditing what exists, then introducing incremental change patterns.
- A PIM health check will reveal where taxonomy, attributes, governance, and integrations are holding the business back. Then it produces a prioritised improvement plan rather than working off a redesign fantasy created using hopes and intuition.
- Group-level data model work can define shared vs banner-specific structure so multiple business units can flex without fragmenting the core model.
- You can focus on re-implementations which redesign the data model and attribute framework so that they better match the needs of business partners
The above are all examples of a similar mindset: Structure is a controlled, ongoing discipline.
A practical checklist: “Are we designing for change?”
If you want a quick test, ask yourselves the following questions about your product structure:
- Can we add a new category without reworking half the catalogue?
- Do we know which attributes are global vs category-specific vs channel-specific?
- Do attributes have definitions, allowed values, and owners?
- Do we have a versioning approach for hierarchy and schema changes?
- Can we run old and new structures in parallel during a migration?
- Do downstream mappings (feeds, marketplaces, analytics) tolerate change, or are they brittle?
- Is change routable through workflow and governance, or does it require a project?
If you’ve got more “no”s than “yes”-es, the problem isn’t an ‘imperfect’ structure – it’s a structure which isn’t safe to evolve.
The payoff: progress without rewrite panic
When structure is designed for mindfully-managed change, teams stop treating taxonomy and schema as a one-time bet (fingers crossed!)
Instead, they can, with confidence:
- improve filters and navigation iteratively
- onboard new suppliers without undermining standards
- add sustainability/compliance fields without chaos
- prepare product data for PIM, marketplaces, and AI without brittle foundations
Most importantly, they regain the ability to move. Because, to labour a point well worth labouring, the goal isn’t perfection.
It’s progress you can trust.
Auditing your structure
If redesign fear has stalled your product data work, start with a structure audit.
A good audit doesn’t just “grade” your taxonomy. It shows, concretely:
- where structure is brittle
- where attributes are non-conforming or duplicated
- where governance is missing
- what safe evolution steps look like (in priority order)
Key Takeaway
Don’t build for the catalogue you have; build for the catalogue you might have in three years. A “perfect” structure is a finished one, and in e-commerce, finished is another word for obsolete. If structure change feels risky, don’t attempt a wholesale redesign. Get in touch with us today at Start with Data to discuss a product data management structure audit. We can review your taxonomy, schema, governance and downstream mappings to show exactly where change will break filters, feeds or reporting, and where it won’t. You’ll then get a prioritised set of fixes and safe migration steps, so the structure can evolve without turning into a high-stakes project.