What content ops tooling covers
Content operations tooling is the technology layer that enables content strategy at scale. The right tools reduce friction between creation, review, publishing, and measurement. The wrong tools create bottlenecks, force workarounds, and accumulate technical debt. The most common mistake is choosing tools first and building strategy around them — rather than defining what your content operations need and then selecting tools that fit.
The content technology landscape has shifted dramatically. Traditional CMSs (WordPress, Drupal) that couple content management with presentation are giving way to headless CMSs (Contentful, Sanity, Strapi) that separate content from delivery. AI-powered writing and editorial tools are changing production workflows. And the boundaries between CMS, DAM, collaboration, and analytics tools are blurring as platforms expand their feature sets. Choosing the right stack requires understanding not just what tools do today but how your content operations will evolve.
CMS evaluation and selection
CMS Evaluation Framework Core Method
Use when: selecting a CMS for a new product, content program, or migration.
CMS selection should be driven by operational requirements, not feature lists. Evaluate across six dimensions. Content model flexibility: Can you define custom content types with the fields and relationships your content strategy requires? Rigid, page-based models limit structured content. Editorial experience: Is the editing interface intuitive for your content team? The most powerful CMS is useless if editors hate using it. Test with actual content creators, not just developers. API and integration: Does it integrate with your existing stack — design tools, analytics, translation management, marketing automation? Headless CMSs excel here; traditional CMSs often struggle. Workflow and permissions: Does it support your editorial workflow — drafts, review, approval, scheduling, publishing? Can you define roles and permissions that match your team structure? Scalability: Can it handle your content volume, traffic, and localization requirements? Test with realistic data, not demo content. Total cost: License/hosting, implementation, customization, training, migration, and ongoing maintenance. The cheapest CMS on paper is often the most expensive in practice.
Headless vs. Traditional vs. Hybrid Decision Matrix Framework
Use when: deciding the right CMS architecture for your content needs.
Traditional CMS (WordPress, Drupal, Sitecore): Content management and presentation are coupled. Best for: marketing sites where the CMS team owns the entire experience, teams without dedicated front-end developers, simple content needs with standard templates. Weakness: difficult to deliver content to mobile apps, IoT, or multiple channels without significant custom development. Headless CMS (Contentful, Sanity, Strapi, Hygraph): Content is managed via API and delivered to any front end. Best for: multi-channel delivery, complex content models, developer-led teams, products that need content in apps, websites, and other surfaces. Weakness: editors can't preview content in context without custom preview builds, and editorial experience requires more engineering investment. Hybrid CMS (modern WordPress with REST API, Storyblok, Builder.io): Traditional editing experience with headless delivery capabilities. Best for: teams that need both editorial ease and multi-channel delivery, migrations from traditional CMS where editors shouldn't lose their workflow.
Content technology stack
Content Tool Stack Audit Technique
Use when: evaluating whether your current tools support your content operations or create bottlenecks.
Map every tool involved in your content lifecycle and identify gaps and overlaps. Creation tools: Where content is written — CMS editor, Google Docs, Notion, specialized editors. Look for: friction between draft creation and CMS entry (copy-paste formatting loss is a red flag), version control, collaboration features. Asset management: Where images, videos, and files live — DAM (Bynder, Brandfolder), cloud storage, CMS media library. Look for: orphaned assets, duplicate uploads, missing metadata, and integration with the CMS. Workflow tools: Where editorial process is managed — project management (Asana, Monday), dedicated editorial tools (GatherContent, Airtable), CMS workflow features. Look for: process steps that happen outside the tool (Slack approvals, email sign-offs) as signs that the workflow tool doesn't fit. Analytics: Where content performance is tracked — web analytics, content analytics, CMS analytics. Look for: gaps between what you need to measure and what your tools can measure. Integration layer: How tools connect — native integrations, Zapier/Make, custom APIs. Every manual step between tools is a point of failure and delay.
Content API Requirements Technique
Use when: defining what your CMS API needs to support for multi-channel content delivery.
If content needs to reach more than one surface (website, app, email, in-product help), API capabilities are critical. Query flexibility: Can you query content by type, tag, relationship, and custom field — not just by ID? GraphQL APIs offer more flexible querying than REST for complex content models. Localization support: Does the API return locale-specific content and fall back gracefully when translations are missing? Preview and draft access: Can the API serve draft and preview content for editorial review without exposing it to production? Webhooks: Does the CMS emit events (content published, content updated, content deleted) that can trigger downstream actions — cache invalidation, search re-indexing, notification? Rate limits and performance: Can the API handle your traffic patterns? CDN caching for public content, reasonable rate limits for editorial tools, and fast response times for user-facing requests.
Content workflow automation
Content Workflow Automation Design Technique
Use when: automating repetitive content operations without losing editorial control.
Automation should handle mechanical tasks and leave creative and judgment tasks to humans. Safe to automate: Content status transitions (draft → in review → scheduled → published), notification when review is needed, scheduled publishing and unpublishing, metadata validation (required fields, character limits, image dimensions), broken link detection, content freshness alerts. Automate with human oversight: AI-generated first drafts, metadata suggestions, tag recommendations, SEO optimization suggestions, translation routing to vendors. Don't automate: Final editorial approval, brand voice decisions, strategic content decisions (create vs. kill), legal/compliance review. Implementation: Start with the automation that saves the most manual time for the least implementation effort. Content status notifications (Slack message when something needs review) typically deliver the highest ROI for the lowest investment.
CMS migration
CMS Migration Planning Template Core Method
Use when: planning a migration from one CMS to another with minimal content loss and disruption.
CMS migrations fail when they're treated as purely technical projects. Content audit first: Don't migrate everything — audit existing content and retire what doesn't need to move. Migrating bad content into a new system is expensive and pointless. Content model mapping: Map old content types and fields to new content types and fields. This is where most migration complexity lives — old and new systems rarely have 1:1 content models. URL strategy: Define how URLs change (or don't). Every changed URL needs a redirect. Broken URLs lose SEO authority and break inbound links. Migration phasing: Don't migrate everything at once. Migrate by content type or section, validate each batch, then proceed. Rollback plan: Keep the old system running in parallel until migration is validated. Define success criteria (zero broken links, content parity check, editorial workflow functional) before decommissioning. Editorial cutover: The moment editors switch to the new system is the riskiest point. Train editors before migration day, provide support during the first week, and have a clear escalation path for issues.
Vendor evaluation
Vendor Selection Scorecard Technique
Use when: comparing CMS or content tool vendors systematically.
Vendor evaluation should be structured, not vibes-based. Build a scorecard with weighted criteria. Must-haves vs. nice-to-haves: Define non-negotiable requirements (e.g., SAML SSO, GDPR compliance, API access) separately from desirable features. Any vendor missing a must-have is eliminated regardless of other strengths. Proof of concept: Don't trust demos. Build a real proof of concept with your actual content model, your actual editorial workflow, and your actual integration requirements. Vendors demo their strengths, not your use cases. Reference checks: Talk to customers of similar size and complexity — not the reference list the vendor provides, but customers you find independently. Ask about implementation difficulty, support quality, and hidden costs. Lock-in assessment: How easy is it to leave? Can you export all content in a standard format? Who owns the content? What happens to custom integrations? Total cost modeling: Include 3-year costs: licensing, implementation, customization, training, ongoing development, support, and integration maintenance.
Templates and checklists
- Content model supports all required content types with custom fields and relationships
- Editorial experience is tested and approved by actual content team members
- Workflow supports your editorial process (draft, review, approve, schedule, publish)
- API supports multi-channel delivery (if needed) with adequate performance
- Localization capabilities match your current and planned market coverage
- Permissions model maps to your team structure and access requirements
- Integration with existing tools (analytics, DAM, translation, marketing automation)
- Security and compliance requirements met (SSO, data residency, access logs)
- Migration path is feasible — content, URLs, redirects, and editorial workflows
- Total 3-year cost is modeled including implementation, customization, and maintenance
Real-world examples
Case study
Spotify: headless CMS for multi-surface content
Spotify uses a headless CMS approach to deliver content across web, mobile apps, smart speakers, and in-car displays. Content is authored once and adapted programmatically for each surface. Playlist descriptions, editorial content, and artist bios are managed in a structured content model that separates the content from its presentation, allowing the same content to render as a full page on web, a card on mobile, or a voice summary on smart speakers. The content API serves all surfaces from a single source of truth.
Why it works: Headless architecture enables multi-surface delivery without duplicating content. Structured content models ensure each surface gets the right content in the right format.
Case study
The Washington Post: Arc XP and custom CMS evolution
The Washington Post built its own CMS (Arc XP) when existing solutions couldn't meet their scale and workflow needs. Rather than forcing their editorial process to fit a tool, they built a tool to fit their process — then commercialized it for other publishers. The lesson for most organizations isn't to build custom (few can justify it) but to evaluate CMS choices based on workflow fit, not feature lists. The Post's editorial workflow — breaking news, planned stories, multimedia integration, multi-edition publishing — drove every architectural decision.
Why it works: Tool decisions were driven by operational requirements, not vendor marketing. Workflow fit was the primary selection criterion.
Common pitfalls
Choosing the CMS before defining the strategy
"We need a CMS" is not a strategy. Before evaluating tools, define: what content types you need, what your editorial workflow looks like, what channels content needs to reach, and what integrations are required. Tools should serve strategy, not replace it.
Headless because it's trendy
Headless CMSs solve a real problem (multi-channel delivery) but create a new one (editorial preview and experience require custom development). If your content serves one website and your team isn't engineering-heavy, a traditional CMS with a good editing experience may be the better choice. Go headless when you need content on multiple surfaces, not because it's fashionable.
Migrating without auditing
Moving all existing content to a new CMS without auditing first means you're spending time and money migrating content that should be retired. Audit before migration, retire what's outdated or redundant, and migrate only content that earns its place in the new system.
Connected topics in your library
Cross-discipline connections
PM.2.06 Product Analytics Infrastructure covers analytics tooling from a product perspective. This topic covers content technology infrastructure — the tools and systems that enable content operations at scale.