What happens when you have no product owner at all? How does a team know what features to develop in what order?
Several teams I know encountered this. They all had product managers. Most of them had Business Analysts. All of them had a technical manager who was willing to be their product owner, but they had no real product owner. They called themselves Scrum-but.
I used to think this was ok. I now think Scrum-but is a bad label.
That's because agile approaches need a responsible person who is part of the cross-functional technical team—but also understands product strategy—to rank the backlog so the team knows the order of the work. Without that person, the team does not know what to do.
So why is it so bad for a team to call itself Scrum-but? Because it's not Scrum-but. It's not Scrum at all. Your team is using an iterative and incremental approach, but it's not even close to Scrum. And it's definitely not an agile approach.
Review an Agile Approach
A product owner fulfills an essential function: to represent the customer or act as a customer surrogate. That means the product owner has to be part of the team and also part of other teams.
Every agile team needs that customer or customer surrogate function, to represent the customer in the various decisions.
That customer focus helps the team have better conversations about the product.
The manager I described above can help the team understand the requirements, but the manager is not the customer. That means the manager is not the person who can set the real acceptance criteria. The manager can see the demo, but the manager cannot say for sure that the team is developing the correct requirements in the correct order.
Product Leaders Help the Team Clarify When to Build, Not What
Agile approaches need that separation of what to build and when to build it.
If your team does not have access to a product leader, they do not know when to build something even if they (think) they know what to build.
That's not an agile approach. Instead, if you don't have a product owner/product leader, you might have an iterative and incremental approach—but it's not an agile approach.
In my little picture, the customer or responsible person explains the when-to-build decisions. (Ranking the work.) The team decides how to build to solve the problem.
When the team manager gets involved, that allows the “business” to be unaccountable for developing the system. How do you know what if you have a shippable product without the responsible person?
Product Development Requires Cross-Functional Collaboration
We have a pervasive problem in product development. Product development is a joint venture between the business people and the technical people. We need the legal, marketing, sales, and anyone else on the “business” side of the house to help us with the what-and-when to build decisions. That's why we need a responsible person. In Scrum, that person is called a product owner. And, we need a technical project team to deliver the value. As part of that agile approach, the team uses a demo to show business value every iteration.
When the business is unaccountable, the agile ecosystem breaks down. We no longer have ideas coming into that funnel, being evaluated by that responsible person. Sure that responsible person has a lot to do. And, that responsible person should develop product roadmaps and make the potential product direction transparent to the rest of the organization.
That way, the next iteration or two is clear for the team, and everyone can fight discuss the product direction. But when all the discussion is in the technical organization, those discussions tend not to happen. Or the discussions go off in a different direction than the product needs to go. And, that's a Very Bad Thing.
When those vigorous discussions don't occur, the technical team takes all the responsibility for the product: for what to build, when to build it, and for how to build it. And that means we have let the rest of the business abdicate all of their responsibility for their part of the product. That's not the partnership nor the transparency agility promises us.
On the Road to Agility
So, when you hear Scrum-but because you have no product owner, substitute “On the road to agile.” You're actually using an iterative and incremental approach, but not an agile approach.
Your organization has not made one of the necessary cultural changes for transitioning to agile—the separation of responsibility for how to build and what and when to build.
Teams need to know that they are implementing what the customers value. That's the role of a product leader. Not a technical manager, even as well-meaning as that manager might be. But a leader who shepherds the business value of the product for its customers.
Can you keep doing what you are doing? Sure, if it's working for you.
That's the million-dollar question: How is this working for you?
(If you would like more hints as to what else to do, consider these books:
- Manage It! Your Guide to Modern, Pragmatic Project Management
- Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver
- Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility
Don't worry if you can't change your culture. You have other options. Those other options will help you move closer to agile than trying Scrum-but and failing.)
(I updated this post in February 2025, to clarify my writing. The essence is the same from 2011.)
I agree with your point about the product owner being essential. But why, I have to ask, do so many supposedly knowledgeable people advocate this role being taken by a trained business analyst. Not the same thing at all!
Good post Johanna. This is definitely a difficult transition that I think often gets overlooked. The partnership is somewhat of a balancing act and I think the community could use some more ideas and maybe suggestions on how to foster and build that partnership effectively. I also think renewed focus on the goal of delivering “valuable software” not just “working software” would help a lot as well (putting the finishing touches on my own post on this subject).
I also agree that I don’t like the Scrum-but term. I talked about that at the end of my presentation at Agile2011, I would only call it Scrum-but if you know you aren’t following the rules of Scrum and have no plans to get there (don’t think the rules apply to you). If you don’t think Scrum is right for you, but you are doing other agile practices, it’s okay to just be agile and not Scrum, you don’t have to call it Scrum-but. If you are working on adopting Scrum, but just aren’t quite there yet…that’s fine too. As long as you recognize you aren’t there yet and have a plan to get there. I like the “On the road to agile”, sounds a little better than my suggestion in my presentation of “not-scrum-yet”!
I’ve seen another symptom of Product Owner malfunction….and wonder whether you’ve seen this and might comment on it. The Product owner is busy (way too busy) gathering and ordering requirements, prioritizing backlog items…but the technical and development team isn’t commenting on or providing the PO any meaningful feedback. Instead they are grumbling that the PO is clueless….
This doesn’t seem healthy to me either.
Whole team means that ideally the feedback goes both ways (between the dev team and the PO). I think that healthy discussion is important to a vibrant product. The builders and designers often have deep insights about the product, too…
Let’s focus on what we mean by ‘agile’. The goal is for the company, or at least a workgroup within the company, to be agile. It’s not about the software developers being agile. I think many people miss this part of the concept. Johanna gets it.
We need to find ways of working with business organizations in developing good software. This requires an understanding on our part that business people have work to do, goals to meet, issues to resolve, etc. Working on software development with us is not a core competency of theirs. We haven’t solved that part of the problem and until we do, true agility will elude us.
@Rebecca, I think I have seen what you are referring to as well. I just finished my post I mentioned earlier (http://www.developmentblock.com/2011/08/is-working-software-enough/) and I think it could be a symptom of the same problem…too much focus on velocity, not enough focus on value. Really it seems like we may have just moved the fence…it’s great we’ve pretty much gotten rid of the fence between development and testing, but now there still seems to be a fence between the product owner and the rest of the team in some cases.
Yeah we really need a product owner that have the time and capacity to handle that role. I am interested in your view of combining the product manager and the product owner into one person. I have done that for a while and strongly suspect that it is the product management part of me that is suffering.
@christian I am currently doing what you talk about (product manager being the product owner), and it works well, I am far enough from the team, and close enough to the customer to be the customer advocate.
As you hint, this definitely impairs my ability to be the fullest sense of the “Product Manager”. I suspect that the reason why we overload the Product Owner role as a part time responsibility to some other person in the organization is the perception that it is a role that has heavy responsibilities around the iteration end/new iteration planning, and is fallow in between.
I would argue that this is neither accurate, nor true. I am constantly fiddling with my backlog, adjusting priorities, applying learning from customer interactions, and accommodating difficulties in the development process (i.e. feature X hit a roadblock, and will require significant refactoring to achieve success. Let’s slide in some more stories to fill out an other area and reschedule the “hard” task as appropriate.).
In this sense, I believe that the goal is to have a product owner who is dedicated to the role, without outside responsibilities to defer their attention. Where I am at, they are experimenting with a dedicated role, called Technical Product Manager. Great idea, but, these appear to be staffed with people who have so little experience, and not enough authority to even visit the toilet without permission. I fear it doesn’t bode well to staff the role with puppets, either.
Loved the post!
I disagree… we live in a post modern world and I think there are many constructions of teams that achieve agility.
I think you are talking about a common problem in many businesses where you need someone to make certain types of decisions about what the product needs to do and tradeoffs of when those things get done. This is most often needed when the “development” people are not ‘experts’ in the domain and business of the product they are creating. They have no idea how to make the tradeoffs necessary or identify the key functionality needed. But this isn’t true of all teams!
Some groups of people don’t necessarily need this person/role, it’s quite possible for a group of people to develop a product making all the decisions themselves about what, when and then also how and to do all that in an agile manner.
There is no formula for agile. Agile is primarily a set of values and principles, if you can’t imagine multiple ways for people to organize themselves around these values and principles, then I say, *you* aren’t agile. You’ve become concrete and rigid about one mode of being agile. And as I said, we live in a post modern world, there are many modalities.
There’s value in discussing labels, roles, and specific techniques within one of those modalities, but don’t fall into the trap that that is the ‘one true way’
Hi,
I agree to the post above, the problem technical team encounters when there is no product owner or a product owner who dedicates very little time to the cross functional scrum team is the delivery ends up in chaos. The value of agile is truly acheived when the product owner reviews the sprint and makes his comments and prunes the product or release backlog accordingly and that results in continuous reprioritization according to the business needs and business value.when this continous pruning of product backlog does not happen the team loses direction and the purpose of delivering high business value is lost and often high priority items which is of high business value are ignored and worked very late in the release which endangers the release and loses value with the customer.
Pingback: Product Owner Addiction – itkanban
Pingback: Product owner links – Agile-School
Pingback: Product Owner Addiction - itkanban - itkanban
Pingback: Agile Faux-Pas: Lack of a Product Owner | Being Nimble