The Pressure Owner

Since one frequent source of problems for a software developing organization is when conflicting goals are communicated from the business to the developers; one success factor, common for many different agile methods, is the introduction of a Product Owner.

The PO is a person with basically two responsibilities:

1. Keeping all wishes from the business sorted so that you always can see what is more important than anything else.
2. Being able to clarify exactly what those wishes - requirements - are.

In other words, the developers say: "Dear PO, you should represent the whole business to us, now go and figure out how!"

It is no wonder that Product Owner burn-out is an expensive and painful reality.

The problem is that the role is very clearly defined, but the tools for fulfilling the role is almost non-existent. As a PO, you know from the Scrum Guide that you should come to the Sprint Planning with a well-groomed backlog, but you get no advice on how to put a backlog together in the first place.

The PO has no well defined method or process to stick to. That creates an awful amount of stress.

From my experience in acting as a PO in both large and small organizations, and coaching groups of PO:s in very large organizations, I have seen that one key is the ability to translate what works in Scrum, into something that does it for PO-work.

The thing behind sprints for instance, is the introduction of a common inspect and adapt loop between the askers and the doers, at regular intervals. Points in time where everybody knows it is time for some serious collaboration across organizational borders. As a PO, you need to identify the need for other cross-organizational inspect-and-adapt-loops in your neighbourhood, and then make them happen.

I will follow up with some examples of how that can be done, you could even call it a concrete method for how PO-work could be done, no matter what method the developers use.

But for now: realize that the PO-stress is real, common, and just a consequence of the developers asking the business a very normal question: Exactly what should be done now? You need to bring that question out to the business in a structured way, collect the answers, and go back to the developers. I will soon show you how.