Digital-first companies thrive on mobile disruption. Everyone else struggles.

Organizations can’t succeed in our new multi-platform, mobile world unless they transform themselves into digital-first businesses.

Everyone’s talking about the mobile challenge: platform fragmentation, new customer expectations, increased competition, and an increasing rate of change. New techniques like responsive design can help, but—as Sara Wachter-Boettcher and others have pointed out—only if we acknowledge that mobile is a content problem as much as a design or development problem. As Karen McGrane puts it:

“…the problems we have with mobile and the problems we have with content management systems (CMS) are the same problem. … If we’re going to succeed in publishing content onto a million different new devices and formats and platforms, we need interfaces that will help guide content creators on how to write and structure their content for reuse. When we talk about mobile, we often focus on the front end interactions, design, and code, but what I realized this year [2011] is that the solution to many problems with mobile lives way further down the stack, in the CMS.”

A fancier CMS won’t give you mobile-ready content

“Aha,” I hear you say, “I get it! We need a fancier CMS that supports semantic authoring and multi-channel publishing. The type of system technical writers have been talking about for years.”

A CMS "owns" content, usually at the page level

I have bad news: a fancier CMS won’t help you withstand mobile disruption. Sure, we need new tools, and we certainly need systems that understand semantics and taxonomy. But the the type of “Intelligent Content” pioneered by Ann Rockley and others—centered on multi-channel publishing systems that use XML technologies designed for technical documentation—are focused towards legacy publishing processes (printed manuals and electronic help), and treat the web and mobile as just another channel:

“If you plan to create an enterprise unified content strategy… a web content management system is probably not the best solution for you. Treat the Web as a channel and manage your content elsewhere.”

—Ann Rockley and Charles Cooper, Managing Enterprise Content: A Unified Content Strategy, 2nd Edition. My emphasis.

Today, web and mobile platforms aren’t just another channel, they’re the primary channel—and they actually increase the complexity of managing content, to a level that systems designed for legacy channels (e.g., print) can’t handle. (Of course, today’s web content management systems can’t handle this complexity, either—more on that later.) Rockley’s enterprise content strategy will help a legacy business become more efficient at managing technical content, but it won’t help that business withstand the mobile revolution.

When we talk about moving from platform-specific content and functionality—content stuck in a desktop web silo—to a central content API that supports multi-platform digital interactions, we’re not talking about a fancy new CMS. Instead, we need to stop treating digital as a bolt-on, and start to transform into a digital-first business.

Businesses treat digital as a bolt-on

Today, our organizations are structured like industrial-era factories. Digital capabilities like websites, web applications, mobile apps, and social media are bolt-ons to the real business—they operate in silos embedded in the hierarchy, we manage them using meaningless metrics, and we often outsource the skilled labor to external agencies and the software systems to IT vendors. The organization is saying, “we don’t do digital—we have people to do that for us.” In a sense that’s fair enough—the organization’s been around for longer than the web, so why should we suddenly need to develop new capabilities? It’s not in our mission statement!

Businesses treat digital as a bolt-on

Here’s the problem. Asking an external agency—or a web silo deep inside the organization—to manage your digital presence is like paying someone to take a vacation for you. Things seem to happen, but you don’t benefit.

I’m not arguing that using agencies is always a bad idea, or that buying software from vendors is stupid. But if you want to survive this revolution, you need to take responsibility at an organizational level for the digital manifestation of your company (your websites, apps, social media presence, etc.), and your core business systems, which includes managing your content. Most organizations use vendors as a way of avoiding responsibility for areas of expertise they don’t understand, and to dodge the organizational change (and resulting turf battles) associated with becoming a digital-first business. In other words, executives are taking huge risks with the future of their organizations.

Structured content is core to your business

Today, structured content is core to your business: you can’t manage it in a CMS you bought from a vendor. Yet that’s the way we manage websites, because organizations don’t see the link between their digital content and their core business.

Businesses treat content as single-channel brochureware:

  • Written and edited separately for specific channels, e.g. desktop website, call centre, printed brochure.
  • Maintained in a channel-specific CMS (or InDesign files, call centre systems.)
  • Unrelated to web or mobile apps.

If we want to tackle mobile, we can’t replace our siloed CMS with a new product that supports multi-channel publishing, because we’re talking about a core business system, not a generic IT requirement. Our new system needs to integrate with whatever our core business is, incorporating:

  • Detailed, accurate, relevant product content appropriate to the customer’s context.
  • Access to customer databases with appropriate privacy controls.
  • Billing systems.
  • Customer support content.
  • Links to legacy IT systems (via APIs or systems integration layers.)
  • Integration with workflow and governance systems, including legal approval processes.

Today’s web and mobile apps are mashups, not sets of pages

