Using Wardley Mapping with the Value Flywheel

Now that we have our flywheel turning (see our posts What is the Value Flywheel and 12 Key Tenets of the Value Flywheel), how do we ensure we are moving in the right direction? The flywheel provides and distributes the power, but applying Wardley Mapping throughout all four phases of the Value Flywheel Effect provides direction and prevents derailment. Wardley Mapping encourages organizations to make constant micro-adjustments to maintain direction and move at pace.

After all, any change effort, or even the process of building something, requires a cadence—a synchronization point to ensure a group of people is on the same page. In the early days of software, a build was seen as “one and done.” We build the house, and then we’re finished. Software is more like creating a botanical garden. It’s an iterative process. It requires thought about the grand design, the detail requires attention, and there is as much maintenance as there are new additions. Thankfully, the Agile Manifesto has changed the mindset of linear builds versus iterative builds, but there are still many ways to approach this.

What is Wardley Mapping?

Wardley Mapping is a sense-making device developed by Simon Wardley. The constraints and language that Wardley Mapping provides are compelling for aligning your teams or peers. (You can view our post on How to Wardley Map or visit LearnWardleyMapping.com for more.)

When mapping any scenario or problem, the first questions are the most potent: Who is the customer, and what do they need? Wardley Mapping starts by asking you to give the customer a name and understand who they are. Now, let’s talk about what they need, not what they want.

Let’s look at an example of Wardley Mapping. As cloud adoption started to grow in the late ’00s, Simon Wardley surprised many people by describing the future before it happened. Using a technique he created, called Wardley Mapping, Wardley was able to create situational awareness and show how the future evolution of specific components in the value chain would change behaviors.

What was so impressive about using this technique in a deeply technical environment was that many technologists spend a lot of time dissecting the details, and Wardley Mapping provides a common language to lift everyone simultaneously. Just at the time when containers and containerization were looking like the big strategic play for the cloud, Wardley declared that containers had won the battle, but serverless had won the cloud war.

And sure enough, he was right. This ability to inject situational awareness and “look ahead” is critical in today’s business environment and essential to realizing the full benefit of Wardley Mapping.

Applying Mapping to the Value Flywheel Effect

A shared understanding is one of the most challenging things to achieve in software. The process of developing software involves layers upon layers of abstraction: we take code and hide it behind a single call or button, and then we build again on top of that. The code is an abstraction, the architecture is an abstraction, and the deployed system (especially on the cloud) is an abstraction.

In a group of more than three or four people, team dynamics start to take effect, and responsibilities require clarification (never mind teams with several hundred people). The software serves a market, which is usually represented abstractly too. Finally, there’s leadership, who need to understand all this context, shape a compelling purpose, and work it into a plan to reach an outcome.

Laced through these layers of abstraction is a sense of urgency. Few will admit it, but many companies or executives do not have a strategy—short-term thinking prevails (“Let’s hit our numbers this quarter.” rather than “Let’s pivot to address new customer needs.”). Of the companies that do have a strategy, there are two issues. First is the planning off-site—a day or two at the start of every year or quarter to “do strategy.” Despite the best intentions, the planning off-site won’t result in lasting change; usually, this point-in-time conversation is more about alignment than strategy. Second is the fact that many of the strategic tools used are static—they don’t factor in movement.

Within each phase of the Value Flywheel Effect, it is essential to use mapping to help direct your path and course-correct along the way. Let’s look at the four phases of the Value Flywheel Effect in more detail as they relate to mapping.

Phase 1—Purpose and Vision

The critical activity here is to clarify a purpose or “north star” and measure some key metrics. Time to value (as a version of lead time) is essential to capture here. How long does it take to build a feature and get it into the customer’s hands? We’ll use a map to flesh out the purpose. Often a map of the competitive market will help identify gaps your business can address. What are your differentiators? Do you understand what customer needs you are solving?

Phase 2—Challenge and Landscape

An assessment of psychological safety is crucial to understand your organization’s “sociotechnical” elements— that is, how your people interact with your technology. Can you see the system of technology and people that your company is built from, or is it a big ball of mud? Question your organization’s “way of working.” Does challenge exist in your organization? Do healthy inquiry and debate of critical components exist in practice? The ability to map the capability of your organization is timely here. Do you have the people or capability to do what you need to do? How can you grow your people?

Phase 3—Next Best Action

We now have a purpose and situational awareness. Next, you’ll need a robust technical strategy to start improving your time to value. A frictionless developer experience is an excellent place to start, and we recommend a serverless-first approach. Remember, code is a liability! Start as you mean to go on, so create the correct mindset now. Here, it’s helpful to map the tech stack. What is good and bad about your organization’s tech stack? You may find that your engineers are wasting vast amounts of time on a flawed process. 

Phase 4—Long-Term Value

As the flywheel starts to turn, longer-term value is essential. Well-architected systems and sustainability combine to create a culture of problem prevention. Teams can use any of the three maps discussed in the next chapter (stack, org, or market) to troubleshoot issues, communicate, or discuss options. Mapping should be a constant and quick exercise as the team starts to move through the Value Flywheel.

Example Wardley Map in Action

Often, the story of how a company came to be is told as a straightforward series of events with a specific starting point. There are many smaller, interconnected, or diffuse events that impact other events. These are often overlooked when companies tell their “transformation story.” The Value Flywheel Effect is one of those events. It exists outside of the company strategy and often acts as the engine that drives transformation and success.

