Reading Time: 42 minutes

Thoughts on Agile Value-Driven Product Development

Main Takeaways

Reading Time: 42 minutes
Many companies show big misconceptions in using the notions of value and value-creation. Value is hard to measure. To measure the value of their products, companies often tend to place different kinds of proxies there.
However, the Agile Community, Agile Product Development, and Design Thinking use the term „Value-Driven Development“ frequently with a clear understanding of “value”. This interpretation differs dramatically from the traditional Value-Stream approach of Lean Manufacturing.

Value-driven development is an illusion as long as we are all trapped in different manifestations of the Feature Factory mindset and Project Thinking. As long as organisational silos between product management, design department, development department, marketing department, and supplier management are not broken down and all participants work together in a solution-oriented rather than product-oriented way Value-driven development is an illusion.

When we talk about Value-Driven Development we should be very sensitive to our background and the context we are talking about so that it does not become a new cargo cult.

Tl;dr:

Introduction

If you dive into Agile Product Development or into Agile Software Development you get into a lot of new and abstract terms. One of the most blurred and therefore most fascinating ones is "Value" resp. "Product Value".

Product Value is hard to measure. To measure the value of their products, companies often tend to place different kinds of proxies there. However, in the Agile Community, Agile Product Development, and Design Thinking the term „Value-driven Development“ is frequently used with a clear understanding of “Value”. Since the agile definition differs from the traditional Value-Stream approach of Lean Manufacturing, misunderstandings are inevitable. This happens especially when in agile contexts both concepts are mashed up due to lacking differentiation needed. For whatever reason.

In this post, I share some of my thoughts on Agile Value-driven Development based on more than 10 years of supporting companies in moving towards Agile. To have a common wording I will use the following terms with defined semantics. All highlightings in bold, underline, or italic fonts in text and quotations are done by me. For certain keywords, I use capital in the text by purpose.

Product: is a vehicle of Value (Scrum Guide 2020). — A Product satisfies a Customer/User Need or Problem (Problem-Fit). From a business perspective, the Product has to fit the market (Market-Fit), to create a sustainable business from it (Andresen June 25, 2007).
Problem: for the Customer/User a matter or situation regarded as unwelcome or harmful and needing to be dealt with and overcome.
Complexity: the behaviour of a system whose components interact in multiple ways and follow local rules, leading to nonlinearity, randomness, collective dynamics, hierarchy, and emergence (Snowden, Boone 2007).
A complex Product consists of many parts, it is hard to understand because it interacts with its environment in its own dynamic and emergence in multiple nonlinear, random ways.
Customer: pays for the Product and does not necessarily use it. Can be external groups, or internal ones of the manufacturing organization.
User: uses the Product and does not necessarily pay for it. Can be external groups, or internal ones of the manufacturing organization.
Product Value: is connected to the usefulness of the Product for the Customer/User to solve a Problem. – Value is related to Outcomes not to Output (Ageling 2020, Apr. 18). A Product must be Fit for Purpose (Anderson, Zheglov 2017) and must be able To Do a Job (Christensen 2016, Ulwick 1999).
Business Value: is a financial measurement of tangible and intangible benefits a business can get from the capabilities of a product. These benefits differ between products created for internal use (products created by the company and used by the company) and products for external use (to be sold to customers). To name a few:
- Internal Use: Employee Satisfaction, Total Cost of Ownership, Return on Investment, Cycle Time Reduction, Service Level Agreement Penalties and Bonuses, Outage Penalties, Work Effort, Service and Problem Tickets, Legal, Contractual and Regulatory Compliance.
- External Use: Company Reputation, Customer Satisfaction, Revenue Growth, Percentage of Market Share.
- Both: Product Reliability and Safety, Outage Rate.
Project: discrete scope of work and time with a specified aim.
Product-led company: the company knows that the success of Products is primarily driven by growth and learning as opposed to other forms such as sales-led, visionary-led, technology-led, or simply shipping Features. Real Product-led companies are Value-driven.

Ok, now let me continue to present the topic of „Value-driven Development“. First I present several interpretations of Business Value and my point of Value in Scrum. Then I will argue about the difference of Lean Value Stream and vs. Agile Value Stream.

Facettes of Business Value

The notion of Business Value has multiple facets.

"In management, business value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run. Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added, and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. Many of these forms of value are not directly measured in monetary terms."

Wikipedia

Christiaan Verwijs drills it down into five dimensions (Verwijs 2014, Feb. 24). I summarise them as follows.

Commercial Value is the functionality or work that translates into profit directly. The key question to ask is "How much revenue or profit does this work result in?".
Market Value increases the potential number of customers. The key question to ask is "How much revenue or profit do we gain from our customers?".
Efficiency Value increases organizational efficiency and thereby decreases operating costs. The key question to ask is "How much is the difference between investment and operational costs?".
Future Value increases the chances of more easily achieving one of the above values in the (near) future by investing in innovation and learning now. The key question to ask here is "How much will this save us in time or money in the future?".
Business Value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run.

In 2017, the Scrum Guide started to focus on "Value". Since this, the notion has become prominent in the Scrum community and in Agile Product Development. The Scrum Guide 2020 (Scrum Guide 2020) mentions it 25 times. Scrum doesn't detail "Value" any further. Value remains an abstract concept, vague, and without any further explanation. Christiaan Verwijs relates it to Business Value arguing "that the work that a team does should benefit the organization or business as a whole somehow" (Verwijs 2014, Feb. 24).

I appreciate Christiaan and his publications very much. But I do not agree with him on this point. Instead, I do relate "Value" more to the term "Product Value" than to Business Value. Here are my arguments:

Since Simon Sinek's Golden Circle, we should always ask the "Why"-question first (Sinek 2014, 2009). Therefore, take any organization and raise this question: "Why does the org exist?" An obvious answer is "a company exists to make money". But today the answer is not so easy. The quote by Peter Drucker (Drucker 2006) "the purpose of business is to create a customer" is one of the most frequently cited definitions of the purpose of a business. It is a shortcut of "Because the purpose of business is to create a customer, the business enterprise has two–and only two–basic functions: marketing and innovation. Marketing and innovation produce results; all the rest are costs. Marketing is the distinguishing, unique function of the business."
Takeaway: “People don't buy what you do; they buy why you do it. And what you do simply proves what you believe” (Sinek 2014, 2009).
We have to keep in mind, Peter Drucker is talking primarily about marketing and innovation and only secondarily about the importance of companies.
Takeaway: The notion of Drucker's "creating the customer" is ambivalent. In 1950-1980, in the era of mass manufacturing and advertising, companies focused on selling what they wanted to sell by creating a customer need to be profitable.
The reality of today's business world changed drastically. Today, companies do not create a market and customers by selling and marketing their products. In contrast, being able to "create a customer" requires knowing and understanding exactly who our customer is. Thus, today a company makes a profit by selling something which they assume could be a market opportunity because it could have value for its customers. In case of innovation and disruption, these needs must not necessarily be obvious to the customers.
Takeaway: Raise business growth by looking for opportunities.
Today's business is not to create customers by selling them products designed by business people. Business success is by knowing and understanding exactly who our customer is, and creating products suiting their needs best, instead.
Takeaway: The purpose of a company is to create value by creating opportunities by knowing and understanding the customers' needs best.
Scrum is well-known as a lightweight framework to help people, teams and organizations to generate value through adaptive solutions for complex problems. The fundamental idea of Scrum is to implement incrementally the product in multiple timeboxes (so-called Sprints) by starting with a basic concept of minimal functionality without big upfront planning. The result of each sprint is a tested and functional product increment that is reviewed by stakeholders and customers for its solution fitness and direct usability. If necessary, it is adapted to extended or new conditions and requirements in the next Sprints (fact-based, experience- and evidence-based development).
Takeaway: In Scrum, we build a product incrementally by adapting each increment to new or changing requirements. Each Sprint result is a functional useable product increment that can be examined, reviewed, and used by the customer.
Let's summarise the above five points. Companies create customers and markets by building products which satisfy their needs. With Scrum, we build in complex environments products via product increments which each customer can use.
Takeaway: If the question and the answer are "Who should use the Sprint increment?" — "The customer/the end user!" the consequence is: In Scrum, we create value for the customer resp. end user.

