Transcript of Lean vs.

Agile
vs. Design Thinking with
Jeff Gothelf
Jeff Gothelf

Good morning, all right. It's days like today that help me
remember one of my favorite movie lines. One of my
favorite movies is Caddy Shack, and there's a line where
Bill Murray says, "I don't think the heavy stuff's going to
come down for quite some time." It talks about the rain. I
guess you had to be there.

Speaking of movies, I want to talk to you about lean,

agile, and design thinking. I want to talk about principles
rather than processes. I started with a movie quote-

Whose mic? His?

I want to continue this conversation about movies for just

a second-

You're not seeing it?

because I love movies-

Oh, yeah. She turned it off because of the crosstalk.

My favorite movie is Goodfellas. Goodfellas is my favorite

movie. How many of you have not seen Goodfellas?
Wow? Really?

Okay.

Do we have 90 min? 2 hours? Take a little break and

watch it? I'll tell you about a scene in it if you haven't seen
it.

It's a fantastic movie. It's a gangster movie. And this is my

favorite scene in that movie. Now, in this scene, you've
got Ray Liotta, Joe Pesce and Robert DeNiro. All
gangsters. They have a problem in the back of Ray
Liotta's car. There's a problem.

Our A/V friend, why don't you turn your mic back on. He's
pretty clear. He knows which one it is now.

There's a problem. It's late night and they are stopping

off at Joe Pesce's mom's house. That's Joe Pesce's mom
right there in the movie. They're stopping off at her house
to get a knife. A big butcher's knife to take care of the
problem that's in the back of the car. It's late at night but
she wakes up and it's an Italian household so she, of
course, invites them to eat. You have to sit down. You
have to stay. You have to eat something.

So, they're having this late night meal at Joe Pesce's

mom's house. And during this conversation-

It isn't for Kim or Brian. Yeah.

The discussion turns to this painting. It's a painting that

she painted. She's talking about this particular painting
and they're passing the painting around and as they do
that, Pesce says what is one of the most memorable lines
in a movie filled with memorable lines. I actually have the
30 second clip of that right here. Check it out right here.
Okay?

Tom ever tell you about my painting?

No.

Look at this.

It's beautiful.

I like this one. One dog goes one way and the other dog
goes the other way.

One is going east and the other one is going west. So

what?

And this guy is saying, "What do you want from me?"

I love it. Now you have to go see the movie if you haven't
seen it. So, look, I've got one dog going one way. I've got
one dog going the other way and I got this guy in the
middle saying, "Hey, what do you want from me?" How
does this all tie into lean, agile and design thinking? Well,
I'll tell you.

I had a client conversation recently. It was a manager, so

a fairly high ranking manager at a bank and he was in
charge of the digital transformation of that particular
bank. He wasn't a designer. He wasn't a product
manager. He was an agent of change in that particular
bank.

He's managing cross-functional teams, designers,

product managers, engineers and he's trying to get them
all to play nice together in this new agile world. Right?
Every organization is agile. Right? At least they say they
are. And so then how do we make all these products, all
these processes play together.

And he says, "Look, I've taught my tech guys agile. I've

got one dog going one way. Right? I've taught my product
folks lean and lean startup. One dog going the other way.
And in this particular case, he actually had a third dog. It
was the designers and he's looking at how the designers
design thinking. Right?

I've given everybody the trainings and the coaches and

the things that they're looking for. The things they've
asked me for. This magical synergy of processes and
methodologies and ways of working isn't happening.
There's no shared language. There's no shared cadence.
There's no shared definitions of success. There's no
sense of like who ... everyone's running in three different
directions and I'm sitting here in the middle saying, "Hey,
what do you want from me?" Right? I gave everybody the
training they asked me for.
I got agile training, lean, lean startup training and I got
design thinking training. We can't make these processes
work well together.

This got me thinking. This got me thinking a lot about

why that was the case, because by all accounts he was
doing everything right in that he was listening to his
people. He was trying to build cross-functional
collaboration. He was looking for a place for design to fit
into this process. He was getting them all of the insight,
all the training, all the knowledge that they could. But, he
couldn't figure it out.

It's kind of dawned on me a little bit. Is that when we're

looking for these problems to solve, these collaboration
problems. These process problems. These cultural
problems. We're looking at processes as the answer.
We're going to hit everything with a process hammer.
Right? If all you have is this process hammer ... we're
going to hit it with the agile hammer until it works. We'll
hit it with the lean startup hammer until it works. We'll
bang it with the design thinking hammer until works.
Right?

We keep looking for these processes to be the actual

answer to these collaboration challenges that we're
finding ourselves in as designers, product managers,
engineers, makers of digital products and services.

Now the interesting thing is that startups don't have this

problem, generally speaking. Right? Coolest startup ever,
maybe? I don't know which startup that is. That office is
awesome. Startups don't have this problem because
there's just that, there's not that many people to worry
about. Right? You've got a clear set of choices and a
clear set of consequences. You've got a sense ... you
know exactly who you have to do the work and you know
exactly who you don't have to do the work.

Most importantly, you know how much runway you have

and you know what's going to happen if you make
enough wrong decisions. Everybody picks up a little bit of
something. Everybody collaborates. Everybody shares
information. We work to build some kind of a successful
defined product market fit. To find traction for our
startup. And then we get lucky, maybe. Maybe not lucky,
we get successful. Right? And we find that product
market fit and we start to grow the company. It becomes
a high growth company and then a medium sized
business and then a large company and then an
enterprise.

All of a sudden things change. The way that we approach

how we do work. How we collaborate. How we build
teams. How we measure success all of a sudden changes
when we're staring at large piles of money and large
measures of success in an organization. Right? We've got
access to larger teams. We can hire more people. We can
hire more disciplines. We can hire specialists. We've
seemingly endless runway. We'll just keep ... we're big.
We're successful. We've been here for decades. We're
just going to keep going. Nothing's ever going to slow us
down.

