Empowered Product Teams 💪💥

By Gordon Weir (implementer of significant change at Merrill Lynch, highly experienced software delivery expert, integration wizard and Agile fan. Gordon’s passion for creating learning organisations that thrive on change will be apparent in his upcoming ‘Product Discovery and Delivery in the Real World’ course)

I was just reading one of Kent McDonald’s excellent emails, titled “Delivery, feature and product teams inside organizations,” and it really got me thinking. He references a number of articles by Marty Cagan, another of my favorites in the product-management space. In particular this one about Product vs Feature teams.

It’s a subject close to my heart. I was just today talking to the COO/CFO at the company where I’m a product manager about team structure. His view was that teams should be split between function and component, this seems to be natural thinking in many ways, to try to figure out how to allocate cost and increase efficiency. My mind doesn’t work that way… anymore. It used to, as that is what we are taught about “efficiency”. Nowadays, the idea of people being aligned with either a component or function makes no sense to me. In this case, a “function” is an activity like analysis, testing, operations or development.

I’ll try to explain why, firstly by referencing this well-structured argument on Feature Teams, by Craig Larman. In short, he explains that it is a local optimization to have teams of specialists, be that application or process specialists. Creating an organization like that forces delivery to be waterfall with validation and integration only ever happening at the end. There is no way around this truth. He is absolutely right.

I’m not religious about feature teams, though I was for quite a few years. I would say I was a bigot I was so sure it was the right thing to do.

Secondly, I also agree with Marty’s view on empowered product teams but see no need to be religious about that either. Everyone seems to be missing the point.

The genesis of the feature-team model came from the 1986 HBR paper, the “New New Product Development Game”. Somehow the term “feature teams” has turned into a term to describe something that is not even close to the core principles and model described in the NNPDG paper. What Marty is arguing is that teams need to be truly empowered, and have the right skills and knowledge necessary to shape, define, design, and deliver products that solve their market problems. These people need autonomy and the trust of the company within which they operate. Exactly, Marty. He is absolutely right.

The research that underpinned the paper found that without true empowerment, multi learning and instability, true product innovation generally did not happen. This is a paper Craig makes you read before embarking on his course.

All I am saying is don’t give these things labels or try to argue that it is the result of new thinking or innovation. A different version, but the same underlying concept is described in Fred Brook’s awesome book, The Mythical Man Month. If you do anything at all in software and you have not read this book, then shame on you! I’m serious. Stop reading this and buy it.

Here’s the real rub: it completely depends on context, and what you hold dear in your software and teams — your principles. As Dan North said in a talk we did together: Context + Principles = Practices.

My addition to Dan’s equation is:

Context + Principles = Practices + Organization

Where Organization = people, skills, structure.

Let us think about it and to do that I’d like to use an example from my past. Context: say you’re building software and implementing change in a legacy mainframe. It needs to be done to enable new business products, or to support a new regulation. Our development principles were: high quality, reliability, and capacity.

We tried varying models of organization and practise to fit our context. It turned out Scrum and Feature teams did not work well — they actually made things worse. (I’ll be writing an article on this reality, soon.) What did work was using a Kanban model, a fairly large group of highly cross-functional and component skills and knowledge coupled with forming flexible teams depending on the work, which would return to the group when the work was done. A small change was implemented by a pair, larger more complex changes by a multi-skilled team. It was remarkable how well that worked!

Ultimately what I am saying is this: a Product Manager, Designer, and Engineering lead are a perfect combination for user-centric and highly innovative product companies. And, as Marty says, especially when they are highly skilled and experienced. But this construct is not perfect for other product contexts. What is important is empowerment, trust, safety, and alignment. And those things are really hard to get right.

Though empowerment, trust, safety and alignment might be hard to get right, Gordon’s two-day, London-based ‘Product Discovery and Delivery in the Real World’ course can help! Head to the course website to find out more.