Technology Trends: Frameworks for Design

DON NORMAN: The new me is beauty.

(Laughter) Yeah, people used to say, "Norman's OK, but if you followed what he said, everything would be usable but it would be ugly." Well, I didn't have that in mind, so ... This is neat. Thank you for setting up my display. I mean, it's just wonderful. And I haven't the slightest idea of what it does or what it's good for, but I want it. And that's my new life. My new life is trying to understand what beauty is about, and "pretty," and "emotions." The new me is all about making things kind of neat and fun.

And so this is a Philippe Starck juicer, produced by Alessi. It's just neat; it's fun. It's so much fun I have it in my house -- but I have it in the entryway, I don't use it to make juice. In fact, I bought the gold-plated special edition and it comes with a little slip of paper that says, "Don't use this juicer to make juice." The acid will ruin the gold plating.

So actually, I took a carton of orange juice and I poured it in the glass to take this picture. Beneath it is a wonderful knife. It's a Global cutting knife made in Japan. First of all, look at the shape -- it's just wonderful to look at. Second of all, it's really beautifully balanced: it holds well, it feels well. And third of all, it's so sharp, it just cuts. It's a delight to use. And so it's got everything, right? It's beautiful and it's functional. And I can tell you stories about it, which makes it reflective, and so you'll see I have a theory of emotion. And those are the three components.

Hiroshi Ishii and his group at the MIT Media Lab took a ping-pong table and placed a projector above it, and on the ping-pong table they projected an image of water with fish swimming in it. And as you play ping-pong, whenever the ball hits part of the table, the ripples spread out and the fish run away. But of course, then the ball hits the other side, the ripples hit the -- poor fish, they can't find any peace and quiet.

Is that a good way to play ping-pong? No. But is it fun? Yeah! Yeah.

Or look at Google. If you type in, oh say, "emotion and design," you get 10 pages of results. So Google just took their logo and they spread it out. Instead of saying, "You got 73,000 results. This is one through 20. Next," they just give you as many o's as there are pages. It's really simple and subtle. I bet a lot of you have seen it and never noticed it. That's the subconscious mind that sort of notices it -- it probably is kind of pleasant and you didn't know why. And it's just clever. And of course, what's especially good is, if you type "design and emotion," the first response out of those 10 pages is my website.

Now, the weird thing is Google lies, because if I type "design and emotion," it says, "You don't need the 'and.' We do it anyway." So, OK. So I type "design emotion" and my website wasn't first again. It was third. Oh well, different story.

There was this wonderful review in The New York Times about the MINI Cooper automobile. It said, "You know, this is a car that has lots of faults. Buy it anyway. It's so much fun to drive." And if you look at the inside of the car -- I mean, I loved it, I wanted to see it, I rented it, this is me taking a picture while my son is driving -- and the inside of the car, the whole design is fun. It's round, it's neat. The controls work wonderfully. So that's my new life; it's all about fun.

I really have the feeling that pleasant things work better, and that never made any sense to me until I finally figured out -- look ... I'm going to put a plank on the ground. So, imagine I have a plank about two feet wide and 30 feet long and I'm going to walk on it, and you see I can walk on it without looking, I can go back and forth and I can jump up and down. No problem. Now I'm going to put the plank 300 feet in the air -- and I'm not going to go near it, thank you. Intense fear paralyzes you. It actually affects the way the brain works.

So, Paul Saffo, before his talk said that he didn't really have it down until just a few days or hours before the talk, and that anxiety was really helpful in causing him to focus. That's what fear and anxiety does; it causes you to be -- what's called depth-first processing -- to focus, not be distracted. And I couldn't force myself across that. Now some people can -- circus workers, steel workers. But it really changes the way you think.

And then, a psychologist, Alice Isen, did this wonderful experiment. She brought students in to solve problems. So, she'd bring people into the room, and there'd be a string hanging down here and a string hanging down here. It was an empty room, except for a table with a bunch of crap on it -- some papers and scissors and stuff. And she'd bring them in, and she'd say, "This is an IQ test and it determines how well you do in life. Would you tie those two strings together?" So they'd take one string and they'd pull it over here and they couldn't reach the other string. Still can't reach it. And, basically, none of them could solve it. You bring in a second group of people, and you say, "Oh, before we start, I got this box of candy, and I don't eat candy. Would you like the box of candy?"

And turns out they liked it, and it made them happy -- not very happy, but a little bit of happy. And guess what -- they solved the problem. And it turns out that when you're anxious you squirt neural transmitters in the brain, which focuses you makes you depth-first. And when you're happy -- what we call positive valence -- you squirt dopamine into the prefrontal lobes, which makes you a breadth-first problem solver: you're more susceptible to interruption; you do out-of-the-box thinking. That's what brainstorming is about, right? With brainstorming we make you happy, we play games, and we say, "No criticism," and you get all these weird, neat ideas. But in fact, if that's how you always were you'd never get any work done because you'd be working along and say, "Oh, I got a new way of doing it." So to get work done, you've got to set a deadline, right? You've got be anxious. The brain works differently if you're happy. Things work better because you're more creative. You get a little problem, you say, "Ah, I'll figure it out." No big deal.

