Tom Chi just might be the smartest man alive. He started doing astrophysical research at 15, helped design the feel of Microsoft Outlook, led the product experience team at Yahoo!, co-founded Google X, and pioneered Google Glass. But the real magic happened when he turned his brain toward humans, and the management thereof. That’s when he started developing his ideas around rapid prototyping as a strategy for driving innovation and solving complex problems.
Now, after years of using his talents as a consultant for companies like GE, Cisco, Wells Fargo, Intuit, and Fitbit, he started an online Prototype Thinking course (register at prototyping.strikingly.com) to bring his methods and insights to social entrepreneurs working to solve some of the world’s thorniest problems. You could take his class — we did — but in the meantime, you can share our peek into his amazing mind.
Please share your story with us; particularly how you came to do the rapid-prototyping work that you’re doing.
Tom Chi: I live by this idea that the more people you lead, the more people you serve. When I first moved into a management role, I got very interested in what it means to serve a team of people counting on you, whether they directly report to you or whether you’re just helping run a project they’re a part of.
That began a weekly practice of experimenting with different ways of working. The practice was very simple: On Friday morning, look back on the week and write down the things that you got done — the substantial things, not just sending out email. Typically, it’s three to five things. You write that on the left-hand side. And on the right-hand side of that same sheet of paper, next to each one of the things, you jot down an experiment you can imagine doing that would make accomplishing that thing 10 percent better the next week.
You’re challenging yourself, week over week, to say, “Here’s what we’re getting done. Here’s how we make it 10 percent better.” That’s in itself a special mental hack, because the way people get lost is they either get good enough at something that they stop improving, or they’re so bad at a thing that they can’t even start. Saying “10 percent better” addresses both of those blocks. Even if you’re quite good at something, you can imagine being 10 percent better at it. And even if you’re terrible at something and you’re intimidated about starting, you can absolutely imagine being 10 percent less awful at it next week.
That practice got me into this cadence of weekly experimentation, which I’ve been doing in various forms for the last 17 years or so. It’s the genesis of how I’ve been developing, refining, and processing new ways of rapid prototyping pretty much everything.
Do you have an example of something your team would have shared in one of these Friday feedback sessions?
TC: Yeah. Just to be clear, this is about reflection. You reflect upon what the team has done. There are thousands of examples of things we improved over the years.
Here’s a story that rolls together a bunch of them: When I was an executive at Yahoo! , I was working in this division of 600 people and my boss’s boss ran a group of 9,600 people. We were in a strategy meeting with him trying to talk about the future of the multibillion-dollar business unit I was a part of. During the meeting, he comes up with an idea. I whip out my laptop and I appear to be typing out his idea so it doesn’t get lost. But what’s actually happening is I’m opening up two instant messenger windows and I’m contacting three members of my team and quickly giving them a brief on what the idea is.
This was an hour-long meeting. Thirty minutes after he came up with that idea, so about 45 minutes into the meeting, I was like, “Hey, Ari. Do you remember that idea you had about such-and-such?” And I turned my laptop around and nudged it toward him and said, “Try it out.” The whole thing was working in that time period.
He sat down and he started using it and he was like, “This is crazy. This is real data, too.” He was using his idea and it was blowing his mind. At some point, he put his hands up and pushed the chair back and was like, “I have 9,600 people reporting to me and I don’t know how this could get made in two months. How in the world could this get made in 30 minutes?”
Then I explained to him the many changes we’d made that were related to that being possible. One change I’d made is I’d created this thing called “15 Percent Learning Time.” Google famously has 20 percent do-what-you-want time, but I actually think that’s a little too unstructured. What I created instead was a thing that said, “I’m never going to book you up to 100 percent. I’ll book you up to 85 percent, roughly. You can tell me whether it’s getting to be too much or too little. But the 15 percent of extra time you have, you can allocate to anything you want to learn that’s going to improve your work. You want to learn a new programming language, you want to learn about management, you want to take a design class? That’s great. Go and do this stuff.”
The only caveat to 15 Percent Time is: If there’s ever a point I really need that time from you, then you’ll drop everything and let me work with you during that 15 percent. This wasn’t some sort of escape hatch. I wasn’t stomping on everybody’s education time all the time. Not only was it a rare event, but people would feel privileged to be asked to do something with their 15 Percent Time from me.
That was one change. Another change was I physically set up the environment where, being the executive, I had the corner office and I was surrounded by a little circle of prototypers, and beyond the prototypers were designers, researchers, and all the folks directly required to make software happen. What I would do, because I sat in the corner office, was if I ever needed anything built, I would just stand up and say, “Who has 15 Percent Time?” A couple people just within earshot would stand up, and I’d say, “Okay, great. Olivia, Jeremy, I need your time on…” and then we would brief it for two minutes over the cubicle walls and then we would go into action. So they were already used to these sorts of drills, that we might prairie-dog up and figure out everything we were going to go do, with the expectation that it would be built within a couple of hours.
There’s a lot more to say. We kept iterating, for example, on our data platforms so it became very easy for you to prototype anything on the front end or the back end because of investments that we had made in the software. Anyway, I sketched out for Ari, “Here are five different things that we’ve done as a result of the whole chain of experiments, and when you add those five together, that’s why this thing could be created in half an hour.”
He was dumbstruck. His model was much more the classic model of “brilliant leader comes in, makes plans, creates a specific vision and framework, sells it so people get bought in, and people follow the vision according to that plan.” My take on that kind of work is that it can only be as smart as that one person. Even if you have an incredibly smart person, one incredibly smart person is not smarter than a hundred even averagely smart people.
This is a side note, but let’s say you are crazily incredible at something. Even if you’re one of the most talented people in the world, you can grab any three to five people on the street, and this person’s a better athlete than you, or this person plays this musical instrument better than you, or this person is better at public speaking than you, or this person is a better friend to their friends than you. That’s a good humility check.
Anyway, given that truth, the idea of one leader — even a charismatic leader, an intelligent leader, a talented leader — being the source of truth for an organization is kind of madness.
The design of this rapid-prototyping approach was to say, “I’m going to teach you how I learn about what I learn, and you guys will have the opportunity to reflect and learn yourselves in that same way. And, collectively, we’re going to learn together and solve these problems in a way that’s going to be thousands of times better than anything any single human being could come up with.”
Is working in teams a requirement?
TC: Most of the big things will be done by teams. I do think there’s a place for people to express their individual brilliance by peeling away and going incredibly deep on a thing, but impact typically doesn’t happen in the world unless they come back to the world and teams are inspired. Of course, teams can absolutely inspire themselves independent of the deep work of an individual or a small group of individuals.
“Even if you’re quite good at something, you can imagine being 10 percent better at it.”
What components have to be present to have a brilliant team?
TC: This would take many, many hours to describe. Because there are so many things to say about great teams and I’ve done so many experiments over the years, usually I like to flip it around and say, “What kind of problem are you having?”
If you’re having a communication problem, the things I might say would be different than if you’re having a vision problem versus having a making-your-deadlines problem versus having a level-of-creativity-in-the-team problem versus a motivation problem versus a team cohesion problem versus… This can go on for a very long time. The question is no smaller than, “How do humans get along?” It can be kind of a long one.
TRADITIONAL PROBLEM-SOLVING vs. the RAPID PROTOTYPING METHOD
Why do you feel that rapid prototyping is important, rather than just prototyping or continuous improvement?
TC: The reason for “rapid” is there’s this unconscious bias we have because of how we were educated. Every single time you answered a question on any test in any school, there was enough information in the question to be able to actually answer it. It would be cruel and unusual and frustrating for somebody to have a bunch of test questions where not all the information is there and it’s truly not answerable with what they give you.
We’ve been unconsciously programmed into the habit of thinking we should just sit there and think about it whenever a problem arises. If we think about it enough, since all the information required to answer it must be there, then we’ll figure it out.
In truth, we don’t have all the information required to solve most of the problems we face in the business world when we first get the question, so sitting there and thinking about it actually becomes not just inefficient, but actively counterproductive. Because the more we think about it, the more convinced we are that we’re right about something where epistemologically we can’t possibly be right, because we just literally do not have enough information yet to solve the problem.
Anybody who’s done anything innovative, if you ask them, “On day one, did you know everything you needed to solve the problem?” they’ll be like, “Are you kidding? Of course not.” But our unconscious biases make it so that we’ll make complex strategy documents and execution documents on day one, when, clearly, we really don’t know what’s going on.
This is all prefacing why the word “rapid.” Rapid has the benefit of saying, “No, that’s enough. Just begin doing it.” The happy side-effect is, shortly after you begin to do something — as opposed to just cogitating it — then you will discover a lot of the other missing variables. As you try to put it together, you’re like, “Oh, I didn’t think about it, but the heat seal for this is going to be tough to engineer.” “Didn’t think about this before, but when we try to deploy this social-good thing to the community, then these tribal leaders need to be on board.” “Didn’t think about this before but…” This is the main virtue of doing so quickly.
What most people are afraid of is they’ll do something rapidly and it’ll be the wrong thing. But what they don’t recognize is that assessing right or wrong on a body of thought does not work that well in business innovation. Number one, you don’t have all the information to go solve it on day one, as already noted. And number two, there is no single right answer. For any constrained problem space in the real world — not in a test question — there tends to be 5, 10, 15 totally satisfactory ways that a product or a business could be designed.
Rapid prototyping says, “Let’s go from the idea to something we can actually see, feel, and touch as quickly as possible, because then all these illusions around why I’m right and why you’re wrong and why my ideas or analysis or strategy are better than yours fall away.” We get to the simplicity of: Is a thing truly of service or not?
Another reason for the word rapid: If you give people an incredibly small amount of time — when I teach it, there will be a thing that they’ve been working on for two years and I say, “We’re going to do the first prototype in 11 minutes,” with a stopwatch — they can’t fall into their old habit. If you give a software developer two hours to go do a thing, they’ll whip out their favorite code editor. If you give a designer two hours, they’ll whip out Photoshop and Illustrator. If you give a businessperson two hours, they’ll whip out Excel and start modeling or PowerPoint and start throwing down bullet points to go pitch. If you give them 11 minutes, they can’t do any of that. They need to break their existing habit because the time is incredibly short.
The other reason to go incredibly short is that pretty much 100 percent of the time, they solve critical problems they hadn’t solved for months and months within one or two of these 11-minute prototyping cycles. When they are able to see that things can be solved that quickly, it becomes proof that a different way of working is viable.
“What you need to say, whether a thing worked or not, is, ‘Awesome. What did we learn from it?’”
I’m blown away by the practically flawless success rate you have in implementing this methodology.
TC: It’s not flawless because it’s lacking flaws. All it’s doing is it’s mathematically saying, “Let’s not pick from the best of one or two. Let’s pick from the best of 20.” At the end of the day, a person with a particular mindset can say, “When you pick the best of 20, that means you are 95 percent wrong.” The answer is, “Totally. Yeah. That’s exactly it.”
When people use words like “flawless,” it’s within a culture of right and wrong. What makes this work amazing is it does away with the culture of right and wrong. I get equally excited about things working and not working. This is not true for most people and most teams. But if you’re able to get yourself into that zone, then getting to a high number of trials is easy because it goes poorly and you’re excited. “Oh, we learned why this one went poorly. We’re going to go put it into the next step.” Or it goes really well and you get excited because you learn why that trial went really well and it informs lots of other stuff that you’re going to now try.
Learning why it worked is actually way more important than whether it worked or not. Why it worked is an enduring property. That it worked is an episodic property. Something can work today and not work tomorrow. But the reason why it worked tends to be enduring because it tends to be from inside the person you’re trying to serve.
If you’re able to release attachment to right and wrong and move into a zone where learning is the thing that matters the most, then the number of trials becomes very easy to push out. When you choose from enough trials, you will do better. Even if you don’t get to a perfect answer, choosing from the best of 30 is going to be better than choosing from the best of 3.
What advice do you have for entrepreneurs or executives for beginning to implement this approach to problem-solving?
TC: Start the culture of learning. Pretty much every executive has some weekly meeting where everybody gets together and reports the status of things. What I challenge folks to do is simply add one question on the end of the status reports. What you need to say, whether a thing worked or not, is, “Awesome. What did we learn from it?” You can ask that question whether the thing is going well or whether the thing went totally poorly. We let those opportunities fly by every single week, where we could be learning something huge, either from how a thing worked or why it didn’t work. In that process, we are unconsciously passing up opportunities to move into a culture of learning and away from a culture of right and wrong.
The next step, if you want to make it a culture and not just individual learning, is create a “learning board”: a big foam board or a large piece of signage in your staff meeting room that doesn’t get erased or disappear randomly. Write three learning frontiers on it, like “We want to learn what’s the ideal feature set for Version 3.4.” As people share their status in the meeting and you ask a question in order to get more deeply into what they’ve learned, you write anything that applies to those three learning frontiers up on the big board so it becomes a permanent fixture in that room until those learning frontiers are mastered.
The implicit messages it sends are, number one, we’re all learning together. Number two, whether your thing worked or didn’t work, it can absolutely still lead to us writing something down that helps us with that learning frontier. And, number three, when it actually comes time to make significant decisions on that learning frontier, like what features go into Version 3.4 or how we are actually modifying our go-to-market with this new audience, it closes the loop for people. It lets them know that what they learned on behalf of the organization actually matters.
PRACTICES FROM THE MASTER
Try implementing one — or all! — of these Tom Chi practices with your own team.
WEEKLY EXPERIMENTS
Every Friday, write down the major things you accomplished for the week on the right-hand side of a piece of paper. On the left-hand side, write down ideas for experiments you could try to accomplish that task 10 percent better in the future.
15 PERCENT TIME
Communicate with your staff to make sure you’re never filling more than 85 percent of their time. Allow them to use the other 15 percent to learn new things that will help them with their job. The caveat: You’re allowed to ask them to drop everything and devote their 15 Percent Time to an essential, urgent project. Now don’t abuse that privilege!
A CULTURE OF LEARNING
Write down the group’s three biggest learning frontiers in a central, visible place. (Example: “What should be the feature set of our next release?”). Whenever your team reports the status of their projects (like in weekly staff meetings), make sure to ask what they learned. You can ask that question whether the thing is going well or poorly. Whenever team members report lessons that relate to the learning frontiers, write them down on the board. When it comes time to make a decision related to the frontier, close the loop by making it clear how the team’s successes, failures, and experiments have mattered to the company.
