Design Thinking with Jeff Patton

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly podcast. I’m Drew LeSueur and with me today we have Jeff Patton. Jeff tell us a little bit about yourself and what you do.

Where Did All Start

Jeff Patton: Where do I start? I’ve been in Agile development since starting with Extreme Programming in 2000 and later in 2001 finding that was Agile. For the previous ten years I had been in software development in a huge variety of roles, but eventually ended up in product management. After 2000, I stayed in product management, then I worked as a product manager, and then as a consultant with a company called Thoughtworks. These days I’m independent. My focus is on software product companies, people that make software for commercial sale, although I still work with some companies that do IT.

I like the challenge of working with companies where, if they make a product and it sucks, they’re in trouble. For better or worse, in an IT world, sometimes you can get away with making a product that people don’t like very much, because they have to use it. That’s a mouthful!

Four Steps of Design Thinking

Drew: No, it’s great! I watched a video of yours talking about design thinking, kind of labeled “Four Steps of Design Thinking.” Could you explain a little bit about that, just a rough overview, and how you incorporate that into your work? Working with companies that make software products.

Jeff: Yes. Good question.

The design thinking thing has become fashionable. You can go to amazon.com, type in design thinking and find a great number of books about it. It’s become popular at an executive level in a lot of larger organizations.

The tenet of design thinking is, you start by understanding the problem you’re solving. You’ve got to do enough research or gather enough information about the problem before you stop and say, “This is a good idea,” or “This is a solution we should build.” In an Agile context, for instance, we build product back‑logs, but product back‑logs are filled with solutions and not problems. You know, in theory, if we were writing user stories. We’ll talk about who they’re for and why they want to use the stories.

But, design thinking will ask you to go farther back. Stories contain solutions, most of the time. The next step in the design thinking process is an ideation step.

When I’m teaching people design thinking, I’ll ask them, “Tell me about a typical meeting when someone comes in with a problem.” They’ll say, “Well, then somebody will propose a solution.”

Then, I’ll ask, “Then, what happens?” People will usually say, “Well, then we start discussing that solution.” People usually joke and say, “Then we start tearing it down and then somebody will suggest something else or we’ll adjust the solution.”

That’s exactly not ideation. If we were doing ideation, our goal is to come up with tons of solution, a great many solutions, and not stop and evaluate any of them before we’ve come up with a dozen or so.

Does that make sense?

Ideation vs Iteration

Drew: Yeah, it does. When I watched your video, I wrote down the steps and you, to me, hit the first two at least.

If you have a problem, you “ideate” ‑‑ is the verb you used, which I thought that was kind of a cool verb ‑‑ come up with a bunch of ideas and then, you had a step in there that’s “iterate”.

Jeff: Iterate is a troublesome word.

Drew: Right.

Jeff: In Agile development, I started with extreme programming. These days, I teach Scrum because that’s the role that most person using Scrum as a starting part and Scrum uses the term “sprint”, but in extreme programming, they use the term “iteration”.

Drew: I really like that word “iteration”, too, as far as software development goes.

Jeff: But, iteration can mean repeat the same process over and over. But, when you’re talking about a product, a thing, iteration means, well, it means the same thing as rework.

It means I build something and I look at it and say, “Well, that’s not very good.” I change it or I improve it.

If you’re doing the design thinking thing. You ideate to come up with a lot of possible ideas and then, you have to start combining and refining.

You start to take your best ideas and put them together. The only way you can tell if they’re actually good ideas is to prototype them or put them in a little bit higher fidelity and get them in front of people that might use them.

They evaluate them and they say, “Well, no. Not quite.” Then, you make changes. That’s iteration.

In a lot of companies, that’s rework. That’s not getting the requirements right, or all sorts of derogatory terms. But that’s iteration. And if you’re doing design thinking you want to iterate as fast as possible, so we’ll often iterate with simple prototypes. Drew, I steered you towards a client I’m really proud to work with and that’s the Nordstrom Innovation Lab. They’ve got a video on YouTube that’s worth watching.

And one of the practices we’ve been putting in place is a lot more ideation and a lot more iteration, but oftentimes we’re working with solutions which are a combination of software and other things and they involve multiple people. So the way we’ve been iterating recently is by bodystorming. It’s kind of like using improvisational theater.

We have to act out the way the solution goes, and you’d be surprised when you act out a whole buying process for someone in a retail store how you watch it and go “Oh, no it wouldn’t happen that way,” or “That looks kludgy,” or “That doesn’t work,” you don’t have to build any software to iterate.

Drew: So you’re talking about acting out not only, I saw a video where on part of your video you had people with cut‑out pieces of paper and you would have people implement a website on cut‑out pieces of paper. And they’d have a user touch different pieces of paper, and the person behind who was controlling the thing would show different screens which were all implemented drawn on pieces of paper and to have a prototype of what the website might look like.

What you’re talking about here, kind of going beyond that, and have people implementing a whole buying process or something, without actually implementing it, just acting it out.

Jeff: That’s right. I’m trying to figure out what I can tell about you that I’m not under, that the non‑disclosure for, but oftentimes we’re looking at a buying experience where people in retail stores, they’re looking at things, they’re checking information on a mobile phone, they’re texting information to someone and they’re getting responses back.

We’ll act out that whole experience with people pulling out mobile phones and pretending to type something in the phone and pretending to get the right information back. We haven’t implemented anything, there’s nothing on the phone. It’s just that by doing that we realize “Oh my gosh, I’m gonna need this information,” or, “The time it would take to get that is far longer than I wanna wait, so that’s not gonna work,” you know, things like that.

