Close this search box.
Close this search box.
Close this search box.

How Vendors Can Apply Customer Centricity When Organizing Around Value


This article was originally posted in the Scaled Agile blog.

A lot of our clients are technology vendors that struggle to use the SAFe Operational Value Streams “out of the box”. Here, I explore how such a B2B vendor should organize around value when building products that are used to support its customer’s business operations.

Organizing Around Value

Lots of organizations are organized around functional silos—such as business, system engineering, hardware, software, testing/QA, and operations. These structures exist because they support specialization and allow organizations to grow and manage their people effectively. It’s why so many organizations are set up in this way. And many organizations persist in this siloed structure even when they start their journey toward business agility.

For example, they create Agile teams that map to specialized components or subsystems. Similarly, they create Agile Release Trains around entire departments or functions. From a change management perspective, it’s easier to keep the current structure and apply Agile ways of working on top of it. But value doesn’t flow in silos. In many cases, these so-called Agile teams or teams of teams struggle to deliver valuable increments because what’s valuable requires collaboration across the silos. Additionally, teams struggle to see how their work builds up to something valuable for the customer. 

Business agility and digital transformation are all about speed of learning and value creation in the face of a dynamic changing environment. The classic organizational structure isn’t optimized for this speed, which is why SAFe® introduces the value stream network as part of a dual operating system that runs parallel to the organizational hierarchy.

The value stream network within a dual operating system.

Development and Operational Value Streams

Development value streams (DVSs) are the organizational construct used by SAFe to create this value stream network. DVSs are where the essential activities of defining, implementing, and supporting innovative, digitally enabled solutions occur. Defined correctly, DVSs are able to deliver valuable business solutions on their own with minimal dependencies on other parts of the business. 

Alongside the DVSs are Operational Value Streams (OVSs) which describe the steps needed to deliver value to the organization’s customers. Examples might include providing a consumer loan or provisioning a software product. With this in mind, the DVS has one purpose: to create profitable OVSs. They do this either by creating the systems that the OVS relies on to operate effectively or by building the products that the OVS sells. With this in mind, understanding how the work is done in the OVSs helps us understand what value looks like, how it flows from demand to delivery in our context, and how we might organize our DVSs to support this.

What’s the Right Approach to Defining Operational Value Streams?

Identifying the OVS is a relatively straightforward exercise for a technology/development organization trying to organize effectively around the value that the wider organization is delivering to customers. People supporting systems that are used when providing these services (digital or physical) can easily apply customer-centric thinking and identify an OVS oriented around the needs of the real external customer.

Example of a fulfillment OVS.

It gets tougher to map an OVS when you’re a vendor selling your product/solution for use as part of another organization’s operational activities. A great example is an independent software vendor (ISV). Other examples include vendors building and selling cyber-physical systems such as medical devices and manufacturing equipment. 

Consider vendor ACME Corp, which provides banks and financial institutions with banking systems. ACME Corp is building an AI-powered loan underwriting system that will fit into its banking systems portfolio. What OVS should ACME Corp model when considering how it might organize around value?

Many SAFe practitioners would suggest that ACME Corp model an OVS that focuses on how it would market, sell, and operate its solution.

Example of an OVS that follows the software product buyer journey.

Vendor IT folks supporting systems like CRM and ERP find it a useful way to model the business process they’re supporting. With this OVS in mind, they can make sure they organize around the whole buyer journey. And they can apply systems thinking to explore what features to introduce to the systems supporting this process.

The problem with this approach is that this OVS is mainly from the vendor and buyer journey perspectives. It doesn’t provide any information on how the solution will be used or the kind of work that it will support. An alternative approach is to use the real customer’s experience/journey as the OVS. Basically, take the same perspective that an internal technology organization would when building systems for these customers.

Example of a vendor applying customer-centric OVS.

Both the buyer journey OVS and customer-centric journey OVS exist. The question is: which of them is more useful to focus on? Remember that we map OVSs in order to build a hypothesis around what’s an effective DVS. In this example, both OVS perspectives can be useful. 

The customer-centric fulfillment OVS focusing on the solution context within which the ISVs product lives is the perspective that product development/engineering should focus on—this is where the systems/products/solutions that they create exist. This perspective would be more relevant to people building the products the vendor is selling because it would get them closer to their customers. It would also help them apply systems thinking to which features can really support generating value for these customers and for the enterprise serving these customers. 

When to use which modeling approach

If you are To orient you around Use this OVS
Internal technology organizations focused on the customer journey External customer centricity: enable systems thinking and value delivery across the entire customer journey Fulfillment
Internal technology organization focused on supporting internal systems Internal customer centricity: organize to help support internal processes effectively Supporting/ manufacturing
Vendor product/technology organization Customer centricity from the perspective of your customer’s customers Fulfillment
Vendor IT department Customer centricity from the perspective of your buyer/customer and how to effectively support your sales and marketing force Software product

Emphasize Customer Centricity as Part of Value Stream Identification

The example above illustrates why vendors can find it daunting to figure out which OVS to focus on. Going down the software product OVS perspective often leads to confusion and lack of guidance because it’s disconnected from how the products are used and from the solution context. A common move vendors make at this point is to fall back to organizing around products. Being able to explore, build, deploy, release, and operate/maintain a product can be a significant improvement for some organizations.

Example of a DVS oriented around the different systems/products, plus dependencies.

The problem with this structure is that it still has silos. And once we look at the value the vendor is trying to create, we might see a lot of dependencies between these silos. The management challenge is to connect the right silos—those that need to collaborate to deliver the value that the organization’s strategy is pointing toward. 

