The Taxonomy Truth Nobody Wants to Hear (But Everyone Needs To)

Taxonomy. There’s probably no faster way to clear a conference room than mentioning it. Yet when a website migration gets bogged down or marketing operations grind to a halt, taxonomy is usually the culprit everyone ignored during planning.

Here’s what most organizations get wrong: they treat taxonomy as a single deliverable owned by a single team. It’s not. Taxonomy is a shared responsibility that must balance customer experience, operational efficiency, and system requirements. The disconnect between these perspectives is costing you time, money, and operational efficiency.

The Two Faces of Taxonomy

Customer-Facing Taxonomy: This is the domain of your UX and product teams. Your site structure, navigation, product categorization, how search crawlers understand your content, how AI tools surface your information through chatbots. This taxonomy is dictated by customer needs, search optimization, and business strategy. As someone who runs marketing operations, I’ll be honest: I don’t have much say here, nor should I. Your search team’s recommendations should drive these decisions. Your product strategy determines how offerings are presented.

If you sell shirts, pants, SUVs, and trucks, your customer-facing structure will organize around those categories. That’s non-negotiable.

Operations Taxonomy: This is where most organizations fall apart. While everyone obsesses over the customer-facing structure, they ignore the taxonomy that makes content operations actually function.

When I’m building taxonomy for marketing operations, I’m thinking about asset types, not product categories. Is it a marketing description or promotional content? A legal disclaimer? A product photo or promotional image? A how-to video or background visual texture for a banner?

Why? Because the requests your marketing operations team receives are organized by asset type, not product category. Nobody emails you saying “update all widget content.” They email you saying “update expiration dates on all promotional disclaimers” or “refresh all product photography.”

Scenario: Legal sends an update. All promotional disclaimers need new expiration dates.
Before — product-organized
Product 1
Disclaimer 1find this
Offer 1
Offer 2
Product 2
Disclaimer 2find this
Offer 1
Offer 2
Product 3
Disclaimer 3find this
Offer 1
Steps to update disclaimers
1Navigate into Product 1
2Hunt for the disclaimer
3Update individually
4Repeat for every product
Hours
After — operation-organized
Disclaimers
Product disclaimers
Promotional disclaimersbulk select all
Offers
Disclaimer 1
Disclaimer 2
Products
Product 1
Product 2
Services
Service 1
Steps to update disclaimers
1Navigate to Promotional disclaimers
2Select all, bulk update
Minutes

A Real Example of What This Looks Like

During a recent CMS replatforming project, we had the opportunity to implement atomic content management with taxonomy designed for both customer experience and operational efficiency.

The operations team frequently received requests to update expiration dates on promotional disclaimers. In the old system, finding all promotional disclaimers meant navigating through product-based folder structures, hunting through pages, checking each one individually. This took hours.

We reorganized disclaimers by type: product disclaimers versus promotional disclaimers. Now when legal sends an update, the team navigates directly to promotional disclaimers, selects all, bulk updates. What took hours now takes minutes.

How requests actually arrive
📧
"Update expiration dates on all promotional disclaimers"
asset type: disclaimer
📧
"Refresh all product photography for Q2"
asset type: image
📧
"Pull all how-to videos for the app refresh"
asset type: video
📧
"Update all marketing descriptions for new brand voice"
asset type: copy
How nobody ever phrases it
🚫
"Update all widget content"
organized by product
🚫
"Refresh everything under Product 3"
organized by product
🚫
"Update the SUV category assets"
organized by product
🚫
"Pull everything in folder: Trucks"
organized by product
The gap: Operational requests are organized by asset type. Most CMS structures are organized by product or category. Every request becomes a search party across unrelated folders.

We also separated product content from service content. The client sold both physical products and subscription services. In the old system, everything lived together. But products required extensive content (features, specifications, photo galleries, videos, support documentation) while services needed minimal content (one description, a few disclaimers).

Making these share the same folder structure and content templates created unnecessary complexity. Launching a new service required clicking through a dozen fields designed for products. Updating products meant wading through service content that rarely changed.

By separating these with distinct taxonomies and structures optimized for their actual use patterns, we reduced content management time by 10–50% per task. Multiply that across dozens of products and services, hundreds of updates per year, and you’re saving hundreds of operational hours annually.

