Mailbox’s Gentry Underwood: What Hackers Should Know About Design Thinking

For the first time, Underwood tells the story of Mailbox’s carefully engineered pivot–and how design thinking helped turn his product into a $100 million acquisition by Dropbox.

Mailbox’s Gentry Underwood: What Hackers Should Know About Design Thinking

When Mailbox CEO Gentry Underwood and his cofounder Scott Cannon left Ideo and Apple, respectively, to start a little software startup called Orchestra, they knew they wanted to solve productivity problems. They believed that while Apple had figured out how to design at a large scale, startups weren’t making use of the same philosophy. But when they built their first product, Orchestra, the reception was tepid. It would take another year of experimentation before it would transform into Mailbox, the enormously popular Gmail client which was acquired by Dropbox earlier this year. Here’s what they learned about putting design thinking to work at an early-stage startup.


What did Mailbox’s pivot from being the Orchestra to-do app teach you about pivoting?

Traditionally, a pivot is thought of as something you do as a last-ditch effort when your product is failing: You back up to square zero and try something new or maybe you pick something in your system that’s working and you iterate on that. There’s a freedom that’s discussed around these pivots that I think is naïve. There’s this sense that you can take the parts of [your startup] that are working and re-apply those parts to a new problem–that you end up having these two degrees of freedom. The premise is that kind of freedom makes it more likely you’ll find product-market fit. I think when you have that much freedom, it’s really easy to get lost. It’s easy to lose your bearings in terms of why you’re doing what you’re doing. With that goes I think a lot of the motivation to suffer through all the hard parts that are inevitable, no matter how close you are to an actual solution.

How did this play out with Mailbox?


In our case, we pivoted from Orchestra to Mailbox, but we pivoted in a way that it was pretty different in a sense that we never let go of the “why” that we were trying to solve when we started. Not only the big picture “why” of productivity, but we literally left our jobs when we had the “aha” that people were using email as a terrible to-do list. Orchestra was an attempt to solve that by asking people to use a different tool instead that worked like email, but was organized like a to-do list. The pivot that we ended up landing on was rethinking the inbox itself, where your [email] already lived. The problem was always the same consistently throughout. I think that’s central to why we were able to finally find product-market fit–because we tried a lot of different stuff, but it was always attached to the same problem. It wasn’t like we were truly floating along the way.

Can design thinking help prevent the desperation that leads to a drastic pivot?

The closest thing to “design thinking” in startups is the concept of a “lean startup” and the related concept of pivoting–searching for an MVP in this kind of iterative way. But it’s not quite the same as Human Centric Design. Let’s start with the commonalities. This concept of staying lean and cycling quickly to try and find an MVP looks a lot like the Human Centered Design process of iterating fastidiously with a goal of failing early and often to succeed faster, and increasing the resolution of your prototype as you go forward. In that sense, they look very similar. In a Human Centered Design process, you’re prototyping like crazy. You’re cycling as fast as possible to get feedback on your prototypes. At some point, you go from a small test set which might be your other designers or people in your office to you begin to test them in the field and in that sense, you’re doing the same thing as an MVP. The processes seem quite similar.


What are the differences?

I think where they’re different is: In lean startups it’s as if that iteration is the thing that’s going to save you. That if you try enough things, and you cycle as quickly as possible, and you pay attention as you’re cycling to what’s working and what’s not, that will get you to a solution that works. In Human Centered Design there are two stages at work: There’s the solution–which looks a lot like a lean startup–and then there’s understanding the problem, which is itself an intensive process that is often hand-waved through in tech startups.

Where do you start with design thinking in a startup?


Before you build all your prototypes, work through a design process to be very clear about what the problem is that’s you’re trying to solve: Who has that problem? How big of a problem it is? How much they’re willing to pay for the solution, in some way, shape, or form? In other words–how painful is this problem for them? What can we create that is going to solve this specific problem? Your answers are your design principles, whether in the form of specific statements, or just in the form of frameworks that help you understand the ecosystem that you’re playing in. Those principles are non-pivotable. Those are firm beliefs that you hold onto. Your understanding of them may improve over time; they may increase in resolution or in terms of your understanding, or bring new data to bear that helps you change the way that you conceive of the problem. But from a Human Centered Design perspective, you don’t leave that place of the problem that you’re trying to solve. You don’t let go of your “why.”

