Chicago Camps

Matthew Milan at Prototypes, Process & Play 2017 (Podcast)

This podcast features Matthew Milan, CEO of Normative, and his presentation, “Making Moonshots” from the design leadership conference Prototypes, Process & Play on August 10th, 2017.

Prototypes, Process & Play presentation podcasts are sponsored by Balsamiq – with Balsamiq Mockups, anyone can design great software.

Matthew Milan – Presentation

CEO of Normative

Matthew is a complex systems specialist with a focus on software innovation. He has degrees in Ski Area Management, Geographic Information Systems and Environmental Planning, and has spent most of his career helping organizations make concrete decisions about the future through the integration of strategic design and technology prototyping.

Matthew has spent the last decade at Normative leading teams on the fuzzy front end of emerging technologies. Along the way he’s discovered that when you work at the intersection of people and technology, change is the only constant. Dealing with ambiguity is what gets him up in the morning.

Matthew married with three children under 10 years old. They ski a lot.

For more, keep up with Matthew at or on Twitter as @mmilan.

Making Moonshots

A critical part of leadership is the reduction of ambiguity for your team. Your job is to make it clear, so the team can work towards the goals you’ve set. The reality is that many of the goals you’re setting are make-or-break for the future of your organization. If you work in a field like design or innovation, you’re probably already sick of hearing the word “moonshot.” Maybe you’ve even been part of one, or more likely, you’ve unwittingly part of many. As a leader, moonshots are part of the job. There’s just one problem with the “moonshot” approach: the real moonshot wasn’t a single giant leap forward. It was a series of incremental experiments designed to test the riskiest parts of going to the moon, as soon as possible. This approach put humans on the moon within a decade of Kennedy’s famous speech, and it’s the same approach that the best innovators like Elon Musk use to get rapid traction on the hardest and most complex problems of our times.

This session will demystify complex, challenging “moonshot” initiatives and give you a set of principles and practices that you can use to wrestle the riskiest innovation challenges to the ground. You’ve already got the tools: research, prototyping, planning and production. Now, let’s help you to connect them together with the right questions and perspectives, getting the traction you need make innovation work practical and successful.

Presentation Transcript

Please note:

Podcast transcript below.​ Please note: Transcription was recorded live; there may be errors (typographical and contextual), as well as omissions or other content gaffes.

​Additionally,​ there was microphone feedback that happened in the room from time to time, and we did our best to minimize it in the podcasts. We apologize for any disruptions to your listening experience that this may cause.

Matthew Milan:

So let’s get started. Today we’re going to talk about making moonshots. And specifically, we’re doing to switch this up here, I want to talk about what people try to do with moonshots, why they do them, and how you can deal with these types of projects and make them successful in an organization. Whether you’re a startup, or in a lot of folks’ cases, large organizations.

Does anyone know Paul’s work. You totally should. He is awesome. He’s interesting. He’s a designer. And he’s also an actor and the last person in the world to get a degree in cybernetics.

He wrote a book. And I’m going to put up the URL. You can Google Little Gray Book Leadership. This is my favorite quote out of the book. And it’s one of the things that is going to tie my entire talk together, which is this idea that leadership is the reduction of uncertainty in an organization. Leadership is not somebody at the top, and leadership is not folks on the ground. Leadership is the reduction of uncertainty in the organization.

And as a member of the team, regardless of whether you’re the CEO or part of the executive team, the director of innovation, whether you’re a chair designer, whether you’re an engineer challenged with being more creative, this is a big part of your job.

So the question is how to help reduce uncertainty. That’s what we’re going to dig into today. I’m going to give you my thoughts on some respected principles and practices for dealing with innovation challenges, and specifically the places of innovation challenges that a lot of organizations are starting to go through these days.

So what’s the job we’re going to talk about here? What’s the job to be done? I think it’s really quite simple. What you want to do is create by reducing uncertainty. We want to talk about how the tools that you have as designers, engineers, and innovators can help you create confidence provided that leadership availability in organizations that are doing really challenging things.

So here is the takeaway for today. Remember this. This is the one of the key points. Good innovation is risk management. It’s not taking wild and crazy bets. It’s not going and doing feats of fancy and things like that. It’s managing risk. One of the things about moonshot is people trying to solve complex systems by creating a complex system, which is bonkers. But most projects end up in that domain.