The Value Chain

To get your flywheel started, the organization must have a strong value chain, a desire to execute, and the will to continue the journey. A simple Wardley Map can get us started. First, we must start by identifying your value chain. The value chain is quite simple. For the stakeholder of your company, there must be a clear business goal, a plan. For this plan to execute correctly, the plan will need some effective people or teams of people. Those teams will need technology to help them, and the technology will need to work effectively (i.e., not keep falling over).

If we take the value chain and turn it into a Wardley Map, we can assess what we need to focus on as well as the potential inertia points. We’ll map our value chain on the map with the stakeholder at the top. Positioning the elements left to right (or along the x-axis) depends on how well developed that element is.

Business Goal

Let’s work through our approach. First, your organization needs to have a clear business goal and single-threaded leadership committed to delivering (the first phase of the Value Flywheel). In our example map below, this is shown as a pipeline. The business goal is represented as a cascading value, with the most ambitious (difficult) goal to the far left (in Genesis) and the tamer achievable goal to the far right (Commodity).

Teams need to be crystal clear on their goal. The North Star Framework can help. It should be possible to link the lagging output metrics in the high-level vision to smaller leading input metrics that the teams can track and improve. In saying that, all metrics must be observable—presented in real-time and in dashboards. A transparent system of telemetry across the entire system will keep everyone focused on the goal at hand. If business results are not presented in real-time or if they need to be generated manually, you are not a data-driven company. Remember, all software in the cloud has fine-grained audit trails; you just need to tap into them.

The more the goal or north star of the organization moves to the left on the map (toward Genesis), the more unique that goal is on the market (and potentially more valuable). But, if the components below the goal are also situated too far to the left (i.e., if the elements needed to achieve the goal are still too expensive, require too much toil, etc.), then the business goal may seem too farfetched— it will not get the support required.

The best outcome for this map is the business goal to the left and everything else to the right. This would represent a goal that is unique on the market and potentially highly valuable (in Genesis on the map) but can be easily supported through the consumption of products and commodities (i.e., nothing must be custom built to support the business goal).

Let’s take a moment to look at that in another way. Why did it take Tesla to change the electric vehicle market? Many tried before and failed. When Tesla was founded in 2003, the idea (business goal) was to produce electric vehicles that were better, quicker, and more fun. In 2003, this idea was firmly in Genesis. Tesla also recognized that three underlying components would need to evolve to deliver on their idea: the battery, the car software, and the motor. Tesla was designed to spend the early years of its existence moving these underlying components to the right, so it could pull the electric car into Product (through Genesis and Custom Built).

People & Technology

Once we have established clarity of purpose, we need to think about our people (phase two of the Value Flywheel: Challenge and Landscape). A team-first focus encourages strong units of delivery, as has been observed repeatedly in numerous organizations. But diverse and cross-functional teams can only be effective if they are supported—if an environment of psychological safety is created. These two elements (creating a team-first, psychologically safe environment) create the necessary environment to confront the business challenge.

Next, these teams must work in a low-friction environment, somewhere that they can experiment and do their jobs efficiently, without lots of unnecessary overhead and hand-offs. (Hint: one way to achieve low friction is for other teams, enablement teams, to help them with their work—good old continuous improvement.)

With a team-first environment, great things can happen, but we must also ensure that the technology strategy deployed will move the team forward, not impede their progress (phase three of the Value Flywheel: Next Best Action). The level of engineering in the team must be held to a high standard—not just technology from yesteryear shifted onto a different platform. A serverless-first approach helps here.

Risk

Now that you’ve thought about your people and the technology they’ll use, it’s time to think about how to address risk. When building complex cloud systems, for example, risk must be mitigated quickly. The landscape is always changing, so it’s essential to constantly assess and get ahead of risk—security risk, business risk, maintenance risk, and compliance risk. Reduced risk leads to sustained long-term value (phase four of the Value Flywheel: Long-Term Value).

The Platform

Next on the list of map components is your platform. This system must be maintainable and sustainable. What happens if your customer base triples in size quickly—Can everything scale? There is no point in having a great software system if the manual onboarding process prevents customers from using it. Your platform needs to be to the right on your map as much as possible—well known, well understood, and well-practiced. If it’s new and novel (on the left of your map), there will be mistakes (or system failures).

This is just a beginning exploration of how you can apply the Value Flywheel Effect to Wardley Mapping. You can read more, including the three types of maps, in new book The Value Flywheel Effect. 

- About The Authors

David Anderson

David Anderson has been at the leading edge of the technology industry for twenty-five years. He formed The Serverless Edge, and continues to work with clients and partners to prove out the thinking in his book, The Value Flywheel Effect. He is also a member of the Wardley Mapping community.

Follow David on Social Media

• 
• 

Michael O’Reilly

Michael O'Reilly is a Software-Architect who specializes in arming organizations with the ability to develop ideas into world-class products by leveraging the capabilities of the modern cloud.

Follow Michael on Social Media

• 
• 

Mark McCann

Mark McCann is a Cloud Architect and leader focused on enabling organizations and their teams to rapidly deliver business value through well-architected, sustainable, serverless-first solutions. He was heavily involved with Liberty Mutual's journey to the cloud, leverages Wardley Mapping, and writes for the The Serverless Edge.

Follow Mark on Social Media

• 
•