„Value“ in Lean Development/Manufacturing

In Lean Production, the term „Value“ is well known and established without relatedness to its Usage: Toyota Production System, TPS (Ohno 1988), Six Sigma, and Lean Software Development (Poppendick, Poppendick 2003).

In Lean Development/Manufacturing Value is attached to „Value-adding“ and „non-Value-adding“ activities. Image, a Customer/User orders a Product. The manufacturer starts to work. First, he buys all materials needed (Value creation 1).

Value-Adding vs Non-Value-Adding Activities

Then she performs all other activities to produce the Product. Certain activities will add Value to the work item, others not (Value creation 2-n). E.g., in the first place, the Value of an axis of a car to be built consists of material and Production costs. By additional welding or ironing activities, the axis becomes stronger, with more shock and temperature resistance – it becomes a premium. Instead, transporting the axis only from plant A to plant B is a non-Value-adding activity.

Mary and Tom Poppendick compared waste (aka non-Value-adding activities) in Lean Manufacturing and Lean Software Development (Poppendick, Poppendick 2003).

Waste (Lean Manufacturing )	Waste (Lean Software Development)
Inventory	Work Done Parallel
OverProduction	Extra Features ("Gold Plating")
Extra-processing	Relearning
Transportation	Handoffs
Waiting	Delays
Motion	Task Switching (Multitasking)
Defects	Defects

The goal of Lean Manufacturing/Production is (1) from the business perspective to increase profit by eliminating all waste (all non-Productive activities), and (2) from the Customer perspective to minimize the customer waiting time from the time ordering the Product to the point of getting it shipped. Since (2) counts toward (1) increasing the manufacturer's profit:

In Lean, Value, Value-adding actions, and Value streams are strongly related to the monetary aspects of the Product.

– (see Exhibit 1).

Value Stream

Value Stream (Lean Manufacturing/Production)

Value streams are part of the business ecosystem that describe how Stakeholders/Customers/Users receive Value from an organization. From an outside-in view, Value streams can be cross-mapped to business capabilities to describe what and how an organization must do to deliver Value to the Stakeholder.

A Value stream is the set of actions that take place to add Value to a Customer from the initial request through the realization of Value by the Customer.
A Value stream always begins and ends with the Customer. The goal is to improve time to Value by optimizing the whole Value stream.

Exhibit 1

Value-stream mapping is diagraming every step involved in the material and information flows needed to bring a Product from order to delivery. It is a fundamental tool used in continuous improvement to identify and eliminate waste. It clearly showcases the flow of goods from third-party vendors to Customers through your organization.

Toyota developed Value-stream mapping — which it calls a material and information flow diagram — and it is a critical part of the Toyota Production System. Value-stream mapping is one of the key Lean Six Sigma tools/techniques used to provide a detailed visualization of processes in an organization.

Value-stream mapping

Value Stream (Agile Definition)

According to Jurgen Appelo, founder of Management 3.0 and entrepreneur, Value streams satisfy high and low-level jobs to be done. Instead of waiting for a Customer/User request (order), we should wait for Customer/User signals of interest. Therefore we have to improve the experience for Users as well, not only Customers.

"A Value Stream is the set of actions needed to discover or deliver on a Job-to-be-Done basis a signal to the Customer/User Experience.
A Value Stream always begins and ends with a User or a Customer.
The goal is to improve the experience by optimizing the whole Value Stream."

– (Appelo 2022a)

Within this definition, Value streams start prior to a Customer or User request. The manufacturing organization has to observe the market resp. Customer continuously for her signals. And the Value stream finally ends when the User discards the Product and doesn't use it any longer — she “lays it off”.

„Value“ in Agile Product Development

Value is an important concept in Agile. However, in Agile Product Development, “Value” is interpreted differently than in Lean Production.

“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.”

— (Scrum Guide 2020)

Here, the focus is not on adding Value-added activities essentially. Instead, the focus is on the Product's Usefulness.
Samuel Adesoga distinguishes between "Usable", "Useful" and "Valuable" (Adesoga 2022, Oct. 20). A usable Product is one that is fit for use and there is a closely associated measure for Usability known as “Ease of Use”. Usefulness means to “find a use” for a Feature or Product. Value is focused on the point of view of the Customer.

"For a Product to be useful, it must be usable; and for a Product to be valuable, it must be useful."

— (Adesoga 2022, Oct. 20)

A "useful Product increment" can be created by Value-adding activities in the traditional sense (like additional ironing). But, what is much more important, is that a "useful Product increment" is not limited to Value-adding activities only.

Thus, in Agile Product Development, Value is not primarily related to monetary aspects (the more Features, the more Money). Instead, it is connected to the Product's Usefulness for the Customer/User Need instead. – The Product must be Fit for Purpose.

"Products have a Purpose, a Mission, a Goal."

— (Anderson, Zheglov 2017)

Products and Their Usefulness

Before I go into details of Product Purpose, we have to define the notion of Product. When I asked the Teams or Product Owners I worked with about "What is your Product?" often they answer first with a list of Functions and Features. In the second attempt, then they describe the Purpose from the view of the Engineers and Designers, and how they intend it. Very seldom did the Customer occur.

Roman Pichler defines "Product" as

“Something that creates specific Value for a group of people, the Customers and Users, and to the organisation that develops and provides it.”

— (Pichler 2016, Jun 14)

Functionality is only one part of the Product. For a complete picture, there are many other aspects.

Product Usefulness is related to the Product Value Proposition and Product Mission. The Product Value Proposition is a statement that clearly identifies the benefits a company's Products and services will deliver to its Customers. A well-crafted Value proposition will differentiate the company and/or its specific Product or service in the marketplace and among a target market or target audience.

A Product Mission is a clear, concise statement that explains the Product's highest-level Purpose. It clarifies who the Product serves and what it does for them. It also identifies what makes the Product unique and answers the question: “What difference do you hope your Product will make for the Customer/User?”

Product Usefulness is the Outcome of using the Product. It is the impact the Usage have. It is not he Output, the amount of Features the Product has.

