Skip navigation

Five Minutes with Luis Perez-Breva

Innovating is for doers: you don’t need to wait for an earth-shattering idea, but can build one with a hunch and scale it up to impact. Luis Perez-Breva discusses his new book, Innovating: A Doer's Manifesto for Starting from a Hunch, Prototyping Problems, Scaling Up, and Learning to Be Productively Wrong. Catch his talk at the MIT Press Bookstore on Tuesday, March 21st at 5:30pm to hear more.

Your book is a “doer’s manifesto.” Who are “doers”?

There are many ways to look at them. A doer is anybody who thinks about trying something first before stressing out about whether this will be a dramatic multibillion dollar enterprise at the end of the day.  These are people who fix stuff when they see it’s broken (at your home or somewhere else), people whose first instinct when they see a problem is to put a few pieces together and see if they can make it make sense. It’s people who can only understand things when they connect their brain and their hands. We call them hackers, hobbyists, nerds, DIY enthusiasts.

Once they are successful we forget that and start calling them entrepreneurs, innovators, visionaries, that's very opportunistic and not at all inspiring. These people need a new name that does justice to the fact that it's a valid professional path. Today they are doers—we could even call them heroes—for they are at the basis of the next productive economy. As they start to act, they become innovators, when they succeed we can start calling them all those other nice things.

For some examples from the past, Microsoft showed they could use the BASIC programming language in a machine that was not intended for that. Jeff Bezos started a bookstore online. He proposed it first, was told no, and went ahead and did it and it was so successful that Barnes and Noble who had rejected the idea went back and did it. Henry Ford was a complete nobody who started to make cars.

Nowadays we have a lot of people who are inclined to doing but the only place a doer can do is in software and apps, or at least that’s what we’ve been told. We need to focus on doers because the people who are holding the purse strings, they’re used to being pitched a grandiose vision, rather than being shown that something can actually be done, and so they don’t necessarily know how to receive ideas like this. What’s the business case, what’s the marketplace, those are fair questions to ask, but before you get to that point, there needs to be a demonstration of something, not just these fantastic numbers. We need to focus on doers because they are orphaned by current entrepreneurial mindsets.

What is the main problem with all the other books on innovation that are out there?

One complaint I hear a lot is that there is a lot of jargon and buzzwords in books about innovation.

Another problem is that most books are talking about the outcomes of innovation: it’s almost a circular reference, if it’s an innovation, it’s praised but there’s nothing telling you what to do.  It’s kind of robotic, for something that’s supposed to engage in creativity. You’ll be thrown a chart, which reflects the outcomes of other peoples’ projects and you’ll be told a lot of stuff that over-concludes from that chart because there’s no information about the dynamics of that particular situation. Or you get a flow chart, which is effectively an algorithm. A lot of innovation literature is obsessively algorithmic (and this comes from a person with a PhD in AI).

I’ve written a book that accepts that we learn things in different ways. What can open my mind? Every other book in the pile is either overly prescriptive about something that’s not supposed to be prescribed, or are really good academic treatises on the outcomes of a process that’s really unknown, or a story of how cool it is to be an entrepreneur. I read that, and I still don’t know what to do. And that’s where this book comes in.

A book for doers that is also peer reviewed by folks from academia and industry, that's a first and also something this field badly needed. I want to change the conversation and making something accessible yet rigorous was the first step. The alternative would have been to fall for either populism/recipes or for hiding behind academic jargon and practices of a different field. I aim at creating a new conversation about the action of innovating that complements the extensive literature about its outcomes and related marketing/design. This is a conversation that goes beyond the current management-centric dialog, it should include everyone it ought to give equal footing to engineers, scientists, managers, people in the humanities, and so on.

This book emerged from your teaching. What are some examples of projects your students have worked on that have made use of the innovating techniques you describe in the book?

What’s truly remarkable when I taught this material at Skoltech in Russia is that people started to build ideas and continue to build on ideas that have resulted in companies in industries as diverse as pharmaceuticals, social media, energy, and DNA technology. I teach Innovation Teams at MIT, where I do a little piece of what I cover in the book here and there, and people have gone on to join start-ups like Lantos, Eto Devices, Arctic Sand, and C2Sense. Their start to their ventures is so different because they were able to shake away the perception that everything had been figured out before.

After my classes they may start a company, more important than starting a company, though, is that they become professional innovators. The first company may not be the one to make it, but they find themselves routinely seeking problems that they need to learn from and they do one, a second, a third, a fourth.

