Build: An Unorthodox Guide to Making Things Worth Making

by Tony Fadell

The call from Apple came the first week of January 2001. A couple of weeks later I became a consultant leading the iPod investigation. But it wasn’t the iPod yet. The code name was P68 Dulcimer—and there was no team, no prototypes, no design, nothing. In March, Stan Ng and I pitched the idea for the iPod to Steve Jobs. The first week of April I became a full-time employee and pulled the Fuse team with me. By the end of April, Tony Blevins and I found our manufacturer, Inventec, in Taiwan. In May I hired DJ Novotney and Andy Hodge, the first additions to the original Fuse team. On October 23, 2001—ten months from when I started—the iPod emerged into the world, our fat plastic-and-stainless-steel baby.

So don’t just make a prototype of your product and think you’re done. Prototype as much of the full customer experience as possible. Make the intangible tangible so you can’t overlook the less showy but incredibly important parts of the journey. You should be able to map out and visualize exactly how a customer discovers, considers, installs, uses, fixes, and even returns your product. It all matters.

But the longer I made things—at General Magic, at Philips, at Apple—the more I realized that many things don’t need to be made.

People often get excited about making something with atoms—they dig into the design, interface, colors, materials, textures—and instantly become blind to simpler, easier solutions. But making anything with atoms is incredibly difficult—it’s not an app that you can copy and update with a click. The only time hardware is worth the headache of manufacturing and packaging and shipping is if it’s critically necessary and transformative. If hardware doesn’t absolutely need to exist to enable the overall experience, then it should not exist.

Your product isn’t only your product. It’s the whole user experience—a chain that begins when someone learns about your brand for the first time and ends when your product disappears from their life, returned or thrown away, sold to a friend or deleted in a burst of electrons.

Your customer doesn’t differentiate between your advertising and your app and your customer support agents—all of it is your company. Your brand. All of it is one thing.

To do that right, you have to prototype the whole experience—give every part the weight and reality of a physical object. Regardless of whether your product is made of atoms or bits or both, the process is the same. Draw pictures. Make models. Pin mood boards. Sketch out the bones of the process in rough wireframes. Write imaginary press releases. Create detailed mock-ups that show how a customer would travel from an ad to the website to the app and what information they would see at each touchpoint. Write up the reactions you’d want to get from early adopters, the headlines you’d want to see from reviewers, the feelings you want to evoke in everyone. Make it visible. Physical. Get it out of your head and onto something you can touch. And don’t wait until your product is done to get started—map out the whole journey as you map out what your product will do. That’s how you hack your brain. How you hack the brains of everyone on your team. Start from that very first moment of the customer journey. You should be prototyping your marketing long before you have anything to market.

A good product story has three elements: » It appeals to people’s rational and emotional sides. » It takes complicated concepts and makes them simple. » It reminds people of the problem that’s being solved—it focuses on the “why.”

That “why” is the most critical part of product development—it has to come first. Once you have a strong answer for why your product is needed, then you can focus on how it works. Just don’t forget that anyone encountering your product for the first time won’t have the context you have. You can’t just hit customers on the head with the “what” before you tell them the “why.” And keep in mind that customers aren’t the only ones who will hear this story. Telling the story is how you attract people to your team or investors to your company. It’s what your salesperson puts in their slide deck and what you put in your board presentation.

He used a technique I later came to call the virus of doubt. It’s a way to get into people’s heads, remind them about a daily frustration, get them annoyed about it all over again. If you can infect them with the virus of doubt—“Maybe my experience isn’t as good as I thought, maybe it could be better”—then you prime them for your solution. You get them angry about how it works now so they can get excited about a new way of doing things.

Steve was a master of this. Before he told you what a product did, he always took the time to explain why you needed it. And he made it all look so natural, so easy.

Steve didn’t just read a script for the presentation. He’d been telling a version of that same story every single day for months and months during development—to us, to his friends, his family. He was constantly working on it, refining it. Every time he’d get a puzzled look or a request for clarification from his unwitting early audience, he’d sand it down, tweak it slightly, until it was perfectly polished. It was the story of the product. And it drove what we built.

And when I say “story,” I don’t just mean words.

And the story doesn’t just exist to sell your product. It’s there to help you define it, understand it, and understand your customers. It’s what you say to investors to convince them to give you money, and to new employees to convince them to join your team, and to partners to convince them to work with you, and to the press to convince them to care. And then, eventually, it’s what you tell customers to convince them to want what you’re selling. And it all starts with “why.” Why does this thing need to exist? Why does it matter? Why will people need it? Why will they love it?

To find that “why,” you need to understand the core of the problem you’re trying to solve, the real issue your customers face on a regular basis. [See also: Chapter 4.1: How to Spot a Great Idea: The best ideas are painkillers, not vitamins.]

