Adapting an outcome-centric mindset

Hi Josh, nice to meet you. Let's start with an introduction and how you got into the world of product design.

Thanks for inviting me, Jan. Glad to be here. I studied writing in college and I was interested in fiction writing, which is a hard field to work in. After college, I moved to the San Francisco Bay Area and as tends to happen in that place, I stumbled into working in technology. This was in the early 90s. I ended up getting very interested in user experience, user interface design, and I was lucky to land a job with Alan Cooper.

Alan Cooper wrote About Face, and I think he's one of the really influential early designers in software. I worked in his studio for four years and I left when I moved back to New York, which is where I'm from originally. One of the things that started to happen, this was the 2000s, the teams I worked with were getting involved in agile methods.

There was a lot of conflict in those days, there probably still is. There was a lot of conflict between the traditional design methods we were trying to employ in software and agile methods. Traditional design is very holistic and agile software is very incremental. So there was a lot of work to be done on trying to make these two things work together.

I really believed they could and so I started to get involved with the communities that were interested in working on this stuff. Around the end of that decade, I met Jeff Gothelf. Jeff and I were both working as design managers in New York City. I was working on Wall Street; he was working in a startup. We got to know each other and discovered we had very compatible ideas.

At some point, with a third partner, we decided to open up a studio together. We built products together and we were very committed to agile methods, user experience, and cross-functional teams, but we also trained people in how to work that way. We had started calling this method Lean UX by now.

Jeff and I literally traveled around the world together teaching these methods. And from that experience of spending about a year together teaching, we really got our ideas articulated and aligned. We figured out how to talk about them and teach them and that was really where the book Lean UX came from. That was our first book together that came out in 2013.

‍

You’ve written several great books, and one of them is called Outcome over Output. Could you give us your rundown on how to think about outcomes and how to start implementing that way of thinking in our work?

One of the key ideas in Lean UX is, the first writing that Jeff did on Lean UX was an article called Getting Out of The Deliverables Business. It was an article that argued that the job of the UX designer was not to make wireframes. And this I think is an insight too from the agile world.

Agile believes documentation is important, but the less documentation you can get away with the better. Your goal is not to produce specifications and requirements. Your goal is to build highly valuable software. Typically, you have to document your work, but it's a record of what you've done rather than the value that you're delivering.

When you think about that, and you're saying, "We're not in the deliverables business,” well then, what business are we in? We started to talk about that and you hear the community talking about it as being in the business of generating outcomes.

It's really hard to argue with the sentiment that says, "We should be more outcome-focused." Everybody wants that. Nobody's going to argue about that but it's also really hard to do because what is an outcome? Is it just a positive result? Is it profit? You start there and you say, "Okay, it's profit." Or, “It's social good." It's something big and abstract — the subject of many inputs and variables.

As we started to talk about it, one of the things that I discovered in my consulting work is that if you have a really specific and well-defined way of talking about outcomes, it really helps teams on the ground move forward.

Instead of saying, "Well, it's a good result," you say, and this is the definition in the book, "An outcome is a change in human behavior that creates results."

When you start to talk about it that way, a change in behavior that creates results, what you get is a target that's observable. We can see people behave and it’s measurable because once you can see it, you can count it. The more we use that idea and the more I use that idea in my practice, the more power I found that it has. So that was when I decided to write the book Outcomes Over Outputs.

As a side business, Jeff Gothelf and I run a small publishing company called Sense & Respond Press. We've published about a dozen books by now. They're small books designed to be read in a single sitting or two.

I decided to do this book on that press as a way of helping people understand this notion of outcomes. Not just a vague idea but a very specific idea that you could use in lots of different contexts inside organizations; both for product development and for process change and in service-design contexts. That's where that book came from.

You mentioned a few benefits in terms of getting teams to work better together, which is great. But how would this get presented to stakeholders? How would you get those people on board on that way of thinking?

The modern products and services that we're working on are complex and the relationships of the parts are unpredictable. If you look at the social networks, for example, the origins of Twitter were that you could broadcast an SMS to a small community. Look at the crazy unintended consequences that Twitter has had on society. That would have been very difficult to predict by that small founding team.

More concretely, a lot of what happens in our product development process is we have this idea of a feature, we work really hard on the feature, we ship the feature, and it functions. In other words, it meets the specification, it does what it's supposed to do, but it doesn't create any value for the organization.

I think if you've spent any time in product development, you've had that experience of working long and hard on a feature. You ship it and then nothing, crickets. Or even worse, you put it in the world and you have no idea whether people are using these features. And then you just keep going and making more features.

The idea of being more outcome-focused is to say, "Look, the unit of success here is not counting how many features we deliver over the course of a year." The unit of success here has to do with the value that we create for our users, our customers, and our business. That unit is hard to define.

If you just say that the unit of value is profit, revenue, cost reduction, whatever, that's true as far as it goes, but it's very hard to work on. If I'm in a large organization, imagine a bank that employs 100,000 people and I say to a team of five or six software developers, "Your mission is to make the bank more profitable." It's absurd.

How do you scale that down to a team size mandate? You need some intermediate measure and that intermediate measure is, what do the customers do that creates value for the bank? You could say to that team, "Your mission is to get more people to sign up for our mailing list." We believe that that will create value for them and for the bank. "Your mission is to get more people through the mortgage application flow." Some other team's mission is to get them to that flow, your job is to make sure they get through that flow successfully.

That's very different than telling a team, "Build a new mortgage application product." That's the output, build a new product. If you say to the team, "Make sure that more people successfully apply for or can successfully apply for mortgages," that's a really different mission.

It may ultimately result in the team having to make some software or make changes to the software, but the measure of success is not, "We changed the software." The measure of success is, "Look, we used to get an abandonment rate of X%, we've reduced the abandonment, and now we get more people through the flow."

‍

That's great and I think it's a good leeway to talk about the differences between user outcomes and business outcomes. How do you weigh those two, and which one comes first? Do they impact each other?

Yeah, very much so. I think this is where a service design mindset is very useful because it's very rarely the case that we are designing systems these days that serve a single end-user. We are designing systems that serve lots of different constituents and we need to understand them, understand what their goals and motivations are, and how they get value from participating in the system.

To keep it really simple, your sponsoring organization, whether that's the company you work for, or the client you're working for, or the government that you work for, they are sponsoring your work because they have some organizational goal. Just to simplify the language, we'll call that the business outcome. Then that business is serving some constituent, we'll call that person a user. Although in the B2B world, you typically have customers and users.

Those people have their own definitions of value. So the basic idea is that you need to think about a logic here that if we serve the customer's goal, the customer will do things that create value that will benefit us as the sponsoring organization. You need to understand both of those. I think when you conflate them, if you treat them as the same thing, bad things start to happen.

For example, one of the stories that I like to tell is about John Deere. I don't know if you're familiar with John Deere, but John Deere is a huge manufacturer of agricultural equipment. They are the big, green, and yellow tractors that we're very familiar with here in the US.

The last few years have been filled with controversy for them because traditionally, farmers are very do-it-yourself people. You buy a new tractor and the first thing you do is you take a wrench to it. I have a friend who grew up on a wheat farm and he recalls as a kid, the first thing they would do when they would buy a new piece of farm equipment is they'd take their wrenches to it. They'd remove all the parts that they felt were unnecessary and they'd put them in a barn somewhere.

Then they would familiarize themselves with the machine because farmers work on a very tight schedule and if the machine breaks, you can't put the seed in the ground, or you can't harvest the crop, you're in trouble. So they need to be self-sufficient. They need to be able to repair their machines.

Well, what John Deere did recently as their machines have become more and more computerized, they've offered these incredible benefits of computerization. These machines can follow GPS routes now, they can report diagnostics back to headquarters. John Deere made a policy decision that you weren't allowed to work on your own machines anymore; only authorized John Deere repair people could work on those machines.

