In Delivery teams, we typically have a PO acting as a “backlog administrator” and a Scrum team delivering outputs. I don’t think this model adds confusion to the debate, as I hope we all understand that what this person is doing on a daily basis is far away from the job of a true product manager in an empowered product team. To be more precise, and quoting Marty Cagan again:
“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.”
However, Feature Teams and Project Teams are similar in appearance to Empowered Product Teams. Yet, very distinct. Some common characteristics of Feature Teams are:
- The Product Manager, or Product Owner, is really just a “facilitator”. A pretty different role than a Product Manager in an Empowered Product Team.
- Executives or middle managers are responsible for the value and viability of the products or features that are being built, rather than the team.
- Discovery is pretty much just design and usability testing, and it’s implemented as a project phase rather than being a continuous team habit.
- The team is mainly composed of mercenaries. Feature teams usually don’t feel accountable for the outcomes and there’s no or very little involvement from the engineering team.
Project teams are a variation of feature teams described above but have the additional problem of ownership. The mercenary element can be quite high in feature teams. But here, it just skyrockets… It’s not a team creating and owning something together (missionaries), it’s a group of individuals executing requirements temporarily (mercenaries). When the project is “closed”, the output is shipped, the real outcomes unknown, and some of the project team members go on and execute some other project.
On the other hand, Empowered Product Teams work truly collaboratively in discovery and delivery, where:
“The Product Manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that works for all of us.”
Most “product teams” out there are feature and project teams, which serve as fuel for the next mad pattern. Let me spoil it for you:
Because they’re teams of this nature, a classic example is to have a Product Manager working with a designer in a “project-based discovery” model. This means they define what to build, write the requirements, and — to quote most PM job descriptions out there — “translate the user needs to the engineering team”. Sadly, these needs do need to be “translated” in detail to them because they were not involved in the discovery at all.
Paraphrasing Teresa Torres on this, the challenge we run into with project-based discovery is that sometimes these feature teams are moving really fast and they’re just dumping requirements to the engineering team, constantly increasing work-in-progress. Other times, we see the opposite happening, where discovery is taking a long time, and the engineering team is just sitting and waiting for more work.
Because of this, conventional organizations start wondering:
“Hmm… this is not working very well. We either need more discovery teams or more delivery teams. Let’s have the Product Managers dealing with discovery and business with the Designers, and then a Product Owner managing the backlog and leading the engineering team!”
At this point, we run into the PM plus PO madness.
Madness #2: The PM plus PO
For feature factories, it may be convenient to add Product Owners as a separate position to work with Product Managers. It’s an excuse to separate “the business person” from “the person that talks with the developers and manages the backlog”.
This may be seen as beneficial but if your goal is to bring through innovation to serve your customers in ways that work for your business, it’s just ridiculous — to put it bluntly. It doesn’t work. Melissa Perri “has never seen it working”, Petra Wille shares the same experience, and I could go on referencing similar opinions.
Because we’re introducing even more handovers and have the engineering teams even more distant, this model leads to many systemic challenges: from slow and deficient innovation, tragic technical debts, wasted engineering talent and creativity, to sky-high turnover of great product people that won’t put up with this. To quote Marty Cagan,
“I absolutely believe it’s critical to be a single person rather than two.”
Note: If you’re doing SAFe, a scaled “agile” framework, you’ll be familiar with this institutionalized double role madness of PM plus PO. Cagan has previously described the framework as “deadly to innovation” and I couldn’t agree more. Jonathan Smart also mentions: “SAFe clearly can’t, and I don’t believe is intended to, optimize for outcomes across a diverse, heterogeneous, complex adaptive system.”
Madness #3: The PO as a PM overnight
I hope it’s somewhat clear by now that if your goal is to build products that customers love within sustainably profitable and innovative business models, having both a PO and PM in the same team is — as a rule of thumb — madness.
Yet, another mad scenario is having people who’ve never worked in Product Management but have a Product Owner certification (CSPO), doing the job of a Product Manager overnight — without any further training or understanding what’s expected of them. This happens especially when the organization is already infected with madness #1 and thinks the roles are “fairly similar”. Most “digital transformations” these days involve establishing Product Manager titles so, unfortunately, this is more common than you might think. Yet, and again, as Cagan puts it:
“The result of this is that countless people with just product owner training — but the product manager title or responsibilities — to put it bluntly, have absolutely no clue what they’re doing.”
If you want to move into an empowered product team model with true Product Managers, and you currently operate on a delivery/feature/project team model with Product Owners, make sure you train your POs in Product Management if you want them to succeed in a very different role. And, of course, make sure you empower them too.