Scrum's "Product Owner" Problem

Restoring a Proper Balance Between Product and Engineering

Image by Mediamodifier from Pixabay

In Scrum, Product Owners have sole authority over the Product Backlog; they control what to build and when to build it. Engineers are merely ticket-takers, implementing one instruction after another.

This arrangement is flawed—it’s upside down and inside out. In a dynamic, fast-paced world, successful teams make decisions in real time. Front-line workers get quick results from tight feedback loops, reassess, and make their next move. It is inefficient for them to look to “experts” or “leaders” for their next step. It leaves them powerless while competitors race by.

Product teams provide input to engineering, but their input is among many. There is much to consider when building software: target hardware, hardware cost and availability, available technology, pre-built software solutions, legacy code bases, competitor solutions, off-shore collaborations, as well as product team recommendations; and that’s just the tip of the iceberg.

Like a soldier dropped in the middle of enemy territory, engineers have to assess their circumstances constantly, take into account all available information, and make real-time decisions. Product Owners might be on the radio giving intel, but engineers need to make decisions about the immediate path forward. The alternative would be disastrous.

As a result, the ideal role for a Product Owner is providing data and assessment—not direction.

Perhaps the easiest way to understand this relationship is by looking at the types of questions engineers direct to their Product Owners. The Scrum Guide would have you believe there are only two appropriate questions to ask a Product Owner: “What features should I build?” and “In what order?” The answers to those questions take the form of a prioritized backlog. It’s not common for engineers to seek more data than that. This reveals a dysfunction.

In reality, there are many questions that engineers should be asking the Product Owner (notably, the two questions that Scrum prescribes are not among them). Here are some examples:

• Who are our customers?

• What problems do they have?

• How are we trying to help them?

• Who are our competitors? What do their solutions look like?

• Who are our customer’s competitors? What do their solutions look like?

• When can I meet some potential customers?

The answers to these questions provide engineers with important data to factor into the next round of engineering experiments (which sometimes require writing code). But it is only a part of the full constellation of data they are evaluating. The process looks something like this:

1. Evaluate Data

2. Perform an Experiment by Writing Next Batch of Software

3. Update the Data with Experiment Results

4. Return to #1

And when it comes to collecting results, instead of asking if features in the backlog are complete, we should be asking:

• Will this solution work?

• What should I improve?

• What should I keep the same?

• Can a potential customer try it out?

Then we go back to work. Until, finally, we get a ‘yes’ to the most important question Product Owners can answer:

• Is this solution something we can ship?

Do you see the difference? “What should I do next?” vs. “What information can you give me to help me make an informed decision?”

Is it too audacious to suggest that engineers should be making product decisions? I don’t think so. I tend to agree with Erik Dietrich, who argues in his book Developer Hegemony: The Future of Labor, that Software Engineers market themselves incorrectly. While we usually see ourselves as software construction workers, we are really software architects. We architect solutions that automate people’s work—usually with computers. As Dietrich puts it, we are efficiencers:

I now owe you a definition of this term “efficiencer.” In short, it’s the name describing the service that we as software developers provide. “Software developer” is descriptive, but it suffers the fate of being entirely too procedural and focused on details. We perpetuate this problem by being, ourselves, far too focused on details. The value proposition that we offer the world, notwithstanding what we write on our resumes, is not “five years of Python, three years of JavaScript, etc., etc., etc.” The value proposition that we offer has deep roots in efficiency.

…Our value proposition is that we provide expertise in efficiency. “I help you have more time and money.” Or, at the risk of sounding a tad overly dramatic, “I help raise the standard of living.” Sounds pompous, but that’s what we do—eliminate jobs of drudgery and create ones of knowledge work.¹

Improving efficiency is our specialty. We use and write software every day to do just that. It’s our raison d'être. But if we merely take directions from product departments and hammer them out, we’ll never leverage that specialty for the customer’s benefit.

An apt analogy for the proper relationship between product and engineering is a restaurant.

Engineers are the chefs in the back. They prepare the menu. They’ve been preparing meals for a long time, and they’re good at; they know what’s in season and where to get the freshest ingredients; they know what people are making at other restaurants; they have ideas of their own they are eager to try.

Product Owners are more like the Maitre d'. They handle reception and guest seating. They visit with everyone as they come in, ask lots of questions, and address any special concerns. From time to time, when a chef come out to interact with customers directly, the Maitre d’ will help the interaction to go smoothly. The Maitre d' may even knock on the kitchen door occasionally and whisper helpful information to the chefs. But for the most part, they stay out of the kitchen and let the chefs provide the meals. If they interfere too much, the food will be delayed and poorly prepared.

In Scrum, the Product Owners have taken up a permanent residence in the kitchen—they draft the menus (can you say Product Backlog?), tell the chefs what ingredients to buy, what dishes to prepare, in what order.

Under this arrangement, engineers might be able to get something out to the guest’s tables, after considerable time and effort, but it won’t be anything the guests tell their friends about. It won’t delight them.

So, while product teams have an invaluable role to play and will certainly provide input that finds its way directly to the final product, they shouldn’t define the product and give orders to engineering to bring it to pass. It’s time they steered clear of the kitchen and gave the chefs space to do their best work.

1. Developer Hegemony: The Future of Labor by Erik Dietrich: page 311-313