PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
everything in its right product #
every PRODUCTHEAD edition is online for you to refer back to
tl;dr
Rather than existing in a bubble, each product team should have core members, collaborators and supporters
How you should divide up teams depends on your product’s overall flow; avoid ambiguous ownership
Teams should have end-to-end responsibility for a part of the user journey with minimal dependencies
One approach is to delineate between teams working on a core problem domain, and on those enabling their work
hello
What if we designed our team structures more intentionally? That’s the question the authors I’ve included this week are answering.
It seems to me that organisations often structure their teams by happenstance. Even if there was some kind of rationale at the beginning, the cumulative effect of hiring, layoffs, internal restructuring and good old office politics is that teams can end up looking like they’ve been thrown together.
In the absence of any better ideas on how to improve a business’s performance, rearranging the org chart ends up being the fallback option. Yes, doing so certainly drives change, but not necessarily for the better.
“Ah, but our company is different.”
Great. Perhaps your organisation went all-in on team autonomy and inadvertently created small, team-sized silos that don’t play nicely with each other. Or perhaps your CEO, under the influence of some mind-expanding consultancy, blindly instigated the Spotify model, and now everyone’s a bit embarrassed about calling things ‘squads’ and ‘tribes’.
Just as copy-pasting product strategy without contextual awareness is a poor idea, so too is copy-pasting organisational structure.
For you this week #
As an alternative approach, this week’s PRODUCTHEAD brings you articles from Emily Webber, Elias Lieberichs, Petra Wille and Susanne Kaiser. Each discusses aspects of team topology in increasing levels of depth. Enjoy the articles!
Speak to you soon,
Jock
what to think about this week
The Team Onion
I’ve recently been playing with ways of explaining the extended team for large and largeish organisations. I get frustrated when I see Agile teams that are essentially siloed off from the wider business (for many reasons). This causes dependency and communication issues and means they just aren’t able to deliver anything very quickly. I don’t think the answer is just to throw everyone in together as it’s not always that practical and can cause its own communication issues as the team gets really big. I’ve been using the team onion to describe a model of how it might work.
How many pizzas does it really take to feed your team?
[Emily Webber]
Team Topology: A critical approach to optimizing team structure
Team topology is about more than just organizing teams—it’s about creating a system where teams can thrive, minimizing bottlenecks and maximizing productivity. Imagine crafting an ecosystem where teams are clearly defined, not just by what they do, but by how they interact, share knowledge, and drive value.
Focus on solving problems rather than navigating bureaucracy
[Elias Lieberich / Mind The Product]
Understanding Team Topologies for product people
In many of my coaching sessions with product leadership teams, we often touch on the topic of team topologies. This often comes up when there’s friction between teams—either they’re too small, too large, or just not optimally structured. This friction can lead to inefficiencies and misalignment. Therefore, understanding and applying the principles of team topologies is crucial for any organization aiming to streamline its product development process.
Shared goals without stepping on each other’s toes
[Petra Wille / Mind The Product]
Adaptive, socio-technical systems with architecture for flow: Wardley Maps, DDD, and Team Topologies
This article highlights evolving an example of a legacy system of an online school solution for junior students. It describes creating a Wardley Map visualizing its business landscape and demonstrates connecting the map with DDD to discover its core domain and decompose its monolithic big ball of mud into modular components (bounded contexts). Additionally, this article covers identifying suitable team boundaries for Team Topologies’ team types leveraging the previously created Wardley Map as a foundation.
Combining business strategy, software architecture and design, and team organization
[Susanne Kaiser / InfoQ]
recent posts
The power of open
4 valuable product and culture lessons from the UK’s government digital teams. This was a talk I gave for Product People in September 2024. Video and transcript available.
[I Manage Products]
What to expect from your face-to-face product manager interview
Your product manager interview is as much about you getting to know your interviewers as it is the other way around. Here’s what you can expect along with my tips for standing out from the crowd.
Go a bit meta and challenge the premise of the exercise
[I Manage Products]
Moving up to a CPO or VP Product role
Stepping up to a Chief Product Officer (CPO) or VP Product role doesn’t so much change what you do. Rather it amplifies everything. This guide lets you know what to expect.
Liberating and terrifying in equal measure
[I Manage Products]
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from a leaky umbrella.