There's something I call the visceral level of processing, and there will be visceral-level design. Biology -- we have co-adapted through biology to like bright colors. That's especially good that mammals and primates like fruits and bright plants, because you eat the fruit and you thereby spread the seed. There's an amazing amount of stuff that's built into the brain. We dislike bitter tastes, we dislike loud sounds, we dislike hot temperatures, cold temperatures. We dislike scolding voices. We dislike frowning faces; we like symmetrical faces, etc., etc. So that's the visceral level. In design, you can express visceral in lots of ways, like the choice of type fonts and the red for hot, exciting. Or the 1963 Jaguar: It's actually a crummy car, falls apart all the time, but the owners love it. And it's beautiful -- it's in the Museum of Modern Art. A water bottle: You buy it because of the bottle, not because of the water. And when people are finished, they don't throw it away. They keep it for -- you know, it's like the old wine bottles, you keep it for decoration or maybe fill it with water again, which proves it's not the water. It's all about the visceral experience.

The middle level of processing is the behavioral level and that's actually where most of our stuff gets done. Visceral is subconscious, you're unaware of it. Behavioral is subconscious, you're unaware of it. Almost everything we do is subconscious. I'm walking around the stage -- I'm not attending to the control of my legs. I'm doing a lot; most of my talk is subconscious; it has been rehearsed and thought about a lot. Most of what we do is subconscious. Automatic behavior -- skilled behavior -- is subconscious, controlled by the behavioral side. And behavioral design is all about feeling in control, which includes usability, understanding -- but also the feel and heft.

That's why the Global knives are so neat. They're so nicely balanced, so sharp, that you really feel you're in control of the cutting. Or, just driving a high-performance sports car over a demanding curb -- again, feeling that you are in complete control of the environment. Or the sensual feeling. This is a Kohler shower, a waterfall shower, and actually, all those knobs beneath are also showerheads. It will squirt you all around and you can stay in that shower for hours -- and not waste water, by the way, because it recirculates the same dirty water.

Or this -- this is a really neat teapot I found at high tea at The Four Seasons Hotel in Chicago. It's a Ronnefeldt tilting teapot. That's kind of what the teapot looks like but the way you use it is you lay it on its back, and you put tea in, and then you fill it with water. The water then seeps over the tea. And the tea is sitting in this stuff to the right -- the tea is to the right of this line. There's a little ledge inside, so the tea is sitting there and the water is filling it up like that. And when the tea is ready, or almost ready, you tilt it. And that means the tea is partially covered while it completes the brewing. And when it's finished, you put it vertically, and now the tea is -- you remember -- above this line and the water only comes to here -- and so it keeps the tea out. On top of that, it communicates, which is what emotion does.

Emotion is all about acting; emotion is really about acting. It's being safe in the world. Cognition is about understanding the world, emotion is about interpreting it -- saying good, bad, safe, dangerous, and getting us ready to act, which is why the muscles tense or relax. And that's why we can tell the emotion of somebody else -- because their muscles are acting, subconsciously, except that we've evolved to make the facial muscles really rich with emotion. Well, this has emotions if you like, because it signals the waiter that, "Hey, I'm finished. See -- upright." And the waiter can come by and say, "Would you like more water?" It's kind of neat. What a wonderful design.

And the third level is reflective, which is, if you like the superego, it's a little part of the brain that has no control over what you do, no control over the -- doesn't see the senses, doesn't control the muscles. It looks over what's going on. It's that little voice in your head that's watching and saying, "That's good. That's bad." Or, "Why are you doing that? I don't understand." It's that little voice in your head that's the seat of consciousness.

Here's a great reflective product. Owners of the Hummer have said, "You know I've owned many cars in my life -- all sorts of exotic cars, but never have I had a car that attracted so much attention." It's about attention. It's about their image, not about the car. If you want a more positive model -- this is the GM car. And the reason you might buy it now is because you care about the environment. And you'll buy it to protect the environment, even though the first few cars are going to be really expensive and not perfected. But that's reflective design as well. Or an expensive watch, so you can impress people -- "Oh gee, I didn't know you had that watch." As opposed to this one, which is a pure behavioral watch, which probably keeps better time than the $13,000 watch I just showed you. But it's ugly. This is a clear Don Norman watch.

And what's neat is sometimes you pit one emotion against the other, the visceral fear of falling against the reflective state saying, "It's OK. It's OK. It's safe. It's safe." If that amusement park were rusty and falling apart, you'd never go on the ride. So, it's pitting one against the other. The other neat thing ...

So Jake Cress is this furniture maker, and he makes this unbelievable set of furniture. And this is his chair with claw, and the poor little chair has lost its ball and it's trying to get it back before anybody notices. And what's so neat about it is how you accept that story. And that's what's nice about emotion.

So that's the new me. I'm only saying positive things from now on.

JEFF GOTHELF: Hey, folks. Good afternoon. You made it. One more to go. And once again, I find myself in the unenviable position of being between you and beer. All right, but to get through this, I'm going to tell you a lot of stories. I love telling stories. My kids, my wife are kind of fed up with that. But you kind of have to listen to my stories. So, I'm going to tell you some stories about that.

I want to start with a story about my favorite movie. I love movies. My favorite movie is Goodfellas. How many of you have not seen Goodfellas? I just don't get a sense. Do we have like two hours to take a break, watch it? We'll watch it later.

It's a great movie, but it's 25 years old now, which is really kind of depressing, a little bit. This is my favorite scene in the movie. It's a gangster movie. If you don't know it, it's got an all-star cast. It's got De Niro. It's got Pecci. It's got Ray Liotta.

And this is my favorite scene. This is a late night-meal that's happening at Joe Pesci mom's house. Now, what's happening in this scene is De Niro Pecci, and Ray Liotta, have a problem in the back of Ray Liotta's car. It's in the boot. It's in the trunk.

And they're stopping off, late night, at Joe Pesci's mom's house to get a knife, big knife, so they can solve the problem that's in the back of the car. Now, it's late night. They make a little noise in the kitchen. She wakes up. It's an Italian household, so, of course, she invites them to eat.

They sit down. They have a meal. Doesn't matter that it's midnight or whatever it is. And through the course of the discussion over dinner, the conversation turns to this, which is a painting that Joe Pesci's mom painted. And as they're passing it around, Joe Pesci says one of the most iconic lines, I think, in a movie filled with iconic lines. And I actually have the clip here. It's 30 seconds long. This is what he says. Listen.

[VIDEO PLAYBACK]

- 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?

[END PLAYBACK]

JEFF GOTHELF: It's great. One dog going one way, one dog going the other way. This guy in the middle saying, hey, what do you want from me? How is this relevant to anything that we're talking about today? Fair question. OK, here's how. I was having a conversation with a client of mine in the US. And this gentleman was in charge of transforming a division of a bank into a modern, digitally-powered banking division.

And he said this to me, he said, look, I'm trying to get my teams to work well together. I got my tech teams learning Agile, one dog going one way. I got my product folks, they're learning Lean and Lean Startup and those types of things. I got one dog going the other way. He actually had a third dog in the race. It was the design team, which was good. I was happy about that.

He was like, I'm teaching them design thinking. And he's like, where is the magic, the synergy, the shared understanding, the vocabulary that we're talking about, the cadences and the promise of these processes? It's not happening. Everyone is speaking a different language. Everyone's working at a different pace. Everyone's working towards a different goal.

And I'm here in the middle saying, hey, what do you want from me? I trained everybody in all the right processes. This is what I'm supposed to be doing. And this really got me thinking about these processes. You heard a lot about framework's. How do we actually figure out which one of these is the right one?

Is there a right framework? Is there a right process, kind of following up from Jen's talk. Now, the reality is this. If all you have is a process hammer, if that's the tool you have to solving your problem, everything looks like a nail that we can fix with Agile or with design thinking, or with Lean Startup. And this is an interesting challenge for organizations, particularly large organizations and legacy organizations that are trying to become leaner, faster, more efficient.

Now what's fascinating about that is that, generally speaking, startups don't have this problem. Startups have a limited number of people. They have a limited runway. They have limited time to make mistakes. So they work very quickly, and they try to find that product-market fit that allows them to scale and to grow. They don't worry too much about whether they're lean, or agile, their design thinking, all of those things.

But some startups succeed. And as they start to grow and become bigger companies, the problem starts to become more acute. We start to hire people. We start to hire specialists. We start to build bigger teams. And the questions start to come back. Well, which process should we use?

Should we be agile? Should we be lean? Does it really matter? We're big. We're successful. We can't possibly lose at this point. It's particularly true of large multinational corporations. And so they continue to work without really trying to solve this particular problem, assuming that because they're big and because they're successful, what got them here will get them there, will continue to move them forward and allow them to continue to grow.

And yet, every organization that I work with, and I work with large companies, primarily medium-size and large companies, they all say the same thing. They've got these talking heads in the background saying we want to be lean, we want to be agile. John talked about it this morning, the startups want to be endups. The endups want to be startups. How do we actually recapture that spirit of being lean and agile?

And as they head out, as organizations head out to try to figure out what's the right recipe, what's the right framework, the reality is that there are no shortage of recipes for you to choose from as leaders of transformation, as builders of products, as makers of digital services, for rekindling that innovation, that agility, that efficiency in your organization.

In fact, one consultant tried to put it all in one chart. I feel for this guy. He took a lot of heat for this chart. And look, this is a horrible chart, but it's not horrible because of the aesthetic choices that the gentleman who made this chart made. What you're looking at here, if you're not familiar with it, this is an attempt to map out with a kind of a London Tube map aesthetic, the Agile landscape, all of the things that you could potentially do to improve the way that your team is working, or you could choose to do.