What can happen if you don’t stick to your principles?

A sad example is the startup Tipping Point, which had this heartfelt intentional desire to bring crowds together to make changes happen. Then the team figures out that the crowdsourcing aspects of it can better be applied to daily deals, and they become Groupon. Groupon explodes to exploit this one human behavior that it’s found, but literally devours its market and there’s nothing but a skeleton left from the other side, certainly, not a sustainable business. I find that to be sad.


Do engineers have any advantage over nontechnical founders, coming from a lean startup mentality?

When you’re an entrepreneur, there’s this idea that if you’re searching out solutions to a problem and then you discover a new problem which your solution happens to fit, that should be fine. I think it makes sense in theory. From an engineering perspective, often an engineer is much more specifically tasked with a problem. They’re well aware of the fact that they’re free to iterate on, or explore, a “solution space” in order to find the best solution to that problem. But if they find a solution to a different problem, that is not success.

What advantage does a narrow focus give you later?


Startups are so hard. They ask so much of you and they ask you to ask so much of your team. If one day you’re asking your team to kill themselves because you’re going to change the world by creating mass crowd sources to end injustice, and the next day you’re actually telling them that all that hard work is now going to serve people 50 cents off their next latte, then you’re going to have a hard time appealing to [employees’] passion in the long run. I can only speak out of personal experience and maybe for some people this isn’t the case, but startups ask almost everything of you. They are entirely consuming. If you don’t deeply care about and deeply believe in the thing that you’re trying to do, the things, the problem that you’re trying to solve, I don’t know how you can sustain the pain and the energy requirements–to actually go from failure to eventually finding something that approximates success. If you can imagine before you’re building all your prototypes, you’re working through a design process to be very clear: What the problem is that’s you’re trying to solve? Who has that problem? How big of a problem it is? How much they’re willing to pay for the solution, so to speak in some way, shape, or form? In other words, how painful is it to them? What is it that if we create it, is going to solve this specific problem?

Solving really common problems usually means inviting a lot of competition. How do you cordon off a section of the market?

There’s zillions of similar products for people that sit at their desk all day coding on 27-inch monitors, because that’s everybody building for themselves. Often in a startup, the problem is deeply felt by the founder–that’s an easy way to tap that same kind of empathy. You don’t build such empathy skills if the pain is already yours. But if you’re good at stepping into somebody else’s shoes, you can often find a lot of other problems that other developers don’t have. Then you have the advantage of finding a market that’s not necessarily served.


What are some obstacles to the design process?

Sometimes the human problem gets muddied along the way. Steve Jobs in some interview once talked about how when you start at the beginning of this process and you found a problem that you want to fix, your understanding of it is fairly simple and so your solution is, too. Part of what’s attracted to you at that stage is how obvious things seem because there is such a simple solution. That energizes you to go after it and solve the problem.

Steve’s actual quote here from a Newsweek interview in 2006:

When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions. Most people just don’t put in the time or energy to get there. We believe that customers are smart, and want objects which are well thought through.

What happens when the honeymoon period ends?


Then you go after the problem and you start working on it, and you start encountering all the edges, and all the complexities, and all the issues that happen at scale and all of the unforeseen consequences to your particular solution. Your understanding goes from simple to complex and so does your solution. You start to be in the space of complexity–and often technical complexity too. All for what once was a “simple” solution to a common problem. Where Apple always pressed was to keep going, keep going past not only your simple solution to a simple problem, but also past your complex solution to a problem that you really now understand back to a place where it’s simple again. Where you have simplified the solution to such a degree that the people who are not deeply immersed in the problem will look at the solution and say, “Of course, that’s the way to solve it.” They’ll have that same experience that you had in the beginning.

How do you peel all the layers off the onion?