Customers did not buy our Product because of the Features, but because of the Outcomes (Benefits), they assume to get triggered by these Features. According to (Huryn 2022 Jun. 1) there are three different types of Outcomes a Product may trigger:

Functional Outcomes. – The core tasks the Customer/User wants to get done. A car, it’s travelling from point A to B. At this level, it doesn’t even matter whether it’s a VW beetle, a Rolls-Royce, or an Uber.
Emotional Outcomes. – How do Customers want to feel or avoid feeling as a result of using your Product? Is it safety, freedom, joy, or taking care of the environment?
Social Outcomes. – How do Customers want to be perceived by others by using your Product? What does driving Dacia or Ferrari tell others about your status or Values?
...at least of all the mix of all makes the Complexity.

Products Have to Solve Problems

Customers/Users want to get solved the problems they have. Thus, they search for proper solutions or tools to support them — or best, for Products to solve their problems for them.

"Customers/Users don’t give a damn about your Product Features. – They strive for solutions."

– (Huryn 2022 Jun. 1)

“People don't want to buy a quarter-inch drill, they want a quarter-inch hole.” (Theodore Levitt)

In Product Development are many approaches to align Products with Purpose and Usefulness.

Job to be Done Theory (Christensen 2016), Outcome-Driven Innovation (Ulwick 1999). — People buy („hire“) Products or services to get a „job“ done until they are “lays-them-off”. Jobs are functional, with emotional and social components.
Great Products inspire & empower Customers (Cargan 2018, 2020).
With great Products, Customers/Users fall in love, they are immediately hooked to them (Eyal 2014).

Customers did not buy our Product because of their Features, but because of the Outcomes (benefits) that were triggered by these Features (Huryn 2022 Jun. 1).

Product Discovery

In the Product Discovery Phase, we identify additional opportunities for either implementing (Product modifications) or applying our potential solutions (new markets, new Customer/User segments). – By differentiating all these options we ensure to build the right Product.

This leads us to a predominant challenge and conclusion.

"Before we can deliver Value, we first need to discover Value."

— (Appelo 2022a)

"Product Discovery is Discovery of Opportunities."

— (Cagan 2006, Torres 2021)

In this context the following terms are relevant.

Product-Solution Fit: The evidence that a Product, or a service, solves a Customer’s problem. When Customers/Users care about certain jobs, pains, and gains we have evidence that a Product, or a service, solves a Customer’s problem. Product-Solution-Fit is a validation of our solution. We test it with prototypes and MVPs. And if we have no Solution-Fit we iterate or pivot our development.
Product-Market Fit: This term comes from Steve Blank's Customer Development Model (Blank 2013). We have a Market-Fit when Customers/Users are buying our Products just as fast as we can build them, or when Usage increases faster than we can scale Production. In contrast, we have no Product-Market-Fit when Customers/Users don't fully understand what Value our Product or service actually provides (Andresen 2007). The Product fits the market, so we can create a sustainable business from it. Product-Market-Fit is a growth and scale-up indicator.

Product Delivery

In the Product Delivery Phase, we test continuously together with the Customer/User (peer groups) our implementation. Actually, we test several implementation proposals till the Customer/User accepts one finally. – This ensures we build the Product right (Torres 2021).

Be careful, what we deliver are our decisions what might be valuable.

"We often deliver wrong decisions — causing us to build a faulty Product."

— (Carleson 2021)

If we have no feedback loop with the Customer, this fault is detected when we show the Product to the Customer resp. in the market introduction only. We basically will never know what Value something will deliver until it is used by the Customer. Therefore we should prototype our solution(s) early and often, and learn early and often (keyword: Minimal Viable Product, MVP).
And we should make decisions at the last responsible moment. That is while we still have some options, but before we run out of options. We should create prototypes with loose internal couplings. When making decisions, we should hold and move smaller sets of decisions to correct mistakes sooner.

Any (Agile) Product Development initiative is highly doomed to fail when it starts to solve a problem by taking the first solution coming to mind as the final one, and/or by building a Product with a lot of Features thinking the most the better.

Essentially, if this happens, we live in a pseudo-agile bubble. Instead:

we should discover as many aspects of the potential problem by staying as long as possible in the Problem Space. Then we decide what you have to solve.
we should discover as many alternatives of potential solutions by staying as long as possible in the Solution Space.
we should defer the decision of which option might be the final one as long as possible. Then we decide how you want to solve it.

Another great mistake is to do Product Discovery and Product Delivery in combination with the traditional, Lean Manufacturing Value Stream interpretation in mind.

Mashing up this Lean Value Stream concept with the agile understanding of Product Discovery falls too short since the Purpose dimension gets lost. In consequence, we focus misleadingly on building Feature after Feature. In the end, we are stuck in the Feature Trap aka Feature Factory.

Product Delivery Anti-Patterns

Product Death Cycle and Product Build Trap

The Product Death Cycle was first described in a tweet by David J. Bland, a management consultant based in San Francisco. The Product Death Cycle is the failure mode where a Team making a B2B, or B2C Product focuses on Customer/User feedback over Product Vision (Bland 2014).

There is no Product Vision or Product Strategy.
The Product Manager forgets about the “Why” and becomes a kind of steward for Customers, Users, and Stakeholders.
To please everyone, the Product Manager collects and waterfalls all the requirements to the Team.
Features shipped in a hurry do not solve anyone’s problems and do not drive the expected business results.
The Team is under high pressure and cuts corners, compromising the quality.

The Death of the Product becomes a real risky possibility.

Product Build Trap

The Product Build Trap was first described by Melissa Perri. It happens “when organizations measure their success by Outputs rather than Outcomes!” (Perri 2014, 2018).

The reason for the Build Trap is that our first ideas are not always the best. When we immediately jump into build mode, we don't have much information on how our Customers will respond to our Products, what they would want to do with them, or if the Products even solve a problem. Our design or Product decisions are not based on facts, but on our best guesses. And most of those guesses are wrong.

“The Build Trap is when organizations become stuck measuring their success by Outputs rather than Outcomes. It’s when they focus more on shipping and developing Features rather than on the actual Value those things produce.

Companies can get out of the Build Trap by setting themselves up to develop intentional and robust Product management practices […] to maximize business and Customer Value.”

– (Perri 2018)

Product Death Cycle and Product Build Trap happen when the Product focuses on Customer/User feedback more than on Product Vision, and success is measured by Outputs rather than Outcomes.

A lot of companies are building Feature after Feature, without stopping to validate what Customers truly want and need.
Instead of measuring the Customer/User Value, companies tend to place proxies there.
It’s wrong to think that the faster we code, the more money we make.
It’s wrong to think that the more Features we deliver, the more the Customer/User likes what we make.
Our Products become a hodgepodge of Complexity.
The Death of the Product becomes a real risky possibility.

Feature Hell and Experience Rot

When we start to develop a new Product, the Team starts with a certain amount of Features for which they have evidence to hold them as being essential for successful Product Usage, feedback, and market fit. Then the Team releases the first version 1.0 as a minimum viable Product (MVP).

With feedback from real Customers, the Product evolves more and more over time. At a certain time, the number of Features grows so much that the Complexity of the Product exceeds a certain critical threshold.

In the end, the Complexity is so high that it is hard for the Users to understand the Product. At this point, a once great User Experience from the beginning is rotten to a point where it is hard for the User to actually know and use all the Features.

This Experience Rot is bad for as well existing Users as new Users. Existing Users won't use the new Features and will stick to the old known essential ones instead. And the new Users first need to figure out which basic essential Features they need and where to find them.

But the Complexity is not only a problem for the Users. It is also extremely hard for the Product Development Team as well. Maintaining, extending, and innovating the Product becomes harder and harder.

With every new Feature, new demands on the Product Architecture rise up, probably not considered from the beginning. These demands stress the Architecture to the consequence, that Technical Debt builds up and the need for Refactoring increases. In consequence, for every change, the development and release time get longer and longer. — Welcome to the Feature Hell. — And, have more fun, Dependencies aren't counting in here!

Scope Creep and Feature Creep

Scope Creep and Feature Creep are two terms often used for changing given and/or adding new requirements (i.e. Features). The Team starts with an initial Product Vision and a core set of Features identified (MVP). It bundles these Features into an MVP and starts developing them.

But over time the Team, the Product Owner, and the Stakeholders come up with new Ideas for small changes or small additional Features. And as they go along with them, they shift the Scope more and more.

This happens often unnoticed by the Team. Scope Creep leads to a delay in the Product release timing and increases the cycle time of Features and releases. This increases the risk and the costs of Product Development. In the worst case, the identified core Features are extended so much with added functionality that the Product is getting harder to use.

Scrum is a Framework For Product Discovery AND Delivery

Primarily, doing Agile or Scrum, it’s not about the best Products we could build. It’s about how we work better together to build the best Products.

“We are uncovering better ways of developing software […].”

– (Agile Manifesto 2001)

And as a side effect, the Products become better!

David Pereira (Pereira, 2022, Nov 22) states rightly "Embracing the unknown is the core of Agile". Scrum is not a silver bullet to solve everything problem. Scrum works only in certain domains correctly. Scrum is a framework to address Complexity and Uncertainty. Scrum addresses complex problems while delivering the highest possible Value.
Scrum Teams build valuable Products in a complex environment.

"Scrum is a lightweight framework that helps people, Teams and organizations generate Value through adaptive solutions for complex problems. [...]

– (Scrum Guide 2020).

Scrum is a discovery framework. The Sprint is a container to explore potential solutions and to implement the most prominent one. Sprint Planning, Daily Scrum, and Sprint Review are events to support Teams and their Stakeholders to inspect and adapt. Scrum Teams and their Stakeholders need to be able to adjust the course based on new information.

"In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making."

– (Scrum Guide 2020).

Yet, Scrum is a framework suitable for both, Product Discovery and Product Delivery.

"A Scrum Team, […] focused on one objective at a time, the Product Goal.

The Product Goal describes a future state of the Product which can serve as a target for the Scrum Team to plan against.

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide Value, the Increment must be usable."

– (Scrum Guide 2020)

Scrum is by purpose incomplete to be applied to different fields of applications. Hence, Scrum doesn't prescribe how the practices it offers should be executed. Eventually, these practices can be realized in various ways.

This holds for Sprint Goals and Product Goals as well. Therefore, some Agilists view the Product Goals as the Product Vision, while others relate them to the Product’s Value proposition. In the end, the Product Goal describes the Product Value as the Customer/User experience of its Usage and Purpose.

The Sprint Goal describes the Value of the Sprint Increment to be delivered by the end of the Sprint. "Why is this Sprint valuable?" is the most important question in Sprint Planning. Answering this question needs to result in the Sprint Goal. Often the Product Owner comes with a suggestion. This drives a discussion since the entire Scrum Team (which the Product Owner is part of) needs to agree upon the Sprint Goal because they have to commit to meeting the Sprint Goal by the end of the Sprint.

Since the Sprint Goals provides a certain flexibility in the work to achieve it, and the Scrum Team is accountable for the value of the Increment and commits to the Sprint Goal, the Team has the authority to decide which exact work is needed to achieve this Goal. In extreme, the Scrum Team has the openness to replace during the Sprint a planned Backlog Item with a different one fitting better the committed Goal. In setting certain boundaries, the organization defines and equally respects a Team's Autonomy and Self-Management – or worst it sabotages the ideas of Scrum.

Scrum Teams commit to the Sprint Goal, not to the work to be done during the Sprint.

In determining and limiting Scrum Teams to deliver work as planned only we completely ignore the fact that Scrum is intended to be used in complex environments where we don’t know what will happen, even within the Sprint.
This insight wasn't in Scrum right from the start. In the early versions of Scrum starting in 1995 (the first Scrum Guide was published in 2010) and up to 2017, Scrum was more Delivery-oriented. It was only with the new Scrum Guide that this changed and Scrum became Value Driven by introducing the notions of Sprint and Product Goals.

"Without a value-driven mindset, all Agile frameworks will lead you to the same place. Nowhere."

– (Pereira, 2022, Nov 22)

Doing Scrum with a Value-Driven mindset combines both: Product Discovery and Product Delivery. First, we start with an idea or problem solution (MVP). Then we refine and sharpened this idea continuously by demoing and discussing with the Customer till together we agree on the best-suited Product Solution for the intended Usage. Stefan Wolpers wrote a very useful article about Value Creation in Scrum, (Wolpers 2022, Nov 21).

Evolution of Scrum Teams

When we analyse the history of Scrum Adoptions a certain pattern shows up that Scrum Teams go through a 3-stage evolution (Pereira 2022, Aug. 25). As aforementioned, even Scrum ran through this evolution but left out the waterfall phase, by intention.

Faster Waterfall: Everyone is still responsible for one specific aspect of the Product, and nobody is responsible from end to end (Lack of Accountability). The Team decompose projects into smaller tasks and organize their work to meet deadlines (Tasks-driven). Tasks are technical and can only be done by specific Team members (Siloing). The Team doesn’t make decisions but receives directions and requirements from Stakeholders/higher-level management (Unempowered Team).
Feature Factory: Sprint Goals refer to delivering a certain number of Features by the end of the Sprint (Commitment to Output/Features). Increasing velocity defines how successful the Team is.
The Scrum Team is accountable for the whole (Feature Accountability). Unlike waterfall, the Team doesn’t have siloes anymore; they learned how to collaborate and create Features from beginning to end. Due to role-driven hand-overs often we can find in these teams small silos inside causing small waterfalls in the Sprint (Scrumfall, Waterscrum).
The Product Owners write User stories and refine them with the Team. The Team self-organizes how to solve stories instead of breaking them into technical tasks. Feature factory Teams don’t expect people to decide how to deliver Features and which requirements to follow (Self-Managing).
Feature Factory mindset is Issue-driven or Ticket-driven (Klein 2022, Aug 23). In Sprint Planning, the Team looks at the list of issues in the Backlog and selects some that they think they can work on, typically according to how many they can fit in a Sprint. Sometimes the Sprint Goal is “finish all the issues”, and sometimes there’s no Sprint Goal at all, just a list of issues. In the Daily Scrum, the Team mostly talks about what issues they are working on. In the Sprint Review, the Team and Product Owner determine what was done or not done according to the status of Sprint’s issues.
Common perils are Product Death Cycle, Build Trap, Feature Hell, Experience Rot, Scope Creep, and Feature Creep.
Agile Value-Driven: Focusing on solving problems; Questioning over answers; Arguing intensively and committing; Learning from real Customers.
David Thiel differentiates Output-oriented Teams from Outcome-oriented ones (Thiel 2022, Aug 16):
- Output-oriented Teams are Teams that focus heavily on eliminating technical risk and delivering Features quickly. They are so focused on gaining knowledge, minimizing technical risk, and developing the Product with high efficiency, speed, and quality that Customer Value becomes secondary.
- Outcome-oriented Teams focus primarily on creating Customer Value. However, they focus so much on Customer Value that development keeps going through feedback loops, forgetting about efficiency, speed, and technical Product quality.

This evolution is not limited to (agile) software development. It holds for Product Development in general, Design Thinking, and UX Design in particular (Gothelf 2011, Mar 7).

In an Agile Transition, very few companies are aware of this evolution and run into three major pitfalls.

Ignoring phase 1, phase 2. — Companies believe to become immediately Value-driven by installing Scrum Teams and running Scrum events only. However, there is no shortcut or elevator to skip one or two of these evolutionary steps. We have to go through all of these steps, step by step. And this takes its time. And it doesn't matter which agile framework we will use, plain Scrum, LeSS, SAFe, Nexus or Scrum@Scale.
Mistaking the Lean Value Stream approach with an Agile one. — As a consequence, the company skips the Product Discovery phase and keeps staying in Product Delivery (Feature Factory).
Keeping a Project Mindset instead of changing to a Product Mindset. — Products are ongoing concerns. They continually evolve based on learnings, feedback, changing market conditions, and financial fundamentals. There’s always room for improvement, enhancement, and expansion into new markets and use cases. In contrast, Projects are discrete undertakings with a predetermined Definition of Done. In projects is little strategic thinking once it has started. Keeping up on time and under budget and meeting the acceptance criteria is the one-and-only goal.

Many organizations slip up without knowing. Hence, Value-driven Development is an illusion as long as we are all trapped in different manifestations of the Feature Factory. Value-driven Development never ever evolves as long as the organisational silos between Product Management, Design department, Development department, Marketing department, and Supplier Management are not torn down and all participants work together in a solution-oriented rather than Product-oriented way. In my opinion, for a successful transition to Value-driven Development, we should consider the new approaches of dynamic teaming (see below).

For the success of the radical organisational revolution, these are promising solutions. However, they require a certain maturity of the Teams as well as the organization, which must be achieved first.

Agile Value-Driven Product Development

In Agile Value-Driven companies, people know that Product success is essentially driven by growth and learning and not by as opposed to other forms such as sales-led, visionary-led, technology-led, or simply shipping Features (Pereira 2022, Aug. 25).

Teams focus on solving problems: they solve real end-Users' problems and drive business Outcomes. They don’t fall in love with solutions but with problem-solving.
Teams questions over answers: Curiosity drives actions. They ask four or five times more questions than give answers. First, they want to understand, then they talk about potential solutions.
Teams argue intensively and commit: they argue and commit and then they bond with each other to deliver meaningful solutions.
Teams learn from real Customers/Users: they continuously learn from your Customers/ Users and uncover hidden opportunities. They strive to gain evidence from experiments.

Agile Value-Driven Product Development revolves the whole organization since it questions the status quo. It’s important to understand that the transformation has to happen as aforementioned in the entire organization, not just within Scrum Teams. All Teams will be trusted to make decisions on how to create Value instead of how to deliver Features. Such massive change may take years instead of months.

Reducing Complexity with Agile Value-Driven Product Development

Aspects of Complexity

The Cambridge Dictionary defines Complexity as "...the state of having many parts and being difficult to understand or find an answer to". Wikipedia characterizes Complexity as "the behaviour of a system or model whose components interact in multiple ways and follow local rules, leading to nonlinearity, randomness, collective dynamics, hierarchy, and emergence."

The reason for nonlinearity, randomness, and emergence is when working in a complex system even a small change can have a big impact and we can’t control all factors, since we can't survey all potential interactions between the subsystems and parts of the Product.

I think, for Agile Product Development, blending both definitions would be very helpful.

A complex Product consists of many parts, it is hard to understand, and it interacts with its environment in its own dynamic and emergence in multiple nonlinear, random ways.

Therefore to be successful in Agile Value-Driven Developing, Discovering, and Innovating Products, we have to work in two disjunct systems mixed. We have to blend the designer's/developer' system view with the system view of the Customers/Users applying the Product to their final needs. Both systems will interact successfully only when designers/developers continuously empathize, observe, and have feedback from Customers/Users. Thus, to be successful in Product Discovery, Product Delivery, and all their related Outcomes – making Customers/Users happy – we have to take a Systems Thinking approach.

The Cynefin Framework, created by Dave Snowden in 1999, is a framework for sensemaking when finding decisions. It draws on research into systems theory, Complexity theory, network theory and learning theories. It helps to identify how we perceive situations and make sense of our own and other people's behaviour.

Complexity is one of five decision-making contexts aka "domains" in the Cynefin framework. David Snowden and Mary Boone describe Complexity as:

"In a complex context, right answers can’t be ferreted out at all; rather, instructive patterns emerge if the leader conducts experiments that can safely fail. This is the realm of “unknown unknowns,” where much of contemporary business operates. Leaders in this context need to probe first, then sense, and then respond."

– (Snowden, Boone 2007)

The other domains are called clear (known as simple until 2014, then known as obvious until recently renamed), complicated, complex, chaotic, and confusion.

Cynefin Framework

The Clear domain is characterized by stability, rules in place (or best practices), and cause-and-effect relationships clear to everyone. The right answer is self-evident. It represents the "Known knowns". To react in such a situation is to "sense – categorize – respond": establish the facts ("sense"), categorize them, then respond by following the rule or applying best practice.
The Complicated domain may contain multiple right answers. Although there is a clear relationship between cause and effect, not everyone can see it. This is the realm of “Known unknowns”. The relationship between cause and effect requires analysis or expertise; there is a range of right answers. To react in such a situation is "sense – analyze – respond": assess the facts, analyze them, and apply the appropriate good operating practice.
The Complex domain represents the "Unknown unknowns". Cause and effect can only be deduced in retrospection, and there are no right answers. To react in this context we need to probe first, then sense, and then respond.
In the Chaotic domain, cause and effect are unclear. It is the realm of the Unknowable. And it is futile to search for the right answers. The relationships between cause and effect are impossible to determine because they shift constantly and no manageable patterns exist. This is the realm of "Unknowable". Action — any action — is the first and only way to respond appropriately. In this context, we should apply the pattern "act–sense–respond": act to establish order; sense where stability lies; respond to turn Chaotic into Complex.
The Confusion domain in the centre represents situations where there is no clarity about which of the other domains apply. By definition, it is hard to see when this domain applies. To react in this context is to break the situation into its constituent parts and assign each to one of the other four realms.

Keep It Simple — Idiot!

Modern Product Development is complex by nature. Here are some reasons:

Our Products have to solve modern-day problems and keep pace in a complex, volatile, and uncertain environment. No two problems are the same nor are the approaches to solving them. We can’t expect a positive Outcome by just coming back with best practices. Instead, in complex contexts, we have to find good practices.
A complex Product environment isn’t served well by traditional management approaches (Ageling 2020, Mar. 15).
Product Development should be managed based on the Outcomes, not on the Output only (Ageling 2020, Apr. 18).
We gain the best overall Customer/User Experience when we embrace collaboration across development areas and Teams (Ageling 2021, Jan 17).

The transition from delivering an initial simple, resp. clean Product to a complicated Product or even to a complex one is emerging, sneaking, over years. And very often this happens unnoticed by the Team. However, in this transition, there is a small range where the Product becomes really more valuable (in the sense of Customer/User Experience and usability). But, exceeding this range by adding more Features, all the aforementioned anti-patterns will hit us and the Product becomes worse.
And there is another interesting observation: this transition is a one-way direction since it’s easier to make a Product more complex than to make it simpler. When improving Products, people/engineers tend to add new Features instead to remove Features. They systematically overlook subtractive changes (Adams et al. 2021).

The simplest way to achieve simplicity:

"Simplicity is about subtracting the obvious, and adding the meaningful."

"The simplest way to achieve simplicity is through thoughtful reduction. When in doubt, just remove. But be careful of what you remove. … When it is possible to reduce a system’s functionality without significant penalty, true simplification is realized."

– (Maeda 2006)

Seen from the perspective of Production, if we do this transition consciously and stay by Purpose as long as possible in this Value-creation zone, we innovate the Product successfully. But, beyond this zone, Innovation might fail because we increase Product Complexity by adding more Features than necessary. More Complexity leads to Customer/User Experience Rot and at the end to Product Death.

Unfortunately, a lot of the Complexity has its origin in still doing Big Design Up Front (BDUF) and detailed technical planning. This happens even in Agile Product Development. Often it is caused by upper management chasing half-heartily the agile transition in adopting pseudo-agile frameworks supporting the existing silo hierarchies than cross-department collaboration. I avoid mentioning SaXXe here.
The point is, most often, Products aren't designed to be complex by Purpose (well, some were) but because BDUF inherently connects to silo development and existing workflow bottlenecks.

"The more you focus on processes to avoid errors, the less you can benefit from agility."

– (Pereira 2022, Nov. 8)

Another aspect to consider is Conway’s Law. Conway’s Law says that the Complexity of the Product being developed mirrors directly the Complexity of the manufacturer's organizational design In reverse, by minimizing the Product Complexity we might minimize Dependencies between both, Features and our Production workflows. The reason for this is, we operate in two complex systems parallel. System 1 is our organization with all its internal Dependencies in development activities and workflows we work in. And system 2 is the Product with all its interacting parts and sub-systems we implement facing our own working Dependencies.

"With large organizations, you will face complexity and may try adding more of it. Don’t focus on complexity. Simplicity is your best ally."

– (Pereira 2022, Nov. 8)

The Agile Principle of Simplicity holds for the Product's Architecture Design as well as to design the workflow needed to build the Product.

“Simplicity – the art of maximizing the amount of work not done – is essential.”

– (Agile Principles 2001)

You can't simplify everything. Some things can never be made simple. Complexity can be beautiful.

Nevertheless, the decision to make the Product as simple as possible and stripping it down is sometimes the better option. On the one hand, it reduces the working Dependencies (organisational Complexity) and makes the Product easier to maintain for the developers. On the other hand, the Customer/User Experience increases when Product handling becomes easier. In the end, you get more and happier Customers.

Just do less.
Less is always more.
Make the Product as simple as possible. Reduce your amount of work.

This is the hardest challenge.

Managing Non-Technical Dependencies

In the broadest sense software project management is managing all kinds of Dependencies. We have to deal with Technical Dependencies due to the SW tools we use and the Product Architecture decisions we agreed to.
We have to deal with non-Technical Dependencies caused by workflow and Team Dependencies due to the organizational Work model and the design of our organization in departments and expert groups, how the work is structured in preceding/following activity relationships, and other planning Dependencies like third-party Products/services, or working with non-Agile groups, to name a few.

When we develop Products we can't avoid Dependencies. Although Zero Dependencies is – in analogy to Zero trust in IT security – a common trend on the internet. However, it's wishful dreaming. The last consequence, concerned with Technical Dependencies, results in full-stack code ownership. And, for non-technical and workflow Dependencies the consequence is the complete isolation of the teams and their full authority and responsibility to do all the work by themselves only with no external support.

In contrast, if agile Value-driven Teams should deliver rich Customer/User Experiences, they have to have Dependencies. They have to collaborate.

Per se, non-Technical Dependencies are not bad.— A Team without Dependencies to other Teams is a silo.

In consequence, we have to differentiate between good and bad Dependencies and have to eliminate the latter only. It's quickly speaking.

Bad Dependencies are situations that prevent the Teams from discovering or delivering Value to Users and Customers.

– (Appelo 2022a, Appelo 2022c).

At least

Without good interactions between Teams, we will have an overly-fragmented User Experience.

Non-Technical Dependencies are Dependencies caused by the organisational Working Model applied. Essential for bottlenecks are External Work Dependencies. External Dependencies occur when the Team's work success depends on work to be done by someone outside of the Team. By External I understand as well External-External in the sense of third-party suppliers or services outside the manufacturing organization as well as Internal-External, where the work depends on work done by other Teams or Departments inside the manufacturing organization. This could be a database admin changing a table, a developer from another team who is the expert on a certain code library, or a needed approval (review) of a pull request. In both, due to waiting for the externals, the Team can't reach its Sprint result even if they finish their own work. And the un-done backlog item is carried over to the next Sprint. This is very frustrating for the Teams.

In large organizations adopting Agile, all kinds of External Work Dependencies are very common. The reason is that the organization starts its journey by setting up its Development Department as the Island of Agility. Whereas on the Agile Island people embrace Agility and aim to make the best of it, the rest f the organization – the mainland – is far from Agile and has its own, different idea of priorities. Usually, traditional Project Management Departments (PMO) and Quality Assurance Departments live on the mainland and ask constantly the Agile Island for compliance with processes and long-term plans, deadlines, forecasts and tight schedules.

A very painful situation is when even on the Agile Island the Teams have Non-Technical Dependencies internally. It's caused by either (1) the Teams are set up with cross-functional competencies only inside the team without giving competence or authority to do full end-to-end work. Or, (2) on the Agile Island are some teams not working in an agile way. Resulting, that customer-centric end-to-end work being only possible when all necessary teams collaborate together. Worst they do this in an "agile" work chain. – Welcome Scrumfall and welcome Waterfall!

We should take Internal-External Dependencies as Organizational Debts. Analogue to Technical Debts (technical leftovers of implementational shortcuts or short-term decisions) Organizational Debts are legacies of taking over the old working model into the new world without getting rid of all its deficiencies. We should take Organizational Debts as being temporary. We should pay them off as fast as possible otherwise they get more and more expensive, hindering us continuously to do customer-centric end-to-end work and Value creation.
Badly, large organizations keep their old working model as long as possible or worst don't change it fundamentally. With small modifications only, the old model is sold as the new agile working model.

Mostly, Internal-External Dependencies and Organizational Legacy Debts are caused by staying at Work Areas being grouped in development activities related to the Product's Architecture decisions as long as the organization can. Development Work Areas tend to be more fixed over the lifetime of the Product. They focus on Architecture and are characterized by code ownership per sub-system.
Instead, Customer-Centric Work Areas focus on the Customer and are organized around Customer Requirements and Needs. Customer-centric Work Areas are temporary in nature and should change over the lifetime of the Product, but not at each development iteration. They have collective sub-system code ownership.

We are heading to Agile Value creation only and get rid of Internal-External Dependencies if we drastically revolve the existing working model from Development to Customer Work Areas. Everything else creates more Complexity in our daily work satisfying customer needs. And many large organizations fear doing this. They camouflage instead their legacy working model with pseudo-agile concepts.

Identifying Dependencies

There are two prominent ways to identify non-Technical Dependencies.

Search bottlenecks in the workflow. Bottlenecks might be administratively needed activities, or lack of resources or of knowledge/competence (e.g. subject matter experts, SME) to name a few.
Identify the area(s) of competence needed from outside the Team. The idea of end-to-end responsibility of Teams for their Products implies the Teams have all the necessary capabilities and competencies. If Teams need external expertise that blocks the Value stream.

In Agile and Scrum-like Product Development, the development process is described by so-called Product Backlog Items (PBIs) aka User Stories. A Product Backlog Item isn't a requirement with its specifications. Instead, a Product Backlog Item is a communication scheme to start conversations with Stakeholders, and Customers/Users about the Purpose and Usage conditions of Features needed. Over time with the evolution of Agile, a hierarchy of PBIs emerged: User Stories (the smallest unit), Epics (collection of multiple User stories), and Sagas (collection of epics). In some agile terminologies, Themes and Initiatives are synonyms for Sagas, in others, they are larger entities than Sagas. It depends on the agile terminology you use. However, all these notions aren't part of Scrum as the Scrum Guide defines. The Scrum Guide only refers to Product Backlog Items.

However, we can identify Dependencies (in the sense of needed collaboration between Teams) on all levels of Backlog Refinement:

On Saga level: Initial Saga creation and follow-up Saga refinement. — Try to identify potential cross-Saga-dependencies when creating the Saga and follow-up refinements.
On Epic level: Detailing Sagas into Epics and follow-up epic refinements. — Try to identify additional potential cross-Epics-dependencies when Sagas are sliced into related Epics.
On User Story level: Detailing Epics into User stories and follow-up User story refinement. — Try to identify additional potential cross-User stories and follow-up User story refinements when Epics are sliced into related User Stories.
On Daily base: Daily scrum meetings (Stand-ups). — When the team discuss the daily plan they should identify potential blockers.
On Blocker level. — Anticipate dependencies by studying historical blockers. If you want to understand what dependency (aka potential future blocker) risks are worth paying attention to, study historical blockers from previous programs (Yip 2023, Jan 12).

Breaking Dependencies

To break non-Technical Dependencies we have to change organizational boundaries. Agile Value-Driven Teams have two options to change their boundaries:

to restructure once to dismantle Dependencies permanently or
continuously dissolve and re-form dynamically depending on the work Complexity or required skill set to handle the workload.

We can do the second one either before each new project starts or during the project before each new Sprint starts.

Most of the well-established concepts to break Technical Dependencies can easily be transferred to breaking Dependencies of organizational design and workflow: modularization with autonomy in module design, loose coupling, and specification by interfaces/handovers.

Customer-centric Modularization — Organize the wanted functionality in Work Areas by grouping all customer-centric end-to-end activities needed. Break up technical Component Areas into Customer Requirement Areas.
Autonomy of Work Areas — An organizational Change in a Work Area or its implementation (work results) should be possible at all times and should have no consequence on the results of other Areas as long they meet the specified technical and organizational Interfaces. You can give Autonomy to Teams or Areas by freeing code ownership only.
Interfaces — specify handovers on technical and organizational levels between Work Areas as a strict working protocol that must be met. Changes are only allowed if all Areas consent. For this, Modularization and Autonomy of Work Areas are prerequisites. You can rely on Interfaces only in case of Modularization and Autonomy.
Organizational Loose Coupling of Work Areas — Design the Work Area network in a way to change connections/interfaces easily if needed.

These techniques are very challenging for development organizations with a long tradition reflected in their code base. The myriads of existing repositories cause huge learning curves for newbies and multiple coding errors for seniors. Maintaining existing functionality or implementing new ones affects hundreds of repositories with their own unique code ownership.
A nightmare.
Beware, before you can benefit from breaking Dependencies easily and continuously, you have to untangle this mess of Technical Debt first. To have the capacity needed, you have to have to accept the valley of tears in reducing innovation as much as possible.

Methods to Break Dependencies

Break non-Technical Dependencies by reshaping existing, departments, Teams and working groups. Jurgen Appelo presents a list of 10 bad Dependency Breakers (Appelo 2022b).
There are other interesting approaches to reshaping Teams dynamically as well.

Dynamic ReTeaming Patterns to move Team members around Teams in different ways (Helfand 2019).
Dynamic Value Stream Crews and Dependencies Breaking Patterns. There is a larger pool of people, organizing themselves around the work at hand. As a larger group, they have the opportunity to be truly cross-functional, so that they can cover the complete Product experience or Value stream, unFIX framework (Appelo 2022b).
Fluid Scrum Teams to cope with Dynamic Workload Changes. Fluid Scrum Teams organize themselves based on the work at hand. Every time new topics need to be addressed, the people of the fluid Scrum Teams organize themselves to optimize the chances to succeed with their challenges (Ageling 2021, Jan 17).
FAST Agile. FAST is an acronym for Fluid Scaling Technology. FAST Agile does not build on static Teams. Instead, it creates a fluid lattice where Teams dynamically form, change, dismantle, and reform (Quartel 2022).
InnerSource. Code ownership in large organizations is treated similarly to Open Source projects. Everyone can change the code. Before taking on any major change, the Team making the change must go through a design discussion on changes planned with the owning Team. No code will be accepted without adequate test coverage. All changes have to go through peer-reviewed pull requests (@jukesie 2018).

Value-Driven Agile Product Roadmaps

In the traditional way, a Product Roadmap states when and which functionality will be released. The Roadmap is aligned with the business strategy and release dates. It is a kind of Roadmap, a long-term plan.

Instead, an Agile Roadmap is more about communicating our Product Strategy than it is about communicating Features and Dates. However, important dates should and could be mentioned, the Roadmap is a statement of intent and direction. The Roadmap visions the certainty and Uncertainty of the project/Product evolution. It is not a Gant-Chart, or milestone table.

“We need to let go of the idea that we can enumerate a list of Features that represents what we’ll do in the future. This idea is absurd.

Rather than sharing Feature lists with the rest of the company, we should be communicating how we will make decisions.

Stop putting Features on your Roadmap. Building Products isn’t about Features anyway.