If somebody makes the wrong decision, in most cases,

nobody gets fired and in most cases nothing ever really
happens. There's no sense of learning. There's no
curiosity. There's not that what Astro Teller from GoogleX
calls enthusiastic skepticism. Right?

That sense is gone because we're big. We're successful.

We know everything. We've crushed the market.
Nothing's ever going to dislodge us from this leadership
position here. We're big and we're successful. Right?

And yet, every large company that I work with, and I work
with a lot of large companies. Right? Are saying the same
refrain. The same talking heads back and froth. We want
to be lean. We want to be agile. We want to recapture
that innovative spirit. We want to reinvigorate the teams
to the way it used to be when we were smaller. We seem
to be losing that as we scale and we grow up.

I hear this again and again and again. We want to be like a

startup. What's fascinating is that when you start to take
these approaches of lean and agile and design thinking
and you start to stretch them, they tend to break. They
really seem to kind of ... if you read the books, the books
talk about single ... sure there's books on scaling. There's
a lot more books on scaling. But certainly the kind of the
original canon on lean, agile, design thinking is all about
single teams. When we stretch this out to multiple teams,
it starts to break.

And so, the question became why? This is the thing that I
was looking for was why? Because my friend, my friend,
he was also my client. He was managing these teams in a
large organization. He was trying to scale these
processes and it wasn't working for him. He wasn't
finding that synergy. And so I did a bit of scientific
research. And by scientific research, I mean I asked
Twitter and I said why do these processes, lean, agile,
design thinking, why do they seem to break at scale?

And what was fascinating was, the responses came back

that mirror all of my experiences. My anecdotal
experiences in my work. And at a high level, these were
just some of the themes that came back from those
conversations. These will probably look familiar to you,
because again, these are consistent throughout
companies, across industries, across the world in
different countries. We already know what we need to do.
Why do we need to waste time learning?

Again, we're big. We're successful. This learning thing is

fun, but we've got to ship. Right? We've go to deliver.
Process. Lots and lots of process. We get mired in the
approval process. Nothing ever gets done. A mysterious
"they" that block everything. That's the name of my new
band. The mysterious they. Which I love.
We need to see a detailed business plan upfront. Fully
spec'd out or we're not funding anything. Right?
Convince me this is going to be a success because you
can predict the future. Silos, valuing business needs over
user needs. Right? And then lastly, really worried about
trying anything new because we may disappoint our
existing customers. They've come to value certain level of
service from us and if we try things that aren't fully
polished or fully finished, we may end up ruining the
brand.

These are consistent themes that I hear over and over

and over again. When you go out into the market as
leaders of teams or as members or teams or as folks
trying to figure out how to build this collaboration
between product, design and engineering, there are no
shortage of recipes. Right? Everybody's out there going
to tell you here's how you do it. Here' this process and
here's that process and it will all work.

In fact, if you out to the agile community, you're going to

find yourself with at least this many options when it
comes to the processes that you may want to choose.
Now, this is how I feel when I saw this particular diagram
for a second. Look, what this diagram is, is this is a ...
Deloitte consultants attempt to map the agile landscape.
Now look, this is a horrible diagram. But, it's not horrible
because of the aesthetic choices that this consultant
made. It's horrible because it's true. Right?
As organizations try to bridge the gap between design,
product management, engineering, agile, the business,
customer needs and all of those things, every single stop
on this map is a thing that you might be abl to put into
action to try and make those things work more
successfully.

Everything's on here. Right? Everything's on here.

Conbonnet's, scrum and XP and design sprints and five
why's, and research. Everything. Everything's on here.
Again, as an organization or as a team or as a manager of
a team, how do you know which one of these ideas to put
in place? Which ones of these ideas to put in place?

Well, to answer that question, we have to think, we have

to talk really quickly about the root methodology. Agile,
lean startup and design thinking very quickly. Let's talk
about agile very, very quickly. Okay? Agile was born of
software engineers frustration. 17 software engineers
about 17 years ago were frustrated with how software
was being developed. They were missing deadlines. They
weren't shipping to meet ... they weren't meeting
customer needs and a lot of times they weren't shipping
at all and they figured there had to be a better way.

They spent a long weekend at high altitude on a mountain

in Utah and at the end of that long weekend, they
descended biblically from the mountain having delivered
unto us the agile manifesto.
I actually had some friends, it's a true story, I actually
have some friends who live, who recently made a
pilgrimage to Snowbird to go see the whiteboard. We still
call them friends which is, you know? We don't publicize
that.

But the agile manifesto, look, if you haven't read it, the
manifesto is a philosophy. There's nothing in there that
says you will stand up everyday at 9:15 for 50 minutes.
Right? None of that stuff. It's not in there. Right? It's really
about ways of working and perhaps the most interesting
thing about agile is this, agile basically says, look, you are
going to make a plan. You are going to start executing on
that plan and along the way you are going to learn new
things. As you learn new things, it is your obligation to
change course based on what you learn.

That's it. That's agile. That's agility. That's the whole

principle. The principle is, we are going to change course
when we learn new things. That's all there is to it.
However, what we've actually done is we've taken this
process and we've turned it into these recipes.
Organizations are hiring agile into their companies now to
deliver faster, higher quality code for production. For
velocity. That's it. Not for this continuous learning and
improvement, but simply to get more code out faster. The
belief is if we bring in agile, this is what our engineers will
be doing all day and god forbid they stop for a second.
Right? Terrible things are actually going to happen. All of
this in the name of velocity. Velocity. That's the key driver
in a lot of companies today.

Let's crank out the software. The software factory has to

be running 24/7. But the reality is that we can't operate as
a software factory. We're going to integrate agility into
the way that we work. We can't operate as a software
factory. We have to change that because more code does
not equal more value. Not manufacturing products. We're
building system. Right?