And you have to hold on to that “why” even as you build the “what”—the features, the innovation, the answer to all your customers’ problems. Because the longer you work on something, the more the “what” takes over—the “why” becomes so obvious, a feeling in your gut, a part of everything you do, that you don’t even need to express it anymore. You forget how much it matters. When you get wrapped up in the “what,” you get ahead of people. You think everyone can see what you see. But they don’t. They haven’t been working on it ...

There’s a competition for market share and a competition for mind share. If your competitors are telling better stories than you, if they’re playing the game and you’re not, then it doesn’t matter if their product is worse. They will get the attention. To any customers, investors, partners, or talent doing a cursory search, they will appear to be the leaders in the category. The more people talk about them, the greater their mind share, and the more people will talk about them.

A good story is an act of empathy. It recognizes the needs of its audience. And it blends facts and feelings so the customer gets enough of both. First you need enough insights and concrete information that your argument doesn’t feel too floaty and insubstantial. It doesn’t have to be definitive data, but there has to be enough to feel meaty, to convince people that you’re anchored in real facts. But you can overdo it—if your story is only informational, then it’s entirely possible that people will agree with you but decide it’s not compelling enough to act on just yet. Maybe next month. Maybe next year.

So you have to appeal to their emotions—connect with something they care about. Their worries, their fears. Or show them a compelling vision of the future: give a human example. Walk through how a real person will experience this product—their day, their family, their work, the change they’ll experience. Just don’t lean so far into the emotional connection that what you’re arguing for feels novel, but not necessary.

Every person is different. And everyone will read your story differently. That’s why analogies can be such a useful tool in storytelling. They create a shorthand for complicated concepts—a bridge directly to a common experience. That’s another thing I learned from Steve Jobs. He’d always say that analogies give customers superpowers. A great analogy allows a customer to instantly grasp a difficult feature and then describe that feature to others. That’s why “1,000 songs in your pocket” was so powerful. Everyone had CDs and tapes in bulky players that only let you listen to 10–15 songs, one album at a time. So “1,000 songs in your pocket” was an incredible contrast—it let people visualize this intangible thing—all the music they loved all together in one place, easy to find, easy to hold—and gave them a way to tell their friends and family why this new iPod thing was so cool.

I remember there was one complex feature that was designed to lighten the load on power plants on the hottest or coldest days of the year when everyone cranked up the heat or AC at once. It usually came down to just a few hours in the afternoon, a few days a year—one or more coal power plants would be brought on line to avoid blackouts. So we designed a feature that predicted when these moments would come, then the Nest Thermostat would crank the AC or heat up extra before the crucial peak hours and turn it down when everyone else was turning it up. Anyone who signed up for the program got a credit on their energy bill. As more and more people joined the program, the result was a win-win—people stayed comfortable, they saved money, and the energy companies didn’t have to turn on their dirtiest plants. And that is all well and good, but it just took me 150 words to explain. So after countless hours of thinking about it and trying all the possible solutions, we settled on doing it in three: Rush Hour Rewards.

Everyone understands the concept of a rush hour—the moment when way too many people get on the road together and traffic slows to a creep. Same thing happens with energy. We didn’t need to explain much more than that—rush hours are a problem, but when there’s an energy rush hour, you can get something out of it. You can get a reward. You can actually save money rather than getting stuck with everyone else.

You should always be striving to tell a story so good that it stops being yours—so your customer learns it, loves it, internalizes it, owns it. And tells it to everyone they know.

Evolution Versus Disruption Versus Execution Evolution: A small, incremental step to make something better. Disruption: A fork on the evolutionary tree—something fundamentally new that changes the status quo, usually by taking a novel or revolutionary approach to an old problem. Execution: Actually doing what you’ve promised to do and doing it well. Your version one (V1) product should be disruptive, not evolutionary. But disruption alone will not guarantee success—you can’t ignore the fundamentals of execution because you think all you need is a brilliant disruption. And even if you do execute your idea well, it may not be enough. If you’re revolutionizing a major, dug-in industry, you may also need to disrupt marketing or channel or manufacturing or logistics or the business model or something else that never occurred to you. Assuming V1 was at least a critical success, the second version of your product is typically an evolution of your first. Refine what you made in V1 using data and insights from actual customers and double down on your original disruption. The execution should step up a notch—now you know what you’re doing and should be able to provide a significantly more functional product. You can continue evolving that product for a while, but always seek out new ways to disrupt yourself. You can’t only start thinking about it when the competition threatens to catch up or your business begins to stagnate.

The key is to find the right balance—not so disruptive that you won’t be able to execute, not so easy to execute that nobody will care. You have to choose your battles. Just make sure you have battles.

If they can’t innovate, they litigate.

