In the latest of our Prioritised AMAs, we were joined by Marty Cagan who took your questions on empowering teams, discovery challenges, Product Owners, transitioning from product role to a leadership role, and much more. If you missed it, you can watch the whole session again, or read on for a transcript* of selected questions and answers.
About Marty Cagan
Before founding the Silicon Valley Product Group to pursue his interests in helping others create successful products through his writing, speaking, coaching and advising, Marty was most recently Senior Vice-President of product and design for eBay, where he was responsible for defining products and services for the company’s global e-commerce trading site. Marty is the author of the book INSPIRED: How To Create Tech Products Customers Love.
Topics & Questions
Empowering Teams
- We’re big believers in the power of empowered teams but why is there still so much resistance to this new way of working?
- What motivated you to write Empowered?
- How can Product Managers help to move their product team to an empowered team? Is there more of a bottom-up approach?
- How do you actually organise teams in order to empower them?
- What are the key ways to influence leadership to empower their teams?
- What are the red flags that an organisation doesn’t want to be fixed?
Product Roles
- What advice do you have for those transitioning from a Product Manager role to a leadership role?
- What are your thoughts on separating the product management role from the product ownership role?
Process and Strategy
- What are your thoughts on creating a separate role or team to do discovery?
- What are your thoughts on combining internal and external use cases/products into a single product stack?
- How do I align my product teams to a problem to solve, or business outcome, rather than a product with a load of features?
Other
*Questions and answers have been edited for clarity
Empowering Teams
We’re big believers in the power of empowered teams but why is there still so much resistance to this new way of working?
I’d say the biggest reason is that so few people have had an opportunity to actually experience and see this way of working done well. The people that have, have spread all around the globe, but they’re still in the minority. When you talk to somebody who’s successful, most of the time they were lucky enough, at some point, to work for someone who really knew what they were doing, and cared enough about them to really spend the time coaching them and showing them. And so, that I think is the biggest issue. There’s also an anti-pattern that I think is getting more and more prevalent, and that is where there’s almost a natural selection that happens – a Darwinian process with startups.
You have to be doing some things well to get a certain degree of success. I mean it’s really hard to get the product/market fit if you’re not doing at least some core things well, already you’re in the minority if you get to that situation but then what happens is, you get some funding and the board’s like ‘okay, now you need to bring in a big name from a big company’, and those people almost never come from one of these good companies. And so I’ve seen this way too often where a company is good and then they devolve to not good.
And so there are a lot of forces acting against us but what’s really frustrating, and ironic to me, is that they are literally the most valuable companies in the world. So even if you just want to talk about the greed motive that alone I think should make people want to embrace more of best practices but you know people are complicated things and so that’s why that’s a super hard question.
What motivated you to write Empowered?
I love talking about how to solve hard problems and that’s what Inspired has been about (both editions). That tries to share the latest techniques but one of the things that really became clear with the new edition of Inspired, which spread further than before because I used a publisher, was that it spread to a lot of other companies. And one of the things that was so frustrating to me is that for most teams, it’s not that hard to actually apply the practices and the techniques and to do good work, but what I consistently heard from so many people is that they weren’t really allowed to do good work. They weren’t allowed to work that way. I have since named that and I refer to it now as ‘you’re in a feature team’. You’re already given the solutions on roadmaps and you’re given deadlines, and more fundamentally, the purpose of the team is different. The purpose of the team is to serve the business in a feature team rather than serve customers in ways that work for the business. So I realised that in many companies, they were not set up like an Amazon model, like a Slack model, like a Netflix model. They were set up in this other model and I needed some way to name that because frankly from 100,000 feet, they look the same, but they’re so different.
I realised that the problem is not the people, the problem is leadership. And so, I found myself spending time with these companies trying to get leaders to understand why they are actually the root of the issue here. And we need to get the leaders to provide the environment necessary for teams to be able to do good work. Their teams consistently are capable of that, but they are not allowed to do that, which of course is also a tremendous waste of human potential and that has always bothered me.
So, that’s why I wrote empowered – to help the leaders learn what they need to do, and I know sometimes I’m kind of rough on those leaders. I’m like ‘what are you doing you know you’re the blind leading the blind we have to fix this!’, but other times I’m like, ‘yeah, but you know, they never had an opportunity to learn this’. They worked at some bank for 10 years and they don’t know what this is and so, let’s try to help the leaders know that so that they can help their teams.
How can Product Managers help to move their product team to an empowered team? Is there more of a bottom-up approach?
You definitely can have an impact. It’s not impossible to cause the necessary changes from the bottom up. One of the companies I worked with that was a great example was the BBC. The leader is a political appointee so change is not going to happen from the top. I saw amazing product teams, but the senior leaders were supportive of these things.
It is hard though. Now here’s the thing, it’s a lot easier to do some of the things, but the ones that require the senior leadership error cover are the ones that are really hard. When companies talk about transforming what they don’t realise is that it’s not just product and engineering and design, it impacts finance, HR, sales and marketing, it impacts all the stakeholders. And so, without the error cover of senior leadership. That’s hard.
What I suggest though is to go to the leader or the most senior person you can, and say, how about we do a test. How about we do a little experiment as a company, just a little AB test? I usually try to understand who the senior executives really admire e.g Netflix, the BBC, Spotify and then suggest we try working more like them for a few months as an experiment. If it doesn’t work for us, there is very minimal risk involved. If it does work, great will spread through the company.
I find that very few leaders say no, they’re usually willing to at least try. Every company has some kind of digital transformation going on, so they will have already allocated some funds that way. They just mostly don’t know what to do with them.
How do you actually organise teams in order to empower them?
There are two parts to this. What we want is a team topology team. Topology refers to how you slice up the product into teams. If you want each team to be empowered, they have to have clear ownership. So how do you decide what team is going to own what? And that is one of the big responsibilities of the product leaders, especially the Head of Product and Head of Engineering. It’s also one of the most complicated questions, because there are so many different factors that we’re balancing – not the least of which empowerment on one side and architecture on another. My new book has a whole section dedicated to topology because I’ve always felt that needed more discussion. That’s so complicated for teams.
The other part of this is the organisational question. A product team squad is a flat structure. Nobody’s the boss of anybody. There’s normally a product manager, a product designer, engineers, maybe a user researcher and a data analyst. They are there to solve problems, cross functionally working together, but who manages these people? How does it look on an org chart? Probably 9 out of 10 product companies do it the same way – the functional org model. The premise is very simple, and it’s still the most prevalent because of this. Normally people want to work for somebody who can help them get better at their job. So a designer normally wants to work for a Head of Design, a Product Manager wants to work for a Head of Product Management and an engineer normally wants to work for an Engineering Manager. There is the one out of ten companies that use other models and in those models, they’ll separate the HR reporting manager from the person or people who are there to help you get better at your job.
Those are when I pick my battles. I don’t worry about that one because that would rarely make the difference. As long as everybody on the product team has at least one person that they know is assigned to help them get better at their job – that’s great!
What are the key ways to influence leadership to empower their teams?
There are different ways to influence them. One is basically the existential threat to the business, like an Amazon. The second one is, the board has to step in, and the third, and this is certainly the less threatening, is that the team volunteers to do an experiment and see how it works. That last one works the best to accommodate that technology adoption curve.
I used to answer that by saying there’s so many good books that make the case for empowered teams. And there are. But often the leaders read them and say they like it, but they don’t listen to any of it. So, to me that says, intellectually they know it’s important, but they don’t seem to be able to connect the dots and make those changes.
Once the leaders of product management in your organisation are at least supportive enough to let an experiment happen, then everything really depends on them. They are the ones that either make it happen, or don’t make it happen, even if you’ve got a supportive CEO. You see them hire some big consultancy like Bain or BCG or McKinsey and say help us with a transformation, and nothing happens. Because the CEO is willing to spend money, but they don’t have the leaders in place that really are going to make this work.
What are the red flags that an organisation doesn’t want to be fixed?
One of the things I learned a long time ago really helped me to understand more of what’s going on. You’ve probably heard of the technology adoption curve.
Geoffrey Moore talked about it years ago and I’ve used it in my work for years but it’s talking about customers. It’s talking about when we make changes to our product and how to be smart about that so that your customers don’t revolt against the change, but they can digest the change. This is very helpful and it really shows us why we need things like A/B tests. But one of the things I was realising was the same thing happens inside a company. The technology adoption curve exists inside a company.
You have people who love change and people who hate change and most people are pretty much in the middle. Knowing that really helps us – and by the way, this can be very counterintuitive. I have found more engineers that hate change, for example, and that is just crazy to me. Why would you become an engineer if you hate change? The technology changes every few months. A lot of executives hate change too. Change is evil. Change is dangerous. It’s the devil we know versus the devil we don’t, we hear this all the time.
So, understanding that that curve is in place is important because, of course, you can leverage that curve and you can go to the people that are anxious for change and want to try (they’re usually much more on board with trying this stuff out) and then that their success is what helps those middle groups, the early and late majority, get more comfortable with the necessary change.
Product Roles
What advice do you have for those transitioning from a Product Manager role to a leadership role?
The most fundamental thing I try when I coach people who are new to product leadership roles, is that the skills that got you that promotion are probably not the skills that you need to succeed going forward. Instead of thinking of the product as your product, you need to think of the team as your product. And that’s a very different day. You’re spending your day coaching, on strategy. You’re not spending your day doing discovery. You’re not spending your day talking to customers. It’s a very different life.
Of course, some people try it and they run back to the team because they miss it so much, especially engineers. I would just encourage you to really commit yourself to focusing on making your people as strong as possible. We say first focus on competence and then to reach for their potential. That is going to consume most of your time. And of course, selfishly speaking, I wrote a book for somebody exactly like you.
What are your thoughts on separating the product management role from the product ownership role?
That’s been a bad idea for 10 years and what this is a sign of is a much deeper issue. It’s a sign of a company not really understanding the role of their engineers. I will argue that the single most important thing when it comes to being a great product organisation, if you had to pick just one thing, is empowered engineers. And in that model, where the engineers are forced off in their silo and given a Product Owner, not a Product Manager, you have one Product Manager that focuses on the problem, and one Product Owner and the engineers that focus on the solution and divide and conquer. That is not the bad thing. But the bad thing about that is that it will almost certainly kill any chance you have for innovation. This is because innovation really happens when you knock down that wall. So the last thing we want to do is institutionalise this separation. That’s the worst thing you can do.
You’ve heard me say probably that if you’re just using your engineers to code you’re only getting about half their value. So, what I’m guessing is that in this company you have a very IT style, engineering model, that’s very old school. They may even use outsourcing for the engineers and this is not what we want. In fact, you’ll find that a smaller team of engineers that are empowered and really working with the Product Manager and the designer will get much more done, and they will have much more fun doing. You’re describing a mercenary model you’re describing, a very unhealthy environment and when I see that that’s a sign of much worse. Sorry!
Process and Strategy
What are your thoughts on creating a separate role or team to do discovery?
That is a really bad idea. But I want you to know why. The irony is, it’s not bad because I’m not suggesting you won’t come up with awesome stuff if you’ve got a separate discovery team versus delivery team. The issue is not really with the discovery, assuming you have an engineer there, a designer there, and you. The issue is it’s now different people that have to make this a reality and they were not there in the room, where it happened. They think you’re another group (there’s that silo thing coming in again) and so, it’s so we never want to separate the two activities of a product team – discovery and delivery.
That has been tried many many times, and if you want to know why corporate innovation labs are so consistently disappointing, this is why – because one group does the innovation and everybody else is, what, the implementation team? It’s not what we want. Every product team is responsible for discovery and delivery. Just like every product team is doing coding and QA testing. We have multiple activities going on, but we really never want to separate that. I’m thinking of writing an article about that because, for a long time, I never saw that, but there seems to be a little bit of a resurgence of that idea right now. And I’d like to try to nip it in the bud.
What are your thoughts on combining internal and external use cases/products into a single product stack?
Often as a business, you might have all these different solutions: some for internal stakeholders, some for customers, and it can be difficult to keep all of those running. That’s a classic problem. And so, from the product strategy point of view, businesses will often create a platform that lets them have the same foundation, with different experiences for different users.
That might be a brilliant strategy. It might be. I have seen it play out. I have seen that work where the company probably would have gone out of business if they didn’t do that. But it’s impossible to say whether it’s brilliant or futile without knowing enough about how distinct those experiences really need to be. This is normally what your Head of Product, Head of Technology, and Head of Design would figure out together. It’s probably a good move because not doing anything is probably going to be fatal over time.
How do I align my product teams to a problem to solve, or business outcome, rather than a product with a load of features?
You know, it did take me more than 400 pages in the new book to answer that question, it’s a very big question! But if I had to summarise – the main thing is product strategy (visit the SVPG blog for lots of articles on this). The point of product strategy is to figure out which problems we need to solve. Which ones, in order, to get the results we really care about. And so that’s why it’s so essential. That’s why most companies in the feature team model don’t even have that so they’re just trying to serve the business. But if you have empowered teams, you are trying to deliver on this strategy and the strategy tells us which problems need to be solved by the leaders. After the strategy, you have to assign those problems to specific teams, which is not really that hard – teams are responsible for certain areas, and so you assign the problems to the right teams. You just have to do it in a way that’s not disempowering – you want to give them the problem to solve.
Most people don’t use OKRs this way because they totally bastardised OKRs, but that’s what OKRs were actually created for so that you can assign a problem to solve, to a product team. So, what I would suggest, to answer that question specifically, is to search Google for ‘SVPG product strategy overview’ and ‘SVPG team objective overview’, that will take you to some articles that walk you through that process. Search Google now or see Recommended Resources below.
