Product404 – Marty Cagan (Product Leadership & Teams, Product vs. Feature Teams, OKRs, and more)

Empowered teams vs feature teams

• Is there something PMs can do to push stakeholders towards empowered teams?
  • Most teams are feature teams, and doing almost no innovation
  • It’s not an easy change. Moving to agile doesn’t tackle any of this
  • Which is why companies get very little out of their digital transformation, because this is what they thought it meant
  • It needs at least three things:
  1. You need product leaders who know how to do this
     1. Without that the stakeholders won’t have trust in them to let them be fully empowered
  2. Redefine the relationship with the business
     1. Can just be the one team at first
     2. Once they are really ready to be fully empowered, they need to go to stakeholders and redefine what a product team means
     3. Feature teams are there to serve the business. Product teams are there to serve the customer, in ways which work for the business
     4. Moving from a subservient relationship with the business, to a partnership with the business
     5. This is only works if the product leaders step up and do their homework, and earn the trust of the leaders
     6. They must become experts on the customers, experts on how the company works – how does it sell, market, finance itself, etc.
  3. Educate the company on the role of technology
     1. The way people view technology is fueling the feature teams
     2. Do they view it as a necessary expense? Or view it as really what powers the business?
     3. This is the easiest thing to spot. Talk to any of the engineers, and you can tell how the business thinks of it.
• In a feature team, the engineers and designers rarely have any respect for the PMs. They don’t understand what the point of them is. They do a little bit of product management work, which anybody could do, and that’s it. They’re not adding the value.

Agile

• There are two issues here:
  1. There are way too many companies out there doing the rituals of agile and kanban, and still only releasing once every ten weeks. This is missing the most basic point of agile. The better companies are releasing at minimum every two weeks.
• There are other companies who are doing this well, and probably doing continuous delivery. But it doesn’t mean they are agile in spirit – because they are still feature teams, doing quarterly roadmaps.
  • Agile really means you’re able to spear out difficult problems – this is not talked about a lot.

Team topologies

• Book recommendation: Team Topologies – written by guys coming from the dev ops world.
• One of the big factors to look at when structuring a team is the skills you need.
• You want any product team to have clear ownership of something. If it’s a true startup, and the company is essentially one team, it’s easy. But once you get ten teams and beyond, then this becomes a much more complicated problem.
• Head of Product and Head of Engineering have to figure this out together.
• One of the issues we had before was lack of skills for native mobile apps – so that ended up being all in one team. But now it’s much less of a problem, so you can have those skills in any team.
• But now the same issue is happening with machine learning – they have very few people who know it, so this factors into the team topology decisions.
• Stable teams is key, so how do you do this when you have these scarce resources. You need to then create a team focused on that work – such as a machine learning team. That becomes like a platform team that others are dependent on.
• We’re trying to optimize for teams that work really well together, and trust each other. Once we get something that clicks, then we don’t change it.
• You don’t want to break up teams which work really well. Better to just give them more challenges, even if it means some time to learn and get up to speed together.

OKRs

• Have always been a fan of OKRs, but more recently have stopped advising companies to use them, because if teams are not empowered it doesn’t work.
• Realized I was in a bubble with the kind of companies I was working with – OKRs worked well there. But in most of the world you’re talking about feature teams. OKRs came from empowered teams.
• If you have roadmaps and OKRs, that doesn’t really make sense. Roadmaps mean feature teams. OKRs end up being just theatre and meaningless.
• If you move to empowered teams, then OKRs are a good recommendation. It’s the most popular way to give those teams work.

Roadmaps

• It’s fair enough for the board to want to know what teams are working on. But a roadmap is not a guarantee that those things are going to produce the results they’re looking for.
• They care about business results.
• So you want to show the problems the teams are working on and showing the progress.
• But lots of companies are addicted to roadmaps. And it’s just too easy to get stuck on feature teams and roadmaps.
• It’s a fundamental change that needs to happen. Focusing on outcomes rather than on features and roadmaps.
• Teams can move to an outcome based approach fairly easily – just do it for the next quarter or whatever cadence you normally have. What is harder is to train the rest of the company.
• What matters here is then the leaders, they are the ones who can make that happen, or not.

Product management trends in 2020

• Not seeing a lot of change honestly. There are just as many feature teams as ten years ago.
• There are companies out there running SAFe, which is the polar opposite of what is great – this model makes feature teams look like a beautiful destination.
• I can understand why leaders buy into this, it’s the same pitch as waterfall had. It’s just new buzzwords. They deserve what they get, because we’re talking about leaders which are really deficient. It’s natural selection in our industry.
• The empowered teams however are getting better and better. The pace of innovation has really increased.
• Lots of teams are just training on CSPO and thinking that’s it. In many ways teams have gotten worse than ten years ago.
• The CSPO aspects is the administrative part of the job only, it’s like 5% of the work.
• Encouraging companies to adopt APM type programs. An associate product manager is an entry level position, they are like apprenticeship programs. You need one very strong product leader who is willing to coach people. Doing this will raise the bar on product people.