Finding your have-to-haves often means boiling the most critical elements of a product down to one or two key features. In the case of the iPad, the product had to be lightweight enough that customers could hold it up easily. “Apple worked on the iPad for years. Steve Jobs always said it was too heavy. They turned it into the iPhone, worked on that for years, shipped the iPhone, went back to the iPad, worked on that for years and finally shipped the iPad. There probably wouldn’t have even been an iPhone if they hadn’t had that guiding principle for the iPad. They didn’t ship the earlier iPad prototypes because they were too heavy. It was tiring for your hands. It takes a lot a lot of discipline to keep developing until you nail your key features,” Kalinowski says.
Slide into a Prototyping Plan
…making 100,000 of a product versus two million changes your risk tolerance. You cannot recover from problems in the design of a two million unit product the same way you can with hundreds of thousands,” Kalinowski says. “If I’m at Apple developing the MacBook Air, I’m going to be far more cautious about risk because it’s a huge, high volume product. It’s expensive to recover from mistakes. If I’m designing the first VR product, I’m going to use less caution and be more ambitious because my volumes will be manageable enough that I’ll be able to fix problems in flight. I’ll try to move faster.…
The Six-Step Approach to Prototyping
First, frontload. …
Start with what’s hardest.
Braid in other hard things as you progress.
Make seriously ugly prototypes.
Let each team own their best-case scenario. When developing Apple’s cylindrical computer, the Mac Pro, Kalinowski had to juggle a multitude of factors. “The industrial design team wanted the device to have a really small diameter. But that meant a small diameter on the heat sink — which was a problem, because we wanted as much heat transfer as we possibly could. When the heat sink was small, more air had to be pulled through to cool the central processing unit (CPU), making it louder. Yet still we needed the computer to be quiet,” Kalinowski says. “The way to solve this problem was to let each team completely own its best-case scenario. There were separate teams inside Apple focused on optimizing for small diameter, focusing on keeping the noise down, worried about the heat transfer — we just let each one own that and drive as hard for their goal as they possibly could. For the thermal team, since this is a high performance machine, we needed the CPU performance as unlocked as possible, and so we let them fight for that. Then the audio team made sure the fan noise didn’t cross a certain threshold. Let everyone work on the best possible outcome for the feature for which they’re responsible, and you’re likely to end up making the best product trade-offs — and that means a better product.»
Smooth the negotiations while merging best-case scenarios. Once each team has come up with their ideal solution, you’ll have to start making tradeoffs — maybe the heat sink has to be tweaked in order to make the computer quieter, for example. “I never go into a meeting where a major decision is going to be made without having pre-baked the outcome. I first do a stakeholder analysis, go to each team, and get my proposal approved by everyone. What I learned at Apple is you really have to go around and explain what you think is right to each team. If you don’t have, for example, buy-in from across the product teams for a product decision, you really aren’t going to get anything out of that meeting. Do a lot of the early upfront negotiation so that meetings are just about finalizing decisions and locking them in,” Kalinowski says. “You also have to understand technical tradeoffs. You can’t just go in to an antenna team and say, ‘We can’t put antennas there. You have to put them here,’ and not understand if that’s not going to work. Do a listening tour and learn from a technical perspective about product tradeoffs. Understand why a team wants something. Form relationships with experts in your team, listen to them, believe them, but also push on them all in different ways at the same time as you’re trying to negotiate for that feature.”
The Three Bears of Prototyping
Prototyping for too long. “For the Mac Pro, we struggled to get the extrusion right. Two components, the heat sink and inner enclosure, were supposed to be made from one piece of aluminum. But it was too hard. We wound up cutting it into two pieces, even though the industrial design team really wanted it to be one. We went so far down the path trying to get it to be one piece, but in the end, it wasn’t working. That’s when Matt Casebolt made the call to stop. It’s because he had that feeling. We weren’t going to get there in time. We all wanted to make the industrial designers happy at Apple, but at a certain point, if you’re not converging, you need to make the call. They made this call. It was the right one.”
How to tell if you’re converging on the right solution in your prototyping process
Prototyping too short a time.
Prototyping just the right amount of time. Products are never perfect, but at some point you have to call it.
Getting to Blastoff
“Ending your iterations close to the ship date is really dangerous because of all the interdependencies. Be ready to fight for not fixing problems unless they’re non-negotiables. For example, you can decide to change the material a few weeks before the ship date. Then you’ll find out that the material change means the product is no longer waterfast, or it fails drop testing,” Kalinowski says.
Iterate Your Way To Success
Start your prototyping process by pinpointing your North Star. …Watch out for the warning signs of prototyping too long — or prototyping not long enough. Determine your stopping point by evaluating the remaining flaws you still want to address. The later you wait to make changes, the more dangerous your decisions will be. Be willing to fight for not making fixes.
“Look on the desks of your engineers. Are they littered with ugly prototypes? If so, you’re doing something right. Engineers often say they have it in their head how something is going to work. Ask for the parts. Ask to be shown. It often doesn’t work like they think it’s going to work. …
“Finally — and this is critical — prototyping is supposed to be really fun. If it’s not fun, you’re doing it wrong. If you’re over-constraining your engineers and they’re not able to come up with really cool solutions, or they do and you squash them, that’s bad. Free your engineers to come up with things — there should be an grand excess of cool ideas. After you’ve popped the champagne to celebrate your successful ship, you can pick up the next great product from your cutting room floor.”
appletalk:entremaqueros 