It is called Product OWNER for a reason!
Executive Summary / TL;DR
When a product owner doesn’t own her product, fallout is to be expected.
Unfortunately, that is precisely what we see happening many places today. Ownership in name only. A hierarchy of power, where the product owner only can make decisions as long as they are the in line with what the product owner's superiors, often called product management, would have decided.
This article is about the downfall of the role of the product owner. I will try to explain what a product owner was meant to be, and then propose my theory, that popular “agile frameworks” which make it easy to fall back into old habits, which we all know die hard, are to be blamed.
Understanding this is a first step to being able to resolve some of the issues we see in many agile setups. Namely, a lack of ownership and motivation, not just by the product owner, but entire (Scrum) teams.
Intro
When LinkedIn notifies me that somebody in my network has accepted a new position, I often hit the “Say congrats” button. When the position is that of a product owner, as in the example below (Figure 1), I even used to feel a bit envious, as this is my favorite role.
However, lately, I have started to feel differently. I’ve become a bit of a skeptic regarding this role after having seen what has become of it. I no longer say congrats anymore. I quite often feel more like giving my condolences.
Why?
Because the product owner often isn’t the role anymore, which it was designed to be.
What a Product Owner should be
You can rent a car, you can lease it, or buy it. Depending on which of these options you go for, you’ll have more or less stake in the car and will, possibly, treat it accordingly.
It hurts coming too close to a curb and scratching your rim. Does it hurt more if you own the car rather than rent it? I think it does, for most of us. Especially when it is a big and anonymous agency you rented the car from. It probably is different if it is a car you borrowed from a good friend of yours. Because it is not just the rim you ruined, and thus might have to pay for, but also some trust in you as a good driver, that most likely got destroyed in the process. It is not just about money, is what I am trying to say.
The more is at stake, the more we care. The more focused and engaged we are.
Think of a product owner as the holder of a new Porsche 911, a car which she¹ had longed for since she got a driver’s license many years ago and which she finally (just about) could afford to buy. Put that picture in your head, when thinking of a product owner.
Or, if you don’t like the analogy with the car, think of a product owner as a parent. That will also do fine as an example of what a product owner should be.
A genuine product owner cares for her product like nobody else. She does everything in her power to ensure that it will become a success. She will spend 100% of her time on continuously nurturing and improving it and making other people see how great it is. She will protect it from evil, namely requirements which will not improve the product substantially.
A product owner is not merely administrating a product. She is dedicated to making the product prosper.
She will happily take advice from everybody outside — especially from people who have experience or hold insights and views that she might not have. Say other parents or other owners of the same car model. But nobody is telling her what to do, how and when. She is raising that child; she is owning that car; she is owning that product backlog.
While I am in no way saying one must do Scrum (one really doesn’t), I am using the terminology. I decided to write product owner with lower case letters to make this a little clearer. I know of development teams who don’t have one individual product owner, jet they do prioritize their work — they just do it together on almost a daily basis. They share the product owner role, so to speak. Anyhow, the Scrum Guide says it clearly:
“For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.”
Reality
Unfortunately, and only with few exceptions, this ownership is not what I see today when I speak to so-called product owners. What I see is something I probably would call product administrator.
Product administrators, who have very little power in shaping their product. Somebody else is calling the shots, deciding what to do and what not (though the latter doesn’t happen often enough, but that’s a different topic). Whatever the decision is, the product owner is supposed to execute on it, to use her wand and make it happen. Sometimes magic indeed is required.
I believe one reason for this is the “product management” function made popular by SAFe and other scaling frameworks. Irrespectively of what your favorite methodology might tell you and how well-meant it might have been at the time of writing, my experience is, that most organizations implement this as a hierarchy where product management does the high-level work and splits large chunks of work (often called features or initiatives) into smaller pieces (e.g., epics or large stories), prioritizes these and passes them on to the product owner. The product owner is now splitting these still rather big items into small pieces (should be stories, often really are tasks though, again, different topic) which then are spoon-fed to the developers.
The ownership of the product is not exclusively with the product owner anymore. Her scope of influence has been substantially reduced. Even though she still is called the owner of the product (which, of course, might be a sub-product or module — see my explanation as to what I mean by “product” in the Appendix), she doesn’t decide what will be built next. The product management (or product manager) is doing this, at a high level, anyway.
This incapacitation of the product owner removes her one degree further from the product and its users, and thus reduces engagement for both the product owner and the rest of “her” team.
It is like looking after somebody else’s child, even if it was the child of a dear friend. To get momentary peace, you will feed that child ice cream, and you will let it watch more TV than you would have let your own offspring because the long-term consequences aren't your problem.
A product owner should be spending all of her time on her product. There really shouldn’t be anybody in the universe understanding this product better than her.
This draws a somewhat evil picture of product management. Of course, we have to realize that product management themselves often are in a similar situation, namely are being put under pressure and told what to do (fixed scope, fixed time, fixed everything) and somehow make that happen, even if it is impossible.
Product Management
Is there no space for product management, then? Yes, there absolutely can be. But product management is there to support the product owner, when there are challenges, she can’t deal with herself (for instance obnoxious stakeholders who also believe they should decide on what needs to be done). But this should be pulled rather than pushed. The product owner pulls in product management or artifacts created by product management when needed.
This way, we can stay true to the core principle of the product owner owning the product and making all decisions relating to it. Which features or stories to implement and in which order.
The consequence is also, that the product owner speaks to the stakeholders. Often, I hear the argument that this has become too much work for the product owner and then product management is seen as a way to scale. But it isn’t really, or at best it is a suboptimal way to scale because everybody — not just the product owner — is removed one degree further away from the users. There are many better ways on how to offload work from the product owner. One is by letting the developers decide more. Give them proper user stories (aka requirements) rather than tasks or detailed specifications. Have the rest of the team help the product owner refine the backlog (refinement is more than just a meeting now and then). Pull in stakeholders and have them talk directly to developers (a good product owner is not the bottleneck through which all communication has to go through).
And if it still is too much work to be done by the team, descale by slicing your product into two (or more) smaller sub-products (which isn’t always easy, but it is worth your while), then identify a product owner for each of these sub-products. We call this vertical slicing, rather than the horizontal slicing of product management (speaking to the stakeholders) and product owner (concentrating on the developers).
By redefining product management, we can bring developers at least one step closer to the users and thus reduce the Chinese whisper effect and increase engagement.
How does this work in practice?
Think of it as a buffet.
The Buffet
Product managements delivery to the product owner should really be more in the form of a buffet of high-level stuff the product owner and the developers could work on. If this high-level buffet is prioritized by product management, even better. However, ultimately is up to the product owner to pull any of those items of the product management buffet, and even items that aren’t really on the product management’s radar. Remember, nobody understands the product better than the product owner!
Also, the product owner only pulls as much work as the capacity of the team allows her to.
It is a rather simple change, but also a hard one to do, as one must overcome company culture. A culture where perceived control by product management (deciding what to do) will have to be relinquished to the product owners.
Yet, it is what needs to be done. That’s what leadership is about. Helping everybody understand what the goal is, then supporting people getting there, not directing or (micro) managing them.
It’ll make the product owner's job tougher, but also substantially more engaging. Which is why I love that role. Product management will also be able to deliver a lot more value by not wasting time on doing things the product owner was hired to do, but instead being able to focus on overall alignment with organizational goals and strategy. They don’t even have to know about all the features.
The Ask
Let’s stick to the simple principle, that the product owner decides on everything around their product or products. Let’s give them the trust they require to do their job. Let’s support them if they need our help, rather than tell them how to do their job.
You’ll be amazed how well this can work.
Appendix
What is a Product?
Let me try to explain what I mean by a product.
Saab Gripen Example
Take the Saab Gripen. It clearly is a product. A product that can be sliced into many sub-products or modules. Each of these can be developed independently with few dependencies to other modules, if the slicing is done well and the interfaces between the modules are clearly defined. These modules can often again be split into even smaller modules.
The landing gear could be considered such a sub-product. It could again be split up into further modules like the retraction mechanism, shock absorbers, and wheels. Wheels consist of tires and brakes (yet another slicing), etc.
The team owning the brakes can experiment with new materials, sizes, technologies. As long as the interface doesn’t change, they can basically do whatever they like and deliver new, improved brakes every couple of weeks. It doesn’t even have to be on the same cadence as other teams. If they need the interface to change, they will, of course, have to go and talk to the relevant team(s). Say they want to try a new material which would be lighter and cheaper but also heats up more. They would then have to go to the team of teams who is responsible for the landing gear as a whole and discuss possibilities on how to improve airflow to the disc brakes such that they get more cooling.
As a matter of fact, this is mostly how the Saab Gripen is being developed. The interested individual can go and read this article “Owning the Sky with Agile” (PDF).
Spotify Example
The whole Spotify experience could be considered the product, of which the web player is just one sub-product (the Android and iOS apps could be considered other sub-products). The web player (open.spotify.com) is further split into modules — in other words not just one but multiple teams, or a team of teams, are working on it at any one time. One of these team, for instance, will own the playlists. They improve it constantly. They add new ways of creating, finding and sharing playlists. Another team is owning the actual music player. Of course, these two teams would have to agree on an interface between these respective modules, but as long as this interface remains stable, they can develop their module independently. They don’t even have to be on the same cadence. Obviously, they will go to the other team and talk to them if they need the interface to change to implement a particular new feature, which can’t be done with the currently agreed interface.
Modules vs. Products
I’ve used different words like product, sub-product or module. Mainly for readability. To me, they are all products.
The art is to break down products into smaller products.
A product doesn’t have to be hard- or software. It could also be a process. Like the lending process of a bank. This again could be split up into modules — for instance, different steps in the lending workflow. All that is needed (ok, now I make it sound a bit too easy, it obviously isn’t) are clear interfaces between these different modules. Then, multiple teams can work rather independently on their module(s) / product(s).
Always …
Any feedback is welcome. I enjoy discussing stuff like this. I enjoy being challenged. I enjoy learning about and experiencing new perspectives.
[1] … or he. I am not too fond of spending a lot of energy on the gender discussion, so that’s why I decided to address the product owner as a female. It could just as well have been a male, of course.