Which means that our measure of success ultimately has

to change. The production of software is no longer the
measure of success. If we can start shifting our
organizations that way and that train of thought, we start
to bring in a more customer-centric way of thinking.
Right? Because again, just because you can build it
doesn't mean that you should. That's the thing that I want
you to take away from that particular slide.

So, lean comes in. Lean says, hey, we can put a brain on
this agile process. We've got a good decision making
framework. Lean says, look, traditionally, we've got this
manufacturing mindset where we produce goods and we
push them onto the market. Right? Lean says, well, you
can't predict the future. You don't know how much stuff
to make. You don't know who's going to buy it. So, we're
going to flip that on it's head. We're going to make it into
a pull model.

A pull model simply says, we're going to look at signals

from the market to indicate what we should make. How
much of it we should make. Where we should make it and
when we should make it. And then we are only going to
do that and nothing more. Because anything more than
that is waste. It's potential waste which means it's
potential risk. We don't want to do any of that. And along
the way, we are going to empower our people. The
people closest to the product. The people closest to the
market to make the tactical day to day decisions.
Because they know best. They're the closest. That's all
that lean says. Right?

And lean, when it combined with agile starts to build this

cohesive conversation because it instills the ideas that
your always moving from doubt to certainty. Right? Oh
yeah, we should spec out a business plan for the next 18
months. Actually, you can't predict the future. Right? So,
we need to move forward cautiously. We move forward
cautiously by working in small batches. Sprints. Iteration.
Right? Those are small batches.

This stuff works nicely together. Lean startup comes

along and does a really nice job of bringing lean into the
software world. Lean thinking in the software world.
Basically, Eric Reese said, look, everything that you're
working on is an experiment. It's a test of whether or not
this thing should be built. Not can it be built. Right? It's a
test of should we be working on this and then is we can, if
we should, then the question is can we build a business
around it or whatever the measure of success is at your
organization. Right?

And those experiments are the first versions of our

product. That's what lean startup says. Now, I'll tell you
from experience, no one wants to buy an experiment.
They want to buy apps. They want to buy systems. They
want to buy solutions. They want to buy other things.
They don't want to buy experiments. So, we've got to
figure out how to bring this all together.

In comes design thinking. What is design thinking? Well,

if you ask a lot of people, this is what they think design
thinking is. Right? Can't have design thinking without
post-it notes. You ask some other folks, they think this is
design thinking. Right? I love that guy. That guy forever.

Look, design thinking again, kind of boil this stuff down to

it's core principles, all it says is designers have a set of
tools that they've been using for years to solve design
problems. Why don't we apply those same tools to
business problems? Let's give that a shot. And it's been
fairly successful. Right? You know this. We empathize
with our customers. We define the problems that we're
trying to solve. We ideate on some solutions. We create
some prototypes. And then we test those prototypes.
Sound familiar? Build. Measure. Learn. Right? Think.
Make. Check. All these ideas are in there.

Actually, it fits pretty nicely. Right? The design thinking bit

fits really nicely into the learn piece of the build, measure,
learn loop. People have started to build that process into
the way that they're working. And then they try to attach
the agile production piece to this learning loop. Right?
And this is where we start to see problems because even
in its best incarnations, people are still trying to string
these processes together and we end up with situations
like this, where it's kind of human but not really. It kind of
walks and it kind of talks, but it's not really what we're
trying to achieve.

How do we solve all of this? How do we actually bring this

stuff together? Well, to drive this home, we need to think
about these things as principles. Right? Not processes.
The descriptions of the methodologies that I just showed
you, there was no process in there. It was principles. It
was about empathy. It was about continuous learning. It
was about adapting to change. Right? How do we build
these principles together to change the way that we
actually want to work.

Ultimately, it doesn't matter if you call it agile, lean or

whatever. I've got ten principles to go through in the time
that I have left, so I'm going to move a little quickly. I've
got examples for almost every one of them to share with
you. Each one of these principles is something for you to
consider as a way to underpin how you are thinking about
your work and how you're thinking about your
collaboration with your colleagues in engineering,
product management, your stakeholders and the
business and so forth. Okay?
Let's get started. First and foremost, Principle #1.
Perhaps the most important one. Customer value and
business value are the same thing. It's true. If you make
your customers successful. If you respect their time, if
you build products that are easy to use that are a delight
to use in the right situations that solve real problems for
real customers in a meaningful way, your customers will
reward you. They will buy more stuff from you. They will
tell their friends. They'll tell their boss. They'll do the
things that you want them to do in your products to make
you successful.

Always focusing on what the customer's trying to achieve

will ultimately drive the success of your business. Let me
share with you a case study.

Gibson Guitars is out of business. Did you guys know

this? It's really sad, actually. The Les Paul is gone. Gibson
Guitars noticed that guitar sales were plummeting over
the last few years. They decided to bring in a new CEO.
The new CEO was all about innovation. Innovation for
innovation's sake. Let's get new gadgets out there. New
tools. New technology. New ways to play the guitar. But
what they ignored was the target audience. The target
market.

Part of the reason there was a change in the market for

guitar sales was that the audience was changing. 50% of
new guitar buyers were women. And those women
weren't fixated on the rock gods of old. This is what the
Gibson website still looks like today. Right? But half the
market for guitars these days doesn't care about Slash.
It's not their motivation. They want to buy a guitar and
they want to learn how to work. I'm sorry. How to play.
How to play the guitar. Sorry.

Gibson's new CEO ignored that target market and simply

innovated for innovation's sake. Gibson ran out of
business. Fender Guitar's, by contrast, is thriving. This is
what Fender's website looks like because they
understand who their buyers are. They understand who
their customers are. They're catering to that audience.
They're building not just product, but services for those
folks as well. Online guitar learning systems. Ways for
them to not only purchase the guitar, but learn how to get
up and running very very quickly. Fender is thriving.