The Hidden Benefits

Here’s what most people miss: when you optimize taxonomy for operations, you often improve everything else too.

By grouping all product content together with consistent structures, you make it trivial to:

• Expose content through APIs for mobile apps, in-store kiosks, or chatbots

• Automate content assembly for personalization

• Enable search bots to understand and index content more effectively

• Migrate content between systems without manual rework

Those other systems can rely on one consistent format for each content type. Your chatbot doesn’t have to handle seventeen different ways you’ve structured product information. Your mobile app doesn’t need custom logic for every edge case.

Operational taxonomy done right creates compound benefits across your entire ecosystem.

Whose Job Is This Anyway?

I’m frequently asked: whose responsibility is taxonomy? The strategist? UX team? Systems team?

The answer is yes.

Each team has legitimate concerns that must be considered:

• UX teams need structures that serve customers

• Systems teams need structures that work technically across platforms

• Operations teams need structures that enable efficient daily work

UX / Product
Customer-first
Navigation, search optimization, how your audience finds and understands your content
Systems / IT
Platform-first
API compatibility, migration paths, consistent data structures across platforms
Marketing Ops
Workflow-first
Bulk operations, daily update patterns, how requests actually arrive from the business
Taxonomy that works for all three
Structured by asset type Consistent across platforms Enables bulk operations Discoverable to customers Governed for scale
What fails:
Any one team defining taxonomy in isolation. UX builds for customers but breaks operations. IT builds for systems but ignores workflow. Ops builds for daily work but creates navigation chaos. The only path is all three at the table from day one.

While marketing operations or systems teams are often fundamentally accountable for defining taxonomy, they’re collectively failing if they don’t hold all these needs in tension and find a reasonable balancing point.

This isn’t a sequential process where one team hands off to another. It’s a collaborative design challenge that requires all perspectives at the table from day one.

The Real Problem

Taxonomy shows up on project plans as a single line item, usually right next to metadata. Everyone looks around the room hoping someone else volunteers. UX teams build for customers. IT teams build for systems. Nobody builds for the operations teams who have to use these structures daily.

The result? Taxonomy that looks great to customers but makes internal operations nearly impossible. Or taxonomy that works for one system but breaks when you migrate to another. Or taxonomy that made sense to whoever built it three years ago but is now maintained through institutional knowledge and prayer.

What Actually Works

Stop treating taxonomy as a single deliverable. Start treating it as a strategic design challenge:

Involve All Stakeholders Early: Don’t let UX finish before operations sees it. Don’t let systems define structures without understanding operational workflows.

Design for Actual Work Patterns: Map the types of requests your operations team receives. What do they need to update together? What do they need to find quickly? What takes them too long today?

Build for Scale: Your taxonomy should make bulk operations easy, not force manual one-by-one updates. If changing one thing requires touching fifty pieces of content individually, your taxonomy failed.

Test with Real Users: Put your operations team in the new structure before you migrate everything. Watch them work. Time them. Fix what’s broken while it’s still easy to fix.

Plan for Evolution: Your business will change. Your products will change. Your taxonomy needs governance and a path for evolution that doesn’t require starting over.

The Bottom Line

Your CMO cares about customer experience. Your CTO cares about system performance and data integrity. Your marketing operations team is stuck in the middle trying to make both work with taxonomy that serves neither.

The organizations that get this right treat taxonomy development as a strategic initiative with executive sponsorship, not a project task to be delegated away. They staff it appropriately. They fund it adequately. They recognize that poor taxonomy creates compound interest on technical debt.

If you’re planning a website redesign, platform migration, or DAM implementation and taxonomy is just a bullet point on page seven of the project plan, you’re setting yourself up for failure.

Give it the attention, resources, and cross-functional collaboration it deserves. Your customer experience team can’t build effective operations taxonomy. Your operations team can’t dictate customer experience. Your systems team can’t ignore either.

But together, with clear ownership and shared accountability, you can build taxonomy that actually works for everyone.

That’s not sexy. It’s not exciting. But it’s the difference between marketing operations that scale and marketing operations that collapse under their own weight.

← All posts