If we can address the content challenges that exist within brands, what opportunities can organisations capitalise on now to deliver personalised experiences? We asked that question to a mix of agencies, brands and partners that attended a WPP European Summit back in June 2015. Here’s what our summit delegates prioritised as the three key areas for serious consideration by the business. In this post, we’ve pulled them together into a draft content engine blueprint:
Show tangible business value and success. Understanding what content exists within the enterprise. Continually show its value, impact, and return back into the business. What if they was a workable content performance framework that continuously linked and tracked the investment case for content as a practical and pragmatic set of KPIs and objectives that quantified success? Imagine that.
Manage content as a product. Move beyond episodic campaigns and projects. Focus on assembling brand communications, using blocks of reusable content that’s accessible across the enterprise. What if content architecture applied end-to-end product management principles to the design of strategic content, from ideation to expiration, based upon transparent and agreed investment cases? Imagine that.
Content lifecycle management. There needs to be clear separation between content products and the services people use to operate them. What if the content operating model surfaced the processes and overarching governance framework for getting content into and out of the enterprise to drive real-time personalised experiences? Imagine that.
Forrester predicts that the volume of unstructured enterprise content is growing at a rate of 200% annually. Content is communication. How well it is designed, managed and measured directly impacts on our ability to engage effectively with customers. The content engine looks to address our content challenges and turn them into opportunities by consciously stepping up to manage content as an enterprise-level strategic asset that drives competitive advantage.
This post has been on my mind, on and off, for about ten years now. I know, I know; I’m slow. It’s about the wide and numerous assumptions people make about design when creating digital products and services. I’ve been doing this for over twenty years now, and to sum it up, we just don’t spend enough time doing design. We pay good lip service to design, but by and large, design is under valued, under sold and always under scrutiny. This is blood boilingly crazy when clearly the likes of Apple, GE, Google, Tesla and Netflix are founded upon the results of great design. So why do the rest of us skimp on design?
Please watch this two minute video. It does an amazing job of describing the utility of APIs using a deck of playing cards.
Content APIs are on the rise because we need ubiquitous access to content. For a while now, I’ve felt like our content management systems are being deployed as Roach Motels (see resources at the end), where content checks in, but it doesn’t check out. Forever locked into a single (web) channel with no easy way out.
A couple weeks backs, I explained why content APIs are becoming critical to those in the content business. They help mitigate the Roach Motel problem. The big guns are already reaping the rewards of their early investments in content APIs. Take Netflix, after just two years of deploying an API, it’s seeing a x37 increase in API usage, the majority of which is through internal consumption.
Today, let’s walkthrough through a couple of examples to drive home the point that APIs lower the bar to making content accessible: available to people, processes and products that potentially do not to contribute to the production or ongoing management of the content.
Have you been hearing a lot about APIs recently? Or maybe the Create Once, Publish Everywhere (COPE) thinking that came out of NPR? It doesn’t matter whether you have or haven’t really. What’s important is that we understand why APIs are on the rise.
Why did the big guns invest heavily in APIs and are now reaping serious benefits. Netflix, NPR, Twitter, Facebook, Expedia, Guardian, Google, to mention a few, have well established APIs that grant third parties, that’s people like you, me and other companies, controlled access to their functionality and content. That’s right, these companies have created a playroom filled with shiny new toys (content and functionality) and have given us the key (API) to play with them. But why?
What value do these companies see in APIs? Why do they continue to invest in them? And how do I get me some API action?
The amount content we produced in 2011 alone exceeded the content created in all previous years combined. ALL previous years combined! We more than doubled the size of our digital content universe.
That wouldn’t be such a bad thing if all that content could get everywhere it needed to be today. It can’t. Instead, it’s trapped in the applications (CMS, DAM,Word) and/or channels (e.g. Web, Email) that created it. This is not a sustainable business model for many companies that create and publish content to better engage with their customers.
It’s stupid, costly and uncompetitive to create great content and not invest the time and effort to make it structured and meaningful. To make it future friendly. And yet the rate of growth for digital content continues to rise exponentially, more than doubling every couple of years. It’s time to stop creating more content (junk) and start making content work more.
Back in July 2010, the Harvard Business Review (HBR) told businesses to Stop Trying to Delight Your Customers. HBR challenged conventional marketing wisdom and declared that satisfied customers are NOT loyal customers.
Delighting customers does not build loyalty. However, reducing the amount of effort required to get things done – does. From a survey of more than 75,000 service-based personnel, HBR found that to really win customer loyalty forget the bells and whistles and just solve their problems.
Make it easy for your Internal Customers
These findings talk directly to the challenges faced by those managing content across multiple channels today. For example, below is a list of common problems internal customers encounter when trying to create and publish content:
The copywriter who struggles to edit an article.
The compliance officer who cannot preview content before it goes live.
The system administrator who cannot police the infrastructure.
The product manager who cannot change prices in real-time.
The brand manager who needs tighter control over digital assets.
The optimisation specialist trying to figure out cart abandonment issues.
A Web Standard is both a guide and a measure. I believe that Web Teams that invest enough time and the enough effort into Web Standards, will reap the benefits. We covered this in a previous post. Today, we dive straight in with a concrete example: URL Naming Web Standard. Note, just to keep this post to a reasonable length, I’ve had to trim it down. Rest assured it does have enough meat in there to illustrate what is a Web Standard.
Not many web sites today are launched with clearly defined and/or enforceable Web Standards. For larger organisations, looking to execute efficiently on the Web, this is a major stumbling block.
Confession. Having worked in and for large organisations for over 25 years, I was never a Web Standards fan boy. They were always out-of-date. They were written by non-practitioners. Their format was dry and verbose. Their purpose unclear but just obey. Effecting change or providing feedback was actively discouraged. In short, information flowed one way: down! There was not much to like about Web Standards.
However, if you can get past all, there were little gems of insight locked away in these Web Standards. Looking back through older eyes I realise that I never really hated Web Standards. I just didn’t like the way they were enforced. So I rejected them and promptly falling foul of throwing the baby out with the bath water.
About 10 years ago I was brought into a digital agency, with a burgeoning technology arm, to help them get better at delivering websites. At first, I was sat with the web developers, but over time my audience widened to include both Information Architects and Designers. That’s when the sparks started to fly and I was plunged head first into the world of mutual disrespect between all parties.
Things have moved on (a little) since then but I would like to share some of things I learnt back then, and mix that in with what I still see today. If you have any thoughts in and around this area, I would love to hear them. Be sure to let me know from which vantage point you’re coming from when commenting though… 🙂
Hey, I’m Cleve and I love technology. A former academic that moved into fintech to build trading platforms for investment banks. 20 years ago I switched to marketing and advertising. I joined a content technology spin-off from the Publicis network that was bought by WPP in 2014. I'm now at Omnicom. These pages chronicle a few of things I've learnt along the way…
My out-of-date cv tells you my past, linked in shares my professional network and on twitter you can find out what I'm currently up to.
