Value stream engineering in a nutshell

Here's a concrete blueprint to absolutely ensure successful delivery of your project. “VSE in a nutshell” is the key.

Photo by Artur Łuczka on Unsplash

This two-part article and accompanying video explains value stream engineering (“VSE”). The first part introduced value stream engineering. In this second article, I’ll do a deep dive into exactly how you can adopt value stream engineering and transform your day-to-day work for the better, and provide a VSE blueprint you can easily use.

Introduction

In this previous article on creating customer impact, I explained how TrustCo, a financial services company, had completely missed the mark with their customer. The product they invested in didn’t connect — their customers didn’t see the point, and weren’t interested in using it. How had TrustCo gone so far in the wrong direction, spending millions of dollars to build the wrong product?

To understand that, we first need to look at how they failed. Some of it probably seems obvious — yet businesses make these same mistakes all the time, “in the moment,” not realizing the cascading impact of small upstream decisions on their downstream delivery.

In TrustCo’s case, those small upstream compromises led to compounding failures.

1. They never identified clear business drivers to ensure a sustainable business outcome.

2. With no clear, unambiguous vision, TrustCo faced constantly shifting targets.

3. Without clear objectives, there could be no clearly defined, quantitative key results to establish (and measure) success.

4. Siloing knowledge created a fragmented solution. Engineering was not involved in design — instead, they were kept at a distance from the customer. The engineers building the product never understood their customer, or what the customer wanted or valued.

5. They did not establish an empirical way to measure progress and gather feedback regarding customer needs.

6. The business was blind to the fact that seemingly good features actually had no material impact with customers (and hence, neither with the business).

7. Ultimately, implementation cost far more than any value it created.

In short, the business, the customer, and engineering never validated their outcomes. Instead of creating a tight feedback loop, and involving their customers every step of the way, the product was conceived in isolation. Someone loved it, but unfortunately, not TrustCo’s customers.

Now that we have a better understanding of where failure came from, we can tackle each of these root causes — and see how value stream engineering gives us the means to reliably avoid similar problems.

If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.

Anytime you'd like to read more, you can upgrade to a paid subscription.

What is “value?”

Determining “value” is not always clear cut. There’s the conflict of business goals (“make lots of money!”) and customer goals (“find cheaper products!”). Sometimes, just deciding how to create user value in a way that’s sustainable for the business is hard. A business needs to be profitable, or it goes bankrupt. And your customer needs to value what you offer more that what other businesses offer (or, again, the business won’t be around long).

Therefore, a business needs to offer valuable products to customers in a manner that is sustainable enough for a profit.

Let’s say you want to build the most widely used email platform in the world. One way to get fantastic adoption is to build and offer it absolutely free to everyone — but, that’s not sustainable. So you need to find a balance, charge a reasonable fee for some features, perhaps more or less for others. Not unlike Google Mail, a service boasting 1.8 billion users in 2025. Google makes money from its app store, premium features, ad revenue, and corporate users. At the same time, individuals can use it for free.¹

One way to establish value is to figure out what offers financial benefit to the organization. It’s a pragmatic solution: we need to deliver whatever has the best outcome to the bottom line. If an organization’s mission is to solve global warming, it’s only going to work if the business becomes profitable and stays in business. Perhaps our engineering reduces cost, or results in more customers signing up, or makes delivery more efficient… whatever the “feature,” it only works if it also creates financial value to the business. At the same time, customers will only pay for what they appreciate. We have to make sure customer features align with customer needs. That, combined with a sound, sustainable business strategy, leads to success.

Both business value and customer value must be considered. They are inextricably entwined.

In this sense, value stream engineering protects both the business and the customer. It protects the business by identifying business drivers that make the business sustainable. It protects the customer by validating that each feature actually creates customer value.

What is value stream engineering

As I wrote in the first part of this two-part article, value stream engineering (or “VSE”) comes down to a few core concepts:

• Correctly identifying what is valuable to your customer.

• Firmly anchoring all of your activity to that clear, unambiguous value.

• Preventing “value drift,” meaning, making it impossible to drift away into activities that don’t move us directly toward that value.

Looking at it another way, when we talk about a feature, who are we thinking of? Is it Sally, who wants to use our web site to buy something? Is it Mike in sales? Or Sara in accounting? How exactly do you know where a feature request originated? And does everyone agree that if Sara and Mike get what they want it will be good for Sally (our actual end customer)?

Value stream engineering answers these questions — and, in the process, keeps us honest in delivering real value to our customer in a way that sustains the business.

Gartner defines this “value stream” as:

The sequence of activities necessary to deliver a product, service or experience to a customer (either internal or external). – Gartner

That’s really it — but optimizing that across a long-running, often multi-team project can be tricky. How do we make sure that every single person on the team understands what they are building, why they are building it and how it creates value?

It’s challenging, but it’s exactly what we have to do. It creates a common understanding of what “good” looks like — an understanding everyone on the team shares.

What good sounds like. When you ask a team member, “what are you working on?” their answer needs to demonstrate a clear understanding of how their task, right now, creates value. “Because I was told to,” or “an in-memory cache will make things faster,” are both poor answers. A good answer is, “it will increase user capacity by 30%, which means we’ll fix the customer abandonment problem.”

The foundation: “verification & validation”

Fundamentally, value stream engineering relies a lot on discovering what is valuable, and aligning work with that value from start to finish. Much of it revolves around “validation and verification,” or “V&V:”

• Validation: Establishing the value hypothesis (by grounding it in measurable business drivers, like lowering cost or increasing user adoption).

• Verification: Tracing work-effort back to that value to ensure all work adds actual value (using KPIs, OKRs and similar measures).

You can think of validation and verification as two sides of the same coin:

• Validation establishes that what we plan to do is actually valuable; and,

• Verification establishes that what we build actually delivers what we intended.

Colloquially I’ve heard this expressed as, “validation is making sure we build the right thing, and verification is making sure we built it correctly.”

Done right, “V&V” cuts across and connects siloed business capabilities, providing end-to-end visibility for a project, from our customer’s ideation through to delivery.

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!

Modeling your value stream

There are six activities fundamental to value stream engineering when delivering software, shown here in the following diagram:

These six activities drive your value stream, creating a clear line of sight to your delivered value. That line of sight is maintained, from the start of the project to the very end. It results in knowing exactly how valuable each and every action is, all the way along the delivery pipeline.

In the rest of this article I’ll explore the six activities of value stream engineering and connect each activity with day-to-day activities. That’s exactly what the Delivery Playbook does — it integrates VSE into everyday actions, protecting your value stream from end to end.

VSE is closely related to value stream mapping (“VSM”), which has roots in lean manufacturing as a technique to analyze, design, and manage the flow of materials and information required to bring a product to a customer. VSM might use a flowchart to document every step in the process. Many lean practitioners see VSM as a fundamental tool to identify waste, reduce process cycle times, and implement process improvement.

Integrating value stream engineering with your day-to-day

A lot of our process is about creating concrete steps to protect our customers' best interests. This transforms it from a concept into actionable work your team will carry out in the day-to-day.

The rest of this article provides a specific plan for adopting value stream engineering. If you’re using the Delivery Playbook, you don’t need to change a thing — it’s already “built in,” and you’re using VSE already. On the other hand, if you’re looking to understand VSE to use it in your own methodology, this will give you a blueprint to follow.