Hi there. I hope you’ve had a good week. As usual, I have been busy speaking to leaders around the world to bring you some of the best practices in product. I’ve had a couple of ah-ha moments in conversations that I wanted to share with you this week: How do we organise product teams round stakeholders, and what are the benefits of small wins when looking at centralisation?

Neither of these are one-size-fits-all (is this ever the case with product in news?!). They are musings that I hope will help provide alternative views to your thought processes. 

Let me know what you think at jodie.hopperton@inma.org.

All the best, 

Jodie

Organising around stakeholders

We have talked a lot about product teams, including a deep dive in my recent INMA report “How Product Is Leading Media’s New Growth Path,” which looks at different organisation structures. There are numerous ways to slice and dice this — particularly around products and processes.

One of the biggest peculiarities of product within news is that product is not a set of features. It is the content experience, thus intertwined closely with editorial. Product often sits closely with editorial if not directly in that team.

Lousie Story, formerly at the WSJ, told me it was vital that she had input into content strategy and, to some degree, the content is the product. But what about the other departments? Product materials always talk about working closely with technology, UX, design, and data. But what about two other departments that are fundamental to a news organisations success: marketing and advertising? 

A new trend is emerging to account for this: organising around stakeholders. 

One CPO told me he has product managers associated with stakeholders so he knows he has people in his team who have deep knowledge of his stakeholders. They hold regular meetings and are deeply ingrained in the relevant business unit, sometimes (pre- or post-COVID lockdown) with a physical desk in that area, too. Thus the product organisation has an accurate reflection of an entire department and not just a single persons viewpoint within that department. 

Riske Betten, digital director at Mediahuis in The Netherlands, has designed a structure that accounts for the cross section of product, processes, and stakeholders as it relates to company and product goals. When I asked her to define how they see product, she told me: “If a consumer sees it, it’s a product.” She’s effectively taken their major focus areas — whether it is a platform, a process, or a department — and organised them into work streams.  

Here, Mediahuis actively looks at advertising as a product with revenue as a KPI. A direct result of this team’s discovery discussions and subsequent work was a creation of a whole news section, which met the joint need of both readers and advertisers. The content was already being produced by the newsroom. And by retagging articles appropriately, they were able to create a new section online, which in turn attracted advertisers. This example has the added benefit of clear revenue consequences, which for many is the holy grail of product. 

Both of these examples combine multi-disciplinary teams with a focus on deep understanding and knowledge sharing between departments — thus aligning goals and metrics clearly, resulting in the breakdown of silos and cross departmental wins.  

Date for the diary: September 15

We’re talking all things apps v. mobile Web with Riske Betten, digital director at Mediahuis (The Netherlands) and Aron Pilhoffer of Lenfest (USA) at my next Webinar. Do you always need an app? Are app users more loyal because they have the app? Or do readers become more loyal when they have the app? Should content experience differentiate? 

What questions do you have around this topic? Send them to be in advance at jodie.hopperton@inma.org and sign up to the Webinar here. 

Centralisation: It’s not all or nothing 

In almost every conversation I have about a product with an organisation with more than one title, there is a conversation about how much should be centralised or localised. Most organisations will want some kind of centralisation to make the most of economies of scale. It makes sense on both cost saving and ongoing ease of management. There are many factors of consideration — such as grouping these systems by brand alignment or by function/feature, as well as how much is centralised.

However, that’s not the debate I want to highlight here. I want to look at the approach taken to centralisation. 

If we start with a simple premise that it makes sense to build in a reusable way — which is what product is all about — what does that actually mean when it comes to centralising functions? 

If you’re starting a new product from scratch, the conversation and decision-making can follow a traditional product development process. However in most circumstances, centralisation is either coming from legacy structures that need modernising or by acquisitions that need integrating. Assuming there is some flexibility in choosing a system, let’s look at two ways to approach this. 

Option 1: Replatforming

Effectively this starts off in the same way as a new product: speaking with relevant stakeholders, going through a needs analysis, understanding the needs and the problems that need to be solved. 

Sometimes it is clear a fresh approach is needed and thus the traditional product development process can be used for selection. However invariably you will find some stakeholders love their system, others will loathe it, and there will be many opinions in between. The bigger the portfolio, the more diversity you will find in these needs.

After a lengthy process, you may get to a one-size-fits-all. But there are often so many different demands that during time it takes to get to a consensus, most people will have to make compromises somewhere along the line. 

Anyone who has been through it can tell you that migrating systems is no mean feat — both from a technology perspective and from a stakeholder/people perspective. With these factors in mind, we often find the replatforming process is long ... with many bumps in introducing a large change to workflows making it tough to make everyone happy. Unless, of course, the legacy systems were so in need of an upgrade that a change is welcome. We’ve seen this at some companies such as The Dallas Morning News (check out the Webinar here). 

Option 2: Using existing solutions

As identified above, through discovery you often find that there are systems people love or are so integrated into workflows that users don’t want to let go. 

Rather than scrap the entire system, could it be adapted and rolled out to the entire organisation?  This can be one large migration, which some companies have been able to pull off. Just look at Gannett’s acquisition of  GateHouse Media. They have integrated many back-end systems and are now reaping the benefits.  

An alternative approach is to migrate the system to a small subset of the organisation that is facing similar challenges: other subscription based titles or weeklies. If you’re lucky, one of these groups may even volunteer to be the guinea pig for migration. This doesn’t need to be a major project involving the whole organisation; it could be a relatively small project. If it’s successful, you can share the win and encourage other departments or units to follow suit, give them a carrot so to speak.

If needed, you can also follow with a stick: Let people continue with their current systems at their own cost or centralise to the preferred system where the costs will be absorbed elsewhere. 

And if it hasn’t been successful, you’ve saved yourself a lot of time and energy. 

This may seem more long winded and even counterproductive to the theme of centralisation. But by getting people to adopt systems that are already tried and tested — on their terms — you may be able to move faster overall. And, perhaps more importantly, you may create more desire to be part of a success story. 

To sum up: This is your friendly reminder that we don’t always need to go for the big wins. Sometimes starting small and building on successes — learning as we go — can work just as well, if not better, than attempting big change. 

Tweet of the week: The job of a product manager in a Venn diagram

The sweet spot in the middle must be growing the business in a timely manner with everyone on board.  

Recommended Reading

• Should you turn your “read next” links into a game? There’s a widget for that on Nieman Lab, covering new INMA member Crux. 
• On Apple this week: Apple, US developers agree to App Store updates that will support businesses and maintain a great experience for users and on Nieman Lab: Apple now wants to be your “News Partner” (meaning they’ll let you keep more of your readers’ cash if you join Apple News)
• Newsletters as a Subscription Hook Are Now a Core Offering from a Media Operator.

About this newsletter 

Today’s newsletter is written by Jodie Hopperton, based in Los Angeles and lead for the INMA Product Initiative. Jodie will share research, case studies, and thought leadership on the topic of global news media product.

This newsletter is a public face of the Product Initiative by INMA, outlined here. E-mail Jodie at jodie.hopperton@inma.org with thoughts, suggestions, and questions. Sign up to our Slack channel.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .