May 9, 2021
Jeff Sussna is a consultant and author specialized in helping organizations deliver software more effectively. This is Jeff’s second appearance on the show. In this conversation, he tells us about Customer Value Charting, a visual tool that helps teams balance strategy and agility.
Jorge: Jeff welcome to the show.
Jeff: Thanks for having me. It's great to be on and great to talk to you again.
Jorge: Yeah, I should have said welcome again to the show, because this is not your first time here. So, thank you for joining us again. Now, some folks might not have listened to our first conversation, so for their benefit, would you mind, please, reintroducing yourself?
Jeff: I'm Jeff Sussna. I live in Minneapolis and I run a software delivery consulting firm there. And our clients are companies that typically are doing some form of Agile and/or DevOps, and they're struggling with it. And what we typically find is that they face a conflict between agility and autonomy on the one hand, and strategy and alignment on the other. And Agile and DevOps by themselves... they're very much about breaking things down into smaller pieces. Smaller teams, smaller systems, smaller units of work, as a way of making change and adaptation easier. But they don't really have much to say about how you put the pieces back together. I like to say that customers don't want to buy microservices, they want to buy service. And so, there's this kind of big missing piece in the discourse around where are we trying to go and what are we trying to do? And so, our focus is partly on helping organizations do Agile and DevOps more effectively, but what that really ends up being is helping them overcome this conflict between, "this is what I'm doing today," and "this is where we're trying to go this year."
Jorge: And this is the reason why I wanted to speak with you again, because this idea of striking a balance.... I'm going to frame it as striking a balance between agility and strategy — or you called that a strategy/alignment — is something that I think plays out in many fields, not just DevOps. This notion that the best way for us to make progress, let's say, is by working step by step and making small adjustments. But those small adjustments need to be in service to something, right? And... anyways, you shared a link to a post on your website about a tool called Customer Value Charting, which seems to get at this idea of striking a balance between agility and strategy, and I was hoping you would tell us about it.
Jeff: Sure. But we need to start by taking a little bit of a step back. One of the things that we've learned working with our clients who typically are making the transition from software products to software services and cloud delivery, is that the cloud completely transforms the relationship between the customer and the software provider.
I had an epiphany a number of years ago. I was looking at a marketing website for an early software as a service company; might even have been Salesforce. And right on their homepage, they were talking about things like multiple data centers, and offsite backup, and advanced security practices. And I realized that they were spending marketing dollars on IT operations. And then I read a sentence that really opened my eyes. It said, "we update the software so you don't have to." And the epiphany was the recognition that the cloud transfers the cost of change from the customer to the software provider.
So, it used to be when software was a product that the feedback from the customer was things like, "well, we have to go through a three-month change management process before we can install the new version." Or "the new version requires an OS upgrade, and we're not scheduled to do that until next year." And with the cloud, the conversation is completely different. It's, "why is it taking you so long to deliver this feature upgrade, or this bug fix, or this stability improvement?"
So, customers start to expect this continuous increase in value. And on the one hand, they become impatient with delay. No matter how good your feature is, if it takes too long to deliver, you start to lose customers. But at the same time, what they want is not just this continuous spray of random features. What they want is improved value. And what value is... I think of it in terms of three dimensions. The first is usefulness. Does it help me accomplish something that I'm trying to do? The second is usability in its largest meaning. Can I understand it? Can I adopt and onboard it? Can I administer it? Can I get help with it? Can I integrate it? And finally, dependability, which is everything from scalability to performance, to resilience, to security, to compliance, to trust. If you look at what happened with Slack this week, when they released this new global DM feature and then pulled it because it turned out to be this opportunity for a huge abuse. They violated people's trust. And so, they had to pull a feature.
Jorge: I see dependability and usability as perhaps table stakes. And when you speak of creating value, that is where the usefulness dimension comes in. Is that a fair reading of that?
Jeff: I think we could have a lengthy debate about whether dependability is table stakes. I mean, yes. Ultimately, what you're after is usefulness, right? The reason I need a dry cleaner is because it isn't feasible for me to clean my tuxedo at home. So, I need someone to do it for me and you're right, that ultimately, that's what I want: is to get my tuxedo clean. But I also need to get my tuxedo clean in time for tonight's formal event.
So, things like speed may be important. I need to be able to easily get to and from the dry cleaner, so usability in terms of access to roads and shopping malls and whatever, may be important. The reason that I put these three together is... again, the shift from product to service involves this inclusion of operations. And that's something that often falls short. Product management tends to think of itself as being in the feature business. I do a lot of work with what I call cloud native product management, which is working with organizations and helping them understand that product managers need to be accountable for these usability and dependability metrics, as much as they are accountable for number of features delivered, or customer growth, or revenue, or anything like that. In any case, what customers are expecting is a continual evolution. So, across these dimensions that the service is getting continually better, not just sort of a random spray of things. And so, the challenge is how do you become more continuous and how do you have some strategic direction?
And again, this is kind of a missing piece in the Agile and DevOps discourse, and I think that's why there's this kind of impedance mismatch intention and a certain frustration between Agile teams and designers or Agile teams and product managers or Agile teams and executives. And in thinking about how to resolve it, it occurred to me that the answer is simply to approach your work, both at the strategic and the tactical level, in terms of the outcomes as opposed to outputs.
And what I mean by outcomes is customer outcomes. Customer benefit is maybe a better word. You know, the benefit of the dry cleaner is that I can get my tuxedo cleaned in time to go to the formal event. It's not fundamentally about a cash register or a counter or even cleaning chemicals. And I mention that because a lot of the conversation I see around outcomes over outputs tends to actually talk about business outcomes. You know, revenue growth and customer retention, and time on site and business outcomes are great. I don't have any problem with them, but people tend to skip this step. We have a hypothesis that this feature will cause this change in customer behavior, which will lead to this business outcome or business impact. But it leaves open the question of, well, why is the customer changing their behavior? What is the benefit to them?
So, I started thinking about both strategy and direction and context, and also tactical work in terms of customer outcomes. We have an epic, or we have a roadmap, or we have a strategy, or we have a user story. Why are we doing that? Who cares? How does it help? And I started working with teams in helping them figure out, well, how do we start to put those two together? And a couple of things happened. One is that for a long time, I've been using some work in something called Promise Theory, which was developed by Mark Burgess, which is a way of thinking about how large-scale complex distributed systems can work well. Where a distributed system could be anything from a large-scale software system to a company, to a city, to an economy. And it's based on the idea that parts of the system make promises to each other. Where a promise is simply an intention to do something of benefit.
So, we can think about Slack as promising the ability to get work done together across boundaries, right? Why do you need Slack? If everybody's in the same office, at the same time and they work for the same manager, you don't need Slack. You just talk to each other. It's when you're separated by space and time, and you're working across an organization, or across multiple organizations that you need help in order to get that done. And you can think about all of the features that Slack contains as working in service to that promise. And you can think of those features also as making promises of their own.
You know, in order to work together across boundaries, you need to be able to have real-time and non-real-time conversations. You need to be able to find and start conversations and dip into them and out of them. None of that says anything in particular about a feature. We haven't said anything yet about a channel, or a thread, or an emoji. We're talking about what it is that Slack helps a user do and what the user can accomplish by doing that.
So, I started working with teams in terms of thinking about what promises we would make. And these could be promises to end users, or they could be promises to other parts of the organization. I do a lot of work with platform teams and their customers are internal development teams. And what happens if you look at particularly traditional IT, there tends to be this approach of: if you want us to do something, file a ticket and we'll do it. It's very requirements-driven. It's very outside-in. We try and do what we're told to do and often we fail, for various reasons, most of which aren't our fault. They have to do with the way that the organization is structured and the way the work is structured.
And this is really about turning it inside-out out and thinking about a platform or whatever the team is in the organization, as a service provider that is making and hopefully fulfilling promises to its internal customers. So, I work with them to understand, well, what promises are you making? How well do you fulfill them? And how can you both do a better job of fulfilling your promises and also think about more useful ones to make, which is where innovation really starts to happen.
The other interesting thing about a promise — and I should probably talk about this a little more — why this word promise? Why not contract or guarantee or requirement? A promise represents an intention that may or may not actually come to pass. I might promise to take out the trash, and then I might forget. So sometimes we break our promises. And counterintuitively, that's actually a really good thing. I had a conversation with a very thoughtful person once; we were talking about promises and then she sent me this email and she said, "I really don't understand why you would ever make a promise that you don't intend to actually fulfill." And I said, "well, you never would, but you can't guarantee things." So, the word "promise" forces you to think about the possibility of failure, which on the one hand helps you do a better job of not failing, but it also gives you an opportunity to think about improvement and repair.
You could think of a promise as a bundle that brings together this idea of service, and customer jobs, and commitments to actually deliver service and continuous improvement. We can create this process where we think about our work at every level, from the tactical all the way to the strategic, in terms of how are we promising to help? How effectively are we fulfilling our promises? And how can we improve our ability to make and fulfill promises that are useful? The next step was to start developing a visual way of representing this. And in particular, a visual way of connecting tactical to strategic outcomes or promises.
For a while I was working with something called Wardley Maps, which is a very powerful visual mechanism for identifying value chains all the way from the strategic, down to the very, very tactical and devolving that value. And the only problem I found is that when I was working with people who weren't sort of math or graphing nerds, if you will, they tended to find Wardley Maps kind of hard to look at. They're very much built around kind of graph theory and cartesian coordinates and that kind of thing. And people seem to get somewhat confused just by the visual representation.
So, I was casting around for another way to present it. I started looking at Impact Maps and User Story Maps, which were very appealing, but what I found in practice was that they tended to kind of fall back into representing features, right? Here's this big feature we want to build and we'll make a User Story Map to represent the parts, and then we'll create slices and say, "we're going to create this set of sub features first." And I really wanted something that focused on this idea of outcomes and promises. And that's what led to Customer Value Charting.
You could think of it as a riff on Promise Theory meets Wardley Maps meets User Story Maps. And it's a very simple visual representation, which is basically a grid of three rows and four columns. When you look at it from the top down, the top row is, "why is your help needed?" What is it that your customer or a potential customer is trying to do that they can't do on their own?
So, if we continue with our Slack example, it's getting work done together across boundaries. If you look at the middle row, this is, "how do you help?" What promises do you make in support of that higher need? So, again, Slack promises things like the ability to have structured conversations that are both real time and non-real time so you and I can just chat and then one of us can go off to lunch and come back and continue the conversation. The ability to dip into and out of conversation. So, if I join a new team, I can find out what conversations have been happening. I can see what happened last night or yesterday. The ability to dynamically create and find conversation.
And the bottom row is, "what help do you need in order to fulfill your own promises?" If you're on the Slack application team and you're building an application, you need things like elastic infrastructure, because it's a very dynamic system and users come and go. It needs to be able to scale up and down very easily. You also need help from the customer support organization, because you need visibility into how are customers using the application and how are they struggling with it so we understand where it needs to be improved. Once you do that, you have a nice visual representation of your value proposition all the way from the top to the bottom of what business are we in and how do we help and who do we help.
Then, if you look at it from the left to the right, you basically lay out your promises in terms of how effectively do we fulfill them. So, at the left, you have promises that you don't make. This isn't part of our business. If you want to manage some very structured workflow like procurement or ITIL or something like that, you don't do that in Slack and do that in something like ServiceNow. Now, that's helpful because it bounds your scope. It allows you to say things like, "nope! We shouldn't be working on this because we don't do it. It's not our business. We don't make any promises about that." But it's also a great place to find opportunities for innovation by identifying underserved customer needs. This is a promise we don't make, but maybe we should.
The second column is, "things that you're exploring." You're just dipping your toe in the water, you know? Maybe you're not sure if there's a market or a real need for it yet. You only did it in order to win a customer deal. For whatever reason you haven't fully invested. The third column is your bread and butter. This is the heart of our product. It more or less works the way it's supposed to and more or less does what people need. And the furthest column to the right is this is where our competitive advantage is. This is where customer delight happens. This is where we know people won't switch to a competitor because they really love or are hooked on this one particular feature. So now you have in one place, your value proposition and your operational reality of this is how we actually execute on our value proposition. And then the exercise becomes a matter of identifying areas where you want to move something from the left to the right. Where you want to become more effective at.
This is an iterative process. You don't start with something that you don't do at all and try and make it highly effective or compelling in one shot. You start by exploring it. Let's dip our toes in the water and find out. And the final step is you start attaching actual work to it in terms of what is the next step we're going to take.
Let's take the example of Slack where Slack doesn't do structured workflow. But a lot of times what happens is people are debugging together in a Slack channel and they find some infrastructure problem and they have to go over to ServiceNow in order to file a ticket. Wouldn't it be nice if you actually had the ability to integrate ITIL directly into Slack because there's a use for it. So, that's an area we want to invest in. We want to explore. And the first thing we're going to do is we're just going to build a very simple connector that allows you to create a simplistic incident ticket directly from a Slack chat.
What you have now done is you have identified a simple small piece of work that you were going to use to validate and explore a larger, more strategic direction. And you use this as an iterative management and conversation technique so that you do some work and then you come back and you ask yourself, "well, how far did that get us along the path that we're trying to get?" maybe it was harder than we thought, and there's not really as much market need as we thought, and we should just stop. Or maybe we learn something from it, and we discover that the next thing we should do along that path is to build Y instead of X.
And again, this entire process is happening in terms of promises of outcomes, not really in terms of locking down features. So, it gives you this ability to explore in an agile fashion, but to give everybody a sense of what direction we're moving in. What is it that we're trying to make better? You know, so often when I work with Agile teams, they do stand-ups and they drew retros and they define their sprint goals and things like that in terms of work and quantity and velocity. Our sprint goal is to finish these 24 stories, and we finished 23 so we're going to declare our sprint a success. Well, what did you actually deliver? What got better as a result, you know? Or what we need to do in this iteration is we need to add three database indexes.
Well, what is the promise that we're delivering on? The promise is to make search 15% faster. And whether you do three database indexes or seven or one, isn't the essential point. The essential point is to make search 15% faster. So, if you connect your work to that promise, you give yourself the flexibility of how to actually go about doing it. But you have a goal that everybody understands and everybody can communicate to each other, to management, to your customers. And so, it brings together this idea of flexibility and agility with having some kind of direction that you're trying to go in that has value in everyone.
Jorge: It sounds to me like a tool to help visualize in a more tangible way, the question, "what is this in service to and where might we be missing something?" And, in that way, it strikes me as a kind of more useful version of a roadmap, perhaps? Is that a fair read?
Jeff: That is an excellent read. Yes! It is all about identifying value and evolving value. And it's funny, I'm glad you mentioned the word roadmap. If you think about a map, right? Like a real roadmap. And remember... you and I are probably both old enough to remember the days when you actually had one of those foldout paper maps. A map showed you how you could get from point A to point B. It doesn't tell you how to get there, right? You get to make decisions about, well, we're going to take highway or we're not going to take the highway, or we're going to go this way so we can stop here for lunch. It presents opportunities. And the problem I have with traditional product roadmaps is they cause, I think, unnecessary pain and frustration.
You know, the underlying insight that Agile had is that when you're building something large and complex and novel — something that's a little different from what you've built before — it is extremely hard to perfectly predict exactly how you should build it, or even exactly what it should be. And if you look at a roadmap... and it's funny, I keep coming back to this idea of AgileFall, where people use Agile to do Waterfall. And there's a lot of grief and a lot of condescension... "Well, if you're doing AgileFall, you're doing it wrong. You're bad. You're bad at Agile." I think what that misses is that AgileFall represents this tension that hasn't been resolved around, "well, we need something more than just what we're going to accomplish in the next two weeks." And so, what happens is people trying to lock down the big picture.
There's a presentation where somebody stood up and they presented this completely Waterfall 12-month roadmap that said, "this is what we're going to do in Q1, Q2, Q3, Q4." And then they said, "but because we're Agile, we might change the dates." In other words, this roadmap is a work of fiction. And its primary purpose is to frustrate you because we are explicitly telling you that we're making promises, right? We promise to deliver this feature on this date. And we're going to break those promises. And I think that people do that because again, we all need a sense of direction and a sense of context. We need it for ourselves, our stakeholders need it, our executives need it, our customers need it. Where are we going? And we don't know how to communicate that other than in terms of work. But if we can communicate it in terms of value, right?
So, if you think about Slack, the ability to find conversations is actually somewhat crude. You kind of have to know what you're looking for, right? You're looking for a particular name, which could be somewhat arcane. So, you couldn't actually really say that the ability to find conversations in Slack is as effective as it should be. If you tell your customers, "we are going to make the ability to find conversations more effective and more powerful and more flexible." — "Oh! That sounds good, because yeah, it really needs to be better. We're really excited about that!" You haven't locked yourself into a particular date or a particular implementation. You can explore and discover that as you go and you can tell your customers, "well, here's this thing that we're delivering this week that will make conversation-finding a little bit better in this particular way." And then, "oh! We can do that again. Well, next week, here's this thing that we're delivering that will make it even a little bit better." So, it allows you to plan, and it allows you to communicate without kind of forcing yourself into a model that doesn't actually work when you're building complex software systems.
Jorge: It strikes me that the traditional roadmap is a forecast of what's going to happen that is, by definition, made at a time when your knowledge of the entire situation is imperfect. And the actual process is more like... it's stochastic, right? Every step that you take changes what happens next. If that's a fair read, then this artifact that you're describing is organic in the sense that it needs to be a living document that is revisited often. And a) I'm wondering if that's a fair read and, b) if that's the case, then who is responsible for being the steward of this chart?
Jeff: It is a fair read. And I'm going to struggle with the answer to who is responsible. I think there are two answers. One is the product owner and the product manager. But two is the team. Because... you're absolutely right. Its intention is as a conversation and planning tool, not actually as a document. I don't care what it looked like last month. The point is to continuously have a conversation around, "are we getting where we want to go? What's the next step to go there? And do we still even want to go in that direction?" And so, it's simply a tool for that kind of conversation.
The reason I hesitate is about who owns it or who shepherds it, is the team needs to be having the conversation. And it's less important to me who runs the session or who... you know, in the good old days, many, many moons ago, before pandemic, I would say: "create a three by four grid on a whiteboard and get stickies and put them up on the wall and move the stickies around." It's funny, because a couple of years ago I worked with a team and they were part of an organization that was very, very JIRA driven. And for whatever reason, they decided to just put stuff up on a whiteboard. And it worked perfectly.So, the mechanism is less important than the process. A high functioning team ought to be able to just have this conversation.
Now, I think where it becomes interesting to think about product owners and product managers is the connection with the larger business context, right? Of why are we going in this particular direction? And how do we provide feedback to the rest of the organization about the success of going in that direction? That's really where I think that sort of... I think what you're talking about in terms of stewardship comes in is: this isn't just for teams, it's a way for teams to communicate with other parts of the organization. Or "well, you want to know what we're doing? Well, what we're doing is we're making conversation-finding better, and here's why, and here's how. Here's what we're doing next to move in that direction." And we can have conversations at a higher management level of, "is conversation-finding something that we want to be investing in?" The nice thing about that is that you stop having conversations about, "well, why didn't you deliver the feature that you said you were going to deliver on this date? Your team is not performing." Right? It makes your stakeholder and management-level conversation much richer and more productive, in my opinion.
Jorge: Well, this sounds like a tool that is much needed. And I'm grateful that you are writing and speaking about it. Where can folks go to find out more?
Jeff: Well, they can go to the sussna-associates.com website, is the best place. There's various information about it there. This is something that I have primarily been using in working with actual clients, so I'm just starting the process of exposing it more generally and starting to talk and write about it more generally. So, I wrote a book, that was really about some of the theoretical underpinnings behind this several years ago. I've been toying with the idea of writing another one, much more practical, down to earth about how to use promises and how to use Customer Value Charts in order to run an Agile organization. So, it's very much of a work in progress. And thanks to you for helping me start to talk about this in a broader context.
Jorge: Well, I'm very excited to see where it goes, and, looking forward to having you again in the show sometime, Jeff! I always enjoy our conversations a great deal.
Jeff: As do I! Thanks for having me, and hopefully it'll be sooner than another 18 months when we do it again.