Even starting something new in a big company won’t protect you. You’ll have to deal with politics, jealousy, and fear. You’re trying to change things, and change is scary, especially to people who think they’ve mastered their domain and who are completely unprepared for the ground to shift under their feet. All it takes to start a landslide is one big scary new thing. Maybe two. Just don’t overshoot. Don’t try to disrupt everything at once. Don’t make the Amazon Fire Phone.

But that’s the tricky thing with disruptions—they’re an extremely delicate balancing act. When they fall apart it’s usually for one of three reasons: You focus on making one amazing thing but forget that it has to be part of a single, fluid experience. [See also: Figure 3.1.1, in Chapter 3.1.] So you ignore the million little details that aren’t as exciting to build—especially for V1—and end up with a neat little demo that doesn’t actually fit into anyone’s life. Conversely, you start with a disruptive vision but set it aside because the technology is too difficult or too costly or doesn’t work well enough. So you execute beautifully on everything else but the one thing that would have differentiated your product withers away. Or you change too many things too fast and regular people can’t recognize or understand what you’ve made. That’s one of the (many) issues that befell Google Glass. The look, the technology—it was all so new that people had no idea what to do with it. There was no intuitive understanding of what the thing was for. It’s as if Tesla decided out the gate to build electric cars with five wheels and two steering wheels. You can change the motor, change the dash—but it still has to look like a car. You can’t push people too far outside their mental model. Not at first.

I had friends at Philips who told me that every time they’d think of a great idea for how to outmaneuver the iPod, we’d come out with a similar feature a few months later and they’d have to go back to the drawing board. It crushed their spirits. We were moving so fast that by the time they caught up they were already behind.

The lesson is about when and how vision and data should guide your decisions. In the very beginning, before there are customers, vision is more important than pretty much anything else. But you don’t have to figure out your vision all by yourself. In fact, you probably shouldn’t. Locking yourself alone in a room to create a manifesto of your single, luminous vision looks and feels indistinguishable from completely losing your mind. Get at least one person—but preferably a small group—to bounce ideas off of. Sketch out your mission together. Then fulfill it together.

At that point you have to go back and, as painful as it is, honestly and thoroughly analyze why you failed. This is the moment when you need to gather data. Your gut got you to this point, so find data to help you understand why your gut was wrong.

When you’re building the second version of your product, you can talk to actual customers and understand exactly what they think and what they want to see next. You can do all the stuff you desperately wanted to put into V1 but couldn’t. You can analyze the numbers, understand the costs and benefits. You can confirm your insights with information, A/B tests, charts, and figures. You can adjust and adapt to your customer’s needs and more and more decisions can be driven by glorious, simple, clear-cut, black-and-white data.

If you wait for your product to be perfect, you will never finish. But it’s very hard to know when you’re done—when you need to stop building and just put it out into the world. When is it good enough? When are you close enough to your vision? When are the inevitable issues ignorable enough that you can live with them? Typically your vision is so much greater than what materializes in V1. There’s always another revision, always something else you want to do, change, add, tweak. When do you tear yourself away from what you’re making and just … stop? Ship it. Set it free. See what happens.

To write a good press release you have to focus. The press release is meant to hook people—it’s how you get journalists interested in what you’re making. You have to catch their attention. You have to be succinct and interesting, highlight the most important and essential things that your product can do. You can’t just list everything you want to make—you have to prioritize. When you write a press release you say, “Here. This. This is what’s newsworthy. This is what really matters.” So spend some time developing as great a press release as you can. Consult with marketing and PR people if you have to. They’ll help you trim it down to the essentials. Then weeks or months or years later, as you’re getting close to finishing, as you’re debating what makes it in, what gets cut, what matters, what doesn’t—take out your press release. Read it.

If you launched right now, could you more or less send that press release into the world and have it be mostly true? If the answer is yes, then congratulations: your product is probably ready, or at least pretty close. You have achieved the core of your vision. Everything else is most likely a “nice to have,” not a priority. Of course, there’s a chance that since you started, you’ve had to pivot so much that the original press release is laughably off-base. Sometimes that happens. No problem. Write another press release. Rinse. Repeat. This is an adventure and adventures never go according to plan. That’s what makes them fun. And scary. And worth doing. That’s why you take a deep breath, surround yourself with great people, and head out into the wilderness.

By the end of the first iPhone project we had about eight hundred people working on it. But can you imagine what would have happened if all eight hundred had been with us from the beginning, watching us abandon the vision and restart the project? And then do it again a few months later? It would have been mayhem. Eight hundred people panicking and us endlessly reassuring everyone, focusing on the positive, trying to keep all those people in sync with a truly crazy number of iterations. So keep your project small as long as you can. And don’t allocate too much money at the start. People do stupid things when they have a giant budget—they overdesign, they overthink. That inevitably leads to longer runways, longer schedules, and slower heartbeats. Much, much slower. Generally any brand-new product should never take longer than 18 months to ship—24 at the limit. The sweet spot is somewhere between 9 and 18 months. That applies to hardware and software, atoms and bits. Of course, there are things that take longer—research can take decades, for example. But even if it takes ten years to research a question, regular check-ins along the way ensure you’re still chasing the right answer. Or still asking the right question.

And in order to keep the project heartbeat going, every team will need to produce its own deliverables at its own pace. Each team’s heartbeat will be different—it could be six-week sprints or weekly reviews or daily check-ins. It could be scrum or waterfall or kanban, whatever organizational framework or project management approach works for you. A creative team is going to have a very different heartbeat than an engineering team; a company that makes hardware is going to have slower team rhythms than companies that only push around electrons. It doesn’t matter what that heartbeat is, your job is to keep it steady so your team knows what’s expected of them.

And that enabled us to build the V1 of Velo in about eighteen months. Then we handed it, gleaming and new, to sales and marketing. And they had absolutely no idea what to do with it. They’d never seen it before. They didn’t know how to sell it, where to sell it, how to advertise it. They had been an afterthought to us, and now we were an afterthought to them. We had figured out our internal heartbeat, but had never synced it with any other team. Nobody else could keep up with our rhythm. We were dancing to our own beat, sure that all eyes were on us, and our dance partner was across the room getting punch, thinking about electric shavers.

We needed internal milestones within the project—regular check-ins where we would make sure everybody understood how the product had evolved and could evolve their side of the business along with it. And to make sure the product still made sense. To see if marketing still liked it. To see if sales still liked it. To see if support could still explain it. To make sure everyone knew what they were making and the plan to launch it. Those milestones slow you down in the short term, but ultimately speed up all of product development. And they make for a better product.

Heartbeats shouldn’t be too fast. If a team is constantly updating their product, then customers start tuning out. They don’t have time to learn how the product works—certainly not to master it—before suddenly it’s new again. Look at Google. Its heartbeat is erratic, unpredictable. It works for them—mostly, sometimes—but it could work so much better. Google arguably only has one big external heartbeat each year at Google I/O—and most teams don’t bother aligning with it.

That was the only way to make the world predictable. And there’s nothing people like more than a predictable world. We like to think that we’re not ruled by schedules, that we can throw off the chains of habit at any time—but most people are creatures of routine. They’re comforted by the knowledge of what comes next. They need it to plan their lives and their projects. Predictability allows your team to know when they should be heads down working and when they should be looking up to check in with other teams or to make sure that they’re still headed in the right direction.

Predictability allows you to codify a product development process rather than starting from scratch every time. It allows you to create a living document with checkpoints, milestones, schedules, and plans that trains new employees and teaches everyone: This is how we do it. This is the framework for how to build a product. Ultimately, that predictability is how you’ll actually make your deadline.

customers need time to feel you out. The vast majority of people aren’t early adopters—they won’t try new things right away. They need time to get used to the idea, time to read some reviews, time to ask their friends, and then time to wait until the next version comes out because that’ll probably be even cooler.

They need time to get used to the idea, time to read some reviews, time to ask their friends, and then time to wait until the next version comes out because that’ll probably be even cooler.

Crossing the Chasm introduced the world to the famous Customer Adoption Curve chart below. The idea behind it is pretty simple: a small percentage of customers will jump to buy a new product early regardless of how well it works—they just want the latest doohickey. However, most will wait until it’s been around for a while and all the kinks have been worked out. Who’s it for V1 V2 V3

If you don’t understand how customer adoption maps onto product and company development, you’re missing a very important part of the puzzle.

After companies find product/market fit, they can start to focus on profitability. Businesses that build with atoms are focused on COGS—cost of goods sold. Aside from direct labor, the main thing they spend money on is actually making the product. So they need to lower the cost of producing their product in order to reach profitability. Companies that build with electrons are focused on CAC—customer acquisition costs. Aside from direct labor, their money gets spent selling and supporting their product. Companies that build with both atoms and electrons have to worry about COGS and CAC, but generally should focus on one at a time. First knock out COGS, then move on to CAC. Build the product, then add the services. And despite the many differences between atoms and electrons, hardware and software, there is one thing that has the exact same stranglehold on both: time. No matter what you’re building, reaching profitability will take longer than you think.

even if your timeline has shrunk—even if you’re just revving an app—your product still has to learn how to crawl, and then walk, before it can run. That can take just as long for an app or service as it does for a hardware launch.

But crossing the chasm isn’t a guarantee, even with much-loved products. And actually making money is much, much harder.

Early adopters know nobody gets everything right with V1. Nobody even gets everything they were originally planning for V1 into V1. The product and customer base evolve and grow with each iteration, and every stage brings on different risks and challenges and investments. Nobody can tackle them all at once. Not at a startup, not at a big company. So you and your employees and your customers all need to have the right expectations. And so do your investors.