Are Product Managers Ready for Value-Based Product Development?
Product development is maturing as a discipline. (Slowly.) We have a long way to go. And although there has been some progress, it is not a well understood or well-defined discipline. After all, what other major investments do organizations make without a clear process for ensuring the greatest chance of success?
What continues to concern me is that as a product building community we are not quite yet asking the right questions.
You will hear product managers talking about being "more strategic" and getting "out of the weeds." But that is really hard because of the day-to-day demands of fixing bugs and releasing something new. It is not unusual to get caught up in tactical discussions or find yourself stuck in micro decisions.
You want to prioritize what will bring the most value. But the process of taking a raw thought through to go-to-market release and beyond is not linear in our agile and agile-ambitious world. That means we can be more flexible, but it also allows for less emphasis on the difficult task of ruthless prioritization. And it leaves more space for chaos.
Product development is a multi-stage process. It starts with strategy and cycles through ideation, planning, building, and onward. And it also involves a lot of groups and people. The most effective product teams I meet are the ones who take a value-based approach. They estimate the value of proposed new functionality long before they ever start building it, continually refine their assessments through the roadmapping and development engine, and measure the actual worth to customers of what has ultimately been built and released.
Value is primarily determined by your strategy and the end user — whether what you have built serves the business and delivers what customers actually use and embrace.
But how exactly do you estimate the value of a specific feature? Is it how many people are willing to pay for it? Or maybe how many customers requested it? What about the benefit to whoever uses it? Does the functionality give your company a competitive advantage? Will investing in it now enable you to better scale the product over time? There is no one answer.
You need to be able to create the most value for the least effort. Your answer will be different than mine, because our strategies are different. Your goals and initiatives are unique to you. But in all cases it starts with knowing where you are headed and why and then assessing new concepts based on how best they can get you there. It ends with measuring whether you were right.
It is also possible to score the value of new concepts at every stage of the development process. We view this approach as the future of product development because it puts value creation at the center of the decision process and removes personal opinions. Here is how to get started:
Use a value-based scorecard
The advantage of value-based product development is that the value score is dynamic. You are accountable for estimating the value during idea management, refining it during roadmapping and tech scoping, and measuring it in production. To do so, you need to use a consistent scoring methodology through the entire process and update the metrics as you go from raw concept to detailed feature or user story.
We suggest starting with the following:
Population: How many people does it affect? This could be tallied from related customer support tickets or how many ideas have been submitted.
Need: How important is it for those who require it? How big of a challenge is the problem? There is value in solving extremely thorny problems. But there is also value in solving something minor but meaningful to everyday use of your product.
Strategy: Does it support overall company strategy? What about product goals and other KPIs? Evaluate how aligned you think it is with business needs.
Effort: What resources are needed? There are real costs to whatever you pursue. Think about this one holistically — there is more to launching a feature than engineering. Consider design and UX, marketing, and other groups that may need to weigh in, such as legal.
Confidence: What is the level of confidence in each score above? Give your best assessment, knowing it may change over time as you learn new information.
The challenge with assessing the effort to deliver something new is that it is hard to gauge the work until the item is fully defined. It also takes both product and engineering teams to work closely together. This is why we suggest updating the effort metric at least twice and then reviewing what it actually took when the work is fully complete.
You should consider using three checkpoints:
Initial value estimate: Early in the idea management process when the concept is raw and not refined
Detailed value estimate: After the effort has been further vetted during roadmap and scoping
Value analysis: What was actually achieved once it is in production and customers use it
It is also important to point out that you want to weight the different metrics based on your business, the product, and how important each one is to you. For example, you might have a well-established consumer entertainment application. In that scenario the alignment and population metrics might be much more important than need and urgency. For early-stage products with small customer bases, need and urgency might be the most important.
Realize the benefits
When you take a disciplined approach to estimating value, everyone is accountable for the result. Value becomes explicit — something tangible and testable. The team is forced to make substantive assessments and take ownership for the impact of what is built.
Success: Identify the best opportunities to build what will actually deliver value.
Discipline: Follow a standard methodology that all teams can leverage.
Transparency: Build clarity into the prioritization process (avoid answering to who yells loudest or one-off sales requests).
Accountability: The team is responsible for making the right tradeoffs and reporting on actual impact.
Learning: Understand the decision-making process and improve your ability to assess over time.
There is another critical component to value-based product development — value must be tracked in all of the tools that the team uses to manage and deliver work. If the thread unravels at any stage, the process is compromised.
Of course, value is not static. Organizations change, markets shift, products mature, and customer preferences will evolve. But if you can focus on optimizing the product development engine to reflect the most current value exchange — from release to release — the team will tune into what will drive more of it forward. Decisions are grounded in reality and the value you defined gets measured within the context of a product in motion.
There is no doubt that product development teams will increasingly be accountable for assessing the value of new concepts, prioritizing what is most important, and reporting back on the positive impact their hard work had. Value-based product development will be the key to focusing on achievement and not just activity.
How does your product team quantify value?
From ideation to launch, better product development happens with Aha! — try it free for 30 days.
