A Comprehensive Guide to Value Stream Mapping

Why Create Value Stream Maps?

In a previous post, I discussed how value stream mapping is one of the most essential skills to develop as an internal developer platform PM.

First, creating a value stream map is a composite skill, so by improving in value stream mapping, you will also improve in a large set of other skills. To do it well, you must become proficient at interviewing, finding data in asynchronous sources, extracting measures, and organizing data into a simple-to-understand experience.

And second, the value stream map you create is the foundation for future product visions, strategies, and roadmap negotiations. It is highly leveraged work, so doing it well makes sense from a total return of effort.

But in this article, I want to dive into my steps to create a value stream map. If I were starting from scratch, this is the guide I'd use to make my first value stream map.

But, before we go into the steps to make a value stream map and its contents, let's first talk about who the artifact is for and, specifically, the "altitudes" they operate within.

What's an "Altitude"?

What I mean by altitude is the amount and the type of details included for a consumer of the value stream map. Here are the most common:

1) Strategic leadership or executives

This persona often deals at the highest altitude: they want to be able to glance and see the problems and theorized impacts so they can make relevant cost-benefit decisions. They will love you if you can provide them with what they need to make fast, confident decisions.

There is a high demand for their time, so the executives highly value efficient information delivery. They often work with implementers who provide data at their altitudes -- too low-level and detail-oriented for the executive to make decisions quickly. So, providing them with something they need without diving into the details is rare and highly valued.

Executives often want concrete examples to "anchor" their understanding and confidence in a high-level strategy. I've found executives dislike generalities since that doesn't help them make decisions, and they dislike lack of context for the same reason. So, your ability to provide a few examples that support a conclusion is highly valued.

2) Architects, engineering management, and engineers

As a group, they highly value their ability to build systems creatively. They want their systems to meet the organization's goals and love things that help them figure out what the software must accomplish without telling them how to design their systems. They only care about the "why" to the extent it helps them figure out what features and workflows their software must support.

So builders bounce between altitudes: sometimes, they are at higher altitudes to figure out the goals their software has to help accomplish, and sometimes, they are at lower altitudes to fine-tune workflows and improve the solution. The altitude usually aligns with the lifecycle of the feature work.

3) The customer engineers or users of the Platform

Customer engineers for an internal development platform are usually at the lowest altitude level. They feel the most acute pain from the fine details – the waiting, the errors, the lack of a feature.

They love to see their feedback used and that the solutions to the complaints will help them. They want to know their pains are driving solutions.

What are the characteristics of a value stream map?

With an understanding of the personas and the altitudes to jump between, what does a value stream map provide strategically to do this? What are the "features," and how do they appeal to those personas and their needs?

Visual First

Question to ask: Is it easy to answer questions without reading?

People want to avoid reading a 10-page PRD. If you wish to engage broad groups of people, it has to be with a visual artifact. Convenience is the goal.

You see this in digital advertising, where ads with images do better than ads without, and ads with videos do better than ads with just photos. The less the consumer has to work to understand what you're offering, the better the ad performs.

Short; "Bite-Sized"

Question to ask: Is it quickly referable?

Building on convenience as a goal, each altitude of a value stream map should be manageable for a brain's "in-memory processing." People will skim this document, not take notes and study it. They want to refer back to it quickly as well.

So, when it comes to a journey, if it seems too big to handle conceptually, you must break it down into parts and hold a consistent convention on where to find information. You're building a tree, similar to how a UX designer designs a table of contents or navigation structure for a webpage.

Specificity: Informed with Concrete Examples

Question: Can I name specific teams and use cases that highlight the frustrations?

This one is critical because all personas use concrete examples:

• executives to anchor

• builders to see use cases to support

• customer engineers to see the impact of their feedback

And it fosters trust and confidence in your work.

Concrete examples and feedback are also the bedrock for determining signals and metrics used in strategic goals for executives. You will only land on reasonable metrics if you show the work. If you want to find valuable metrics, start with specific pieces of feedback and use cases to extract them.

How do I create one?

Step One: Feedback Collection

The first step I take is to collect feedback.

I categorize this into two buckets: slow and fast.

The Fast Approach

A faster approach is to pull out feedback from stateful communications like Slack and email. As a remote employee, Slack (or whatever communications tool your teams use) is a gold mine of content. Much of the feedback I collect comes from Slack interactions I observe in help channels. But, list all asynchronous places people write about their problems or give advice — also, automated reporting tools, like error reporting products, are valuable. Study them without taking anyone else's time.

The Slow Approach

The traditional approach is slow: find people, set up meetings with them, ask them questions, and dissect the answers. The slow process is good, and I like to use it to fill in the blanks from the faster feedback collection process.

I also use this time to confirm the user's goals and any assumptions I make from asynchronous feedback collection. It's slower and takes more time from people, so I leverage it for things I can't collect elsewhere.

Step Two: Detail the Goals or "Jobs"

Remember the audiences: the people who want to understand strategy, impact, and why. Then, the people have to figure out the solution. The visual structure must answer questions to both "altitudes."