What they've done here is they've taken a user-centered

perspective to all of this. Right? Because what they've
done is they've changed the definition of done. Instead of
just shipping product, instead of just shipping the
innovation or the technology, they're looking for the
changes in customer behavior to tell them whether or not
the thing they've shipped actually makes a difference.

Their measure of success is an outcome. This is how they

redefine outcomes. It's a way for us to tell when we've
delivered customer value and, more importantly, it's a
way for us to tell when we're done. Because again,
shipping the product, shipping the software is the
beginning of the conversation with the market. Ultimately,
we need to start to see if we're shifting the behavior. And
the context of use drives everything.

Let me drive this home one last time. Who knows what
this is? Call it out. The [Wankel 00:21:40] rotary engine.
Thank you. The Wankel rotary engine is a complex piece
of machinery. Okay? But, you could take this piece of
machine apart. You could spec out every part. Right
down how to assemble it back together and you can give
it to a qualified individual anywhere in the world. They put
it back together and it would look like this and it would
operate like this. This is a far simpler system. A little
blacktop, maybe some street signs, a little sidewalk,
about it. Divider.

You could recreate this system anywhere in the world and

it would never look like this. This is a unique instance of
that system related to the context of use. The people who
are using that system, the culture, the expectation. You
could take the same exact components and recreate
them here in Boston. It would be different. Right? In
Europe it would be different. In Japan it would be
different. The outcomes are generated by the people who
are using our system. We have to understand those
customers to determine what the best combination of
code, copy, design, features, solution will deliver to them.
Right?

This is output. This is outcome. This is the stuff that we

make versus the behavior change that we're actually
looking for. Customer value. We're looking for those
changes in customer behavior. That's Principle #1.

Principle #2. Working in short cycles. This is essentially

what we're asking our products managers to do. Our
teams, our designers, when we ask them to do long term
planning. Right? The risk here is that we're trying to
predict the future. We're trying to understand what
people will do a year from now. Technology changes too
quickly. Consumer consumption patterns change too
quickly. Instead, we want to make evidence-based
decisions about what we're making. Get something out
into market quickly. Right?

Instead of it taking three months, get it out in a month.

See how it impacts customer behavior. See how the
outcome changes and then based on that, decide what
you're going to do next. The goal here is to start to build
evidence for all of our decision making. Right? So that
we're not just ... we're setting a vision and then we are
course correcting toward that vision with the evidence
that we are collecting.

The things that we put into market teach us whether or

not our ideas are worth investing in further. This is a chart
called the truth curve. It was created by my friend Giff
Constable and I've taken the liberties of adapting it a little
bit. What Giff has done here, is he's laid out a Y axis that
talks about evidence. Right? The Y axis is evidence or
confidence or truth. Right?

How confident are you in your design? In your feature

idea? In your company? In your product? In your
business? The X axis is level of effort. How much effort
do you want to put in to this particular idea? Into your
best guess about how to meet this particular customer
need. If you're in a startup, if you have a new product or a
new feature that you haven't done any work on at all
before, you're over here on the left in the land of wishful
thinking. Essentially, you're down here at the bottom left
hand corner which means you have no evidence that this
is a good idea. You think it is. Right?

So, therefore, you are allowed to spend the least amount

of effort possible to start to discover whether this is a
good idea or not. That's when we do research. Customer
conversations. Paper prototypes. Live data prototypes.
All those kinds of prototyping things.

As the evidence that we get comes back in a positive

way, we start to go up the X axis, which means that we
get to go across and spend more on our ideas.
Eventually, we increase the fidelity of our work to the
point where it's a living, breathing shippable product. But,
we don't want to spend that kind of effort unless we've
got the evidence to prove it. Right?

Unfortunately, anything that you do underneath this

green line is unnecessarily risky. Most of the customers
and the clients that I work with operate over here.
Roughly over here. Very little evidence, full scale
shippable code. Because they believe they know exactly
what their customers want. Our goal is to discover our
way in short cycles. In short feedback loops. As to
whether or not we're building something of value and the
evidence that we're looking for is that change in
customer behavior. And along the way, the questions that
we're asking change. Again, in the early, in the onset
when we're doing this with our product managers, with
our engineers, with our designers. We're asking the
question, should we build it?

And if the feedback says, yes we should, then the

question comes well does it make sense for us as a
business? The questions change as we increase the
fidelity and the level of investment. And again, the two
key framing questions that you always want to use with
your teams. This always brings the conversation back to
learning. It always brings the conversation back to the
risks that we don't know are two key questions to
determine how much you should spend on your idea
during your next short cycle.

First question, what is the next most important thing that

we need to learn? This is a question every team should
ask at then end of every short cycle. At the end of every
iteration. What's the next thing we need to learn? Not
what's the next thing we need to ship. You may need to
ship something to learn it, but the first thing, what's the
next most important thing we need to learn? What's the
biggest risk left in our hypothesis? Right?

And then you ask, what's the least amount of work that
we need to do to learn that? And the answer to this
question is what you're going to do in your next sprint.
You're going to build that experiment. You're going to
build the next iteration of your product. You're going to
build that new feature. Whatever it is. Because it's going
to help you learn the next thing. The learning that you're
doing inevitably focuses on whether or not you're
delivering value to the customer. We're going to work in
short cycles.

Third Principle. Holding regular retrospectives. Now, I told

you the agile manifesto didn't actually say you will stand
up every day at 9:15 for 50 minutes with your friends.
This is true. One of the core agile principles that I love to
implement with every team that I work with is
retrospectives. Retrospectives provide you the ability
after every short cycle. After every iteration, to look back
and reflect on what worked. How did we do? Did we hit
our goals? Did we learn something new? Did we meet
customer needs? Did we work together well as a team?
Right?

