Design Thinking with Jeff Patton

Episode 67

July 04, 2012

17:40

TBD

tbd

The Agile Weekly Crew and Jeff Patton discuss design thinking, ideation and lean startup.

Episode Notes

Drew LeSueur sits down with Jeff Patton to discuss:

Design Thinking

Ideation

Iteration and re-work

Potentially shippable product

Lean Startup

Split Testing

Transcript

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.

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!

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?

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.

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 bui