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

How Vendors Can Apply Customer Centricity When Organizing Around Value

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

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:

Categories:

Tags:

Agile Assembly Architecture
Certified SAFe
Agile Project Management
Accelerate Value Delivery At Scale
Lean Budgeting
EOS®
Presentation
Lean Risk Management
Entrepreneurial Operating System®
LPM
Webinar
Advanced Roadmaps
Scrum Master Role
Agile Basics
Development Value Streams
Professional Scrum Product Owner
Pomodoro Technique
Risk Management on Agile Projects
Amdocs
Lean and Agile Techniques
Agile Testing Practices
RTE Role
Scaled Agile Framework
User stories
Kanban
Agile
BDD
lean agile change management
Atlassian
Continuous Deployment
Agile Product Ownership
speed at scale
RSA
Software Development
Sprint Retrospectives
Engineering Practices
Agile Games and Exercises
Kaizen Workshop
Risk Management in Kanban
WIP
Operational Value Stream
PI Objectives
Agile Delivery
Agile for Embedded Systems
Jira admin
Test Driven Development
Release Train Engineer
Portfolio for Jira
AI
ScrumMaster Tales
Agile Release Management
Elastic Leadership
Releases Using Lean
Lean-Agile Budgeting
Agile Project
Atlaassian
SAFe Release Planning
Applying Agile Methodology
SAFe DevOps
Scrum With Kanban
Agility
NIT
Agile Exercises
Continuous Improvement
Nexus and Kanban
SPC
Professional Scrum with Kanban
Value Streams
A Kanban System for Software Engineering
Kanban 101
Kanban Game
Continuous Delivery
Lean Startup
Kaizen
agileisrael
Business Agility
AI Artificial Intelligence
Self-organization
Agile in the Enterprise
Achieve Business Agility
An Appreciative Retrospective
Limiting Work in Progress
Scrum Primer
Agile Release Planning
SAFe
Agile Program
Managing Projects
Managing Risk on Agile Projects
Coaching Agile Teams
Perfection Game
GanttBan
Effective Agile Retrospectives
Games and Exercises
Nexus Integration Team
Lean Agile Management
Agile Community
Lean Software Development
Certification
Frameworks
Agile Mindset
Video
Covid19
ATDD vs. BDD
ART Success
Tips
Legacy Code
Continuous Planning
What Is Kanban
ATDD
Daily Scrum
Iterative Incremental Development
Systems Thinking
Slides
Scrum Guide
Jira Cloud
Artificial Intelligence
Agile Games
Scrum and XP
Implementation of Lean and Agile
Tools
Story Slicing
Acceptance Test-Driven Development
Product Management
Software Development Estimation
Enterprise DevOps
Scrum Values
Professional Scrum Master
chatgpt
Program Increment
Agile Israel
Nexus and SAFe
Agile and DevOps Journey
POPM
ALM Tools
IT Operations
Lean Agile Basics
Nexus
Scrum
Sprint Iteration
Hybrid Work
Agile Techniques
TDD
Risk-aware Product Development
QA
Kanban Basics
Change Management
Manage Budget Creation
Jira Plans
Lean and Agile Principles and Practices
Kanban Kickstart Example
PI Planning
Agile Development
Agile Product Development
Sprint Planning
Process Improvement
Lean Agile Leadership
Agile Israel Events
AgileSparks
Legacy Enterprise
The Agile Coach
Continuous Integration
Agile India
Principles of Lean-Agile Leadership
Jira
System Archetypes
System Team
Introduction to ATDD
predictability
speed @ scale
Implementing SAFe
LeSS
Built-In Quality
Agile Marketing
ROI
Lean Agile Organization
System Integration Environments
Product Ownership
Large Scale Scrum
Nexus vs SAFe
Code
Rapid RTC
RTE
Scrum Master
Agile Contracts Best Practices
Lean-Agile Software Development
Agile Risk Management
Lean Agile
Agile Outsourcing
Scrum.org
The Kanban Method
Introduction to Test Driven Development
ARTs
Planning
Quality Assurance
DevOps
LAB
Reading List
SA
AgileSparks
Logo
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