Leveraging customer centricity using the customer’s fulfillment OVS can help the vendor transcend product silos and maximize the value created by their product portfolio. More vendors we work with that started with ARTs and DVSs oriented around products find themselves with heavy coordination overhead across different DVSs and ARTs when executing strategic themes and portfolio initiatives. 

Look beyond one product/system – look for collaborations among products

Going back to our AI-powered underwriting product example – This product actually supports multiple steps in the customer-centric OVS, and requires new features across a range of the vendor’s products. Maximizing the value of AI-powered underwriting requires collaboration and coordination with the groups developing these products. If all of these different products are built by different DVSs, this coordination will be slow and painful. If the vendor organizes around value and brings the right people with the ability to get AI-powered underwriting integrated into the different products, time-to-market and quality will be improved. People would also feel more motivated and engaged since they’re very focused and effective. 

Using a customer-centric OVS is key to understanding your real solution’s context. This can enable you to organize effectively to minimize dependencies and enable collaborations that streamline the customer journey. Which is essentially the goal of most products—to help a business better serve its customers.

Example of a vendor creating a DVS modeled around a customer-centric OVS.

Other benefits of starting from Customer-Centric Operational Value Streams

When a DVS is created to support a customer-centric OVS, the organization can use techniques including value stream mapping and design thinking to innovate “in the Gemba—where the real value flows.” When this DVS includes everyone needed to explore, build, deploy, and support solutions that cut across the customer-centric OVS, we’ve truly created a network operating system that’s organized around value. And we’ve taken a huge step toward enabling real business agility. 

Watch our webinar on June 9, 2021 with me and SAFe Fellow Andrew Sales. You’ll learn tactical advice and tips to identify operational and development value streams that help optimize business outcomes. We hope to see you there!

There’s also a video available of me teaching the concept of organizing around value:

SAFe Operational Value Streams and Development Value Streams

Explanation of how Operational Value Streams and Development Value Streams interact in the Scaled Agile Framework and how to orient around Customer-first Operational Value Streams

Yuval Yeret Whiteboard Explanation

Subscribe for Email Updates:



Lean Startup
Lean Agile Management
Scrum Primer
Risk Management in Kanban
Operational Value Stream
Reading List
Continuous Integration
Sprint Planning
Agile for Embedded Systems
Continuous Planning
Story Slicing
Agile Project Management
Kaizen Workshop
Applying Agile Methodology
Agile Marketing
Engineering Practices
Agile Product Ownership
Accelerate Value Delivery At Scale
Software Development
Scrum With Kanban
Process Improvement
Continuous Improvement
Kanban 101
ALM Tools
Agile Product Development
SAFe DevOps
Scrum Master
Enterprise DevOps
Nexus and SAFe
Agile Program
Managing Projects
RTE Role
The Agile Coach
Lean-Agile Software Development
Jira Plans
Jira admin
Agile Assembly Architecture
ART Success
Jira Cloud
Continuous Deployment
PI Objectives
Software Development Estimation
Agile Contracts Best Practices
Agile Techniques
Professional Scrum Master
Agile Development
Daily Scrum
Entrepreneurial Operating System®
Advanced Roadmaps
Perfection Game
A Kanban System for Software Engineering
Development Value Streams
Portfolio for Jira
Kanban Game
SAFe Release Planning
System Archetypes
Lean Budgeting
Legacy Code
Agile India
Principles of Lean-Agile Leadership
Nexus Integration Team
Value Streams
Effective Agile Retrospectives
ScrumMaster Tales
Quality Assurance
Coaching Agile Teams
Elastic Leadership
Agile in the Enterprise
Business Agility
System Team
Achieve Business Agility
Lean Risk Management
Introduction to ATDD
System Integration Environments
Test Driven Development
Certified SAFe
The Kanban Method
Agile Testing Practices
Agile Games
Built-In Quality
Introduction to Test Driven Development
Professional Scrum Product Owner
Lean-Agile Budgeting
Implementation of Lean and Agile
Nexus vs SAFe
Risk Management on Agile Projects
Large Scale Scrum
Agile Mindset
Manage Budget Creation
Managing Risk on Agile Projects
Change Management
Scrum Guide
Limiting Work in Progress
Release Train Engineer
Lean Agile
What Is Kanban
Releases Using Lean
Lean Agile Leadership
Agile and DevOps Journey
Product Ownership
Lean and Agile Principles and Practices
Lean Agile Organization
Agile Outsourcing
Team Flow
PI Planning
Scrum Values
Iterative Incremental Development
Sprint Iteration
Agile Games and Exercises
Product Management
Legacy Enterprise
speed at scale
Agile Release Management
Sprint Retrospectives
Lean Agile Basics
Acceptance Test-Driven Development
Scrum Master Role
IT Operations
Kanban Basics
AI Artificial Intelligence
Lean Software Development
Agile Project
Agile Israel Events
Scaled Agile Framework
speed @ scale
Systems Thinking
Agile Exercises
Professional Scrum with Kanban
An Appreciative Retrospective
Scrum and XP
Agile Basics
Agile Release Planning
Continuous Delivery
Pomodoro Technique
Artificial Intelligence
Kanban Kickstart Example
Agile Israel
Agile Risk Management
Nexus and Kanban
Rapid RTC
Risk-aware Product Development
Keith Sawyer
User stories
lean agile change management
Hybrid Work
Games and Exercises
Program Increment
Lean and Agile Techniques
Implementing SAFe
Agile Community
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart