In this episode, Jeff Sussna, Founder and CEO at Jeff Sussna & Associates and author of Designing Delivery (O’Reilly), joins Matt and Mike to share his experiences helping organizations implement best practices for digital service delivery. He discusses promise theory, value charting, and the role APIs play in the digital ecosystem.
You can listen to the episode:
Typically Jeff and his team are brought into a company once they’ve started an Agile or DevOps implementation and it isn’t working. Rather than tell them which approach to use, he teaches companies to take a methodology-agnostic approach and focus on how to “make things a little bit better everyday.” As Jeff put it, “I’m more of a repair and tune-up shop than a new car dealer.”
The cost of change
Jeff points out that software-as-a-service transforms the relationship between customer and provider. In the past, the effort of installing and maintaining software fell to the customer. Now, with SaaS platforms, the work of maintenance — and incremental improvements — lands squarely in the providers lap. As a result customers expect the product to continuously evolve and improve over time.
Make your work smaller
For a lot of organizations, Jeff says their fundamental problem is that they are trying to do things that are too big. Making things small can help the improvements start to flow throughout the organization. He tells the example of trying to move from committing code changes every eight days to committing them up to ten times per day. Instead of trying to make a big change to your processes, try making smaller ones, first. For example, commit every seven days, then every six, days and so forth. “So much of my work,” Jeff says, “is asking ‘How can we shave a half a day off?’ or ‘How can we reduce on hand-off?’ and so forth.”
Consumed by unplanned work
One of the places this plays out is with over-burdened operations teams. Often these teams are “consumed by unplanned work.” It’s a bit like a vicious cycle. For example, ops teams might say “We know we need to do automated deployments instead of manual deployments but, since we are doing manual deployments we don’t have time to automate the work.”
Jeff’s approach is to ask: “What could you spend 20 minutes doing that would give you back an hour of your time?” Then, “What could you spend an hour doing to get back two hours of your time?” and so on.
The relationship between service and product
In the world of “products,” a customer buys the item, for example, a car and then drives it when and where it suits them. How they use the product is up to the consumer, not the producer. However, with services (for example, dry cleaning), it is the continuing relationship between consumers and producers that is important. Services involve making (and living up to) promises.
However, as Jeff points out, it is increasingly common for consumers to interact with all sorts of services while they are purchasing a product. For example, your new car might have Apple CarPlay installed. You may need to deal with a finance loan service in order to purchase the car, and so forth. So the clear distinction between products and services is breaking down in this new economy.
Today operations are part of the customer experience and part of your purchasing decision.
The importance of data
Sussna says “most companies are just starting to wrap their heads around” the importance of data. In this world of “digital service delivery” providing value by collecting data is a good example of this. Companies can use data collection to answer the fundamental question “What should we do next?”
APIs allow you to discover things like “what data do our customers want?” and “what are they trying to accomplish?” Collecting and sharing that information within the company can transform the way you do product management.
Value charting
One of the things Sussna & and Associates has developed is the technique of “value charting” — a visual technique for doing continuous discovery and delivery. It allows you to chart the promise you make to your customers, how well you fulfill them, and whether they are even the right promises to make. Value charting is customer-centered because it’s about benefit, not function. It lets you create an evolving roadmap that is not focused on features and delivery dates. By mapping promises and expectations instead of features and dates, Value Charting gives you the agility you need.
Helping somebody accomplish something
The notion of service — boiled down to its essence is about “helping somebody accomplish something.” Jeff urges his client to ask the question, “If your software disappeared from the face of the earth, what would become harder, or more expensive, or slower for your customer to do?”
APIs don’t provide indirect value
Jeff quipped that he wanted to make a little bit of controversy when he told us “I don’t believe APIs provide any indirect value.” Instead, he said that some APIs provide direct value but not just to the end customer. Sussna helps his clients explore the answers to three key questions: 1) “What help does your customer need,” 2) “What help do you provide,” and 3) “What help do YOU need?”
“It is important to remember,” Sussna says, “that every API has a customer — even if that customer is another provider in the chain. Companies need to think about designing and building and operating that API or service regardless of who your customer is.”
Scaling with promise theory
You don’t always know where your service fits in the chain of services leading to the customer. And it is important that you do not know to scale your solution outward. Jeff referred to Mark Burgess’ “Promise Theory” as a drive in his value charting approach. Promise theory is “a mechanism for modeling how to deliver scale and reliability in unreliable environments where the overall value to the customer emerges from the value that each of the parts provide to each other.”
The value of design thinking
For Sussna, design thinking is about making user-centered decisions about how things should work and how you should access them. In the end, it’s all about who is the user, what do they need to do, and how well can they use what I built to do it.
There are many other insights to be gained from the episode. Follow the podcast on SoundCloud or subscribe to our newsletter to get summaries of the episodes.
