Killing thy Product Owner
"Why are you doing this to me?" - said the weeping Product Owner while shackled around the chains of a virtual conference where the hysteria of a development team built a mountain of expectations that crumpled on the shoulders of an individual who merely wished for happiness. Isn't this real? Of course you won't agree to this now, may be towards the end (of this post, your life's too long).
The intention of this post is not to demean the profession of Product Ownership and I'm probably definitely not saying that killing them is a solution; in fact, the opposite. I wish to highlight the dysfunctions around this (cool) profession and make ourselves realise how development teams may hijack the Product Owner's responsibilities which may end up killing the credibility and the value chain driven by Product Ownership.
So here are my top three picks of dysfunctions in teams with regards to Product Ownership:
1. Killing creativity and innovation
We all do this; let's say that your Product Owner asked for a feature to authenticate users before editing their profile. Put yourself in their shoes and write a user-story for this feature (take a break from reading this post and continue when you're ready with your user-story). Of course the user-story that you have written is your expectation from the Product Owner for this user-story. Here are two variations:
Which one of these closely resembles the user-story that you've written? Which one of these are you expecting from your Product Owner? If the answer of these questions point to the user-story on the right, you've just killed thy Product Owner.
A user-story is a beautiful tool for capturing product requirements; but it's not a requirements document. A user-story is a promise for a conversation. It provides a platform where the whole team comes together and has a discussion around the why, what, and how of a requirement to be developed. The confirmation of this conversation may end up with the details that you see on the right; but that isn't the place to begin with. The one on the left is my expectation from a Product Owner, just like a matchstick that can light a candle to see numerous possibilities in the dark.
Even for this trivial example, authentication can be performed in a number of ways - something that you know, something that you have, something that you are. We have a team of smart and intelligent business analysts, quality analysts, programmers, user experience designers, and many more; why should we restrict this thinking process to a single individual?
Now it's not to say that the expectations of the development team is what drives the Product Owners to drift towards this dysfunction; sometimes the Product Owner may just be controlling everything since they're accountable for the success of their product. If you have such a Product Owner, kill them (or educate them, that'll probably be better than going to jail, but whichever is easier, your choice).
2. Business Analyst as a Product Owner
Ratatouille is a movie that can explain this dysfunction the best - "anyone can cook". When we go hunting (read recruiting) for a Product Owner, the best suitable candidate we look for is a person who represents the Product Owner's views to the team in their absence. That is of course the Business Analyst a.k.a. our Proxy Product Owner, isn't it? So a suitable candidate for the role of a Product Owner must be the Business Analyst (that almost seems like a promotion). By that analogy, the advisor to the President of the United States must be the Proxy President (with a proxy button on their table), isn't it?
I spoke about Product Owner being the person accountable for the success of the product and there's a difference between accountability & responsibility. A Product Owner is responsible for maximizing the value of the product and managing the product backlog. They may do this with the help of the development team, however, they're accountable for the results. If this is difficult to digest, consider this - an employee at Uber reported irresponsibility of another employee and we held the CEO accountable for it.
If we consider Business Analysts to be our Proxy Product Owner then that is what they are, a Proxy. The Product Owner's accountability is not transferable. Can't we just make the Business Analyst accountable, that would make them the Product Owner, isn't it? Sure, "anyone can cook", not the same as "everyone must cook". Product Owners are responsible to manage scope, manage cost, manage time, manage return on investments, manage plans, manage external dependencies, manage missions & goals, manage … I hope I managed to convey the information. These are not typical responsibilities of a Business Analyst.
Just like Product Ownership, Business Analysis is a cool profession, not a hierarchy of superiority. Quoting Ratatouille again, "not everyone can be an artist, but an artist can come from anywhere". If the Product Owner and Business Analyst wish to perform each others responsibilities, the associated accountability can't be left out. Don't kill thy Business Analyst as well.
3. Making Stakeholders Happy
That is the ultimate goal; or is it? Managing stakeholders' needs is a conflict, hence we'll take help of Thomas-Kilmann Instrument (TKI) to understand this dysfunction. If you wish to split $10 between two stakeholders, the most logical way to do that would be $5 each. This is what TKI would term as a compromise. Would this make both the stakeholders happy? In the absence of their context, yes; let's add a context.
Let's say, stakeholder s1 is a tea drinker and stakeholder s2 prefers coffee. Tea costs $4 and coffee costs $6. Who's happy now? Understanding the context by being highly assertive and highly co-operative is what TKI terms as collaboration. Not every stakeholder is equal, not every stakeholder is the end user, and every stakeholder's requirement is the most important for them; but the Product Owner is responsible for stakeholder management and accountable for maximising the value of the product.
So next time when you're in a room full of stakeholders fighting with your Product Owner for their functionality to go in first, time-box that discussion to understand their context, then request them to leave (force is not acceptable but may be necessary), and give control to your Product Owner for ordering the release plan. You may influence their decision but don't kill thy Product Owner just because every stakeholder wants to see themselves win. The music is more important than the instrument.
Conclusion
These are just my top observations; feel free to add more in the comments below. I have seen this happen with multiple Product Owners on multiple engagements and it's really difficult to identify dysfunctions when you're a part of it. The least we can do is flag these dysfunctions when possible and hope it's much before we have killed...