So your job in organizations is really to help reduce the risk. It doesn’t mean take things safe, it means reduce the risk. We’re going to talk about that. So the question is how did I end up being a designer who cares about risk management. I’m going to talk to you for a couple minutes about how I got there.

I started a design firm, about 30 people. We did little interesting things. There was a lot of passion, but there wasn’t any – So three and a half years ago we said let’s really try to take this Silicon Valley idea and pry it apart and actually figure it out. Design shops were being closed and it’s harder and harder to differentiate yourself. That’s what I was hearing from my peers.

So we said let’s go find a niche. Or as we say in Canada a “Nees h” is the proper way to say it.

I went to Silicon Valley. And they said there’s all kind of challenges with designers struggling with this and this. And everyone I talked to kind of told me all these really interesting but known challenges. And then I went to a web design firm. A venture firm that didn’t have a design partner. I had this customer develop a conversation with me. And this is what they said. They said designers don’t get scale. Wow. What does that mean? And he said engineers go through school, all the labs they practice and everything they do is making something work at scale. Shipping something at a million units. I’m going to build this. Marketing very similar. It’s all about quotes. It’s all about scale. Designers are thinking one to one relationships. This is where the point of frustration was.

So I started going and talking to other folks who would hire designers, started branching out and not just talking to venture firms and understanding what their problems were. Started going back and talking to our clients and people who could potentially be our clients. And we spent a couple of years really trying to understand where our needs were and challenges were and where our unmet needs were. And at some point we started going down the rabbit hole of doing a study on our potential products. It got scary really fast. We got this quote a dozen times. These are executives, VPs. I’m on the phone saying what really, really freaks you out about designers. The answer became clear it wasn’t about scale. It had something to do with risk. And there was a really big offset between how a lot of designers were trying to solve problems.

And so we started like, oh man, we spent the last six or seven years trying to do cool, imaginative stuff. Everyone is telling us we’re scaring these folks. Versus a client I had been working with for years. Yep. That’s my biggest fear of you folks. You’re going to come in and do something off the rails and do something without planning. And I was like oh shit.

Anyways. So we really started thinking about what’s going on here and really stepped back and tried to empathize with the leaders in the organization for the first time, the people who were responsible for products. And then as we got more focused on where the problems seemed to be, the people who were responsible for innovation. The C‑level executives. The folks who were really dealing with big innovation challenges. Or as we would like to call, the existential threat. You’ve all heard the stats about a Fortune 500 company lasting 50 years. It’s as plain as the nose on your face, as the saying goes. So what’s going on is that the challenges that they face are very significant. And they’re stakeholders, they’re shareholders, their boards, they’re tracking results on a quarterly basis. The COO is trying to increase margins. Trying to drive profit. Revenue. All of these things the new competitors coming into the market are disrupting them. And it’s very challenging because what these folks increasingly need to do is not make the business incrementally, but while they make the business incrementally, they need to figure out a way to replace the entire business with a new better business that is more defensible or more successful in the next 10-15 years. They have to get a new business out of the old business. That’s why they started getting in these places where they have moon shots.

And this crazy amount of risk, I need to figure out how to create a new business. Organizations that are creating markets. They need to figure out how to do that in the next decade. How I’m going to shift in the next direction and chart a course, that’s scary for them.

And then you got your teams saying check out all this cool stuff. And they’re like you’re going off the deep end, I’m trying to solve this massive business problem and it doesn’t seem to fit, even though on both sides the intentions are always extremely good. This is why risk management matters. Because the folks you’re trying to help, whether they are direct or indirect, might be two or three levels below the CEO, you’re still helping solve that problem around the existential threat. How do I create a future business that allows me to satisfy my stakeholders. Risk management matters.

That’s why moonshots happen. Because at some point some organizations say we really need to make a change. We really need to go after something different. So somewhere in an organization the idea starts to evolve and it goes from a small ride test to 15 years later someone is trying to land spacecraft on the moon. That’s a crazy, crazy bet.

So essentially what you have is you have these leaders charged with setting 10+ year goals where they don’t even really understand the outcomes they’re going to get. They only understand the direction. And they’re trying to help the entire organization go a certain way.

