Contents

I am a HUGE fan of Marty Cagan. It is in that spirit that I take one of his articles and modify it to meet my needs.

You should read all of his books, and the article in which this note is a modified replica of!

—-

Product vs Delivery Teams

The most common in terms of sheer numbers are not really product teams at all, they are delivery teams. Also referred to as “dev teams” or “scrum teams” or “engineering teams” and if your company is running something like SAFe, then unfortunately this is you. In this situation, there are some number of developers, and a product owner. The product owner in this model is what I refer to as a “backlog administrator.” Someone does need to do this administrative work, but this is all about delivering output, and it’s really very little to do with what I am concerned about in terms of the need for true, consistent innovation on behalf of our customers. This model is really just re-packaged waterfall, and is not used at true tech product companies. So let’s get that out of the way.

Product Teams vs Feature Teams

Today as an industry we refer to both of the other types of teams as “product teams” or “squads.” But as you’ll see, while they look similar at a superficial level, they are dramatically different.

Product Team = cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.

The purpose of a product team in this sense is to solve problems in ways our customers love, yet work for our business.

As much as I might wish otherwise, I know that only a small percentage of teams out there are product teams in this sense.

Much more often than not, the teams are not empowered at all. In contrast, they are there to serve the business.

These are feature teams. These teams are all about output. Features, and occasionally projects. Usually provided to the team in the form of a prioritized list that is called the roadmap.

—-

Recall that in product there are always four ingredients that lead to value:

Adoptability (how might we continuously deliver value that people will buy and/or try?)
Usability (how might we continuously deliver value that users figure out how to, and then continuously use?)
Possibility (how might we be on the forefront of what is possible and utilize the time, skills, and technology we have such that we are continuously learning, innovating, and delivering value along the way?)
Viability (how might we continuously deliver value that is first and foremost outcomes based, JTBD oriented, and will work for the various dimensions of our business?)

In an empowered product team, the product manager is explicitly responsible for ensuring business viability; the growth product manager is responsible for ensuring adaptability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring possibility.

The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all.

Product Team vs Feature Team Indicators

Are you provided roadmaps with prioritized features and dates, or are you assigned problems to solve with business outcomes?
Do you have a team of missionaries or mercenaries?
What is the level of accountability?

While product and feature teams look very similar on the surface, they are dramatically different in how they operate, the level of empowerment and accountability.

Just those responsibilities?

Product management is about more than just viability, design is about much more than just usability, and engineering is about much more than possibility, and growth product management is about more than just adoptability.

If something ships, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet we should be able to go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong.

Similarly, if the product ships and performance is terrible you can bet we should be able to go directly to the tech lead with the same question.

Similarly, if something ships and the analytics show that it’s either not being bought or not being used you can bet we should be able to go directly to the growth product manager.

And most frequently of all, if something ships and no one was operationally ready, no one can state the why, no one knows how we have and will continue to measure results, or it turns out that it violates some business constraint like compliance or privacy, you can bet we should be able to go directly to the product manager with that question.

So it’s critical on an empowered product team that we have the skills we need, and that these people are accountable for their work.

All that said, and back to the heart of the question, the way we come up with good solutions is with an intense give and take.

Designers often have insights based on deep understanding of our users and their behaviors that lead us in a different direction in terms of the problem we’re solving, or our approach to the problem. These insights will often have big impact on value, and indirect impacts on things like performance.

Similarly, strong engineers have deep insights into the enabling technology that often leads us to entirely different solutions to the problems we were assigned, often much better than anything the product manager, the designer, the growth product manager, or especially the customer could have imagined.

If I had to pick the one thing I love the most about the feeling of working in a truly empowered product team, it is the form of magic that happens when you have people that are a) motivated and b) skilled in their respective discipline – product, growth, design, and engineering – and they sit around a prototype or watch a user interact with our prototype, and the engineer points out new possibilities, and the designer points out different potential experiences, the growth expert weighs in with the sales or financial implications, and the product manager ensures we are focused on client outcomes or operations related implications, and after exploring a bunch of approaches, they find one that actually works – it’s adoptable, it’s usable, it’s possible, it’s viable… which is our definition of valuable.

So hopefully this makes clear that these are two different but related points. Yes, the designer is responsible for ensuring a usable product; and yes, the engineer is responsible for ensuring a possible product; but coming up with that product requires their full range of skills.

– Can you summarize the differences between delivery, feature and product teams?

Delivery teams are not cross-functional (basically just developers plus a backlog administrator product owner), they are not focused on outcome (they are all about output), and they are not empowered (they are there to code and ship).

Feature teams usually are cross-functional (at least some form of designer and some form of product manager), but they are still all about output and not empowered.

Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.

Why did you write this revision of a great article AR3?

I cannot stress this enough, I (AR3) am a major fan of Marty Cagan, and this note is essentially a replica of his article. I wrote this because I needed something to share with my current team at CareerPlug about the model we are going to try.

Why am I differentiating from Marty’s way?

In our distribution model, adoption is so hard I needed an entire seat focused on this
- I believe that Product should be at the table when it comes to revenue impact, and as such we’ve organized Product Marketing to live within the Product Squads. In order to not have title confusion we call folks that would be Product Marketers at many organizations, Growth Product Managers.
In our business, the operational needs are so intense I needed an entire seat focused on this
- We have a parent-child network style model and have been in business for 17 years so our customer diversity and operational complexity is off the charts.
I wanted something focused more on the team/squad and not as much focused on the PM
I love the risks, but disagree with the way they are framed. I prefer to frame them in the”how might we” light as opposed to the “how do we avoid” light. I also define value as customer results, so I needed to rework the equation a bit; Adoptability Usability Possibility * Viability = Value

Quads may be my official recommended org design for what I’m calling the Continuous Value Delivery form of the Product Operating Model.