How regional newspapers can rebound
Recently, I learned a lot about today's editorial workflows in daily newspapers in Germany. Together with some colleagues (journalists, developers, process managers, strategists) and a hired media consultant (founder of the institute for media strategies) who advises several papers in these challenging times, we played regional newpaper for a day. We planned, created, edited, produced and finally got ready to publish. It was a well defined process from plan to product, kind of logical and inherent. Okay, we stumbled over a problem here and there (like the lack of smart planning software), and some of them were even painful (hard-to-use cms, formatting stuff, sending printable photos with low bandwidth, et cetera). But at the end of the day we executed our plan successfully - the compression rolls got their food to print and a pleasant little selection of stories got it on our website. We all deserved a little sundowner under a grey sky, I guess.
But, at the risk of spoiling my point already, it felt completely wrong. And I do mean completely. The whole time my stomach tried to tell me we don't really know what we were doing. And this was not because we weren't real newspaper editors. The idea to plan a set of news articles for the next day without considering the amount of attention our already digitally published story versions generate, just didn't make sense to me. And I asked our workshop mentor (the media consultant) more than once, if newspaper editors still really work this way. Well, there are newspapers who have changed their priorities from print to digital, he said, but that's just a handful, and it's mainly the bigger ones, the nationals. Regional papers are still almost 100 per cent print-focussed, and they are not aware this might lead to a shutdown of their media operation in the very near future, say in the next couple of years.
Being a digital native myself (well, professionally at least - I got my first real job in 1996 and my title was "head of online", whatever that meant back then), I couldn't really believe that in 2014 we're still at this point. For one thing, I'm just not comfortable with paper when it comes to news. It feels expired no matter what, and I immediately want to grab my notebook, tablet or phone to get a fresh version of the story. This is how I feel as a reader.
For another thing, sticking to a "news plan" in an uncertain, fast changing environment (which in this case is life as such, in a community or region, every day, every hour, every minute) means noticeable risk of generating waste (covering stories that gradually become irrelevant) and missing opportunities (poorly covering stories that actually get more and more relevant every hour), big time. This is how I feel as a (digital) business developer.
So, this workshop got me started, indeed. Mainly because I recalled this feeling, this specific tension I had when product development plans were long-ranging and I had to deliver exactly according to the plan (although everyone involved knew things had changed in the meantime). I almost forgot that feeling, and now I feel (it) for those editors, although they don't even know they are doomed unless they change. Sounds a little contemptuous, I know, but that is not how I think about it. My idea is to take a look at all those wonderful concepts that helped me/us to overcome those tensions and to create a lot more value than waste. Yes, I'm talking about lean and agile practices, methods and principles that - in the last couple of years - changed software (product) development profoundly. And here's how I tried to adapt some of them to the editorial world.
Minimum Viable Story
In Eric Ries's book The Lean Startup, one of the main ideas is to get a product out as soon as possible. His expression for this very early version of a product is Minimum Viable Product (MVP). The earlier your product hits the market, the earlier you learn if you're on the right track. If you are, you keep on following your original plan (until feedback tells you otherwise). And if you're not, you pivot. In order to decide whether to continue or to pivot, you would have to measure the usage of your MVP. So it all comes down to three activities: building, measuring and learning, in this order, over and over again.
The same thing applies to a story that you create. There is absolutely no point in creating a huge story with a lot of resources that in the end (aka the next day) no one is interested in. Thus, a good idea might be to write a short piece with some core aspects on the issue and publish it as quickly as possible an the Web. Once the item gets enough traction (you would have to define in advance what "enough traction" means), you invest more resources. The story gets bigger and bigger by feedback, it grows itself and its audience. This way everyone wins:
The editor does only relevant stuff, the online reader gets only relevant stuff, the publisher knows her resources are well spent and no waste is being generated, the advertiser gets more eyeballs or the paywall gets more leads respectively, and even the print subscribers get well grown (long form, visually appealing) articles the next morning. It's reporting (a story), measuring (its popularity) and learning (from measured data) - a report, measure, learn cycle.
In agile software development the developer project team collectively "ownes" the source code they write. Surprisingly enough, it's called Collective Code Ownership. This means everyone is responsible for the software quality. Each day, they come together and review all the fresh code that has been written since last review. They work together, they help each other, they feel being a part of a team that aims in one direction.
Most of the time, stories are created by one editor. But sometimes, a story might evolve into something big that requires more attention than a single editor can handle. In this case it might be reasonable to gather all editors on that story in one room and let them discuss a lot on the topic, and maybe even use collaborative text editors like Google Docs (let's ignore reasonable, NSA-related fear at this point, I'm sure we will find ways to bypass them pretty soon). I figure that this might be the case already in some newsrooms, but I'm fairly certain those editorial story teams won't invite colleagues form other areas to their sessions. Which leads me to the next concept ...
Cross-functional Story Teams
A lean startup wants to get things done, and the most effective way to get things done, i.e. to create real value as fast as possible is when people with complimentary skills and responsibilities work on the venture in one team, very closely, very intensely. So it's the sales guy, the ux-guru, the designer, the software developers, the marketing lady, the accountant, and the ceo who makes the final decisions. Of course you need some kind of protocol, a defined process that enables a cross-functional team to be effective and productive. This is where agile implementations like Scrum or Kanban come into play.
Wouldn't it be great if newsrooms did the same thing and assign cross-functional teams to stories in order to grow them continuously? Planners, (digital) producers, (multimedia) editors, software developers, photographers, proof readers - all in one team, working on the same story, together, continuously. I am pretty sure this would generate highly relevant (i.e. vertical and local) and enjoyable content on every device that people eventually would pay for.
A build-measure-learn-cycle works best if it runs fast. In order to run fast the team has to be able to deliver new versions of the product continuously. That is where deployment management tools like Chef get their part in the game. They allow teams to deploy upgrades (almost) fully automated.
The mindset of an editorial team should be the same. They should WANT to publish new versions of their story continuously. Why? Because with each update they create a new lead for the story. And they could even try different headlines and measure which one gets more attention. That might also get them valuable insight on the direction of the story, for instance, are their readers more interested in facts or in people, or do they long for explanations because they don't understand what's going on?
Okay, those are a few thoughts on how existing production and development concepts (mainly in the software sector) might help regional newspapers to rebound from the ongoing print downturn. In the end, it's about reducing waste and creating relevant content faster and better. To achieve this, the focus has to shift from print to digital. And to those who just don't like all this digital frenzy and really want to stick to their paperwork, let me say this: the better you (or your colleagues) do the digital stuff, the better your next day paper gets ...
Promise!
