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:

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