Create A Plan

Drew: And the last step that I saw on your video was of this design thinking kind of process is “create‑a‑plan,” so you identify the problem, you ideate, you iterate on that with prototypes, or whatever, and then you create a plan.

Now, as far as where I come from with Scrum and Agile is there’s a big focus on the shippable product, or potentially shippable product, or releasing early, releasing often. How does this design thinking, this process of figuring out what the problem is first, how does that fit into that and how long should it last?

Jeff: Good questions. Well first off on the plan part, so what I mean by plan and I would’ve talked through is in theory if we’re talking about Scrum process, the plan is a backlog, and I create a backlog. But, a good plan is a plan to learn. Drew, you’ve probably come across, the big buzz in the world today is the lean startup thinking, that you’ve come across?

And a core tenet of this lean startup stuff is validated learning. They redefine the term MVP as ‘minimal viable product.’ The term MVP used to mean, and it still does mean, a product that is viable on the marketplace. A lean startup will say “Let’s not worry about viable in the marketplace, the first thing we have to do is prove that there is a market for what it is we’re trying to build.”

So an MVP in lean startup terms is the smallest possible experiment. So a plan, at the end of a design thinking process might be a series of smallest possible experiments. In fact those smallest possible experiments might actually be part of iteration and the so your question there is “How long does it take to do this design thinking stuff”? I will refer to this as a discovery phase and this is the stuff that in Scrum would have called the sprint zero phase and how long that takes.

I’m finding more and more that the design thinking part if we can join the design thinking part which is a core tenant of lean startup thinking. With Agile delivery mechanisms and if we talk about the iteration part as a validated learning phase so we don’t just build paper prototypes or do bodystorming like I was talking about where we mature that and actually build something working but it’s not potentially shippable.

It’s not the code we want to keep it’s the code we built to learn something from then it starts to overlap with delivery and what I see in working with people like Nordstrom they will go all the way from the design thinking to implementing something they can learn from inside of five days, inside of a week, much faster than anybody’s typical sprint. And when I am talking with people about a discovery phase I’ll generally say a block off two weeks of discovery to drive two to three months worth of development for a smallish team of five to seven people.

Drew: OK. And I’m curious, too. Part of my passion is, I love releasing software, I love being on teams that release software. With design thinking a lot of times we will release the wrong software, right? My understanding is with this process or with this in mind you will be able to focus on releasing the right software. When you are iterating on these ideas, is it always in house that you release them to or have you worked with companies or in your experience, do you iterate on these ideas and release them to other people, like beta users or alpha users or whatever?

Jeff: Well, Yes, beta and alpha users. But like I mentioned I work with product companies and they are not willing to risk releasing something that won’t be successful to a large body of consumers. At least most of them aren’t. What they will do is a lot of split testing or AB testing. If you have heard that term, defining something that is a smaller experiment or a different way of doing things and releasing that to a subset of your audience and lately a subset of your audience for a limited amount of time.

I have one group that I am working with that will come up with something that is a small experiment and release it to a small group of people for three hours on a Sunday and then measure the results and then use that to make a determination about where to go next, whether to iterate it, adjust it or go big.

Drew: That sounds great.

Jeff: You know, like you, design thing is just part of it and like you, what drives me, what I’m passionate about isn’t any of the building of the stuff but what happens after. I like, the pride I take in any of this stuff is knowing that there are people out there using products I built 10‑15 years ago now and they are still in use everyday. It’s about making things, and it’s about getting things out there so design thinking is just a step in a bigger thing.

Drew: That’s a great perspective too. I share that. It’s so awesome when you are creating something that it actually gets used and adds value to people, they benefit from it and that’s one thing that you mentioned too we want to minimize the output but maximize the outcome.

Jeff: Yeah.

Drew: I think that’s a good way to look at it.

Outcomes vs Output

Jeff: That language comes from a lot of different places. The problem with outcome is you can’t measure it until after it comes out. So the outcome is what happens after you ship your product and for better or worse Agile development doesn’t talk very much about that. You don’t see it in a burn down chart whenever I go, whenever I read anything on Agile metrics, none of them are about outcomes they are all about output. How fast we’re building stuff or how good the quality of this stuff is but not how well it does in the world.

Drew: That’s a great perspective. So we are about out of time. Do you have anything that you would like to promote or share with the listeners?

Jeff: For the people out there that might know me they will have looked me up on the web you will find a stale old website that I haven’t updated and I won’t explain that. If you look me up at amazon.com you might find a couple book titles which aren’t coming out but I get known for a practice called story mapping and I promise there will be a story mapping book out before the end of the year.

I’ve just launched a new company with a colleague of mine, Aaron Sanders, called Comakers. I’m going to take 30 seconds but there are the terms co‑making, and co‑creation and we are sort of championed the idea that the model we use a lot for software development is broken. When things work best there isn’t a client and a vendor.

When things work best there is someone that has problems and someone that can build them and the person making things needs to go take several steps in to understand the problems and the person that has problems needs to take several steps towards the maker and understand what’s involved there.

We’re shooting for co‑responsibility so sometimes being honest, I have a problem with the standard Scrum processes or Agile processes where I have got a product owner and a team. Yeah I guess someone needs to decide but I really want all of us to be responsible for those outcomes. I am promoting my company I guess but to me the concept is more important. It is that comaking concept.

Drew: Great! Thanks a lot. We really appreciate your perspectives and for the listeners if you would like to join in on the conversation reach us at Agileweekly.com or at facebook.com/agileweekly. Thanks a lot Jeff .

Jeff: Thank you, Drew.