Product managers v. product owners

Let’s talk about this question of product manager versus product owner in a little more detail. We’ll look at the focal points between the two of them because sometimes they’re the same, sometimes they’re not. And we’ll look at how to evaluate with the development team, the agile team is getting what it needs, from whoever is doing that role. And then we’ll look at whether that should be you or not you depending on your particular circumstances. These are the specific jobs and in agile team roles scrum master or increasingly people use the term agile coach. It’s a little more appropriate, because you’re coaching and helping people self organize, not mastering them and telling them what to do.

This maps most generally to the traditional or general role of project manager.

Though as we’ll discuss, this is it’s quite different, the way the project management works in this sense. And the product owner is often, or is most associated, with the traditional role of product manager, and then you have the rest of the development team. So this is people, engineers, software developers, testers, people in operations

or interdisciplinary folks doing DevOps type work on the infrastructure. And so this is the composition of the team that you’re presumably working with, more or less, if you’re doing agile. Now let’s sort of texture out the differences between product manager and product owner in a little more detail. I’m going to draw on the scaled agile framework, which isn’t something that I necessarily particularly subscribe to, but they do have some interesting ideas about how to organize some of these things. We’ll talk about product manager versus product owner, whoop.

And we’ll talk about it in a few different dimensions. So the focus, Of the product manager is more market-facing at least in that capacity, or we use the term business-facing, and more customer-facing. And the product owner is more development or engineering-facing.

Working with the agile team, the development team. And the product manager, what do they create regarding the activities of the development team? Well, the product manager creates the focus for the product and its direction.

Sometimes, encapsulated in this sort of vague idea of a roadmap. And the basic idea there is you’re driving that intersection of desirability, feasibility and viability are setting the direction for the product. You are its sort of manager in the more general sense and in the product owner

creates a story backlog for each agile iteration. So they prep those user stories, if these two people are separate, probably together. And then they have a backlog of user stories that is the input to the iteration that is the agile iteration one to five weeks. And that’s what these guys or women, as the case may be, create. The time horizon for the two are the product manager in the scaled agile framework they call these programming commits so these are sort of larger blocks of time. They depend on the type of product and company, but roughly on the order of maybe a quarter, so three months or something like that.

Where as the horizon here is an individual agile iteration we’ll say one to five weeks, hopefully, I recommend generally the lower end of that. And what do these guys review, what is their primary thing that they look at? Well, the product manager looks at these sort of finished features which might be the sort of an epic story, or sort of an amalgam of a bunch of different stories, it’s a sort of discrete functional unit whereas the product owner is looking at the execution of individual user stories.

Now this distinction is although tricky, I think that the real point is that I think that user stories are the best thing for everybody to focus on, even perhaps customers if they’re doing product with you. But I think that the real point here is they’re looking at these user stories as they’re kind of put together and aggregated, they’re not in this product owner role. This is a little bit about the difference between the one versus the other, in this framework can you do both jobs? You can, but traditionally the product owner is there all the time, focusing on just doing this job with the engineering team.

So if part of your job is to create sales forecasts and come up with pricing plans and things like that, you may find it difficult to do all of that, you may have to make some hard choices. But let’s talk a little bit about how is the product owner role performing, how do we know if things are okay or not, because that’s probably the first question asked. Well, are there a lot of surprises when the product is shown to internal stakeholders or released to the market, or people are like, my God, this is just not what I expected. That’s a bad sign. Are there a lot of questions from development?

And probably more importantly, are those fundamental questions of why the heck are we building this and who’s going to use this? Or are they they kind of tactical questions that a well briefed team that’s getting good stories and good story workshops is going to ask. Just tactical execution details, which one is it? That matters, the one to signal that, the product owner role needs more kind of gas or juice to bring in better narrative and a better explanation of what the team’s trying to achieve. The design process, is it robust or not robust? Or you building, for instance, interactive prototypes, before you go and put things into code?

This matters somewhat, because a robust design process will somewhat front-load the questions that the dev team is going to have. Not completely, and you should always encourage those questions. They are so much more valuable to answer them now verses have them crop up later. But a robust design process is something that will help you have a little more control over when and how the inputs and the questions get answered. And then the second question is, should this be you? Or should you work with somebody else to perform this product owner role? Well, the first question I would ask is, how are things going?

If really bad, you may need to step in and do this, or look at other sort of more fundamental alternatives. And what are the options, is there someone on the team that has an interest, or someone who could get on the team who has interest in doing this, and wants to do it? And where is this going to get the most value from you? And this is sort of the hard question because if you’re with a development team and you do feel you need to be there. You’re answering a lot of questions, there’s a lot of work to be done to perform this role. Which is likely and which is fine but you’re struggling to provide good answers.

You desperately need to go out and spend more time with customers to understand what’s really valuable for them cause you’re releasing things and you’re engagement isn’t good. Well then you may need to make some hard decisions about just starting to put something in place for yourself, for the team, for the moment, and then making time to go out and see those customers. And then finally can you work in small batches so you can kind of experiment with different approaches? Those are some things that I would step through.

I don’t think there’s a single right answer to this question and the circumstances of your company are going to be different and part of the product manager’s job is to make the hard choices about where to invest their time and where to focus the team. But I think this will give you a little bit more of a structured view of how to think through that. And how to evaluate and monitor the decisions you make so that you’re constantly thinking about what’s the right thing for the team and the overall picture for the product and the company.