Product organisational structures are changing, again

By Jodie Hopperton

INMA

Los Angeles, California, United States

Connect      

Hi there.

The question I get asked the most is around the product organisation structure. Of course there is not one single correct answer, however I have a couple of new perspectives from trusted sources that I want to share today. 

Also I have an ask: Could you share your product org chart with me either confidentially or openly? For anyone willing to share openly, I will give you access to others, too. You can pop it over in an e-mail to me at Jodie.hopperton@INMA.org and just mark it “confidential” or “open.”

Many thanks, Jodie

What does a perfect product org structure look like? 

My usual answer is, “It depends.” There are so many dependencies, which means no cookie cutter approach. I’ve been asking some trusted sources about this. Firstly, the INMA product advisory council had a deep discussion based on actual org charts that they currently use. And I learnt a lot from the keynote presentation of the innovative content formats master class we just wrapped up.  

Here are a few of my takeaways:

1. Almost every product org is in a state of flux. Given that it’s hard to find a single solution that works across all capabilities and metrics, most organisations are frequently tweaking theirs. These orgs will always be in a state of flux to some degree as we are constantly moving forward and changing with moving goalposts such as technology shifts, new data points, etc. — and that’s OK!

2. There is a need for departments AND cross-function squads. The cross-functional squads often focus on “problems to be solved” or “missions” such as storytelling, identity, engagement, commercial. In larger orgs, this is further split into media type or group such as paid/premium products, digital only etc. But you should note that whichever set-up you choose, there will always be power dynamics to take into account, as is human nature.

Matthew Skelton of Team Topologies differentiated squads from enablers and it was a real lightbulb moment for me. Not everyone needs to be on a squad as it slows things down. Think about what skills and experience need to be on the squad all the time, which are more complicated subsystem skills that need to be brought in to support, and which are enablers that need to share wisdom.

An example here is if there is a team on personalisation, the core squad is likely to be product-led with AI specialists as the core competency team and editors to shape the boundaries as the enablers. I’ve over-simplified, but I hope that makes some sense. Check out Team Topologies for more depth.

3. The jury is out on whether product and tech should sit under one person/in one team. This isn’t news and I have written about it before. But one thing I have seen is that there is a halfway house with software engineers sitting under the CPO, while architecture and product-as-a-service sit with the CTO. The main point here is that engineering cannot be lumped into a single skillset. Technology covers IT support, cyber security, infrastructure, and much more.  

4. On engineering resource there are arguments for and against having teams focus on fixed areas vs shorter-term problems to be solved. If a team works on the same thing, you have predictability and expertise builds, but that can make people less flexible/hard to move. A more flexible pool of resources means nimbleness but has dangers of building up tech debt as there have no long term ownership.

Again, from Matthew’s keynote, I think the Team Topologies structure may be a solution as it balances the two by having squads for longevity with complicated subsystem teams (that can work across squads). This is a slide from Matthew’s deck that shows this in action:

Matthew Skelton of Team Topologies proposes having squads for longevity with complicated subsystem teams.
Matthew Skelton of Team Topologies proposes having squads for longevity with complicated subsystem teams.

5. UX and design almost usually sit under product. User Experience is, of course, core to everything that product does. And design is absolutely core to UX.

6. Data and audience research often sit under product but don’t have a clear “home.” Qualitative and quantitative are often treated entirely separately and can sit in different places. It relates to the question of who “owns” the audience. The other thing to note here is that “data” in itself is misleading as a group term. It ranges from UX to privacy/compliance, which is very different to normalising and storing, let alone top layers to allow people to interrogate and obtain insights from.

Stuff in New Zealand recently made some massive changes to its product org, and the slide below very much resonated in how to handle brands as products and shared capabilities as products.

Stuff in New Zealand illustrates vertical ownership and horizontal support of its key products.
Stuff in New Zealand illustrates vertical ownership and horizontal support of its key products.
 

If you are planning on making changes to your team, check out TeamOS and TeamForm (which I think are free).

Date for the diary: World Congress in New York next week

If you are joining us in New York — or are based there — please come and join us for an extra curricular product meet-up during the INMA World Congress of News Media. We’ll be at The Long Bar on Thursday from around 6 pm. Message me and I’ll add you to the calendar invite. I am so looking forward to finally meeting some of you in person. You can follow along the week’s activities here.

The emergence of the storytelling product manager

You may notice in the Stuff example above that a layer is devoted to storytelling. I’ve noticed an emergence of a specific role for storytelling within the product department in media companies that I have a lot of respect for, including Schibsted, The New York Times, and Stuff. 

There are a few things to note here:

  • As an industry, we are identifying different focus areas and capabilities that are needed. It’s important for us to be able to react to new information, technology, distribution, and capabilities. Using focused squads is a great way to do this. By having a core team with a singular focus, you can truly match skill sets and experience to work effectively together. Maybe you bring some in from the gaming industry or Hollywood, arguably the best storytelling industries in the world. They don’t need prior news experience because you can make that up elsewhere in the squad. 

  • Why storytelling specifically? As our understanding of audiences becomes more in-depth, the range of formats becomes more and more diverse and distribution channels more complex. How we tell stories becomes more important. The role has moved beyond content to become more nuanced. 

  • The squad that focuses on storytelling also often has responsibility for the CMS internally. Why? Because the CMS is the absolute enabler to effective storytelling. Building on strong workflows and capabilities into a CMS means that everyone can tell better stories, more efficiently. 

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.

About Jodie Hopperton