#delivery #team - 6 mins read

The feature team fallacy

A lot of literature would have you believe that there are two distinct, almost polar types of product teams:

• Empowered teams (aka outcome teams, missionary teams, empowered product teams)
• Feature teams (aka delivery teams, mercenary teams, dev teams)

On the whole, I’ve found this perceived mutual exclusivity somewhat lacking throughout my career. I’ve only once worked somewhere that I felt really qualified as the former, and oddly enough that was the one that had a twelve month feature roadmap outlined from the kick-off. All the others have been closer to the classical feature team, but it is far from a binary affair.

To help me better understand this, I created the table below. It's a "product team maturity scale" of sorts, with 28 characteristics listed out in the first column, and the second and third column providing the polar extremes of each characteristic. For example, I suspect that a feature team would be more likely to be measured on velocity, whereas an empowered team would be more likely to be measured on impact.

As is almost always the case in product development though, the reality is significantly murkier. One team in particular I worked in whilst at the BBC comes to mind here. Around half of the 28 items above would have fallen in line with the empowered team definition, a handful would have been closer to the feature team end of the spectrum, and the rest would have landed somewhere in the middle. Is this team a feature team, or an empowered product team? What makes it one or the other?

I had a recent conversation with a colleague who worked in a team that ticked almost all the empowered team boxes, but they had absolutely no user invovlement and never experimented. Any discovery they undertook tended to be technical discovery. How do we classify this team?

Teresa Torres’ 2023 Continuous Discovery Habits survey findings corroborate this ambiguity.

Just under a half of respondents advised that their teams were tasked with achieving outcomes AND delivering specific features. Question: Is your team currently being asked to deliver outcomes or outputs?

• 48.3% - A mix of both-we have metrics that we are trying to impact and we are asked to delver specific features
• 29.7% - Outputs-we are asked to deliver specific features
• 20.8% - Outcomes-we are asked to drive metrics, not to deliver specific features
• 1.2% - I'm not sure

The cadence of user contact varies wildly. Question: When was the last time you talked to a customer?

• 45.3% - In the past week
• 26.3% - In the past month
• 11.5% - In the past quarter
• 9.1% - More than a quarter ago
• 7.8% - Never

Teams rarely experiment continuously. Question: How many assumption tests or product experiments did your team run last week?

• 70.6% - Zero
• 26.6% - 1-3
• 2.1% - 4-6
• 0.7% - 7 or more

Pivoting away from something based on feedback is unlikely. Question: When was the last time your team discarded a solution that your team was considering?

• 29.7% - In the past month
• 22.7% - In the past quarter
• 17.3% - Never
• 16.8% - In the past week
• 13.4% - More than a quarter ago

Iteration is less prominent that you might think. Question: When was the last time iterated on a solution based on something you learned from an assumption test or product experiment?

• 28.1% - In the past month
• 22.7% - Never
• 18.5% - In the past quarter
• 16.6% - In the past week
• 14.1% - More than a quarter ago

But here’s the thing: Yes, the highest performing teams tend to tip the scales to the right, but you are much, much more likely to find yourself in a team towards the left. And that’s okay.

Working in teams closer to the right-hand side that have all of these things in place may mean that you have more day-to-day impact on your product, your users, and therefore business objectives, but there is much more headroom for improvement in teams closer to the left, particularly if you consider the human element of your team, so personal development, autonomy, quality, mastery, leadership, continuous improvement, and so on.

There is just as much enjoyment, satisfaction and personal development to be had in teams to the left as there is in teams to the right. Perhaps more so.

It’s one thing to spend a few weeks delivering a new capability to users that moves the user and the business forward 0.1%. It’s a whole other thing to spend a few months enabling a team to have the focus and headspace to do the one thing that they think is the most important, or putting the mindset and framework in place to actually measure impact and react accordingly.

I’ve recently started assessing where each team I join initially lands on the above chart, and document the constraints I find as and when I butt up against them (spoiler: there are always some).

Just the act of doing this can be hugely beneficial, even if nothing changes (although it inevitably does). There’s something cathartic in jotting this down. It helps some people let go if they can see and empathise with a constraint. It helps others redouble their efforts if they realise that the team is behind the curve in one area and it is wholly within their gift to move towards the right.

Reassessing once a quarter and documenting progress is where it really comes into its own. I can’t think of a single team I’ve worked in where the team hasn’t moved on after a few months. Individually, these smaller steps often go unacknowledged. They don’t make it on to weeknotes. They don’t make it onto roadmap playbacks. They don’t get a nod in the quarterly all-hands. But they do matter. And they really start to stack up over time.

Visualising the state of play, and noting the sliders moving from left to right over time can be incredibly motivating for a team. It can also be eye-opening for leadership and others outside the team. As I’ve mentioned, these items can often go unnoticed—particularly in organisations that obsess over velocity and output—but there is something powerful about seeing a team improve of its own volition. Often the penny can drop with others who consider applying this approach to their own team, or to their own development, or ask themselves how they can help the team on this journey of collective improvement.

Five key take-aways to close with:

1️⃣ We don’t have to classify teams. A team doesn’t need to be labelled a feature team or an empowered product team. The lines are much blurrier than this in reality.

2️⃣ Every team operates within constraints. Legal constraints. Industry-specific constraints. Most predominantly, organisational and people-related constraints. This is okay, and very much a part of product development.

3️⃣ Teams are constantly evolving and adapting. This is a good and natural thing.

4️⃣ We can (and in my opinion should) strive to improve the teams in which we work, but we cannot expect to achieve this overnight. It takes a long time, and in some instances we’ll never achieve this. To go one further, this may not even be desirable in some circumstances.

5️⃣ Measure your progress. Record your constraints. Celebrate your wins. It’s eye-opening. It’s incredibly satisfying, rewarding, and motivational. And it’s infectious.

And some further reading on the feature teams vs empowered teams dichotomy:

• Product vs. Feature Teams by Marty Cagan
• Missionaries vs Mercenaries by Marty Cagan
• Delivery, Feature, and Product Teams by Aakash Gupta

Written by Dave Baines

Co-founder, Product Lead

03 May 2023

link