Being a valuable Product Owner

In the Product Owner training, we learn that the Product Owner is in charge of the Backlog, and therefore controls "What" is being done "When". With this, the Product Owner leads Product Value - and: success.

Those are the basics.

Many times, you see "Fake Product Owners" in corporations. Retrained team leaders, project managers or even analysts.

They are handed requirements or, even worse, detailed specifications by other departments and are then expected to utilize the team to turn these into Working Software.

Let me be blunt here: If you have a good team, you don't need them. Because they can't do the job they've been set to.

It is not a Product Owner's job to play "Chinese Whispers" between business and the development team.

Understand the Customer

If you want to be a good Product owner, you must understand your customer. Please ask yourself a few questions about the product:

• Do you know any real customer and what they think?
• Do you really know what your customers are and will be doing with the product?
• Do you have facts, rather than opinions, regarding what the customer pays money for?
• Can you correlate features with relevant business figures? (more on this later)

A witty side reminder to PO's working in corporations: Unless you are working on an in-house product which is exclusively being utilized by staff of your company, your customers are not internal stakeholders, such as your Division Head, your Marketing Department, your Legal Department or your CxO.

If you do not have any access to real users and their needs, you are, at best, a proxy. Most likely, you'll be doing a political project where success is not determined by hard cash - which means, you won't be able to contribute anything relevant.

 

Determine Priority

Your team may be doing a tremendous job, but they are not omnipotent. They can't do everything at the same time, and they probably also shouldn't.

You probably heard the proverb, "Get your priorities straight".

Let me tell you: It's wrong. You don't have priorities. You have exactly one priority. Your first priority is "to satisfy the customer through early and continuous delivery of valuable software".

To do this successfully, you must be able to determine what satisfies the customer most, so that you can set your team to work on the one thing which provides the most value to the product.

Weeding the Backlog

You have a backlog rather than a requirement list mainly for one reason: You already know that the amount of requested work is higher than the amount of available resources.

Don't even bother with anything that can not be delivered in the near future, also don't even bother with anything that won't satisfy your customers.

 

You must say "No" to anything which you do not consider sufficiently valuable. Don't beat around the bush. Let people know "No means no." Please refer to "Weeding the Backlog" to see one approach to obtain a thinner backlog.

If you can not say "No" to anything put on your desk, you will be doing a miserable job. 

Learning how to say "No" so that people will not be personally offended with you is an art, however.

Slicing to the Bone

I love hate it when people approach me with "world hunger type" feature requests. Yeah, I understand that you want a widget that has thingummywat to do oomlah. But Rome wasn't built in a day.

Stakeholders love to push Epic work into your team, because they feel that they get something significant. Let me tell you what: Don't bother unless they can cut it down.

It isn't sufficient to merely throw a feature over the fence, groom it, develop it. That's not your job. Your job is to extract the Minimum Viable Product from each and every feature!

If you can't fit it into a single sprint, you are probably not working on an MVP.

To give you a specific example of what I mean: I can produce a skeleton CRM System with a single team in one sprint. But it won't do much. It will just tell me (and my customers) what must be done next to bring the most value.

Cut out everything that's not vital. Maybe that means cutting out the entire backend - maybe it means cutting out the entire frontend. But you must get useful, working software fast.

Keep the time!

Based on your customer, the priority and with minimal slices, be prepared to deliver what the customer wants, when the customer wants - with high quality. The only thing you must never promise is that the customer gets the entire scope they might have imagines.

Never, ever, postpone deadlines to stuff in more features.

I recently saw from a DevBlog for a new video game: "We could have made the skill wheel in 3D, but it would have cost too much development time." - throw out the chaff, never get yourself into a mess where you have to stand empty-handed before your customer because your scope didn't fit the time.

Your customers will be forgiving on the scope, but not on not having anything on the agreed date. Deliver. On time. 

Increment afterwards as long as there is value to harvest.

Summary

You are responsible to deliver a satisfying, valuable product in short, frequent intervals. If you do this well, the customers will be praising your product and your team - and you.

If you don't do this well, you'll quickly become everyone's punching bag.

Being a good Product Owner requires a solid understanding of your product, your customers and then making tough choices and "having balls". 

You won't please everyone. If your managers or internal stakeholders are an impediment to success, you need to bulldozer your way. 

If you can't or don't dare do that, Product Owner may not be the right job for you.