Stakeholder value as a compass for product development (Part 1)
Good requirements are important for successful product development - nothing new so far. But what use are perfect requirements if they are based on incorrect or incomplete assumptions? This is frighteningly often the case in practice. Especially when developing innovative products, we often have a false understanding of the stakeholder value of the solution at the beginning. And even if we don't, the value changes over time, because customer requirements, markets and technologies continue to develop.
We are quite good at tracking value in development. But this is of little use if there is no clear understanding of what „value“ actually means at the stage before that. That's why we not only have to record and keep the stakeholder value up to date, but also keep an eye on it as a compass during development.
This article is about how we can arrive at an understanding of values that can be taken up and used effectively by product development. A future part 2 will describe how this can be used in the product.
Measuring value means understanding the problem
Value is always created when a stakeholder gets a better solution to a problem that is relevant to them. This sounds banal, but is rarely clearly defined in practice. So before we talk about functions, features or design, we need to understand which Problem we actually solve and how strong the Pain of this problem. Here are two examples:
- For a while now, the automotive industry has been trying to focus less on the product „car“ and more on the problem of „mobility“.“
- A luxury watch seems to solve the problem of „showing time“, but the more important problem to solve is „showing status“.“
The following list will help you to avoid overlooking any important problems. Problems can fall into one of the following categories:
- Functional: something cannot be done
- Performance: it is too slow, weak or inefficient
- Quality: it fails, deteriorates or frustrates
- Economical: it is too expensive
- Compliance: it violates rules or involves risks
- Emotional: it feels unpleasant or uninspiring
- Ecological: it harms sustainability or reputation
value is dynamic and must be measured and updated regularly!
Even if we have understood the stakeholder value and manifested it in good requirements at the start of development, two problems arise:
- The value changes, for example through new customer information or market trends.
- The value flow is not observed during development, i.e. how activities along the development process actually affect customer benefit.
These gaps cost speed and efficiency. Product Velocity, on the other hand, requires that stakeholder value is continuously measured and tracked, just as we continuously monitor quality or performance in DevOps.
OKRs as a bridge between strategy and development
A proven tool for this connection are Objectives & Key Results (OKRs). They combine strategic goals („Objective“) with concrete, measurable results („Key Results“).
OKRs are often used for the scalable management of companies. Prominent organizations that use OKRs are Google and Intel. These companies use OKRs to firmly anchor business objectives in the organization. Departments, such as product development, then have specific key results that contribute to achieving the goals.
Each key result has a clear owner. This creates Autonomy with alignmentTeams can act independently without losing the common direction. At the same time, transparency is created as to which activities actually deliver value. Product development thus has a tool to ensure that activities are aligned with business objectives.
OKRs are therefore a powerful tool for alignment with internal requirements.
Value Framework as a bridge between development, marketing and sales
A value framework, on the other hand, creates alignment with product-specific requirements, which is particularly important for collaboration with marketing and sales.
In many companies, development, marketing and sales work in poorly connected silos, which causes frictional losses. However, modern sales frameworks such as Command of the Message manage to establish a common thread from stakeholder problem to feature:
The individual boxes have the following meaning
- Before scenarios: Describe the initial situation and the existing problems or bottlenecks from a stakeholder perspective.
- Negative consequences: Show what effects the unresolved problem has, such as costs, frustration or inefficiency.
- After scenarios: Describe what the situation will look like when the problem is solved (it doesn't matter how the problem was solved).
- Positive consequences: The measurable benefit and improvement for stakeholders or customers.
- Required skills: List the functions or properties that are required to achieve the desired state. This is the first time we have looked at a concrete solution approach.
- Metrics: Define how success is measured: quantitatively or qualitatively
Such a value framework is typically 1-2 pages long. Marketing uses it to create marketing materials; sales uses it in customer meetings; and development uses it to better understand users and focus development on improving metrics.
What frameworks like SAFe often overlook
What I have just described is actually the promise of the Scaled Agile Framework (SAFe). Many organizations believe that they already have the value flow under control with SAFe. But in practice, SAFe often leads to measuring the efficiency of processes and neglects the stakeholder benefits. The framework shows where value should be created, but does not check whether it is actually created. Unfortunately, SAFe often degenerates into an end in itself.
This does not mean that SAFe is useless. But in order to work, SAFe must be implemented and lived correctly. And that rarely happens in practice. (If you know of any positive case studies, please let me know!).
Outlook: What's next for product development?
If the organization is aligned with stakeholder value, then we can look at how to optimize the value streams within the organization. To do this, we pursue the following four elements, which, according to Mik Kersten, that carry values and contribute to their realization:
| Flow element | Delivers | Driven by | Description | Example artifacts |
|---|---|---|---|---|
| Features | New goodwill | Customers | New functions that create a business benefit and are visible to the customer | Epic, user story, requirement |
| Defects | Quality | Customers | Fixing quality issues that affect the customer experience | Bug, Problem, Incident, Change |
| Risks | Security, governance, compliance | Safety and risk officer | Work to eliminate security, data protection or compliance vulnerabilities | Vulnerability, regulatory requirement |
| Technical debt | Removal of obstacles to future delivery | Architects | Improvement of the software and operating architecture to increase delivery capability | API extension, refactoring, infrastructure automation |
How this works in detail is a topic for Part 2, which is planned for December 2025.
Conclusion: Value is not an artifact, but a continuous flow
We know how to track requirements, validate designs and automate tests. But all this is of little use if the link to value is lost.
The future of successful product development lies in treating value as a system parameter: measurable, feedback-based and continuous. Only if the organization passes this on to product development in a prepared form and maintains it together is Product Velocity possible.