Every one of these stops on here is a practice, a method, a philosophy, a tip, a trick, everything is on here. Everything. Design, sprints, Kanban, XP, 5Ys, you name it, it's on there. And if you are in a position where you're trying to figure out what framework works for us, how do we actually build the kind of organization or recapture the kind of organization that we used to be, and these are your choices, I don't blame you if you feel like the first time you head out to try to figure out what to do all of this.

And in fact, most large organizations, I don't know if that's true in Asia, certainly in the US, this is everyone's favorite right now, it's at Scale. This, if you're not familiar with, this is the Scaled Agile Framework, which has lots and lots of big beautiful diagrams, and executives love this. And they love it for a very specific reason. It's because they can see themselves in the chart, and they're at the top.

And that means that I don't have to change. I can tell everybody below me what to do. And most recently, save trying to kind of broaden their perspective on the world, add a little Lean UX into that, so you know I like it. Again, you can't just add words into a chart and make it actually work in the real world.

So let's talk about this for real. Let's get very specific about these three things, Agile, Lean, and Design Thinking, and then I want to talk about ways to actually meld those processes into a good way of working. So what's Agile all about?

Agile came about from 17 software engineer's frustration about 18 years ago. These 17 software engineers were frustrated with the way that software delivery was happening. It was taking too long. They were missing deadlines. Projects weren't shipping. They simply wanted a better way of working.

And so after a long weekend on a mountaintop in the Western United States at high altitude where the air was thin, they wrote the Agile Manifesto. They descended biblically from the mountain. We have written this for you. Now, look, the reality is this, it's caught fire. It is religion in a good chunk of companies all over the world.

And if you read the Agile Manifesto, which most people have not, there's actually not a whole lot in there about process. It's really more about a philosophy of working. There's nothing in there that says you will stand up every day at 9:15 for 15 minutes. It's not there. It's not there.

In fact, what they're basically saying is what I tried to summarize here in this tweet. If you're working on a team, software development is complex. As we learn new things, if we change our priorities, if we change our plan based on learning, then we're being agile. That's basically what the Agile Manifesto says.

As you discover new ways of doing something or where you were wrong, and you change course, that's being agile, right? That's responding to change over following a plan. But sadly, what's happened in the real world is that organizations have hired --to use the jobs-to-be-done language-- have hired Agile not for learning, not for course correction, not for agility but for the efficient delivery of high-quality code, for the production of software.

Because for some reason, there's this belief that this is what engineers need to be doing all the time. And God forbid a software engineer stops writing code for just a second, and it's apocalypse. It's the end of the world. And really, the thing that we are managing our teams for, most organizations when they're managing their agile teams, is this, it's cranking out the software. Let's just get those features out the door because there's this belief that if we make more software, we deliver more value.

Well, look, we have got to get out of this software factory mentality. We've got to figure out how to recapture the spirit, the original spirit of agility that we're looking for. Because the reality is that more code does not equal more value. It simply equals more code. And so we have to change our measure of success. And that's the thing we're going to talk about next.

Because at the end of the day, just because you can build it doesn't mean that you should build it. The airplane that I arrived here on had seven fewer wings than this one, and it worked just fine. I'm guessing yours did too. So let's think about how to recapture, how do we recapture the brain on this agile process?

Well, Lean does a really nice job of this. Lean says, look, we have got to rethink how we deliver goods to people. Traditionally, goods have been manufactured as a push process. We're going to produce 100,000 units. We'll push them onto the market and hope that people buy it. That's risky today. We simply can't take that risk.

Let's flip that on its head. Let's build a pull model. A pull model says that we are going to look for signals from the market to tell us how many things to make. And then we are only going to make that many things because we can't predict the future, and we don't want to generate any waste. Along the way, we are going to empower the people closest to the work to make the most critical decisions. That's roughly what Lean was saying, very, very quickly. A lot more there, but that's the 30-second summary that I'm going to go with today.

Now, the principles I want you to take away are these. first of all, you can't predict the future. You can't, and so you're always moving from doubt to certainty. And so to reduce the risk of going too far down the wrong path, we work in small batches. Sprints, for example, are a small batch. And at the end of each one of those small batches, we pause, and we reflect. What did we learn?

Does it still make sense to go this way? If the answer is yes, we take the next small step forward. Not the next nine small steps, the next one. And if the answer is no, then we have to change course. These things start to come together nicely.

Now, Lean Startup comes along and really starts to apply this to technology in a meaningful way that's broadly accepted. Eric Ries writes the Lean Startup, and he says, look, everything that you're working on is an experiment. You can't predict the future. You're trying to answer the question not can we build it, but should we build it? And we're looking for these early, minimally viable iterations of our product.

Sounds great, right, except, if you've ever had a boss or a client asking you to build something for them, no one wants to buy experiments. People want to buy products, systems, solutions to these things. And so then how does that fit into all of this? Well, bring in our friend design thinking.

Design thinking is going to solve this, right? If it's not Lean Startup, and it's not exactly Lean, and it's not exactly Agile, this must do it, right? Now, what is design thinking? Well, to most people, this is design thinking. This is the world that we live on, and you're not doing it unless it looks like that.

