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 andalso 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 knowwhen to build something even if they (think) they knowwhat 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 beunaccountable 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 canfight 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.)