Updated February 4, 2020 with additional information.

One small change to how you do your job can make ALL the difference in the world to your success as a Product Owner.

If you’re a Product Owner, your biggest challenge in your daily job is how to get a product out the door to your customers without having to explain changed deadlines, why you cut scope at the last minute, and tell your team that they have to work longer hours to get it done right AND get it done now. It’s a thankless job.

The thing is, in a lot of cases, none of the shouting and hand wringing is even necessary. In fact, studies have shown time and time again that a significant portion of the functionality delivered in software products is rarely or even never used at all!

Why are we delivering stuff no one wants? Well, we wouldn’t, except that when we’re building the product, we’re being told that, yes, in fact, someone DOES want this feature. This, of course, begs the question: why are our users asking for things they don’t need? There are two answers to this. First, they actually believe they DO need it. If you’ve been managing product development for any time at all, the first lesson you already learned is that customers don’t know what they want until they have it in their hands. Second, customers are concerned that if they don’t put something in the plan NOW, they may never get it or they may have to pay exorbitant markups in the form of the dreaded CHANGE REQUEST in order to get it.

Agile Development helps us deal with over delivery of features through collaboration with the customer. Using frequent iterations of functionality that we can show to the customer, we get feedback. That feedback often suggests that there are features (or even pieces of features) that aren’t as important to do. This brings us to one of the most important mindset shifts that a good Product Owner must accomplish if they want to be successful:

WATERFALL is about completing the plan; AGILE is about maximizing the return on investment.

Read it again. A few times. Let it sink in.

Waterfall projects are managed with a focus on completing the plan. Since the plan is “right,” executing the plan will lead to a good result. However, this is apparently only true about 15% of the time. Remember this, in waterfall projects, the GOAL is to complete the plan.

Agile projects are managed with a focus on maximizing return on investment (increasing value while reducing overall work effort). By delivering working, shippable (aka “production quality”) features at the end of every value-generating iteration, agile projects allow us to stop whenever the value we’ve created over one or more iterations is sufficient for the user to be satisfied (or sufficient that someone will purchase the product). You want to be REALLY careful with value. I’ve heard it said, and I totally agree, that “if you aren’t just a little embarrassed by the missing functionality in a release, you probably wrote too much.”

Let me say that again…

If you aren’t just a little embarrassed by the missing functionality in a release, you probably wrote too much.

Getting new functionality in a product is, for the user, like unwrapping a birthday present. Sometimes it’s REALLY cool, and they use it for a few hours (or days or weeks), and then the coolness wears off and its just another toy in the box or trinket on the dresser.

Identifying the Value of a Product Backlog Item

Before you get too worried about the work it’ll take to put value on a product backlog item, let me give you some really simple approaches that will work.

First, simplify (my favorite Agile principle)! Just use HIGH and LOW. HIGH means that the product can’t be delivered without it. LOW is everything else.

Or, try a page from the history books. Have you ever heard of Kano valuation? It’s an oversimplification, but the Kano method suggests that you ask customers how they would feel (between “Very Dissatisfied” and “Very Satisfied”) if you delivered a feature and how they would feel, on the same scale, if you didn’t. The answers tend to deliver one of three states:

• Basic Expectation – functionality that customers are really negative about if you don’t do them, but neutral if you do. This is functionality that they simply expect. You will generally need to do these if you want customers to choose your product over someone else’s.
• Performance – functionality that customers are really negative about if you don’t do them AND really positive if you do. The more of these you can do, the more satisfaction you can create.
• Delighter – functionality that customers are neutral about if you don’t do it. These are the features that make your product more valuable to your customers than other competing products.
• Neutral – functionality that customers are neutral about whether or not you provide them. These are low value and really don’t matter. Don’t build them if you don’t have to.

Using the Kano model, you can identify value on every Product Backlog Item by simply labeling it as: Basic, Performance, Delighter, and Neutral. Then, order your Product Backlog appropriately.

See? Simple.

Protect Your Product Backlog From Waste

If you’re a Product Owner, be THRIFTY with your product backlog. Don’t release a product backlog item to your team unless you KNOW you need it and, even then, only ask your team to build pieces of features. Get feedback from the user and see how they feel about it. The feedback you get can keep you from building the wrong thing or even too much of the right thing.

Lastly, be really, really careful with the ordering of your product backlog. High business value items should rise to the top of the order while low business value items should sink to the bottom.

For more information, don’t hesitate to reach out to us!