To other people, this is design thinking. Just ideating by the lake. Let's watch this for 20 more minutes. That'd be awesome. Design thinking is simply taking the designer's toolbox and applying it to solving business problems. And you've heard a lot about that. Today you heard Bernice talk about it, the same exact thing.

This idea of empathizing with the people that you're solving problems for, defining the problem, ideating, prototyping, testing, sounds familiar? Guess what. It fits really nicely into that Lean Startup loop. It's the "learn" part of build, measure, learn. Fits nicely.

And then what we try to do is take these two things that seem to fit well together and mash them up with this Agile process. Now, the philosophical version of that Agile process should work cleanly, but the reality, the way that it's applied today, leads us to situations like this. Basically, it's these Frankenstein processes that don't work for anybody.

Just like my client at the beginning of the story, we're doing all of these things, and it doesn't work. So how do we solve it? Well, fundamentally, we've got to move away from this concept of integrating processes. It's not fitting Lean into Agile into Lean Startup into design thinking but it's looking for the principles that underlie these ways of working, what are the agile philosophies, the design thinking philosophies and figuring out how they apply to the way that we do product development work, digital development work.

Now look, I've got 10 principles for you to consider about how to change the way that you work, and I've got examples for each. So I'm going to move through them relatively quickly. And then, if you've got questions, catch me at drinks. OK.

Let's start with number one. Principle number one, customer value and business value are the same thing. Most organizations try to optimize for short term business value. But if you make your customers successful, if you respect their time, if you create delightful experiences when appropriate for them, if you solve real problems for them in meaningful ways, they will reward you.

They'll buy your stuff. They'll tell their friends. They'll buy repeatedly from you. They'll be your biggest advocate. Let me show you a story that I love, I learned this one online. Gibson Guitars is out of business, bankrupt, gone, 100 years. Really, really sad. Why? Why are they out of business?

Well, they went out of business because the guitar-buying market shifted, and Gibson panicked. They brought in a new CEO who was an advocate of innovation, innovation for innovation's sake. Not really thinking through what the real customer needs were, but hey, let's invent all of these new gadgets, and let's hope that people continue to buy our products as they always have for the last 100 or so years. Except it didn't work.

What they failed to realize was where the customer value was. It turns out that the market for guitars had shifted radically in the makeup of guitar buyers. It has actually turned to be about 50% women these days. And it turns out that women guitar buyers, not all of them, but a lot of them, they don't care about legendary guitar gods, which is what the Gibson website looks like.

What they care about is how to play guitar. Can you build an instrument that I can learn how to play? Guess what, Fender Guitars paid attention. This is the Fender Guitars website. They're thriving while Gibson's out of business because they're delivering customer value. They understand the market. They understand the needs, and they're selling instruments to women and then teaching them how to play.

And they're building an experience that's welcoming, that's inclusive to this new, relatively new, growing guitar-buying population. And again, this is about how you tell your story. Sharif told us the power of storytelling earlier today. Fender's telling a story, we're listening to you, we care about you, and we're building products and services for you.

And what we've got here is a user-centered perspective on this. Our success comes from paying attention to the market, and our measure of success changes from creating the thing, hey, we innervated and made all these gadgets, to the change in customer behavior that we want to see that tells us that we've actually met a need for our customers.

We call those outcomes, and you've heard a little bit about that as well. Outcomes tell us when we've delivered customer value because people have changed their behavior. And to be very clear, outcomes tell us when we're done. Shipping the product is the beginning of the conversation. The change in behavior tells us when we're done.

Let me put a fine point on this. OK. Who knows what this is? Call it out. Rotary engine, exactly right. This is the rotary engine, a complicated piece of machinery that if you took it apart, wrote down the specification, and gave it to any qualified person anywhere in the world they would reassemble it, and it would look and work exactly like that.

This is, in theory, a far simpler system. A little bit of asphalt, maybe some sidewalks, a couple of street signs, that's about it. If you were to recreate this anywhere else in the world, it would not look like this. It wouldn't operate like this.

If you were to recreate this in Stockholm, or in Sydney, or in New York, or Barcelona, or anywhere like that, it doesn't work like that. Why? Because outcomes force us to understand the context of use for our products, force us to understand who the customer is, what matters to them, and how they'll interact with the systems that we build for them.

We can't just blindly deliver our products to a new market and hope that they work. You heard that in the panel earlier today, outputs versus outcomes. Now, the interesting thing about all of this is that outcomes change how we plan, how we budget, and how we prioritize all of this work. And again, you heard this over the course today, a man who was talking about hey, why are you micromanaging my feature?

Because I've got a sense of the kind of behavior that I'd like to see in the customers over time. And what we have to do is start to change the planning conversation from, I'm going to build you these 15 features to, I'm going to start to change customer behavior over time. And our roadmaps have to change.

