← back to Blog
4
 min read
July 12, 2016

Product Owner, not Product Overlord

As a product owner you represent the customer, you are responsible for their experience of the product. From the messages the customer hears when word of your product first dances into their ears, to account setup, to the warm fuzzy feeling of the product doing just what they needed it to do – You’re responsible for all of it.

As a product owner you represent the customer, you are responsible for their experience of the product. From the messages the customer hears when word of your product first dances into their ears, to account setup, to the warm fuzzy feeling of the product doing just what they needed it to do – You’re responsible for all of it.

That’s a lot of responsibility! A lot of pressure to be the owner of an experience that gets built by a whole lot of people and is depended upon by a whole lot more.

Seems natural that the way to manage all that responsibility is to assert control… “From now on all product decisions go through the product owner! All releases will be vetted! Want to change the product? Talk to the P.O.! One owner to rule them all!”

After all, you’re responsible for the product not anybody else, right? It’s you that gets it in the neck when the customer experience sucks! This is you taking responsibility for that, riiight?

The Problem with asserting control

I’ve definitely been that guy – it’s hard not to be. After all, a tight grip on product changes certainly does the job of ensuring the product conforms to your vision, nothing’s getting out into the wild that doesn’t meet your express requirements.

However there is a cost to that control. Each control checkpoint you put in place drives a wedge between the other people who support, sell and build your product and their ability to affect and improve it. Each control checkpoint introduces a time delay between a good idea and that idea manifesting itself in the product. Each control checkpoint represents additional effort for everybody else that isn’t spent actually improving the product.

These are subtle side-effects at first but the bigger problem with total control is that it doesn’t scale. Pretty soon you notice that all your time is spent reviewing ideas, vetting releases, long email discussions in which possible changes are ruminated upon.

To manage this workload, further controls are implemented… “Minimum requirements for requests! Monthly approval meetings! Fewer, larger releases! No ready-made business case? Rejected! No clear problem statement? REJECTED! No technical implementation plan? REJECTED!”

Your ideas and improvements breeze through this gauntlet of checks and balances but everyone else has a different experience.
Pretty soon all those people who know the most about the product, having spent hours upon hours working on it and thinking about it start feeling pretty disconnected. If they want to use that knowledge to make an improvement they have to spend so much time preparing their case that it’s just not worth the hassle.

A vast resource of energy and ingenuity that was once pouring forth into your product has been shut down.

What’s the alternative?

It’s ok to have processes of review, it’s ok to have processes of approval if necessary. What’s important to recognise is that while they might benefit your personal ability to control the development of that product, there’s usually a price that is paid in the personal empowerment of others and in the rate at which product changes are delivered.

The problem is that a control checkpoint asks the question “Should this change go ahead at this stage or should it be stopped?”, when the answer, providing you’re surrounding yourself with the right people, is very rarely to stop anything. Why would you need to say no? These are smart people, they know their product, they work with it every day. If they say there’s a problem, there’s probably a problem.

You may have tweaks to make, you may decide there’s a better approach, you might need to offer a different perspective, you might need further evidence or have more urgent work but you’re rarely saying no. Why then implement an approach to product ownership that assumes that in at least 50% of cases the answer is ‘no’?

Be a champion of Product Development

Your job as product owner is to advocate for your vision amongst the team and then subordinate to the flow of good ideas turning into product improvements. You facilitate that flow and enhance the improvements with your knowledge of the customers, their experience and the unique perspective that knowledge brings. You contribution must be additive, not disruptive.

Be useful, be available and be someone that enhances delivery, rather than getting in the way of it.

Scheduling everything for everyone

Cronofy reviews sourced by G2