The Content Model That Couldn't Scale
A retailer publishes product content across a website, a mobile app, two marketplaces, and printed in-store signage. Each channel's team maintains its own copy of product descriptions in spreadsheets. When a product's specs change, updates take an average of nine days to reach all channels, and roughly 15% of listings show stale or contradictory specs. A proposal is on the table to build a structured content model with reusable fields (name, specs, description blocks, imagery) and a single source of truth that feeds all channels. Two channel leads object: 'Our channels have different voices and formats; a central model will flatten everything and slow us down.'
1. Evaluate the objection that a central content model will flatten channel-specific voice and slow teams down.
Read the worked answer
The objection conflates structure with presentation. A content model defines the parts of content (fields, types, relationships) and separates them from how each channel renders them. Done well, it does the opposite of flattening: it lets each channel compose and style the same structured parts differently.
The legitimate part of the objection is real: if the model is designed as one rigid description blob, channels lose flexibility, and a slow governance process can bottleneck everyone. The answer is to design the model around reusable, typed components (e.g., short spec, long description, bullet feature list) that channels assemble and style independently, and to set clear ownership so channel teams can compose without waiting on a central gatekeeper. The nine-day lag and 15% stale rate are the cost of the status quo and are strong evidence the current approach is not serving anyone.
2. Describe the key design decisions in the content model and how you would protect channel flexibility.
Read the worked answer
Key decisions:
- Identify the canonical entities (product, variant) and their required vs. optional fields.
- Separate structured facts from prose. Specs are structured data (validated, single-sourced); marketing copy is modular blocks. This is what prevents stale specs, since facts update once.
- Define reusable block types with clear purposes (e.g., 'feature bullet,' 'long description,' 'comparison note') rather than free-form text everywhere.
- Set channel-specific rendering rules outside the model, so each channel maps fields to its own templates and voice guidelines.
Protecting flexibility:
- Let channels choose which blocks to use and how to style them; the model constrains what the content is, not how it looks.
- Give channel leads a role in defining required blocks so the model reflects real needs.
- Define a lightweight change process so adding a block type is fast, not a committee decision.
3. The retailer wants measurable proof the model works. Propose metrics and a validation approach before full rollout.
Read the worked answer
Metrics tied to the actual pain:
- Update propagation time: median days from spec change to all channels reflecting it (target: hours, not days).
- Stale/contradictory rate: % of listings with mismatched specs (target: near zero).
- Reuse rate: % of content blocks used by more than one channel.
- Time-to-publish per channel for a new product.
- Guardrail: channel engagement/conversion held steady (to catch 'flattening' hurting performance).
Validation before full rollout:
- Pilot on one product category across two channels.
- Compare propagation time, stale rate, and time-to-publish against the pre-pilot baseline for that category.
- Check the guardrail metric to confirm channel performance did not degrade.
- Only expand once the pilot shows the lag and stale-rate problems are materially reduced without harming channel output.