A common piece of guidance that product teams often get from agile coaches when it comes time to prioritization is that they should “prioritize by value”.
Wherever I think of that guidance, I think back to a scene from Seinfeld. Just substitute “value” for “write off”:
Jerry: You don’t even know what value is.
Kramer: Do you?
Jerry: No I don’t.
Kramer: But they do… And they are the ones prioritizing by value.
Value is subjective. It’s in the beholder’s eye. It’s quite common to use the word, but most people are hard-pressed to explain exactly what they mean when they say it.
And yet you want your customers to get value out of using your product.
What is value-based product development?
Value-based product development is an approach to providing a solution to your customers that they will pay for and that helps your business reach its goals.
The label value-based comes from a comparison to the value-based pricing strategy. When you follow this strategy, you set your prices based on the value your customers perceive from the product rather than how much it costs to produce it.
The goal of value-based pricing is to find the optimal balance of profit for your business, and the value your customers and suppliers receive from the solution.
Value-based product development extends that basis for decision-making to the entire process. Effectively, you want your product team to make decisions that result in the most value for your customers with the least cost for your organization.
How value-based product development works
So how can you rely on a subjective concept like “value” to make crucial product decisions? To start off with, don’t try to quantify value.
Instead, determine what your customers want to accomplish when using your product. You can think of this as a job to be done.
Next, figure out some way to measure whether your customers get value from your product. You can use these product metrics to help you make value-based decisions.
Finally, use value to filter your customer feedback to determine what you will or will not do.
Let’s explore each of these ideas.
Understand jobs to be done to define value
In order to use value-based decisions, you kinda need to know what you mean when you say “value.” That’s difficult when it’s such a subjective concept.
The easiest way to get a usable understanding of what value means is to build a strong understanding of what your customers hope to accomplish with your product.
The extent to which your product helps your customers accomplish their job to be done determines the value they perceive from your product. It also influences the amount they’re willing to pay for your solution, hence the relationship with the value-based pricing strategy.
Once you understand your customer’s job to be done, you have the information you need to craft a viable solution. A solution that has the functionality to help them accomplish what they want to without extraneous features that get in their way.
That provides value to your customers, and it also provides value for your organization because you don’t build or have to maintain features that your customers won’t use, anyway.
Use product metrics to guide value-based decisions
In order to make value-based decisions, the natural inclination is to measure value. When you’re working on discrete backlog items, that often results in trying to determine how much value each backlog item provides.
To paraphrase Han Solo in The Force Awakens “That’s not how value works.”
Customers get value from a product when they use it to solve a particular problem. It’s usually a combination of features and capabilities that helps a customer solve problems so it can be difficult, if not impossible, to attribute a value measure to a single feature.
Yet, you want a straightforward way to know when you’re successful.
Instead of trying to assign value to every specific feature, establish product metrics such as user adoption, percentage of users who take a particular action, or churn that tell you whether your product resonates with your customers. Chances are if your product resonates with your customers, they’re getting value from using it.
Keep in mind the impact of software development work is not direct or continuous. Sure, there are occasionally specific changes that hit home with your customers. More often than not, it’s a collection of changes over time that help your customers solve a problem.
You can say “this change will give us 5 points of value and that change will produce 8 points of value.” Decide which changes provide a viable solution, put them in place, and then measure the result.
Use value to filter ideas and feedback
If you define value as helping your customer accomplish their job to be done, you have a handy decision filter to evaluate new product ideas and feedback you receive.
When you evaluate product ideas or feature requests, ask yourself “will this help our customers [X]?” Where [X] is your customer’s job to be done. If the answer is yes, then look into the idea further.
If the answer is no, throw the idea away.
Let’s say you’re working on a tool that uses generative AI to help writers get past writer’s block. A decision filter you may use to evaluate product ideas might be:
Will this help writers get over their fear of the blank page?
So why is this approach better than trying to assign a value score to every item in your backlog?
A filter ensures that you explicitly decide not to do things.
Using a value score doesn’t guarantee that you’re doing the right things. Sure, items that have a higher value score should correspond to the right things, but they don’t indicate that.
They are relative scores that imply one backlog item is more valuable than another one. The tricky bit is whether that value is determined based on getting closer to the desired outcome or whether they were determined in isolation.
The mere act of trying to determine a value score is a waste in terms of the time you spend assigning value scores to the backlog items.
Also, when you have a list of things to do, the implied definition of success becomes finishing the entire list or a certain number of items. That almost guarantees you’ll end up delivering things you don’t need.
You can still have a scope, but you define scope as reaching an outcome, rather than finishing a certain number of backlog items. You can also still have time and budget constraints, but how you manage the changes.
So instead of “How can we get 200 Value Points done within those 6 weeks?” the conversation becomes “we have 6 weeks available to us. What are the right things to work on during those six weeks to get us where we need to be?”
Value-based product development helps you meet the demands of the market
The value-based decision provides a framework for understanding what your customers are trying to accomplish and using that knowledge to decide what you will and will not deliver.
When your organization figures out how to use value-based product development, you increase your chances of delivering a product that meets the demands of your market.
That’s because “the market” is the people you’re trying to solve. Their “demands” are a solution or solutions that help them accomplish something – usually solving some crucial problem they face.
And they don’t want a solution that costs too much and is too difficult to use. Value-based product development helps you here too because it keeps you focused on adding only the features to your product that is essential to helping your customers accomplish their job to be done. Nothing more. Nothing less.
