Rethinking newsroom innovation

The idea for BBC News Labs’s Media Innovation Unconference started humbly: “Wouldn’t it be great if we could get all the other people working on the same problems into a pub together to talk about innovation?”

Our team facilitates a range of industry-wide events, the most popular being our #newsHACKs centred on emerging technologies. But we often feel as though we’ve missed out on an opportunity — to share ideas not only about how a particular technology might be optimized for the newsroom, but about how we as innovators can optimize our processes and workflows to maximize the value to our organisation.

So we decided to try something a little different.

Our Innovation Unconference invited innovation leaders to discuss the challenges facing teams within legacy media outlets. Over the course of the day, we discussed themes ranging from project transfer to managing stakeholders, not forgetting an honest review of to the lessons we’ve learned from our biggest failures.

We decided to abide by the Chatham House Rule to allow attendees to speak freely about the experiments that haven’t worked, as well as the ones that have. But without attributing ideas to any participants, we did want to share some of our favourite takeaways from the day.

Please feel welcome to leave comments and join the discussion.

1. Kill your experiments — and celebrate

One of the biggest challenges facing newsroom innovators is transferring one-off prototypes to product teams. This can be exacerbated when there are simply too many new experiments for any one team to take ownership of.

When tools or features aren’t designed to be short-lived, it can be difficult — both politically and technically — to shut them down.

To create the capacity for successful product transfers, kill less successful experiments. This frees up resources for further experimentation and, when you go to transfer a product, means that the teams responsible for taking it on have less on their plate already.

To help make project burial a routine part of your team’s culture:

• Define your metrics for success. Building granular metrics into a project from the get-go means that you can better evaluate its value when the trial ends.
• Give all projects a lifespan. Whether it’s six weeks or six months, evaluate success at the end and kill those that don’t make the cut.
• Consider designating a person to serve as the “Minister of Phasing Things Out”. At the end of a project lifecycle, they can work with users to ensure minimal disruption.
• Build frameworks for tools. A system that’s meant to be used as a base for new experiments means fewer independent products to support.
• Celebrate the deaths of prototypes. Pizza and beer are good tools for reinforcing that “success” doesn’t always mean “transfer”.

From the session “Transferring prototypes to production”.

2. Create a workflow that solves your problems

Should you structure your innovation team to run like a startup — even if your newsroom is anything but?

It’s best not to be dogmatic about sticking to a particular technique, whether it’s scrum, agile or user-centered design. Pick, choose and combine approaches to address specific problems your team faces.

And don’t be afraid to change your process on a project-by-project basis. One size doesn’t always fit all. You’re an innovation team — so experiment.

Here are some additional tips from the session:

• Whatever techniques you choose, make sure that they don’t pose barriers to collaboration. Think about how new workflows can accommodate stakeholders from different departments.
• Finding a process that works for both editorial and technical teams is challenging even when you’re not using jargon. If you adopt methods from agile, scrum or user-centered design, make sure you can explain them using layman’s terms.
• Experiment with tools and techniques that help identify bottlenecks in your workflows. Some we mentioned: daily stand-ups with your team, Trello and Clubhouse.
• Try to identify a single project or product owner instead of seeing ownership as split between stakeholders. Having one person represent the interests of all the various stakeholders can eliminate friction in the development process.
• If you decide to organise stand-ups and retros, make sure that everyone on a team is involved. This can help eliminate an “us-versus-them” mentality when working with stakeholders.
• Practice empathy. If you try to identify what others are struggling with, whether it’s your users, stakeholders or other team members, you’ll be able to develop better ways of working (and better experiments and products).
• Create psychological safe spaces to talk about what’s working and what could be better. That might be regular one-on-one meetings, group retros or a Slack working group where private channels are banned. If team members feel free to raise concerns about projects and processes, you’ll be able to spot problems as they crop up.

And finally, it’s important to consider how adaptive your workflow is to change. Can you try out new techniques quickly, and make changes when something isn’t working? If not, how can you build more flexibility into your working culture?

From the session “Project Process: What is too much?”

3. Consider building capabilities instead of products

The premise of this discussion was the idea that product-centric thinking may stave off innovative thinking rather than encourage it.

Here’s a recap of the pitch:

Because a good product is stripped of functionality that isn’t essential to achieving its end goal, elements that might be useful in future experiments are often shaved away early in the process.

For example, a good product that is designed to automatically generate transcripts for journalists is likely to only include features that help its users achieve that end goal. A feature that that might allow the generation of subtitles from the transcripts would be considered superfluous to the end product.

However, generating subtitles or auto-exporting segments of audio may later form the basis of a new product. Because you’ve eliminated that capability from the scope of the initial product, you’ve set back future experiments.

What’s the solution? Here are a few things we discussed as a group:

• Rather than thinking about products, consider thinking in terms of designing new capabilities. A capability may enable the creation of new tools and products.
• Be aware — and perhaps a little wary — of how your organisation’s structure might be affecting your approach to innovation. Conway’s Law says that the products you build will naturally reflect the design of your organisation.

This may mean that you tend to think about experiments that could be handed off to pre-existing product teams, rather than thinking about experiments that might not have a pre-defined structural home. While this might be pragmatic from a transfer perspective, it might also mean that you miss out on opportunities to solve big problems facing your newsroom.

From the session “Product kills progress(?) Discuss!”

What's next?

We plan to iterate over this initial experiment and schedule another Unconference in the future, taking on board our learnings from the day and feedback from attendees. This is likely to be at the end of this year or the beginning of next.

If you’re interested in being involved, please send us an email at newslabs@bbc.co.uk.