We list out our things. I like this one a lot. This one's a
particularly good retro board. I've used this one. The four
L's retrospective. And the goal here is to reflect back on
whether or not we improved the product. Right? Did we
make a change collaboratively as a team? How did we do
with the product? But also, how did we work together?
How did things go in the last iteration? Well, I felt like the
design was the bottleneck in the last iteration. What was
the root cause of that? Let's talk about that and let's
figure out how we can try and unblock that in the next
iteration.

These short cycles allow you to make small

improvements to your product. They also allow you to
make small improvements to your process. And so, if your
collaboration isn't working. If your processes don't line
up. If your cadences or your language or you shared
understanding isn't there, talk about it at your retros. Try
something different in the next sprint. And talk about it at
your next retro. Find the things that help your team
improve.

Principle #4. Go and see. If you're looking for ways to

work better, walk around the office. See what other
teams are doing. Tom Peters called this managing by
walking around. The idea is that you want to look around
and go find the patterns that are already working for
other teams. I like the way these guys did their board.
We're going to borrow that. I like how they presented
their outcomes on a screen and they're always kind of
updating in real time. We're going to borrow that. Look for
the patterns that are working and amplify them. Don't get
hung up on the labels. It doesn't matter if they're lean,
agile, or design thinking. None of these things actually
matter as long as it's helping you work more
collaboratively with your colleagues.

Look for those patterns and bring them into your process.
Okay? Principle #5. Test your high risk hypothesis. We've
been talking a lot about hypothesis, certainly yesterday
and today as well. Every idea that you put forward. Every
product, every feature, every solution, every business
idea, every design is a hypothesis. It's a hypothesis that
you believe is true, but you don't know because you can't
predict the future. Right?

You believe you're going to generate some kind of a

change in customer behavior. Right? If a specific set of
users or customers gain some kind of a benefit from a
feature or a solution that you want to implement. That's
all your hypothesis said. Right? You can take this
hypothesis statement. Fill it out it looks something like
this. We believe that we'll increase retention by 50%.
That's a change in customer behavior. If college age
students have more time for schoolwork, which is
something hopefully they're looking to do. We hope.
Right? With the food delivery service from the university
cafeteria. We think that's a good idea. We know who it's
for. We know why they would care about it. And this is
how we know we've actually succeeded with our product.

This is our best guess about our idea. It may work. It may
not work. And we're going to generate a lot of these
hypothesis. But at the end of the day ... and this is where
a lot of the tension comes in right between lean, agile and
design thinking, is this, we can't test everything. You
need to ship product as well at the same time. We've got
to do product discovery. We also have to do product
delivery. How do we bring this together? Right? What do
we actually test? Well, as you generate these hypothesis,
one of the things that you have to figure out is which
hypothesis do we test first? Which hypothesis do we not
test at all?

I would suggest you map your hypothesis on this matrix.

It's a matrix of perceived value and risk. Perceived value
is just that. You think this is a high impact or a high value
idea, but you don't actually know. And risk is going to be
contextual to your hypothesis. It might be technical risk.
We've never used this technology before or we have to
integrate with a legacy system. It might be design risk.
We're going to completely reinvent the way e-commerce
is done. No one's ever seen it before. That's risky.

It might be market risk. You might be moving into an

adjacent market. You haven't built products for that
market anymore and so you might have to test that
market. So, risk is going to be contextual to your
hypothesis. The hypothesis that end up in the top right
hand corner, the ones that you believe are high value and
the ones you think are high risk, those are the hypothesis
that you should test. Okay?

The rest of the hypothesis fall into the other buckets. For
example, if something falls into this bucket over here,
that's high risk and low value. Throw that hypothesis
away. It's fun to write it, but if it's high risk and low value,
you don't need to be working on it. Hypothesis here that
are high value that you believe are high impact and low
risk, just build those. Write the stories, put them in your
backlog and get those stories out to market. Right? You
have a good sense that it's going to make a difference
and it's low risk to do it anyway.

The things down here in the bottom left are a little weird
in that you don't, you definitely don't have to test them.
And in most cases, you don't have to build them.
Sometimes, some systems, some ideas fall in there that
you need to build that are simply table stakes to get you
to play in a particular marketplace. Like taking payments,
for example. But, you certainly don't need to test that.
Only test the high risk, high value hypothesis. This is how
we start to build balance between product discovery and
product delivery. We don't try to test literally every idea
that we come up with. We look for the ones that we
believe will have high impact that are also particularly
risky for out teams to build.

Principle #6. Do less more often. This is probably the

most important principle that I would urge you to take
away from this. This is one of the biggest challenges that
we found when we were trying to figure out how to do
design in an agile process ten years ago. This was
something that was lost on us for a while. All we tried to
do was everything in just a shorter timeframe. And the
reality is that in a shorter timeframe, you just have to do
less. But the nice thing is is that that short cycle comes
around more frequently. So, you can do less more often.
Take the processes that you're already doing and just
shrink them down to something that will fit inside your
sprint because that sprint will come around again in a
week or in two weeks and you can do it again and again
and again.

One example of this, and don't shoot me if you're a

researcher, traditional research can be wasteful. Right? It
can be. It's not always wasteful, but it can be. I can't tell
you how many days I've lot on the other side of a one-
way mirror eating candy knowing exactly what the next
ten research participants were going to say. Because we
heard it all yesterday eating candy behind the mirror.
Right? We're looking for ....like for example, when it
comes to research, let's ask these important questions.
The questions around what's the fastest way for us to
learn the next most important thing?

Again, what do we need to learn next? What's the fastest

way for us to learn that? If it's talking to customers, great.
Let's talk to customers. But as soon as we start to hear
the same things over and over and over again, let's cut
that process off. Let's move on to the next most
important thing. Doing less more often is absolutely
imperative to making these processes succeed and
making these processes work together. Because you're
never going to fit all the processes ... you're not going to
fit lean, agile and design thinking in a two week sprint. It's
just not going to happen. Right?