So, what it meant is if your machine broke down in the middle of harvest, for example, and you're out in the farmland in America, you're 50 miles from the nearest authorized repair person, you have to make a phone call. That person has to drive out to your farm, plug in his authorized computer repair unit, and fix your machine. It could be hours. You could lose a whole day.

That's a decision that obviously benefits John Deere. They get more service revenue; their authorized dealers get more revenue and obviously harm the end-user. It's a decision that's made with the business interest in mind at the expense of the end user's interest. If you think about the outcomes, the farmer's outcome is to get back to the business of farming as quickly as possible in the event of a needed repair. They're not serving that outcome. They're sacrificing that outcome to the business's need to direct more business to their authorized service centers.

How do you see user experience design and agile working together? Are there ways to get people talking about this?

One of the things I do is train teams in how to combine scrum methods in agile with user experience. Scrum is quite an orthodoxy and it says, "This is how you do scrum," even though it's a framework for work. How do you make user experience work in that?

Scrum has this idea called the definition of done. We all know that this bit of work is done when it meets these criteria. It has acceptance criteria and it has this definition of done that says it has to meet this standard. Well, all of that applies only to the output. All of that applies only to the software that you're making. From scrum's traditional agile point of view, when you've shipped the feature, you're done.

What you need to then have with your team is a conversation about, "Okay, we've made this thing, but the work isn't over because we have to validate," that's a really important word, "we have to validate that the thing that's done is doing the job that we want it to do — that it’s creating the outcome."

I teach teams that you actually need two ideas. You need "done", which is the output is finished and you need "validated", which is that the output we've made is creating the outcome that we want. First, you get to "done", and then you put it in the real world, and you watch how people use it, and that's where you do that validation work. You need to get your team moving beyond "done" and get them to validate it.

For designers joining a Scrum or Agile team, how could they best prepare themselves or what should they look out for?

Well, fireproof underwear, just joking. I think you really want to have a conversation with your team about what success looks like. And as I was saying earlier, that the more junior you are on the team, the more likely you are to be asked to just make those screens look good. I think the mission of the user experience designer and the path forward is to help the team—not to argue for a different process because that tends to be tough—but to help the team understand what the user is doing and to guide the team through a process of user insight.

That tends to influence things more than arguing for a specific process. Nobody likes to see people struggle with their product. As long as I've been doing this work, the most powerful thing that I've found is to get the user to use the product and show the team the process of the user using the product. They look at it and they're like, "Oh my God, we were wrong." To me, that's the thing. It's like exposure to the end-user. Getting people to see what the end-users need, and then you work from there.

If you’re in a position where design teams practice usability testing, it could even be helpful to share the results with the entire product team.

Yeah, I really believe in that, but one step better than sharing the results is having them sit in on the tests. Having them sit behind the glass or stream it over video or whatever it is; have people watch live. For some reason, and I don't know why this is because I like to think of myself as a pretty good writer and I've written lots and lots of research reports, and they are just not anywhere close to impactful or not as impactful as I would like them to be. You invite an executive or a team member to come sit in on two usability tests, just watch two users use your product and it changes hearts and minds.

They become believers...

Yeah. The first time I ran a usability test, literally the first one I ever ran in my career, I was working with a very good technology team who didn't believe that the software had a problem. I was early in my career. I'd literally come from answering tech support calls. I was hired in this company to be a tech support person and we were getting all of these calls on a daily basis that said people don't understand this one critical feature in the product. And because of that, they weren't using the product.

I made an argument to my boss, "Let me run a usability test. Let me record it. Let me share it with the tech team." We did that. We brought six users in, we videotaped it, and we shared the recordings with the tech team. This was in the early 90s so we literally had to FedEx video cassettes across the country.

I did the tests, I compiled the video cassettes, and the next day I put them in FedEx. The day after that, they sat down to watch them. I'll never forget the head of the team. He called me up the next day and he said, "Look, when we started watching these tapes, we saw the first user, and we said, "Where did Josh find such a stupid user?" And then we watched the second tape, and we thought, "Man, Josh has found two really stupid users." And by the third tape that we watched, we were like, "Oh, maybe there's a problem."'

He said, "By the time we got to the fourth or fifth one, we were all in. So let's get going, where do we start? Let's fix this.” That's the first time I ever did it and I think I've had that experience over and over and over again that getting people to just watch that experience is super, super powerful.

What about writing case studies and portfolios — we now know the importance of outcomes, but how do we communicate that in our work?

Well, I think one of the interesting things is that there's a real tension there for designers. Designers do a lot of different things, but there's a whole part of the design job that I think is quite invisible even to other designers because a lot of our work is about understanding what people need and making strategic decisions about what to deliver and really important, what not to deliver.

This is one of the things that I think is really interesting as a hiring manager. When I talk to designers about their case studies, I'm really interested in the preliminary sketches where I get to see all the directions that they explored and didn't take. So, I tried 10 different ideas here and these are the nine that I threw away, and here's why I threw away these nine ideas.

If a designer will show me that kind of work as a hiring manager, I'm really excited because what that tells me is that they're really thinking rigorously about the possibilities and they're comfortable. I think a key thing in design is iteration and not holding onto your ideas too tightly. I think it's important because that's stuff that we typically don't see, but you can show that in portfolios.

Some of that research process, that decision-making, that how did we come to the insight process, it's hard to see, and it's hard to visualize. So designers, one of the great values that we bring is that we make things concrete. We take an idea and we manifest it concretely in an app or something like that. Portfolios tend to showcase that.

I think it's really important, though, for designers to be able to talk about the results of their work, "Well, as a result of this beautiful thing I made, look at how beautiful this finished product is," or whatever. I think that the more junior you are in your career, the less influence you have on those questions and so you tend to say, "Well, I'm the junior designer on the team. I made this drawing. I have no influence on the strategic impact of this work, but look at how beautiful this drawing is." Yes, that's actually something to brag about in a junior design portfolio.

As you get more seniority and you get more influence on the decision-making, I expect to see more conversation about your strategic contribution and the results of your work. How you made your users more successful, for a mid-level designer and for a senior designer, how you made your business more successful.

Thank you, that’s great. Any last pieces of advice before we round up?

The last piece of advice is just that being more outcome-centric is hard. I think a lot of times people talk about these methods for working. Certainly, I'm somebody who believes in this outcome-centric way of working and I think a lot of times when we advocate for these methods, we want to sell them. We want to say, "I love working this way. I think it's valuable. You should do it."

I think sometimes we forget to talk about, first, that any kind of change is hard. But also, this kind of change, this specific method is simple, but it's not easy. In other words, it's simple in the sense that it's easy to describe, but it's hard to do and it requires practice. A lot of times, teams will try something, they'll struggle with it, and they'll give it up.

I would say if you're trying to be more outcome-centric, you have to set expectations for yourself and your team that it's going to be hard. It's going to require taking a number of shots and practicing to learn how to do it and to get it right, and to start seeing the value.

I just want to give people permission to approach this as you would approach anything else that's difficult. You don't learn to ski without falling down and so you don't learn new methods of work without allowing yourself to make mistakes and to recover.

Thank you so much for your time, Josh. Do you have a place where we can find you online? What book would you recommend we first pick up from your publishing company?

You're very welcome. Thanks for inviting me to have the conversation. If you're interested in learning more about outcomes you can get my book Outcomes Over Output. I would say that it is a short book, so if you don't like it, at least it'll be over quickly. If you want more tactical advice for how to be a designer on an agile team, you can look at Lean UX. It's currently in its second edition. Jeff and I are working on the third edition.

If you're interested in thinking or convincing your executives to change how they're working, you can look at the book that Jeff and I wrote together called Sense & Respond. That is really a book that makes the business case for thinking about these methods.

You can find me online on my website joshuaseiden.com, and you can get all these books online wherever books are sold.