I was very naive when I was a young designer. I used to think that C.O.s were stupid. They say the same simple stuff time and time and time again. Can’t they think about this stuff at the level it needs to be thought about. What I realize now is saying simple stuff really matters and the repetition is everything. Because what you’re saying is by the end of the decade we’re going to put somebody on the moon. By the end of the decade we’re going to put somebody on the moon. You have to take your team of thousands of people and get to that direction. Your message has to be simple and on plan. It has to be something that everybody can look up to and say this is the reason why the organization exists or this is what the organization is trying to become.

These kind of statements really matter. Oh that moonshot it feels crazy. You have an executive who has a huge amount of risk. And what they really want to do is get everyone in the same direction and that’s one of the things that I’m going to hopefully help you understand.

This is an important thing to understand. And right now we’re actually AV testing this. Is vision or fear the driver of moonshot. My hypotheses and basically what we have in terms of qualitative vapor right now is it didn’t matter if your C.O. is a visionary or if they’re scared to death. In either case the legitimacy of the moonshot is the same. And so if it feels like it’s a defensive position, you still need to dig in and push. If there is a conservative approach, you have to understand the individual who is leading this and the individual is really, really trying to get to that 10‑15 goal that allows them to sustain business for the next decade.

So it doesn’t matter whether the person you’re in the room with is inspiring you or you have a C‑level executive who is excited about everything or whether they’re tense and nervous and pushing back on everything. In either way, they’re trying to achieve the same goal. You need to understand that they’re not doing it to be difficult. They’re doing it because that’s the way they feel.

So moonshots quite frankly are probably one of the scariest and riskiest things that a business can do. A lot of them fail. And in a lot of cases people are motivated by the reward, but underestimate the risk. And when you’re a designer and you’re working on a project and figure out what the future of something looks like, this is probably very close to your decision set. What’s possible. And how might we do it?

But you also need to understand that C‑level decision set or executive decision set is very different. There are questions that need to be answered. The reports that you shared with the research that you did. They need to understand this. Can you do this? And should you do this? And that’s very different from saying – they’re not incompatible. But what we discovered is that a lot of design work, a lot of innovation work is being framed up around “What’s possible, and how might we do it?”. And you have somebody say “Can we do this?” And the designer says “I don’t know” or the engineer says “I don’t know.” Go back. Figure it out. So you try to figure it out. But what we see again and again, internal teams, external partners, these questions are not being answered in a way that satisfied senior leaders.

And it’s not just answering the questions. It’s answering the questions in a way in which they can absorb the information quickly and make good, confident decisions with it.

Let’s talk about actionable moonshots, specifically I want to spend a few minutes demystifying a moonshot. One of the best moonshots in the world right now is this. How many people put money down for model three? There you go. My programmer stayed up all night. This happened just so he could do that. He didn’t tell his wife. That was an interesting conversation.

What Musk has done is Musk has essentially completed a moonshot in front of everybody for the last decade in the space where most American automotive manufacturers have gone bankrupt. I think it’s only Ford and Tesla that haven’t gone bankrupt. Made it from a startup of three or four people. Let’s take a look at how they actually did that.

So Elon tells us right on his website. August 2nd, 2006. That’s 11 years ago. He says, check this out. Whoops. There we go.

He says what I do here is I’m trying to help expedite the move toward a solar electric component. This is my moonshot. My moonshots change how the world views energy.

Makes sense. Here’s how I’m going to do it. I’m going to build a car and I’m going to use that money to build a more affordable car, and I’m going to use that money to build an even more affordable car. He clearly understands cash flow. And he’s going to offer power generation options and he says I’m not going to tell anyone. And he did it. And he did it in some very interesting ways. And we’re really going to dig into that side a little bit.

Let’s talk about principles. So you can understand how everyone is working. Here is the first principle. Don’t construct from scratch. So Musk has a very small team and went out and build the Roadster. That was the first car. He didn’t go and put together 50 or 60 people and build a product from scratch. He subcontracted out everything that he possibly could to organizations that knew how to do these things already and focused on the proper tools. So Lotus actually built a lot of the Roadster. There was no point in starting from the beginning.