You just hit the problem over and over again, and don’t get lost in the technical weeds. Try and return over and over again back to the simplicity of the issue were trying to solve, and your understanding of what the key pieces were that needed to be fixed. Let that guide you as you push towards a simplification of the solution. If you don’t have really firm design principles, you don’t get back to simple. Your complexity will shape the way you frame the problem. You’ll start to solve a lot of other secondary issues that suddenly seem important, but didn’t seem important when you were in a naïve place. Suddenly, you’ve got zillions of bells and whistles for all the things that could possibly theoretically happen because now that you’re swimming in them, you see them as real issues. If you could lock onto those key design principles that you had in the beginning and those become your criteria, it enables you to find simple on the other side.


Can you describe this process as you experienced it with Mailbox?

We knew that people were trying to work together all the time, in both casual ways and more complicated ways, [like] in organizations. The actual process of communicating and collaborating itself is laborious. The first goal for us was to take the friction out of collaboration, out of work. Then when we looked at the space of that we actually wanted to focus on, we realized that everybody used email as a terrible to-do list. That everybody had tasks trapped in their email.

What were the design principles that came out of your understanding of the problem?


We over and over again optimized for speed over power, for example. There’s lots of things that people would like to do with their mail, but if it slows them down, we simply don’t do it. Another one: It needed to create a sense of delight. I don’t quite know how to describe it … It needed to help put email in its place. It needed to provide a solution to this feeling of people being overwhelmed with email or it controlling them. There was this sense that we discovered that was pretty ubiquitous that people felt like email was something that was thrust upon them. Something that they were inundated with and they didn’t have any choice but to do. We needed to give them a sense of easy control over this thing that they used to feel overwhelmed by.

How did you hone your sense of empathy for mobile email users, beyond your own wants and needs?

One of the things that we saw when we watched people using mail was that they would often file things in deeply nested folders, but when they went looking for something they would just search. All of that energy and effort being put for organizing–though it felt like it was useful work at the time–was actually contributing to this feeling of being overwhelmed. It was slowing people down. In spite of this fact, folders are the number one asked-for feature for Mailbox and people have complained about it often. We’ve had so many interactions with folks where we explain the reason. It’s this liberating moment. They go, “Yes, I can totally go use search.”


So how does this design process actually happen? Do you just write down problems and solutions?

There’s a diagram we talk about a lot in Human Centered Design which we call “divergence/convergence.” Let’s say you start with: How are we going to fix mobile email? You might have this very clear point where you’re going to attack, this hypothesis you’re going to attack this problem. For a while, you have to diverge, and you diverge in terms of all the things that are wrong with [mobile email]. Then you diverge even further. For each of those things that are wrong with it, what can we do to solve it? You end up with this massive idea space of all sorts of crazy potential solutions to various aspects of the problem that you’re trying to solve that should, theoretically, all derive back to that point. That’s a highly generative process–that brainstorming and prototyping. When you’re done with that stage, you often have a gigantic mess that you then need to begin to synthesize down to a solution, or an understanding, or a particular piece of the problem that’s you’re going to try and fix. You whittle it all the way down: “We’re going to attack this piece first” or “Our solution is going to address these three criteria” or “Of all the prototypes that we have just played with, we’re going to decide to put our energy into this one.” You converge down to a focused actionable piece of your potential space. Then you do it again. Now how are we actually going to make this real? What would make this better? How are we going to take this from a rough version of this feature to the best version of it that can possibly exist and you start all over again?

Won’t these problems multiply and grow in scope as the project goes on?


With whatever design researchers you have, you have to be very focused in terms of picking off pieces of a problem at a time. You can’t put 100 designers in a room and solve a bigger problem. That divergent-convergent process–that’s the way you do that.

This sounds like a lot of effort. Why not just make some silly game?

If you think about human progress as this ongoing, evolving thing that’s happening around the world and lots of people are contributing to it in lots of different ways. For us, it seemed easy to get excited about the idea that if you build tools that are broadly used that increase people’s productivity that helped them focus, that helped them figure out what to work on, that helped them get more done to take the friction out of collaboration, you’re more or less greasing the skids of that whole process. The amount that you’re greasing them is just a function of how much better your tools are and how many people use them. If your tools are way better and lots of people use them, you’re literally going to speed up human progress.

[Image by Johan Larsson on Flickr]


About the author

I've written about innovation, design, and technology for Fast Company since 2007. I was the co-founding editor of FastCoLabs.