A web “page” for a digital-first business looks more like someone’s Facebook wall than a traditional desktop brochureware page of marketing copy—that is, it’s complex and generated specifically for a user’s context. Composing a “page” on a modern website or mobile app could include several different sources of content, some of them coming from outside the organization, composed on the fly. It might include:

  • Existing customer information (account status, recent activity, preferences, status derived from external APIs like Facebook, etc.)
  • Product content relevant to the customer’s context.
  • Support content relevant to the customer’s task.
  • The customer’s own content (e.g., profile page.)
  • Functionality or app relevant to identified customer need, e.g., total cost of ownership calculator.
  • Links to third party content via APIs, e.g., impartial reviews site.

Multi-source dynamic content can't be "owned" by a CMS

Today’s web and mobile apps are mashups, which makes them more complex than traditional document-based content like brochures, marketing materials, or manuals. In the past, content was a set of standalone documents that supported the business. In a digital-first business, this approach falls apart, because the content is part of the product, or more accurately it’s part of the service.

An interaction designer, developer, or content strategist creating a mobile app might want to configure these components in a completely different way to a desktop web page. We need to enable that by creating APIs that serve relevant content programmatically, not by creating CMSes that own static web “pages”.

A digital-first example: Zipcar

The Zipcar website

Consider the content needs of Zipcar, a combination car-club and car rental service which lets you rent a car that lives on your street and pick it up using a smart card. Zipcar is a digital-only company, because its business model depends on digital technology:

  • You reserve cars online (or using a mobile app).
  • You need a mobile phone to call Zipcar if anything goes wrong.
  • You unlock the car with a smart card or a mobile app.
  • The cars communicate with Zipcar’s systems using cellular and GPS technology to report their location, mileage, etc.

Zipcar’s core content is the descriptions of the cars themselves:

  • Car “name”, model, color, etc.
  • Location.
  • Availability and pricing.
  • Registration plate.
  • Photographs of the location to help customers find the car.

Depending on context, Zipcar needs to present this core content in several different configurations:

  • For prospective customers on the website, show locations and names, but not availability, registration plates, or location photos.
  • For logged-in customers using websites or mobile apps, show availability but not registration plates or location photos.
  • For logged in customers who have a confirmed reservation for this car, show everything.
  • For call center staff, show everything but signpost what should be shared with customers.

To complicate it further, Zipcar needs to be able to add and remove cars to the system instantly: sometimes a given location will get a completely new car, with a different name, color, and registration plate. This is a core business system that’s updated all the time, and integrates with the billing system and customer database. Zipcar couldn’t manage this content in a document-centric CMS.

The idealized destination: one API to rule them all

API utopia

In an ideal world, we’d sit down for a few months and create the ultimate central API, which interaction and content designers could use to build approved official products, incorporating:

  • Up-to-date, versioned, governed content, guaranteed.
  • Legal approval.
  • Access to customer databases.
  • Access to billing systems.
  • Links with legacy IT systems.

The reality: continuous iteration, podular structure and a learning organization

Of course, this could never happen, because all of these things are moving targets. We’ll never get to the promised land, and there’ll never be a single API to rule them all. This isn’t about redecorating the lobby every five years (another gem from Karen McGrane)—we need to continuously iterate our services so we can respond to and learn from feedback from outside the organization. We need an evolving suite of APIs that get us progressively closer to our goal—the ability to respond to new developments in platforms, networks, and customer behavior faster than the competition, learning as we go.

To get there, we need to move from command and control, hierarchical, waterfall-style organizations to agile, “podular”, learning organizations. A tall order, but the alternative is to fade away.


If you’d like to explore these issues in depth, come to our workshop in London on 21 September 2012: Advocate, Adapt, Align: Using Content Strategy to Change Your Organisation featuring Sara Wachter-Boettcher, Kate Kenyon, and me.

2 thoughts on “Digital-first companies thrive on mobile disruption. Everyone else struggles.

  1. Thanks for your post, it got me thinking…

    “We need an evolving suite of APIs that get us progressively closer to our goal—the ability to respond to new developments in platforms, networks, and customer behavior faster than the competition, learning as we go.”

    So, if I read you correctly, you’re saying a company’s CMS will become the API to its database, which will be populated by a verbose automated workforce (robots) capable of creating a variety of output appropriate for those in the many stages of their buying decision–oh, and the faster it learns to do it the better. Do I have that right?

    The “buyers” on the other hand, I suppose, will be using programmable software tools to fetch data from the APIs and provide logic for their decision making (a la derivatives trading).

    Seems to me that those CMS’s of the future should also include the capability to integrate the (yet unplanned–as far as I know) twitter server and facebook server (a la the wordpress.org/.com model).

Comments are closed.