Four bullet points. That’s usually something you see. It’s really simple here. And this is really important. Set the high‑level goals. Don’t set the detailed plan. The detailed plan will kill you. Break it into small steps. Small steps matter. This is not about a big jump. You want to go step by step and leverage yourself up. You don’t want to get yourself into a place where you’re taking big leaps. This is critical. We’re going to come back to this in a little bit.

What you want to do is address the big risks as early as possible and when you address the big risks, you need to address them across as many dimensions as possible. So the question that folks have about engineering, this is why it really matters that you have good integrated, interdisciplinary teams. You need a designer and the engineer and the marketer going up in parallel with a single prototype testing the technology constraints, testing the design opportunities or the user constraints, understanding what the market size is and how we actually might get traction.

So you can go into the room with a leader, or likely the person that you work with will go into the room with the senior person and have them say this is how we can do it. I know this is going to work because we already did a test. Your partner, their APIs, we can get 10,000 concurrent connections in a second. We test that up front. Why do we test it up front? Because we know the type of product that you’re asking us to build is going to have to do that later and we want to know on day one or week two whether you’re going to be able to be in a place to actually do that. And that leads to this idea, which is you really want to understand how to prototype your way into production. That doesn’t mean that your protype becomes the production piece. That means you’re building a learning tool that allows senior leaders to make decisions. Yes, that makes sense, and we’re glad you tested it against that API so we can get con currency.

People are going to say things like hey, take these ideas and put them into the product development pipeline. Those are the types of answers you want. That’s what you build moonshots for. You get prototypes of these productions as quickly as possible.

And what I see a lot of organizations do, and I think it’s probably the single biggest challenge in large‑scale innovation projects is they incur risk. Who remembers the 2008 Financial Crisis? Moonshots are right with these types of challenges. The risk of deferring risk is probably the biggest risk of failure for projects.

He’s got some really great quotes which he stole from other people. Number one, survey says you don’t know what you don’t know. So don’t pretend that you can gloss it over and solve it later. Because when you try to solve something later, you push that unknown into the future. And you know what, we want to totally mock this thing up. We can talk to the engineers later and we can go figure out what concurrent connections look like. That’s their challenge.

I was having conversations early this year with the biggest banks and talking to members of the different innovation groups. We were having some conversations around their prototypes. And they were talking about the fact that they’re really struggling. So we said hey we would love to have the next meeting with the engineering team. And it went dark. And then three weeks went by and we’re like what did we say. And did we do something to completely offend them? And then this e‑mail came back and the meeting was set up and everything was cool. And we went back and sat in the room with the product people and the innovation people and the engineering team that happened to be dealing with this API platform that was being developed. That, by the way, all the future products in tin novation pipeline in this massive innovation lab were 100% dependent on it. And it turned out that it would work. And the reason nobody from the innovation team had ever talked to these folks. The reason it took so long is they had to figure out who they were and convince them to come to this meeting. Crazy, right? This is a company that has 200,000+ employees and has crazy institutional laws. They invent a lot of the stuff that you see in the modern day. They’re completely disconnected from the technology folks that they’re dependent on. And then they learned that the prototyping had been going on for 15 months.

I guarantee you you’ll all be there at some point. That’s why I’m going to tell you this stuff so you can make better decisions.

We said to the folks who were setting up this API, we said we think that we can help you folks get unstuck. Take the API and have the designers look at it. Took us two weeks to register, even though it was an open API because nobody had registered for it. We were the first to register on this.

And the reason why I bring all this up is think of all the unknown that has been pushed into the future with this type of stuff. This API is being built to serve all these different needs. This prototyping work is happening. These massive investments in tools and partnerships and everything else around the future has been poured into this and you’re at least 15 months in, and you’re there.

So what you’re seeing is your exposure to the unknown. And this is where it becomes like bad, and this is where as innovators and designers you can stop this stuff. You can start to understand we could have had a 1‑hour meeting with the API team on week 3 or 4 of our project as opposed to week 75. And we would have known very clearly early on where things were going. The general situation where things built are going to come up and be shown to some senior decision maker. So we’re still talking with that organization. They’re still stuck. Because it’s so big and so challenging now that moving it a political nightmare. It’s a financial nightmare. No one can back away.

So when you get into this type of situation, you can’t afford to go back. Imagine if the Apollo program had gotten into a place where they were working together integrated. What would have it looked like if they had just ended up with a bunch of parts on the ground? What would that have done for the national psyche? That’s what failed moonshots do to organizations. That’s why it’s so important to help them.