Lots of conversation on roadmaps at the conference over the last two days. We want to start to think about, what are the behaviors that will help us achieve our long-term strategic goals, and then really think through what we might want to build for our customers over time. Because we don't know, we can't predict the future.

And as we start to put these things in the market, we start to learn what works and what doesn't, and that may change our planning downstream. And there's an increased fuzziness, a fogginess if you will, that takes place with our roadmaps as we look out further into time. This is driven by the complexity of humans, the unpredictability of their behavior, and the fact that our measure of success changes from we made the thing to we actually changed behavior.

Do you like the fog? Isn't that's nice? That's number one. I spent a lot of time in principle number one because I think it's the most important one, managing to outcomes.

Principle number two, working in short cycles. We think we can predict what it's going to look like when it's done, and then we run out of time. We got to hurry up and finish it. When we either attempt to or ask our teams to predict the future, this is what we're asking them to do. We're asking them to simply make their best guess, to try to divine what it's going to do, what it's going to cost, and what it will work. And that is a risky way to manage our product.

Instead, our goal is to make evidence-based decisions. As we put ideas into the market, what are we learning, and then how do we change course? And some of the biggest companies in the world are doing this. We want, from those fact-based decisions, ultimately, to overrule the hierarchy. This is where that conversation and humility comes in.

I have a strong opinion about this, but if the evidence disagrees with my opinion, it should overrule it. That's what we're looking for. And ideally, we're collecting evidence as we're learning. This is a chart called the Truth Curve created by my friend Giff Constable in New York in a book called Talking to Humans.

The idea is that the more evidence you collect, the more you get to invest in your idea. And if you have no evidence, if you just have a cool idea that you haven't even tried at all, you're over here in the land of wishful thinking, which means that you get to spend the least amount of effort possible.

And as you work in these short cycles, and you learn, and you start to get positive feedback, you go up the Truth Curve, which means you get to spend more and more and more, justifiably invest more and more in your product, in your idea. And if at any point the feedback turns negative, you stop that investment, and you reconsider whether that's a good idea or a bad idea.

To be clear, anything you do underneath that green line is stupid. And it's stupid because it's unnecessarily risky. You don't have to take that particular risk. As the maturity of your product grows over time, you'll notice. You're looking for product-solution fit first. And if that starts to happen, we start to look for scalability, for product-market fit.

And the questions that we start to ask begin to change over time. And these short cycles help us determine when we stop asking should we build it and when we start asking can we build a business around it. And the evidence tells us whether or not we continue. To be very, very clear, there are two key questions I want you to consider as you work through that Truth Curve of increased investment.

The first question is, what is the next most important thing that you need to learn? Not what's the next most important thing you need to ship, but what's the biggest risk you're facing next? That's the next most important thing you need to learn.

Once you've identified that, then you ask, what is the least amount of work we need to do to learn that thing? And that's your level of investment, that's your experiment, that's your next learning activity. And these short cycles help us move forward. That's principal number two.

Principle number three, this one seems obvious, but this is one of the Agile techniques that really makes a difference, holding regular retrospectives. And again, I don't really care what your favorite format of retro is, what you think is working for you, and whatever it is. At the end of every cycle, pause and reflect.

What worked with the product that we're building? Improve the product. Move that forward. What worked or didn't work but the process that we're using? Improve that, and move it forward. Again, short cycles, continuous improvement, continuous learning. These are really good qualities that come from Agile that drive our agility.

Principle number four, go and see. This one comes from Lean. Going to the gemba, going to see what's happening, what people are doing, how it's working, whether it's your customers or your team. There was a different interpretation of this created by management guru Tom Peters, he calls it managing by walking around.

Managing by walking around simply means that as your team is working, walk around and see what's working. See what's not working. Don't be this guy. Find the patterns that are working for your teams, the techniques, the tools, whatever it is, the processes that they're using and then amplify those patterns, regardless of whether they are lean. If you can say they're from Lean, or from Agile, from Design Thinking, it doesn't matter. If it's working within your organization, it's making people efficient, productive, they're learning, and they're doing good work, amplify those patterns.

Principle number five, test your high-risk hypothesis. I heard a lot about hypotheses today. In fact, Ken told us about the history of hypotheses today. We've had them for a long time. The idea is that we position our work as a testable statement with the measure of success being an outcome, being a change in customer behavior.

Hypotheses force us to tell ourselves stories that we believe before we actually tell our customers those stories. In other words, if you can-- this is my template for hypotheses. Use whichever one works for you. But if you cannot complete this template, the orange parts in brackets, in a way that you believe, that your team believes, that's a good indication that you should not be working on that feature, or that product, or that solution.

Here's what it looks like complete just to give you a sense of what this looks like. So we believe that a 50% increase in retention will be achieved if parents of school-age kids successfully know that their kids are safe with a location tracking movement alerts service. That feels like a compelling story. You might want to push forward and try to test this.

That's the first, hypothesis statements are perfect for that. Should we even be working on this? Once you've got your hypotheses in place, the realization is this, you can't test everything. You've got to ship software sometime too. Very few of us, if any, are lucky enough to have nothing but a learning budget. We actually have to ship stuff too, which is good. We want to get stuff in users' hands.

And so we focus on the hypothesis that we believe will deliver the most value and have the highest level of risk. That risk is going to be contextual to your hypothesis. It might be some technical risk, whereas we have to integrate a modern system with a legacy system. It might be a design risk. We're going to reinvent the way that people do e-commerce with augmented reality. They may not figure it out.

It could be market risk. We've been building products for a certain market or demographic for a long time, and now we're shifting to a new one. These are all the risky elements that you have to consider, the hypotheses that end up in that top right-hand corner, high perceived value, cause we don't know that it's valuable. In high risk, those are the ones you should spend time testing. That's what your experimentation, your MVP'S, that's where that work goes.

Principle number six, do less more often. Again, it builds into this short-cycle thinking. It doesn't mean that we don't do all the things that we want to do. We just take smaller cycles, smaller slices of those, and we do them more frequently. Pakri told us earlier, 62% of you, the product manager audience, can't do proper research, can't find the time to do it.

And there's a good reason for that. If we still imagine that research looks like this, which is what it looked like when I started my career, you sat behind the glass for two days eating candy, watching 30 people come through, knowing exactly what every single person after the fifth person was going to say.

It can be wasteful. And so, again, how do we do less of this but more often? We ask ourselves questions like, what's the fastest way that we can learn the most important thing? And then we do just that little bit. Move the conversation forward to the next question. And we do that with tactics like product discovery.

There's all kinds of techniques and examples of product discovery. I've got two examples for you here. This is one of my favorites. Came across this one recently. I don't know if you know what's happening here. But I'll tell you what's happening here.

This is Ford Motor Company. Ford Motor Company disguised a man as a car seat to research self-driving cars. Now, Ford Motor Company has been building cars for 100 years. Why would they need to research this? They know how to build cars. Well, there's tremendous risk in all of this. Why not just build a car and see what happens?

They needed to learn some very important things. So they dressed the guy up as a car seat, and they put them behind the wheel of a car. And then they put him on the road. And again, the question is, why would they do this? 100 years of car-building experience, this is just the next evolution. We got this, right?

Nope. We don't. Why? Because we don't know how people are going to react to this thing. No one has ever seen a self-driving car before. We don't know how to write the software to react in certain situations. We don't know what kind of hardware is required to do that. The least amount of work that they needed to do to learn the next most important thing was to do that, to fake a self-driving car so that they could learn how people would react.

I recently worked on a project with a team in New York that was doing Ed tech software. They had to reinvent how they were coaching people through specific educational tasks. They managed the whole thing in Trello. This is what it looks like just to give you a sense. The whole project was managed in Trello with humans delivering the service.

The customers had no idea what was happening. They put this together in two weeks, where it would have taken them six months to build a beta version of the service. They put it together with humans and Trello and email in two weeks. Do less more often. You learn faster, you change course, you be more agile, you become more customer-centric.

Principle number seven, work as a balanced team. You heard a lot about teams today, lots of conversations about cross-functional teams. I love this case study. This is a case study from Westpac. Those from Australia know Westpac. Westpac is the oldest company and the oldest bank in Australia. One challenge that this bank faced, at one point, most recently, was to change an outcome. It takes five days to get a credit card.

Over the course of those five days, we lose a lot of people. And we lose five days of spend as a business. Can we take that from five days to five minutes? The only way that they could actually build a system like this, it's not like they could hand it off to an engineering team or a design team or a marketing team. They had to build a dedicated cross-functional team.

Now, in this image right now, you've got Dan, who's the head of design, or he was the head of design when this photo was taken. And he's leading a team of people from risk, compliance, engineering, and marketing through the customer journey that they're imagining. And everybody that's participating in this, they now understand what they need to do to make this new experience come to life.

We want to build these small, dedicated, self-sufficient teams that are empowered to make decisions based on short cycles. The short cycles reduce the risk, we learn faster, and if we're wrong, it hurts less. The shared understanding that the teams build allows the efficiency to come through because these folks don't have to wait for Dan to write a report about his customer journey. They just walk up to the wall, and they see where their piece fits into that puzzle.

And again, we heard that today from John this morning as he was clarifying that scandalous interview in Fast Company. When we place a focus on the customer's need, which is what we're doing, let's get the customer to the process that much faster and work as a team to satisfy them, everyone wins together. And there's a little bit of extra here, which I want to share from my past as well. When you build these dedicated small cross-functional teams, sometimes you inspire creativity in people simply by being there.

This is an award that I received from my engineers almost 14 years ago at this point simply by collaborating with them. They called me the rogue developer because design was still kind of a relatively new thing, and we inspired new creativity simply by working together as a dedicated cross-functional team. Again, amazing synergy comes from those things.

Number eight, radical transparency. Again, you heard a lot about transparency and clarity this morning, the benefit of this. Transparency builds trust. Transparency builds alignment and vision. It builds that shared understanding that we need to move forward. And so the question becomes how do we get that transparency?

Well, rituals are really good. I told you I love movies, Karate Kid, the original Karate Kid, is one of my favorites. You guys remember this movie? You know Daniel-san comes to Mr Miyagi says, I want to learn karate. Mr Miyagi says, that's great. Paint the fence.

But I want to learn karate. That's great. Wax my car. But I want to learn karate. What he doesn't realize is that as he's going through the rituals, he's actually learning karate. The kind of rituals that I want you to think about come from the Agile and Lean and Lean Startup world.

Standups, for example, standups drive transparency. Every day you have to stand up in front of your colleagues and talk about your work. What did you do yesterday? Well, yesterday I bought a pair of shoes online. Yeah, and, what's getting in your way? All this work I have to do gets in my way of me buying more shoes online, right.

That's going to get old very, very quickly. Demo days are fantastic way of driving transparency. Here's what we're doing, not just the code that we're shipping, the experiments that were running, the customer conversations that we're having. This is what we're learning from them.

Proactive emails, if you heard Amanda's Q&A upstairs earlier, she was talking about teaching an organization about product by sending an email. No one asked her to do that. She just generated transparency for her group by sending out those proactive emails. That's the kind of stuff we're looking for that drives transparency.

Access to customers drives transparency. Literally, just the other day I was working with a client, they were like, I can't talk to my customers. I find that impossible to believe. Get creative because your customers will tell you what aspect of your products are viable. You might decide what's minimum, but your customers tell you what's actually viable.

And they keep you from doing stupid stuff like this. Building $700 juicing machines that extract delicious juice from $8 juice packets that it turns out you can just get it out with your hand. You don't actually need the $700 juicing machines. Access to customers drives the transparency and helps us understand why we're working on something.

And again, we saw Bernice talk about this as well. As she's talking to the people who are struggling here in Singapore, we understand why they're struggling, and we get a sense of how we might fix that for them. It drives transparency into our target audience as well.

Another and final tactic for transparency is access to data. Data should be a utility where you work. In the same way that we give our people internet access, computers, coffee, Hawaiian t-shirt Fridays, whatever it is that we do, we give them access to the analytics. That should not be an exercise in rationing, which I've had to do in organizations. This should not be an exercise in trying to exert my position in the company to get more access to data. Everyone should be able to get to the analytics about what's happening because again, that drives transparency into how well our solutions are meeting customer needs.

Two more, number nine, reviewing incentives and performance management because your ass is on the line with incentives. What are we managing our people for? And what are we measuring in order to succeed? It's fascinating, the companies that I work with are all doing some kind of digital transformation or agile transformation.

And they've got the language down. They've got the ceremonies down. They've got the team names down, and the thing they forget to do is to think about how they're paying their people and what they're paying them to do. And I ask them all the time, what are you incentivized to do at work versus what are you being asked to do?

We're being asked to be agile, to be lean, to be customer-centric, but in most cases, we're incentivized to hit the fixed-time and the fixed-scope projects on time and on budget. And as we all know, when we do that, there's really only three results to fixed-time and fixed-scope projects, we either move that deadline, we reduce the scope, or the worst part is we implement, we call the crunch mode where I used to work, everybody puts in 80 hour weeks to hit the deadline. They burn out, they quit, and they go work somewhere else. Not terribly sustainable.

OK. Last one, last principle, and this is very, very important. Make learning a first-class citizen of your backlog. I'll take this off before anybody gets a seizure. The TL/DR is this, one backlog. Manage all of your work in one spot. Let me reiterate this. There can be only one backlog.

All of your work goes in the same backlog. Development stories, discovery stories, design stories, research stories, those are called spikes, by the way, another Agile technique that works really well, and we manage that work in the same way that we manage all the other work. As soon as you divide work into development work, discovery work, opportunity work, design work, one of those backlogs becomes the priority, and the others get ignored, and ultimately, they just become confessionals.

I'm really sorry we didn't do that work. Here's the card, I'm really sorry we didn't do that work. That's generally how it works. I'll give you one quick technique, write your experiment, your MVP stories on a card. Talk about your hypothesis. Talk about your experiment. Talk about, in the story card, who's going to do that work.

If you do estimations, and I don't have enough time in the world to talk about estimations tonight, put it on there, scope it out, and then put it in your backlog. The same backlog where the rest of the work goes. All of it goes in one spot, we manage it together, and all of a sudden, the design, the discovery, the learning, everything other than writing code gets prioritized in the same way, with the same people, doing the same work.

So to wrap this up, 10 principles to bring all of these frameworks together. Lean, Agile, and design thinking, customer value and business value are the same thing, working in short cycles. Hold regular retrospectives. Go and see what your people are doing. Amplify the good patterns.

Test only your high-risk hypothesis. Do less more often, smaller cycles, more small cycles. Build those balanced, cross-functional teams. Be transparent about everything. Don't be secretive about it. Review your incentive structures. Make sure we're rewarding people for doing the kind of work that we would like to be doing. And then ultimately, make learning a first class citizen of your backlog. Thank you very much.