Stop talking to your Customers about Features and start talking to them about benefits instead."

– (Torres 2014)

Sagas, Themes, and Initiatives structure the Work Areas for your Product, outlining the Customer/User or business Outcome you are trying to achieve. They are not just a listing or grouping of Features.
If the Saga description is free of Featuring listings and describes outlining the Customer/User or business Outcome to be achieved, an Agile Product Roadmap shows on the Saga level, how a Product will likely evolve over a longer time frame and how the related Agile Value Streams deliver Value.

The Agile Product Roadmap is not based on the Product Backlog but on the Product Strategy, and it contains multiple Product Goals. It doesn't forecast how a major release or a new Product version is developed. A Roadmap isn't a Release Plan or Burndown-Chart.

According to Emily Tate (Tate, Lombardo 2018, Aug. 3), an Agile Product Roadmap should consist of the following five components :

Vision: Tells how the Customer/User will benefit when the Product will be fully realized.
Business Objectives: Objectives and Key Results tell what your Product will accomplish, and how it will be measurably different as you fulfil your Agile Product Roadmap.
Timeframes: Timeframes should point to prioritization, and give sequencing and guidance on timing, but should be broad to allow for flexibility. They can show important dates.
Disclaimer: A disclaimer detailing the constraints and the likelihood of change.
Themes / Sagas / Initiatives: Structuring of Work Areas for your Product, outlining the Customer/User or business Outcomes you are trying to achieve. They are not just a listing or grouping of Features.

To fully leverage our Agile Product Roadmap we should avoid the following ten mistakes (Pichler 2022, Nov 1).

The Product Roadmap is a Feature-based Plan. — Drawbacks:
- A Feature-based Agile Product Roadmap can give rise to a Feature-Factory mindset, Product Death Cycle, and Product Build Trap, where adding Features is more important than creating Value and making a positive impact on people’s lives and the business.
- Focussing on Features risks turns the Agile Product Roadmap into a tactical plan that overlaps with the Product Backlog, especially when fine-grained Features are used. This makes the Roadmap harder to understand, and it increases the effort to keep it up to date.
- A Feature-based Agile Product Roadmap is easily mistaken for a commitment rather than a high-level plan that is likely to change. This will not only lead to disappointed Stakeholders. It will also limit your ability to experiment and learn, run sprints and discover the best way to address the User and Customer needs and create Value for the business.
Roadmap Goals are Features in Disguise. — Drawbacks:
- Product Goals are mixed with Features.
- Features describe Product capabilities, they characterise the solution. They do not state why it is worthwhile to progress the Product.
Stakeholders Determine the Roadmap Content. — Drawbacks:
- Individual Stakeholders dictate the Agile Product Roadmap content by wanting to have “their” Features included in the Product.
- Stakeholders' Features don't align with the Product Goal and Strategy. Discuss "wanted" Features by subsuming them to an existing Product Goal, by adding an additional, new Product Goal, or by rejecting them.
The Person in Charge of the Product Creates the Roadmap on Their Own. — Drawbacks:
- It does not leverage the creativity and knowledge of the Stakeholders and development Teams.
- It risks creating a plan that is not clear to the Stakeholders and Development Team members, that lacks a shared understanding, and that causes misalignment.
- People are less likely to support a Agile Product Roadmap if they haven’t had the opportunity to contribute to it. In the worst case, the Stakeholders and development Teams pay lip service to the plan, go off in different directions, and follow their own goals.
The Agile Product Roadmap is Not Systematically Connected to the Strategy and Backlog. — Drawbacks: the Agile Product Roadmap is a plan in its own right, it is a mistake to create and manage it in isolation. This would result in an Agile Product Roadmap that is not aligned with the Product’s Value proposition and business goals and in a Product Backlog that is not linked to the Agile Product Roadmap. This, in turn, can lead to inconsistent and wrong Product decisions.
The Agile Product Roadmap is a Fixed Plan. — Drawbacks: some people mistake the Agile Product Roadmap for a rigid plan that must be executed. But any Roadmap is based on what is currently known. As you start implementing it and learn more about how to best meet the User, Customer, and business needs, the Agile Product Roadmap is likely to change.
The Roadmap is Speculative. — Drawbacks: an Agile Product Roadmap is created by a speculative plan. It is built on wishful thinking rather than empirical evidence. This would most likely result in disappointment and failure.
The Agile Product Roadmap is Overambitious. — Drawbacks:
- An Agile Product Roadmap with unrealistic goals can turn the development effort into a “Death march.”
- The development Team members regularly work overtime, are permanently stressed, and end up being exhausted.
- Creativity, motivation, and Productivity drop, and people’s well-being and health suffer.
- More errors and mistakes occur, and software quality is often compromised making it harder and more expensive to update the Product in the future.
The Agile Product Roadmap is Mistaken for a Release Plan. — Drawbacks:
- The Agile Product Roadmap is the wrong tool for managing development efforts. Development effort is best managed by a Release Plan, e.g., a release burndown chart.
- The Release Plan forecasts how a major release or a new Product version is developed. It doesn't show how a Product is likely to evolve over a longer time frame. This does the Agile Product Roadmap. It is not based on the Product Backlog but on the Product Strategy, and it contains several Product Goals.
The Right Agile Product Roadmap Tool is What Matters Most. — Drawbacks:
- The Team lacked an effective Agile Product Roadmapping approach.
- The Team try to shortcut the Roadmapping process by licensing a powerful tool. They rely on the tool's capabilities more than acquiring relevant knowledge and discovering the right Roadmapping practices.

"Outcome orientation increases the chance of creating value, while output orientation maximizes the odds of delivering crap.
[...] Most roadmaps are the way they are because companies lack the expertise to do it in a better way. Don’t let the status quo limit you. You’ve got a chance to change it."

– (Pereira 2022, Dec 28)

Bottom Line

With its drastic Customer focus, Agile Value-driven Development differs extremely from the (Lean) Product Manufacturing definition. Instead, Agile Value-driven Development opens a completely new perspective in the area of Production Development and the notion of Product Value theory interpretation resp. understanding. Therefore we should be very sensitive in talking about Value-driven Development in the right context so that it does not become a new cargo cult.

Therefore we should:

...being precise about which kind of Value and Value Stream interpretation we use: Lean Manufacturing- or the Agile-based one. We shouldn't ground the agile approach with the traditional Lean Manufacturing Value stream notion.
...being aware of the agile background we are coming from and also being aware of what Product Development horizon we want to open.
...not wrapping ourselves in being in a false safety by mingling both interpretations and using Value-Driven with the wrong connotation.
...accepting that Agile Value-driven Development is the last step in a long agile evolution. It doesn't come automatically by just adopting Agile or Scrum. Instead, it takes time, more than years.
...understanding that the interpretation of Value-creation today differs dramatically from the Value Stream definition of Lean Manufacturing. Today, Value creation is a multi-facette discipline of technology, psychology and humanities, systems thinking, agility, lean, and industrial Product design.

This post was first published at the end of Sept. 2022. In the meantime, I updated it due to further learning of multiple topics. You will find the references in the section "Further Reading" all dated after Sept. 2022.