So how do you stop this? Really simple. You want to test your biggest risks first. Don’t defer. Don’t push them back. Don’t short sell and say we’ll just touch that on the surface. Take the biggest risk you can see in the present. And that’s hard because often it’s not human‑centered designers. It might be a technology person. It’s your job to help you understand that the interface I built for this isn’t going to be able to run 10,000 concurrent instances at the same time.

We start here from this perspective. There’s a great blog post. It’s called the risk case assumption test. It gives you a false reassurance. There is no clear linear path to the outcome. It assumes that you know all the risks ahead of time. That’s ridiculous. When you go into testing mode and you test more than just do users like it and you test all the different assumptions, you get in a place where the focus is purely on the organization. And to the folks who were asking the question about how do you get engineers involved, a big part of it is understanding how can you work together? How can you use a designer, think more like an engineering, how do they learn, and vice versa. How are you going to focus on learning? How do you afford one step at a time? At Moonshot, everyone goes put someone on the moon. It started by putting a chimp in orbit. Put another chimp in orbit. Put a dog up. Put a person up. Put two people up and have them do a space walk. Put three people up and have them land on the moon. Test, test, test, test, test. Remove assumptions. Turn them into information. Turn the things that you know so you can build confidence that you can do it as a team and in support of your organization.

Now here is something that as designers you absolutely need to start to think differently about. Not only are your great ideas not precious, you need to kill most of them.

So I have a problem with traditional critique. I don’t believe that the point of critique is just to make things better. The point of critique is to understand whether this thing is going to fit in the context of what the organization or the market needs it to do. And those are the questions.

So what I want to zero in on is – the PowerPoint. Bear with me. Da, Da. – You might not ever have access to that – I had a talk a couple of months ago. And he said I think it was this. Tony Pattel had this conference room off the side of his office. And that’s where we would take ideas and go and get them killed. He demanded it. All the different questions were talked about. Can we, should we? Dead. Back to the drawing board. It was all about killing things. This actually comes from the earliest fruits of this call from NASA’s jet propulsion. Originally it was called the Risk Assessment Board. – They were originally set up to solve these types of really challenging problems. How do we make sure that we don’t mess this up. We have to be rootless. And the majority of ideas that we’re pursuing need to be shut down. And the sooner we can shut them down, the better we can shut them down. We’re going to talk a lot of theories.

Another example. Something that we helped solve two and a half years ago. So the British government has this very interesting welfare system. There are people who spend their entire life on welfare in the U.K. and that’s part of the social fabric. It loses billions of dollars a year and for all different kinds of reasons. There’s all kinds of places where the system leaks. And one of the places where it leaks really bad and is really hard to track is what they call the – You give money to parents and they’re supposed to spend it on broccoli and shoes for their kids, and they spend it on beer. The money doesn’t go where the parents expected it to and that’s a loss to them.

So the department of welfare came and said we need to figure out in six weeks how to convince this British board that a payment system may help solve the beer and broccoli problem. We can do that in six weeks. Very simply we looked at what are the biggest risks? What are the biggest challenges here? The biggest challenges that we identified, and sorry, I’m just going look here for a second.

We said we need to figure out whether we can make this work with existing communication systems. It has to work with the existing world. Otherwise they’re not going to buy it. We have to be able to post deposits from the government and transactions to people on some type of ledger system so they can track it. And then we have to figure out how to put rules into money. So somebody when they scan this can figure out, the system can say “Hey, you’re supposed to spend that on broccoli, not on beer.”

And I know there’s all this surveillance and other things. But the U.K. invented the surveillance society. They’re cool with it. That’s what we learned. We can direct all the moral and ethical questions to them.

The question that we wanted to help this British board answer is can we do this and should we do this.

We helped them understand that you can tell if they’re buying beer or broccoli. You can post that to a specific type of technology. And now we have a team go and build a biggest test. They finished up the 30‑person test. And now they’re doing a 1,000-person test. And if it keeps going that way, and in a couple years the moonshot of putting the British welfare system onto a block chain is going to work.

Sorry the folks. The internet in here loves being difficult.

