Your problem isn’t software, it’s workflow

This essay is a write up by Matt Locke from a conversation with Paul Ford about the role of CMS in public media organizations. 

I’ve rarely had a job in my life that didn’t involve basically sitting next to somebody and saying: “How can I make this better?” Most of the time, the problem we’re solving at Postlight is not software, but workflow. We see companies that have thought about their audience, set goals, decided on a product, and then dropped a content platform into their organization. But we see little budget put into understanding what people actually do in their jobs all day. This is what PostLight ends up doing over and over again. We just sit with people who are currently using a broken system that they hate, and try to make it better for them.

The core truth is that people always think they have software problems, when they actually have workflow problems.

We’ve had meetings and kickoffs with clients where they look us in the eye and they say “ I’ve seen so many organizations come through like you, and everybody says they’re going to make it better. How are you going to actually do that?” It’s not simple to answer, but the core truth is that people always think they have software problems, when they actually have workflow problems.

We get all kinds of content management requirements presented to us at Postlight. A large NGO came to us years ago and said, “I don’t care what CMS it is, it should just cost half a million dollars”. That was a low point – they were specifying a CMS as if it was carpet or wallpaper – “just get me this much CMS for our money.”

But most briefs focus on editorial familiarity; because the cost of getting editorial staff to take a new technology seriously, and actually use it, is very high. They’re a resistant group because they’ve been burned by really lousy systems that make it hard to do their job.

When it’s got to the point that your staff are thinking “This software is so bad that I’m going to spend time making media about how bad the experience is”, you’ve crossed some kind of line.

We worked with a big media organization where it took hours to upload, and add metadata to, a video because the process was so broken. As a way of showing how broken it was, an editor recorded the process in front of their screen and then sped it up about 10 times with a clock running in the corner, and then shared that around as a product requirement. When it’s got to the point that your staff are thinking “This software is so bad that I’m going to spend time making media about how bad the experience is”, you’ve crossed some kind of line. That’s when you’ve got workflow problems.

This is why the first part of making a decision about a CMS is just sitting with your editorial teams and actually listening to them. And then, and this is the tricky part, going back on a recurring basis to the same people as they start to use the new system, finding out what’s working and what isn’t.

A lot of people start by thinking the end user of content management systems is the audience; but they’re missing the fact that actually, the end users are always the people inside the organization.

It’s hard because, for some reason, we start tech strategy projects by focusing on the user, the business case, and the amazing progress we’re going to achieve. And then once the new tool is in place, there’s a day for training, because everything’s supposed to be so easy and simple to use and not take any time. It’s like saying to a carpenter “I gave you some hammers and nails, why can’t you build me the house that I have here in this picture?” It really dismisses the hard work it takes to help people adapt their workflow to a new system. A lot of people start by thinking the end user of content management systems is the audience; but they’re missing the fact that actually, the end users are always the people inside the organization.

Right now, the way content management systems work is changing, and this is changing the workflow for people in editorial roles. Most people are used to a CMS that doesn’t look too different from early blogging tools. You log into an admin interface, a box pops up, you put words in the box, maybe the title and subtitle, and then another box for the body of the article. Then you click some drop-downs for adding tags or metadata, and then it all goes into a database. Then, when somebody calls your article from their browser, it pulls up that article from the database, puts it into a template, and gives them an HTML webpage.

That has worked beautifully for years, and frankly still works beautifully. But what’s changing is all the major platforms are now thinking of themselves as ‘headless’ or ‘API driven’. What this means is that instead of assuming articles will be displayed in a web browser, the CMS is designed to present content as data that can be changed dynamically by other software products before it’s presented to the audience.

In an API driven headless world, the CMS is one component in a suite of services. It’s no longer the central web page maker. Instead the browser will ask for something, and that will call out to many services, including the CMS, to compose an experience for the user. This really becomes meaningful when you want your content experience to integrate with other large systems.

For example, imagine you want users to fill out a form to download a piece of content, or I want them to pay and register with our paywall. You can have one app to manage user management and logins, one for payment, and another app to ask people to fill out a form before they download the PDF. And then, and this is where people get excited, this can all go into a customer relationship management product (or CRM)  like Salesforce. So instead of thinking of users in terms of their engagement with a single article – like time on site, paid views, ad views, etc – you can start to think of readers in terms of a funnel towards a business goal, like subscribers or registrations.

Publishers are starting to pull back from the big platforms, invest in their own technology, and own more of the value around their own content to create a sustainable business model.