You've got to pick and choose the pieces that we need.

Do less more often.

Principle #7. Working as a balanced team. This is critical.

This is probably the thing that breaks these processes
more often than anything else. We have to start to build
these small teams. I can't tell you how many customers I
work with that have 40-50 person teams. 40-50 person
teams do not, are not agile. They don't turn. They don't
react. They don't respond in any kind of timely fashion.
We need to build dedicated teams. Product managers,
designers, engineers. Focus on one initiative at a time.
This idea that designers or product managers can
support multiple projects at the same time is foolish.

Ultimately, there's context switching costs. There's

dependencies. People are waiting for you to do your work
and that the pace, the speed of the short cycles only gets
held up when other people are distracted by other work
that they're actually doing. You want to try to build as
many co-located teams as possible. I understand that's
not the reality for most of us. But at the very least, if
we're not going to be co-located, we have to be awake at
the same time. Collaboration cannot take place if you're
asleep. There's got to be some time zone overlap.
Cross-functional teams. Again, there is no discover team
and a delivery team. There is no design team and a
product management team or an engineering team. The
team is product design and engineering at the very least.
That's the team. Cross-functional teams are the only way
these processes work because that's how you build trust.
That's how you build shared language, cadence, and
that's how you build that shared understanding.

These teams, like lean tells us, needs to be autonomous

and empowered. Because again, think about it. If you're
working in a two week sprint and you ship something and
it was the wrong thing to ship, so what? The cycle just
comes around again and you get to fix that mistake, learn
from it, iterate, improve and get better. The people
closest to the product should be empowered to make the
most relevant tactical decisions about that product
because they know the most. They're there collecting the
data day in and day out. Where is my joke?

Principle #8. Radical transparency. If you want to build

trust with your colleagues in engineering. If you want to
build trust with your colleagues in product management,
be transparent. Show them your work. Talk about the
challenges that you're having. Talk about where you're
stuck. See if they can help you. Transparency builds
trust. It builds that comradery and it starts to break down
those silos that inevitably get in the way of agile teams
and design teams and lean teams and all of these things.
There's all kinds of ways to break down silos. There is
rituals are great. Some of the agile rituals, particularly the
scrum rituals are particularly good for this.

You guys remember the karate kid? I love the karate kid.
Karate kid was great. Ralph Machio is 50 years old, by the
way. There's a sobering fact for you early in the morning.
Karate kid, Daniel comes to Mr. Miagi. He says, look, I
want to learn karate. Miagi says, that's great, paint the
fence. He says, but I want to learn karate. That's great.
Wax my car. Alright, alright. I want to learn karate. What
he doesn't realize is that by going through the rituals,
he's learning karate.

Same thing holds true for some of these scrum rituals.

Particularly, again, there are things that add a lot of value
to driving transparency. For example, the daily stand up. I
like to pick on it, but the daily stand up drives
transparency. Every day, you have to stand up in front of
your colleagues and you have to talk about what you're
doing at work. What challenges you're facing or what
you're trying to get done. And it gets really, really old if
every day one of your colleagues stand up and says, well,
yesterday I bought some shoes online and today I'm
going to put some money on the ponies. Right? And
what's getting in my way is all this work I actually have to
do.

That gets old very, very quickly. Stand ups drive

transparency. Demo days drives transparency. You don't
have to demo code. You can demo an experiment you
did, or a customer interview that you ran. Something that
you learned from. Show other teams that you're doing
research, that you're doing design, that you're doing this
other work and you're building it into your sprints. Build
the transparency using the ritual. Right?

Access to customers drives transparency. Our friend

Jared Spool likes to talk about exposure hours. Two hours
per team member every six weeks and your company
simply succeeds more. Build better products. Access to
customers is critical. Figure out how to make sure that
you can talk to your customers and if not, get creative
around it. Because as my friend David Bland in California
likes to say, he says, look, you can decide what's
minimum, but it's the customer that decides if it's viable.
You need to get that access to customers to help you
drive transparency into your decision making. We're
making these decisions because customers are reacting
poorly to this particular idea that we had.

Access to data drives transparency. Data analytics should

be treated like a utility at your company. Everyone has
internet access. Right? Everyone gets access to coffee
and snacks. Right? Everyone gets access to data. Report
analytics. We have to be able to understand not only the
qualitative side through our research, but the quantitative
side. Waiting in a queue to get some data and by the time
you get to the top of the queue, the BI team can actually
run your report, it's too late. Access to data drives
transparency in our decision making.
Two more. Principle #9. And this one's a tough one,
particularly if you're not in a leadership position. But,
something to consider is incentive structures. This is
again, one of those achilles heals for a lot of
organizations who are going through very public, very
expensive, very big agile and design focused
transformations. They're changing the way people work.
They're changing their staffing models. They're changing
their success criteria, but they're not changing what they
incentivize people to do at work. And so the question
becomes really interesting is what are you getting paid to
do versus what are you being asked to do. And I see this
a lot in large organizations. We want you to be agile. We
want you to be lean. We want you to talk to customers.
And then we learn things and we want to change course,
but that's not what we get incentivized to do. We still get
incentivized to ship figures on time and on budget. And
that's a really difficult conversation to have, particularly if
you're not in a leadership role. But, it's very important.
Change how we incentivize our teams.

Last principle. The way that lean, agile, design thinking

and all these processes work, the principle that binds it
all together is learning. Continuous learning and
continuous improvement. The only way that continuous
learning will happen is if you make it a first class citizen of
your backlog.

I used to work at a company years ago. We had lots of