People need to understand the problem they need to solve first and I provide the information they can use to shift their thinking. What’s important is that we get people to go out and assume that every problem can be solved.

If you’re a student today and walk into MIT, certified smart and passionate, you are offered an insane number of courses on innovation and entrepreneurship where the end point is a pitch. Then you’re taught to get seed funding, join an incubator, graduate and get VC investment. This is an odd sequence. To make it to MIT you dove into a passion without reservations, you dreamed of solving the unsolvable, and yet nowhere in the process are you taught how to build on that passion and the skills you homed in at MIT to solve the world’s problems; rather it seems you just ought to get funding.

Learning how to pitch is important but students need to know what to do and have means to  quickly understand what isn’t right about what they are trying. The process should change your idea dramatically, not corner you into it.

In that regard it’s not unlike many other endeavors: writing starts with a very poor manuscript. Creative people make mostly bad work until they finally get good work out. That’s the ethos of what you need to be doing.

We need to give people the mechanism to spot problems, create opportunities and become continuous learners. A student of mine who comes out of class and says “I may or may not need seed funding, but I need to have strong footing and clarity of what I intend to do, my position and what it means to succeed”—that is the better position to be in.

What does it mean to be productively wrong?

If you want to make good use of the evidence, you want it to prove you wrong. That’s the only way in which you get information. If you aim your work to prove you right, the amount of extra evidence you need to prove yourself completely right is infinite. But if something is wrong, it is empirically true that there is something that you need to change. When it rapidly becomes hard to continue to find things that are wrong, that’s how you know you are onto something. 

Being productively wrong helps avoid bias. It helps put yourself in the right mindset. The sooner I can prove myself wrong about certain aspects, the sooner I can figure out something new.

It’s a path of building instead of a path of proving, a path of learning not confirming. Trying to validate a hypothesis is not science. It’s an odd tactical approach to confirm your biases and not really challenge them.

It connects a little bit to Nassim Taleb’s idea of the Black Swan: because there is not sufficient empirical evidence, no statistical method can capture a black swan. Something that shatters your beliefs is fundamentally more informative than something that confirms them.

If science claims something is impossible, to a doer that could also mean that the model is incomplete or perhaps wrong. Doers don't need to wait for the model of science to catch up, they can go ahead and build for impact instead of waiting for sufficient statistics. 

Engineers would say “let’s see why it doesn’t work.” It’s called “debugging” in computer science, or root cause analysis, but it’s fundamentally a very different process from the one that’s being promoted when we talk about entrepreneurship. You put things in motion, they don’t work, and you figure out the reasons. The debugging process informs so much of what we do. You’ve learned how to recreate the whole thing better. It sounds like lunacy, but that’s how the Microsoft Kinect team or Ford seem to have done it.

You only need to be right once, close to the end. If you accept that you only need to be right at the end, then you are free to be wrong many times along the process.

Being right constrains you. We don’t observe anyone who was right all along, except when they tell their story in hindsight. Steve Jobs was wrong about the PDA until he was right twenty years later. No one has ever been observed to be right all along. So why are we asking ourselves to do all of these microsteps and be right all along, when it is more constraining?

What was something that surprised you while writing the book?

Writing a book is like building a pseudo-company: it turns out my latest start-up is the book. I didn’t realize how much I had followed my own thinking. The entire book happened the way I talk about things happening in Innovating. One of the things I talk about in the book is having casual conversations with people and putting ideas together. So I had an idea for including illustrations in the book, but I didn’t know any illustrators. I met someone through my daughter’s school who connected me to a sculptor who also illustrates. Then I wasn’t sure whether the illustrations should go at the front or the back of each chapter and my editor suggested having one set of illustrations open each chapter, and then have the same illustration, annotated, at the end. I took the illustrations and using Photoshop knowledge I had picked up along the way, I added in the annotations. And now, when someone picks up the book, they can say “The illustrations tell me what I need to know, and the annotations fill that in.” It’s a far cry from how I described it in the proposal, and I certainly didn’t expect the book to happen this way, but I inadvertently followed my own process.

Share

Or, if you prefer to use an RSS reader, you can subscribe to the Blog RSS feed.

About

Books, news, and ideas from MIT Press

The MIT PressLog is the official blog of MIT Press. Founded in 2005, the Log chronicles news about MIT Press authors and books. The MIT PressLog also serves as forum for our authors to discuss issues related to their books and scholarship. Views expressed by guest contributors to the blog do not necessarily represent those of MIT Press.