This is, for me,  the fundamental change in how we think about content on the internet. Phase one was, “Oh my God, we can put content up on the web, and it’s kind of for free!”, and the only feedback loop was people sending us emails or comments. Phase two was “We can monetize it by putting ads on our content, especially from companies like Google, who just give us all the ads and we get the money!” In Phase Three we’re seeing a backlash to giving away too much control to platforms like Google. Publishers are starting to pull back from the big platforms, invest in their own technology, and own more of the value around their own content to create a sustainable business model.

Publishers are building their own platforms, with apps for authentication, user management, and paywalls, and using these to build closer relationships with their audiences. Distribution is changing from a one-size-fits-all model to more targeted content strategies for different audiences. So they might be pulling things out of their CMS automatically for their newsletters, like automatically creating a bespoke newsletter from their ten most popular articles. The workflows around production and distribution are changing as their readers are having different kinds of relationships with their content. Instead of seeing users as targets for ads, API driven content strategies seem to be more and more about how we can get long term value for both sides of the publisher/audience relationship.

The thing that has truly changed is people just don’t go to websites that much anymore. They see things on Twitter, they get newsletters, or listen to podcasts. People don’t just type a URL into the browser, look at a site, and then type another URL into the browser. Now you are much more likely to see what people are saying on Twitter or on Facebook, then follow a couple of links. You might subscribe to the New York Times and get the newsletter or podcast. You might have your hometown paper, your monthly magazine – you’re expecting to get all this content pushed to you in some way, through subscriptions, notifications or your social feeds. And so CMS and CRM platforms have to support all these different kinds of interactions.

The best way to think about the workflow of production and distribution is as something that is stuck between two funnels. One funnel is the workflow funnel of your editorial teams, where you really have to understand what their everyday working needs are. The second funnel is the audience engagement or monetization funnel, where you really need to think hard about exactly what the audience journey is. You want the content to take the audience member towards a relationship with your organization, and you need to know where the ideal destination is.

Your technology strategy needs to be continually informed by the needs of your editorial team and audience, not by the latest tech, or what promotions the big platforms are offering now.

The bit in the middle that connects the two funnels in the best way possible – that’s your content technology strategy. You have to work inwards from the two funnels to find out what technology you need at the centre. You can’t just buy a new CMS, drop it in, and expect everything else to fit around it. Your technology strategy needs to be continually informed by the needs of your editorial team and audience, not by the latest tech, or what promotions the big platforms are offering now.

For non-profits, having the money to invest in requirement gathering and tech strategy is hard. But getting the budget to maintain and update that technology in a sustainable, iterative way is almost impossible.

When I talk to experienced content publishers, the problem they’re constantly facing is technical debt. They know when they implement a new technology, that over time it will accrue barnacles and become a horrible cost center that makes everyone unhappy. In most mid and small sized not-for-profit media organizations, there is scarce planning or funding to deal with this technical debt. People are like, “let’s just get this done”, and then, “we’ll cross our fingers”. The biggest problem with content technology now is not just specifying the right tech; it’s maintaining it after launch. For non-profits, having the money to invest in requirement gathering and tech strategy is hard. But getting the budget to maintain and update that technology in a sustainable, iterative way is almost impossible.

The problem is that there’s too much focus on innovation for the sake of innovation. There’s a constant demand for new content, new formats, and shiny new things. But the everyday job of making your core production and distribution technology work efficiently is not seen as a ‘new thing’ – it’s seen as boring and dull, even though it has way more impact on your business goals than a shiny new tech project. The true disaster, in my opinion, is rich interactive projects that require huge bespoke technology development to even exist in the first place. The kind of project where there’s video at the top, there’s data visualization, and other whizzy things. I look at things like that and think – that will never be updated and it will eventually fail completely. Doing the work to support bespoke projects like that is incredibly expensive, and although big funders might like the project at launch, they’re not going to be paying for that kind of thing to live forever online. 

So these are the two things you need to think about when making decisions about production and distribution technology – workflow and technical debt. Don’t start by looking at a product, but by really understanding the role of content in your audience development strategy, and the role of your editorial teams in creating that content. And then think about how you can continue to refine and iterate your technology strategy over time.

The move away from single software solutions to headless or API driven technologies can help with this – small pieces loosely joined was the founding architecture of the web after all. What we need now is for funding strategies for public media to recognise this, and invest in building long-term capacity, not short-term innovation projects.

Paul Ford (@ftrain) is the CEO of Postlight, an award-winning design and development agency in New York. He’s a writer, product strategist, educator, programmer and software consultant and has managed digital and editorial strategies for Bloomberg, Condé Nast, Credit Suisse and VICE Media.  He’s written for the New York Times and Wired and in 2016, won the National Magazine Award. He’s advised startups and Medium, and was an advisor to the White House Office of Digital Strategy during the Obama Administration. He also teaches at the School of Visual Arts, and appears regularly on the radio, TV, and on podcasts.