boards. Conbon boards, scrum boards. We had one of
the boards was a UX debt board. Right. It was the place
where ... it was a confessional is what it was. It's the place
where we went we were like, I'm really sorry we didn't
round the corners. I'm really sorry the animation sucks.
I'm really sorry it's ten steps to the register. Basically,
that's what it was. Right? It was great and the idea was
that at some point in the future, we would go and pull
those cards off that board and put them into the backlog.
Right? Where the work actually happened. And it never
happened. We never pulled stuff off of there and put it in
that back because the backlog always gets new stuff in
it. It always gets refilled.

The only way that learning, design, research, all of these

activities that are important to the creation of successful
digital products and services happens, is if it becomes a
first class citizen of your backlog. It has to go in the same
place.

Here's one way to do it and I've done this a bunch of

times. We write out experiments. The learning, the
research that we're trying to do on a card, a virtual card, a
physical card, however you're tracking your other work.
The real work. Right? We track this the same way. We talk
about what we're trying to learn. We talk about the tactics
that we might use to learn that. We talk about who is
going to do that work and if you do estimations, and I'm
not opening up that can of worms with seven minutes left
in my talk, you can estimate it. Right?
And then, the most important thing, again, is to put that
card in your backlog along where everything else goes.
We explicitly prioritize it against all the other work. The
point here is to make it clear that this is real work that real
people on the team have to do and when they are doing
this work, they cannot be doing other work. And even
more importantly, anything that comes downstream,
anything that's prioritized later than this learning work is
at risk because we may learn something that may change
the prioritization of those things that are downstream
from our experiment. That's the key is to start to make
this work a first class citizen of what you do and if it
keeps getting relegated to other areas of work or boards
or GR tickets or whatever it is, it's going to get lost and it
will be difficult to reintegrate it into the way that we work.

And so, to wrap this up and bring it all together. 10

principles. Principles, not ways of working, not processes,
but ways to think about the way that you're working to
integrate lean, agile, design thinking into a better, more
customer-centric, more evidenced way of working.

Customer value and business value are the same thing.

Work in short cycles. And again, that's relative. If it takes
you a year to go through your cycle today, a six month
cycle is better. Okay? Relatively improve your cycles.
Hold regular retros to understand how you're improving
your product and your process. Go and see. Go and see
how other teams are working. I've lots of clients who go
and visit other companies. Right? They go visit the
companies that are famous for doing this well and they
steal ideas. That's perfectly okay. Test only your high risk
hypothesis. Do less more often. You don't have to do
everything in every sprint. Focus on the most important
things. Work as a balanced team. Build those balanced
teams. Be transparent in everything that you do. Review
your incentive structures or at least ask. Point out the
discrepancies in your incentive structures. And then
lastly, make learning a first class citizen of you backlog.

Thank you very much for listening. I appreciate it.

That's fantastic.

Thank you.

Okay. So, we have a few minutes here for questions. So,

here's how this is going to work. You may have noticed
that we have our fantastic camera crew in the back and
they're recording this. In order to hear your question, they
need us to use the microphone. So, have a question, raise
your hand. One of our lovely volunteers will come find you
and then Jeff will ask. So, what questions do we have for
Jeff at this point? What do you think?

I answered all of them.

Okay. So. JD's got the first one here. So, Thomas is going
to come up. Just raise your hand when you have a
question and Jess or Thomas will find you.
So, I'm working with a company where they're doing XP.
They've got all of these practices and principles in place
in their composed lab. They're trying to be, you know, do
all of the principles and yet, there is the ... it seems
impossible to get around the fact that development
teams and stakeholders seem to be in two different
world. The stakeholders are still driven by business
metrics and delivery dates and customer require, you
know, demands for new products and new releases. And
they're pushing their developers to give me timelines and
schedules and, of course, the developers are pushing
back going, that's not how we're trying to work it. And so,
it's, but how do you get through that wall between the
two sides?

Yes. One of the things that's really important to do, and

that's common. Right? Because again, this comes down
to what those, what the expectations are on those
stakeholders. Right? Somebody's told them, go build the
system and ship it by Thursday. Right? And so, the
question that we need to do ... or, they've got numbers in
their heads that they need to hit. One of the things that's
really valuable and that I've found is a powerful way to
start that conversation at least, is to visualize the
correlation between user behavior, customer behavior
and the numbers that those executives care about.

So, profit, revenue, customer satisfaction. Right? Sales.

Those types of numbers that generally what stakeholders
are thinking about. Those things don't happen without
meaningful changes in customer behavior. And we
actually did this in the workshop yesterday was look at
those high level measures of business health and think
through what are all the leading indicators.

So, what drives profit? Well, one of the things that drives
profit is the reduction in support costs. Right? How do we
reduce support costs? Well, we get people to call the call
center less. Right? We can build products that break
down less or that need less support or whatever. Right?
By visualizing, literally visualizing on a board or in
whatever, with those stakeholders the connection
between the customer behavior and the metrics that they
care about.

It starts to at least point out to them that there is a

customer at the end of this and that we're trying to
impact their behavior and this is why you should care
about that. Because, when we get people to call the call
center less, that actually impacts profit which is the thing
that you care about. That at least starts the conversation.
Then, the next thing they'll say, well, what are we doing to
drive, to reduce the call center costs. Well, I'm glad you
asked. We've got these ten ideas that we've come up
with and we think that these three are going to be the
highest impact ones. But we're not sure which one is the
highest one, so we're going to run a couple of
experiments and test those and talk to some users and
figure it out.
All of a sudden, that becomes or should become a more
palatable conversation to those stakeholders. But, I think
it's crucial that you visualize the connection between
customer behavior and business value. It tends to work,
too. Sometimes. Okay. There's one back there. Yeah.

Hi. So, I'm a designer and I've spent a few years doing
different lean and agile methodologies and one of the
problems that I'm struggling with is it seems we do lots of
experiments and it's great and we're learning but it seems
like it's easy to be short-sighted and just doing small
optimizations instead of looking at that big picture. And
so, as a designer on my team now, I'm trying to figure out
how do we, as a design team go for that long term vision
that like is going to take a lot of work, but then also do
little experiments and, yeah, how do you balance that?

