Marty Cagan: evaluation

Transcript context

…Yeah. Well, it's not hard to tell fortunately. I mean, if you've seen both, it's not hard to tell. In a feature team, basically you are handed a typical roadmap. Almost everybody, even though I wish this wasn't the case, almost everybody to have the same thing, that it's a prioritized list of features and projects. So some stakeholders got together, usually quarterly, and they say, "Look, to run our part of the business, we need these features. It's not really complicated. We need these features." And so they're giving you these features. Now realize, these features are possible solutions. So you are being asked to do a little design and a lot of coding and then some QA and then deploy it. And more generally, you're there to serve the business. Now compare that to a real product team. In a real product team, first of all, instead of being given a roadmap of prioritized features, they're given problems to solve. So it might be a customer problem. It could be a company problem, it's all fair, but they're problems to solve. And the team is then given the skills so that they can come up with the best solution to that problem. I mean, that's the Netflix principle is push the decisions down to the people that actually have the knowledge to best solve the problem. The engineers are working with the enabling technology every single day, the product teams are working with the users and customers every single week. So of course, those are the ones that are closest to this, those are the ones you want to push the decision down to. Another difference is when you're given a problem to solve, that's not output, that's outcome, so you either solve it or you don't. As you probably know, most good teams today are doing continuous deployment, continuous delivery. They're releasing many times a day. Who cares if you make another release? If it doesn't actually solve the problem, it's nothing to brag about. It's nothing to celebrate. So in a real product team, you celebrate when you actually solve the problem, when you accomplish those results. That's why we say product teams are about outcomes, they're not about output. So feature teams and product teams, superficially, they're both squads, but they are very, very different. Now it's worth double clicking on the product manager role because fundamentally, the designer and the engineering role are not hugely different. We're asking the designer and the engineers to step up and care just as much about what you build is how you build, but they're using the skills that you learned in university or wherever. On the other hand, in a feature team, the product manager is basically there to herd the cats to get it, and that's non-trivial, but they need to get stuff organized. They need to get stuff gathered. These requirements, you need to document them in whatever tool you're using, in Jira or something, and then you need to get it to sprint planning. You need to make sure it comes out. That's herding cats. se requirements, you need to document them in whatever tool you're using, in Jira or something, and then you need to get it to sprint planning. You need to make sure it comes out. That's herding cats. It's essentially a project management role. But on an empowered product team, where you're trying to come up with a solution that solves the problem you've been assigned, that's much harder because that means we have to discover a solution that's valuable, usable, feasible, viable. Now while the engineers definitely own feasible, and the designer definitely owns usable, valuable and viable, which are two of the hardest things to do, that's the product manager, and those are pretty big shoes to fill. Those are hard. That takes skill, it takes knowledge. That's why we say in order to be a product manager on a real product team, you've got to do your homework. You touched on this idea that people mention this way working sounds like a dreamland to folks that haven't experienced it. And I asked folks on Twitter what questions to ask you, and that came up a couple times, is people are like, "I read your stuff." And I'm like, "Does this actually exist anywhere? I've never experienced this way of working," just to make people feel like this is possible. One, is there companies that are good examples of this way of working that you like to describe? And then two, just to reaffirm, this is possible, this happens at companies out there, correct?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.