We’re now a couple of months into the INMA Product Initiative. I’ve been speaking to leaders from around the world and have already seen some common threads I want to share. I hope this is helpful. If you’re tight on time, scroll down for the key takeaways/TL;DR.

Here are four lessons I would like to share so far.

1. Defining “product”  

The Reuters Institute annual trends and predictions report found 93% of leaders felt product was important, but less than half felt the product role was well understood. 

The definition of product is evolving. Here is a simple version that we’re using: 

“Product” is a cross-organisation function, working closely with content and technology, which balances the consumer experience with business objectives. 

This means product pervades the entire organisation. Practically, product can be broken down into four categories:

• Consumer facing/platform, which can include: Web, apps, newsletter, epaper, podcasts.

• Enabling products (cross-platform), which can include: checkout, paywall experiences, personalisation, OVP, notifications.

• Internal tools, which can include: CRM, CMS, advertising tools.

• B2B tools, which are usually internal tools that have been developed in-house and sold separately, such as The Washington Post’s ARC or The Globe and Mail’s Sophi.

2. Defining business objectives

There is a need for a shared understanding of goals and desired outcomes. Most news businesses will have overall objectives represented as a single North Star metric or as a set such as OKRs (objectives and key results). For many publishers, these revolve around reach, engagement, and revenue.

The key questions here are: How do company goals translate to product so that each person and department is focused on pulling the right levers within their power to meet those goals?  And how should these be measured? We’ll be discussing this on Wednesday in a Webinar with Lucy Butler, director of customer analytics at Financial Times in the UK and Marcel Semmler, global head of technology for publishing at Bauer. You can find more information here. And we’ll cover the topic in more detail in a future newsletter. 

3. Product myth 1: Product = innovation (i.e. developing shiny new things)

In reality, product as a function is being introduced to the news industry most of the way through the product lifecycle — Web sites, apps, and newsletters have been around for a long time. This means that for most product teams, 90% or more of the time is spent optimising the current product rather than developing brand new products.  

Optimisation can make a huge difference. Here are a couple of simple examples:

• The New York Times found that allowing users to login via clicking a link in an e-mail (“magic linking”) had a 2% lift in successful logins.

• The Wall Street Journal was able to increase app downloads by 450% through using link texting for app downloads. 

• The Telegraph saw when it optimised its homepage speed (going from 9 seconds to load to 5.5 seconds), it had a 12% increase in pageviews from subscribers.

And this is a slide from a recent presentation by Kara Chiles, vice president of consumer product at the world’s largest regional news organisation, Gannett, showed some of her team’s key results focused on unifying systems after a merger.

4. Myth 2: Product is a delivery function

Product is not project management. Organisations have limited resources. Therefore everything that gets added to the wishlist has a knock on impact of other work that is happening or scheduled (more on the product roadmap and who owns what in the next newsletter). 

Product people are influencers, educators, and informers who help other departments come to mutually beneficial solutions. Once the solutions are agreed, they will often own the roadmap and be responsible for delivery in conjunction with other stakeholders. 

Who are the stakeholders?

If we go back to the definition of product above, product is a multi-disciplinary function that affects every part of the business. Below shows the main stakeholders. 

Multi-disciplinary teams  

There are many, many different types of organisational structure. “Chief product officer” is becoming more common within the C-Suite. Sometimes this is a progression from chief digital officer (literally so at Prisa in Spain). No matter what the organisational structure of product, it is a function that has many interdependencies and input is needed from all departments. This starts at the C-level — which is multi-disciplinary in itself — in agreement with the major business objectives and priorities.  

Specific products and groups of products will usually have a “product owner” and work with multi-disciplinary teams also known as squads, scrums, or pods. These teams are not hierarchically related with reporting lines into the product owner. Instead, they are designed to ensure the needs of each department are being met and that each department is pulling the appropriate levers in its power to create an outstanding consumer experience and meet the business objectives. 

Product pod/squads/scrums/teams consist of: 

• Product

• Design 

• UX 

• Data 

• Editorial 

• Commercial 

• Other relevant stakeholders 

The mix will vary depending on the product. For example, editorial teams are likely to be highly involved with consumer products (arguably content is the product here), and less involved with enabling products such as checkout processes.

Data-driven decisions

Even with multi-disciplinary teams, the representative from each department must reflect the needs and feedback of the entire department — not simply their own experiences and opinions. For this reason, using a data driven approach is key.

That doesn’t mean intuition and gut feel is wrong. It means data should be used to validate. The Guardian’s Chris Moran recently presented at the INMA Media Subscriptions Summit, sharing two of the company’s six golden rules around data help explain this: 

Almost every product leader I have spoken to, particularly early in the organisational product journey, tells me they sometimes feel like a broken record. Why? Because for every new idea or development that needs to be done — urgently! right now! — they point to the overall goals and ask how this particular thing will help move the needle towards it. 

It takes time to change ways of working. But for the leaders who have gone through this, everyone says that it is worth it. 

Key takeaways/TL;DR

• “Product” is not about developing new products 90% of the time. It’s a discipline focused on optimising current products to improve customer experience and reach company goals. 

• Product can only exist effectively cross functionally. It is the “glue” bringing everything together, which means:

• Working towards the same goals.

• Excellent communication and transparency are needed to break down silos and create trust 

• Specific Product pod/squads/teams are being developed with a representative from each of the appropriate stakeholders and a single “product owner,” who typically is responsible for the vision, the strategy, and the delivery. They are responsible for end-to-end success but they do not own the P&L and the role is reliant on all stakeholders. 

• Product is a structured discipline but can also be creative. The discipline can help bring the gut feels and instincts into a framework for development (more on this coming soon).

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. If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here. 

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