I create a high-level outline of goals -- not necessarily the actions they take, but the goals they are attempting to accomplish. Think about this similarly to the "Jobs to Be Done" view: the customer is "hiring" a product to achieve a job.

For example, I was creating a value stream map where the user had to:

• Create a service account.

• Deploy it as a sidecar.

• Create a security group and firewall rules.

• Attach them to an AWS resource.

To achieve the goal of "Establishing Connectivity Between their service and an Existing AWS resource." Instead of listing all the technical steps the user had to take at the highest level, I encapsulated them under their goal.

Step Three: Apply the feedback to the goals

Then, I structure the quotes and examples I collected under the goal the feedback refers to.

I like to do this early for two reasons: The first is that it improves the structure of the value stream map. The feedback and examples are glue, and you can start to get a sense of hot spots. If you stopped the value stream here, it would benefit all personas.

Staying in a "Working" State

Touching on a more prominent topic, when I'm building a value stream map or any more extensive artifact, I try to keep it in a "working" state as I'm making it. You can validate the artifact while developing it if you focus on staying in a "value-add" state.

Step Four: Detail the actions for each goal

Then, I detail customers' steps and actions to accomplish each goal. This step is detailed and tedious.

You will only sometimes get this from the interviews or feedback collection. That will provide a piece of the puzzle, but not all of it. Other places I look to understand workflows:

• git histories

• documentation, both from customer teams and the Platform itself

I had to detail the networking configuration workflows in the last value stream map I worked on. Luckily, much of it was Terraform, so I could see commits, commit messages, and the churn on specific configuration areas.

Not only was I able to detail the steps common between 3-4 projects, but I also saw where common areas of friction occur. Then, I'd ask the customers if my assumptions of why those were painful were correct.

Customer teams will also create documentation for their use. Their existence signals that the product is friction-creating, though they are also fantastic sources for extracting the typical steps and actions.

Step Five: Extract the Measures

Determining measures is vital for two reasons:

• The first is to show trends. Is what I care about improving or not?

• The second is to help make decisions. How do we build something to create impact?  

Going back to personas, executives often care about the trend and a single, simple point to track. They have many to follow, so make it easy on them and only add one more to their reports. Simple is essential to make it worthwhile for executives and is important when communicating across the broader enterprise.

When I make a value stream map, I always extract the "north star," which I call the "KPI." The KPI is the main goal: what does the customer want to accomplish? A KPI is usually long-lived, and we'll consider investing in automated measurement and reporting.

Then, I extract "signals." Signals determine actions and are manually collected. They are often imperfect, but they don't have to be perfect so long as they help us make the right decisions promptly. Speed is a vital component of how signals provide builders value.

How are they collected?

The North Star KPI and signals come by listening to the feedback and the pain points. The KPI usually isn't tough to define, but signals require a more profound definition of specific use cases that cause pain. What actions were the root of that negative experience? Why? These are significant signals.

For example, in a previous value stream map, engineers often stated that they disliked requesting permission from an external team to take action because it resulted in unproductive wait time. When looking at the specific times this occurred, it was either a PR to another group or a ticket for approval.

So, with speed to accomplish their task as the KPI, one pillar of the strategy was to reduce wait time. The signal of the number of PRs and tickets to external teams made the problem clear to all personas. It gave the builders clear targets to solve against, primarily decreasing the count of external to-team PRs and tickets.

Step Six: Apply colors and icons as visual signifiers

The use of signifiers helps the viewers, or customers, of the artifact easily reference and find answers to their questions without diving into too much detail.

There are two common approaches. The first is using the colors of green, yellow, or red to highlight goals or steps that are particularly painful. The color scheme is conventionally understood and makes it easy to answer the question: "where are the problems?"

The next question is: "What is the problem?". Often, this ties into thematic problems. In "Making the Case for a Developer Portal at Wise by Lambros Charissis," he provides the following icons in his value stream to help executive and builder personas navigate the process:

Or wait times, interrupts, and context switches. So, not only do I not have to read much to see where the problems are, but I also don't have to read much to get an idea of the problem type.

Step Seven: The Summary

Summation of the Signals

Summing the signals is essential for executive personas and a core reference for higher-altitude data. Often, people read a value stream I've done and see a signal in each step, but until this part, they realize in the aggregate just how much drag the entire journey contains.

I've used the signals summary to derive OKRs and show the expected impact on roadmap items. For example, if a team is working on something that will decrease wait times, a value stream map with a signal summary clearly explains a percentage decrease in wait times and how the steps may change for the customer.

Provide a Thematic Problem Statement

The problem statement is the first part of the entire value stream map I write instead of numerical or visual communication. I focus on the most straightforward description of the overarching problem and do my best to keep solutions out. At this stage, solution proposals are premature.

Now, put it to use 

I see value in artifacts like a value stream map as how often they are leveraged or referenced. Depending on your organization, this may result in a product strategy, PRDs, roadmaps, or CVBs -- it's dependent on the context of your organization. Still, the next goal is to see a change in team roadmaps because of the work.