It’s easy to talk at a high level about value stream management, a practice that helps ensure that technical initiatives align with business goals. You don’t need an MBA to understand why value stream management is important or understand in generic terms why businesses should collect and analyze data in order to assess the business impact of technical investments.
What’s harder, however, is explaining how you actually implement value stream management. Which types of data should you track, and how should you interpret it? Those can be difficult questions to answer, especially for business managers who may lack the specific technical expertise or background necessary to understand what technical teams actually do.
With that challenge in mind, this article provides an overview of how to track the customer value generated by technical value streams that originate from a technical product. We’ll focus in particular on software products delivered through a DevOps approach, which is the most common technique for creating software today.
Value Stream Management and DevOps
Let’s begin by discussing why tracking value can be challenging, especially within the context of DevOps.
The main reason is that there is no limit to the software features that DevOps teams can build, and determining which ones actually drive value is very difficult. The fact that DevOps engineers typically don’t interface directly with customers, and therefore lack full visibility into customer value, makes the problem even more complex.
For businesses, then, the key to putting the value in value stream management is establishing specific metrics that they can track to assess how much customer value is created (or lost) by the technical changes made by DevOps teams.
Metrics for Value Stream Management
Here are examples of what those metrics may include for a business that takes a DevOps approach to software delivery.
Total Customers Gained or Lost
Perhaps the most basic value stream metric to track is how many customers the business gains (or loses). By correlating this data with data from DevOps processes – such as release frequency for application feature updates – you can measure which application changes have the most positive impact on total customer rates.
Obviously, there are a variety of other factors that may impact customer totals (such as the outcome of sales and marketing initiatives). You’ll want to keep that context in mind when aligning total customer count with software updates. Still, this category of metrics helps establish a baseline for aligning customer value with DevOps processes.
Average Session Time
Average session time is a metric that tracks how long users spend within your application or website. It’s a reflection, in part, of the quality of experience you are delivering to customers. The higher your session time, the more engaged your customers likely are.
By tracking average session time and determining how it changes when DevOps teams push out a new feature or update an application, you gain direct insight into how technical changes impact customer engagement.
Customer Support Requests
When customers are having a bad experience with technical products, they are likely to file support requests. Tracking how many support requests you receive and determining how that data varies following application updates is another means of assessing how much customer value you are creating through your DevOps value stream.
This is especially true if you are able to disaggregate customer support requests into different categories. That way, you’ll know how many requests involve an application performance or user experience problem versus other, less concerning requests, like requests to update a customer’s license or expand documentation.
Time to Respond to Customer Requests
Relatedly, consider tracking how long it takes your team to respond to customer requests. This metric is helpful because, in some cases, responding to a request requires making a change to the application. Customers may request a brand-new feature or a modification of an existing feature that they find confusing.
By knowing how quickly your team is able to handle requests that customers make specifically because they believe they will create value, you’ll know how ready the team is to engage in activity that is of demonstrably high value for customers.
Feature Engagement Rates
Sometimes, your team may push out a feature that most customers don’t use. They may add a wizard to an app that few users open, for example, or create an optional, “next-generation” version of an interface only to find that most customers opt out and continue using the older version of the interface.
By determining which features see the most engagement, you can directly track which ones create the most value. You’ll also gain early feedback about features that aren’t likely to be of much use to customers, in which case it may make sense to abandon the features rather than continuing to invest in an initiative that is creating little value.
Conclusion: Measuring Success from Concept to Cash
Again, there is virtually no limit to the number of features or updates that DevOps teams can implement. But just because developers can create something doesn’t mean they should. By collecting metrics that assess the impact of each feature change on customers, businesses can accurately determine where the greatest value lies, and make investments accordingly.