We’re going to talk about another example really quickly. Similar scenario. Large organization that we worked with for years. They were trying to figure out the future of television. They put about 400 million dollars into this project from a technical perspective. They came to us and said okay, help us figure out what the user experience could look like. We want to innovate. Now we have to beat NetFlix and all these other things. And so that’s the work we did for them. And it was fantastic! It was fantastic. As we went through this we learned over and over and over people want this, people want this, people want this, people want this. Why did they write down $500 million investment last January? Because it could only run 10,000 concurrent hits at a time and they assured 100,000. That should have been tested the first couple of months into the program. So deferring the risk has billion‑dollar consequences.

So let’s be really straight about this. What do you need to do? You need to change your strategy. I’m going to make it really simple. Innovation is a search problem. You’re searching space for the best possible opportunity to help your organization. Everybody loves a pivot. You learn, you pivot, you learn, you pivot. That’s amazing when you’re a small team and agile enough to change direction every single time. You can recover a lot of your waste in terms of what you’re doing and make it work. For large organizations, you can’t do that. It’s almost impossible. It doesn’t mean you can’t be agile. You have to think about it differently. It’s a portfolio problem. As soon as it fails, go back and find out where you left off. Do it again, do it again, until you hit a point of failure. What you start to learn is if you take all the risky assumptions off the table early on, you get better and better and better at getting it to a point of success. And when you’re doing great design work on new products and things like that, you’re fundamentally trying to help senior leaders answer these types of questions. Can I find the best possible idea using the tools I have in this organization at work?

So you need to reverse engineer what to do next. You need to look at the future and understand what is my biggest risk now. You need to think about how can I prototype the real world? If you can work with some folks who can work front end and back end, and the more you can answer “Can we” the more you can help answer the “should we.” It’s not about saying hey we don’t know if this will work, but let’s give it another shot. If it doesn’t work, it doesn’t work. Take it off the table. Don’t try to polish one that doesn’t work in the hopes of getting it right. You run the risk of half a billion dollars.

And then understand that your real client here is the room. It’s the room where things go to die. Your job is to make the decision makers in those rooms, whether it’s you, whether it’s people you’ve worked for, give them the tools to make the best decisions. So a very small number of ideas are truly transformative, truly bullet proof, and actually have the potential of returning that.

So essentially what you charge those folks is that you can share a risk and help them reduce the uncertainty and that’s how you can lead as a designer with moonshots or when you’re working on something that is risky and there is uncertainty. Every single decision you make, every single design choice that you make is all about sharing –

So let’s talk really quickly about practical applications, how you actually put these to work. It’s really simple. Same tools, different questions. Use sketch, use envision, all the other tools that you’re used to. Ask those questions, but in your repertoire of questions you’re going to add two.

You’re designing something. It’s possible after we do it, can we do it, should we do it?

And two, you start to challenge the C‑level. What is the pressure like on somebody who has to look at the quarterly results and make a return on the business in ten years?

And the final point, I think the most powerful one, if a picture is worth a thousand words, your prototypes are worth a thousand pictures. The decisions that get made are the tangible thing that answers questions across any dimension is way more powerful for a leader. The closer you can make that prototype in terms of covering all the different types of risks, the better it’s going to be. It doesn’t mean it has to run for 5,000 people. We did a test to load up the server structure and see that we can run 10,000 at a time. Add new questions. Understand that the folks making the moonshots have significant pressure and risk. It’s your job to help them lead by reducing that risk and then give them the tools that encapsulate your thinking and allow them to make great decisions.

Thank you.


About Chicago Camps

Chicago Camps, LLC ( was founded in 2012. They plan multiple low cost, high-value events primarily in Chicago.

About this Podcast


“In the Basteal” music written, produced, and performed by Christian Lane.

Publish your podcasts the easy way at

Chicago Sponsors Camps

  • Rosenfeld Media
  • Simplecast
  • Lead Honestly
  • Columbia College Chciago

Code of Conduct

All delegates, speakers, sponsors and volunteers at any Chicago Camps, LLC event are required to agree with the following code of conduct. Organizers will enforce this code throughout the event.

The Short Version
Full Version

Be respectful of other people; respectfully ask people to stop if you are bothered; and if you can’t resolve an issue contact the organizers. If you are being a problem, it will be apparent and you’ll be asked to leave.