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 resources, 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:

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.

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

If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here.

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