Yeah. Really great question. Because I think that happens

a lot. And you can even see it in very short time frames.
You could start working with a team and they could
identify this big vision thing and then within a week they
are thinking super tactically. Should it be red? Should it
be blue? Should it be over here? Should it be over there?

Every initiative should have a vision. Why are we working

on this? Why is it important to the company? What's the
problem that we're trying to solve here? Either for the
business or for the customer. Right? And someone needs
to own that vision on the team so that when people are
hyper-focused on the leaves, someone can hold a bag
and say, hold on, this is the forest. Not just for the forest,
but for the trees. Like you're focused on the leaves.

Someone needs to own that vision and someone needs

to articulate it. If it doesn't happen at the beginning of an
initiative, I think it's a fair question to ask and say, well
hold on, how does this fit into the bigger picture. Right?
Or, how do we make sure that we're always kind of
focused on the thing that matters most? Somebody on
the team needs to own that. Who is it? Product
management is, it's part of their job I would say for sure.

I've been in senior design roles myself, where it's been

my job to own that or some kind of shared responsibility
there. But, you're right, without that and then regularly
kind of hold that vision up as a mirror to the work that the
team is doing. And say, look this is great, we're hyper-
optimizing right over here, but realistically, we're not
impacting the big picture anymore. We're just kind of
tweaking this little thing. Right? I think that's a fair
conversation. And if no one owns it, I would step up and
own it and keep asking those questions until somebody
says, okay great, now we have a better sense or we can
focus on more valuable activities.

I think we have a couple of questions. One over here.

Yeah.

I think she was next, right?

I don't know who has the microphone.

I can go. I'm kind of curious about the shifting incentives.
Can you give a real world examples of what those may be
like to foster that sort of approach?

So, many times in performance management review

processes, people get rewarded for being heroes. For
individual heroism. For being the rock star, the ninja, the
guru, the person who came in and saved the day. The
processes that we talked about today are about
collaboration. Right? They're about cross-functional
collaboration. Again, it's about the team winning or losing
together. It's about customer behaviors and measure of
success. Building in those kinds of aspects. Those kinds
of facets into the performance management of teams
starts to dissuade the rock star behavior.

Because ultimately, people want ... they way that many

performance management processes take place right
now is, what did you do individually to contribute to the
success of the team? And realistically, we want to talk
about how did the team do and what part did you play in
that? I saw Marty [Kagan 00:52:59] speak a couple of
weeks ago at a conference and he talks about the New
Zealand All Blacks who are the most successful sports
franchise ever. Right. And one of the reasons they're the
most successful is because they optimized their hiring
process by one rule. And, forgive me, it's the No Assholes
Rule. Right.

You're forgiven.
Thank you. Thank you, Jerry. But that's it. It doesn't
matter how good someone is if they're going to, if they're
going to be a negative impact to the team because
they're an asshole. They don't get hired. Those are the
kinds of incentives that we're looking for to build into the
way that we work.

Okay. We have time for one more question.

One more question. In the front.

Hi. Good morning.

Hi.

I'm curious. I'm a product designer. Jodie [Panine

00:53:56] from Boston. I'm curious what your
suggestions would be for implementing some of these
strategies and methodologies within organizations that
are enterprise and operating in a more like old school
framework, like bringing them along into the current age?

Like a bank?

Yeah, like a bank.

Insurance company?

Financial institutions or-

Right. I think most organizations have got the bug. In

other words, the bug in that they're terrified that the
world has changed very, very quickly and is moving very
quickly and they need to do something. I don't come
across many legacy, certainly enterprise level
organizations who haven't realized that the world has
changed around them. It's just a question of how burning
the platform is for that particular organization and how
much they are willing to open, but they feel like they are
putting at risk. By doing nothing, they are putting
everything at risk. So, ways to move this forward is to
start small. That's the way that I've seen it. Particularly,
organizations that are adverse to this or feel like we're in
a regulated industry. There's no way we can do this. It's
to start small. I think if you came in and you said, look,
we're going to change the way everybody works all at
once. Right? That's never going to fly.

But if you can say, for example, look I'm going to take five
people. Right? Give me a designer, a product manager,
two engineers and a copywriter and a strategist or
something. And give us a month, three months. Just time
box this pilot initiative. We'll take on this strategically
relevant thing. We'll work differently in this new way. We'll
set different goals. Different ways of working. We'll be
wholly transparent about the way that we work and we'll
show you the outcomes along the way and the benefits at
the end. We'll set clear measures of success for this way
of working. So, you're running a process experiment,
basically. And you're confining it to a time box.

You're reducing its risk. You're saying, give me a small

group of people for a finite amount of time. We're going
to try working differently and at the end of that, I'm going
to show you how we worked differently, what came out
and whether it was a better way of working. And if I can
prove to you that it's a better way of working, I'd like to
scale this to three teams and then I'd like to scale it to
five and then 15 and then 25 and so forth.

So, start small and create that process experiment. Look,

if you can't get three months, take a month. If you can't
get a month, get a week. Right? The goal is transparency
in a time box, so that you do risk the change. So, people
feel like, alright, I can give five people two weeks to try
something different. That's how you get people to at least
try something new.

What if you're in the middle of what? Okay. So, you guys,

when you go back to work, carve out a time box for
yourself, try something new and then prove it. That it
worked. Right? I mean, the goal here is to prove that it's a
better way of working. Right? And so, the experiments
reduce the risk and setting clear success criteria for that
process experiment. Say, this is how we'll know we're
better. Right? And then prove it to folks over time. It
should start to have the kind of impact you're looking for.
Not always, but.

Excellent. Ladies and gentlemen, Jeff Gothelf.

Thanks very much.