PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
productcollider #
every PRODUCTHEAD edition is online for you to refer back to
tl;dr
Organisational changes will reveal weak spots in the current ways of working before you adapt them
Structure teams differently based on the nature of the work
There is value in using shared language to describe how teams differ
hello
Recent conversations with clients have been more about reshaping their product teams than about their products. In one instance, the organisation had changed their business model from the product perspective (annual licensing to monthly subscriptions), and were only now beginning to understand how their team structure should change in response.
A cynical observer would suggest that they should have seen it coming. However, not everyone is a prescient systems thinker. Sometimes you just have to see what happens and react accordingly. Forecasting how the teams will react to organisational changes beforehand is difficult when everything is still theoretical and everyone is still operating in the pre-change context.
Some effects can be more easily anticipated, others are more subtle and will only emerge after the organisational changes are in operation. To take a slightly reductive example: moving from annual licensing to monthly subscriptions increases the frequency of user renewal decisions, so it becomes more important that users see continually see value in the product in order to retain them month after month. How should the product and go-to-market teams restructure to deal with that change in pace?
More subtle effects may manifest: a particular team coming under increased load; or an existing inefficient hand-off between teams becoming more of a sticking point than it used to be. When you take a system optimised for a particular way of working, then change that way of working, it will tend to expose the weak points in the system. It would be like taking a race car designed for speed and getting it to pull heavy loads: different bits of the car than usual are going to stress and break.
To stretch the analogy a bit further, continuing to use the race car as-is and just fixing the bits that break do not fundamentally address that the race car is no longer suited to the type of work it’s now doing. A different design of vehicle is needed instead. In simplistic terms, we need to adapt the structure of our teams to suit the type of work we’re now doing.
For you this week #
To provide you with more context and detail on team taxonomies (classifications), I’m going to start with a gentle introduction by Emily Webber. She looks at four ways of describing the characteristics of a team:
1. Team Type: ‘Enabling and empowering (other internal teams)’ OR ‘User outcome aligned’
2. Team Makeup: ‘Multidisciplinary’ OR ‘Specialist’
3. Team Mode: ‘Long-lived’ OR ‘Temporary’ AND could also be ‘Roving’ (moving around the org as needed)
4. Team Span (or scope): one programme / multiple programmes / organisation-wide
Next I have a couple of articles from John Cutler for you. The first talks about the pitfalls of using a one-size-fits-all approach to how teams tackle different types of work, and suggests a way to uncover the different types of work particular to your organisation. His second article looks in more detail at how the stage of company (startup, scale-up, mature), stage of team (broadly aligned to stage product lifecycle), and the shape of the work all have an effect on how teams should tackle the work.
To finish with, senior engineering figures at Docker Shawn Axsom and Jean-Laurent de Morlhon collaborate on an article describing how they applied the principles of Team Topologies in stages over several years. It’s a great case study because they explain both what worked for them and where they went wrong along the way. They have problems that are relatable to anyone working in software: the struggle to monetize a product more effectively, and the challenge of restructuring siloed product teams.
Speak to you soon,
Jock
what to think about this week
Team Taxonomies for digital, data and technology organisations
Ambiguity about what a team is can create tensions, rework, and confusion and ultimately get in the way of the work.
To help, I’ve been developing a team taxonomy so that some of my clients and their teams can have better conversations about differences and similarities and hint at the expectations of interactions. This post shares these taxonomies in case they are useful to others, too.
Enabling teams are of equal importance to delivery teams
[Emily Webber]
Avoid mono-process (but embrace shared language)
Many companies treat all product work the same . The same stages and phases. The same approaches to budgeting, discovery, work decomposition, and collaboration. The same time-box lengths.
It’s tempting to use a mono-process. The argument goes something like: “If we can’t figure out how to work one way, how can we figure out how to work using many ways?” But what if trying to work one way is actually part of the problem?
Make the language unique to your company
[John Cutler / The Beautiful Mess]
Funding, planning, and context
In a lot of early-stage startups and companies experiencing rapid growth, there is basically only one context. Any variation is consumed by inertia and the “one thing”. But as these companies grow and mature, it becomes increasingly untenable to treat everything the same way.
What changes as companies grow and how to respond
[John Cutler / The Beautiful Mess]
Rebuilding and scaling product development at Docker using Team Topologies
Learn how Docker applied Team Topologies methodologies while renavigating and rescaling the industry standard for containerization.
The hard work after the organisational restructure
[Shawn Axsom & Jean-Laurent de Morlhon / Team Topologies]
recent posts
Cloud computing for non-technical product managers
To understand how cloud computing works, we’re going to start with the basic building blocks and work our way up.
And why is it a cloud anyway? (All is revealed)
[I Manage Products]
Navigating your product management career
Ross Webb and I have been chatting about product management career progression.
We cover topics including:
» Thinking of visibility as a strategic competency, not self-promotion
» Controlling your narrative through regular updates
» Building cross-organisational relationships deliberately
» Mapping your stakeholders’ preferred communication styles
A roundtable chat on moving into product leadership
[I Manage Products]
New technology alone is not the answer
New technology is not going to suddenly make all the challenges facing an organisation disappear overnight. Why? Because more often than not, those challenges are social not technological. Technology alone rarely solves ‘people problems’.
AI is neither a panacea nor a magic bullet just as digital wasn’t for UK gov
[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 unwanted upgrades that break things.