Six Steps to Superior Product Prototyping: Lessons from an Apple and Oculus Engineer


Declare Your Non-Negotiables

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. “Focus on the product and the consumer experience. On the Oculus Rift, if you didn’t experience “presence,” or the feeling that you’re actually in your virtual environment, we weren’t going to ship it. If the Oculus Rift didn’t fit comfortably on a wide set of adult faces, we weren’t going to ship it. Decide at the beginning, what are the goals you must hit in order to deliver those key features? As long as you achieve those product goals, you can have discussions about other matters like secondary features and whether you’ll ship or delay your schedule. Share those must-haves with your entire organization. Get everyone on board with the non-negotiables so you’re moving together towards the same goal.”

Slide into a Prototyping Plan

The Six-Step Approach to Prototyping

First, frontload. Pile on the effort and focus at the beginning of your journey. “My former colleague Doug Field, who was a VP at Apple and now runs engineering at Tesla, had a very useful graph of how to think about design effort. Most people increase their effort and focus as the product develops and they find issues they need to fix or address, peaking at the moment right before you ship. Although this is sometimes unavoidable, this is not what you want to do. Making changes at the end of development is far more difficult, dangerous and costly than in the beginning,” Kalinowski says. “By the EVT [engineering validation test], your goal is to basically be done. Often it’s very difficult to achieve this, but it’s a good goal. If you have to fix major design issues after EVT, you’ll have diminishing returns on your efforts. Ideally, the phases after EVT are a scaling operation in hardware or bug fixes in software. You won’t have much ability to make big changes after this point without causing risk. Focus your effort towards the beginning, where you can squeeze in as many iterations and changes as possible. Go through crazy amounts of work right here. Put the best people on it. Do all of your grinding here.”

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

How to tell if you’re converging on the right solution in your prototyping process

Prototyping just the right amount of time. Products are never perfect, but at some point you have to call it. “There are always more iterations we can do and there is always something that engineers are worried about, because it’s their job. Your engineers will never feel like the product’s done. Usually team leaders are okay with shipping with a few minor issues, but engineers will struggle with it. My strategy is to say we’ll get it right in the follow-on product. Let the engineer know that you care. You want to get it right. But this product needs to go out,” Kalinowski says. “They’ll still get to do all this cool engineering. They’ll still get to solve this problem that they’re unhappy about. Every engineer has that feeling of, “Man, I wish I did this differently. This isn’t quite where I want it to be.’ Great. Fix it, but you don’t have to fix it right now in this product. You can fix it in the next product and the next product, and make sure that it’s good forever forward. That helps a lot. Start a list of what you’re not going to fix. That doesn’t mean you’ll never deal with it. Fix it next time. Worst-case scenario, you can roll a fix after ramp, when you’re building up a bunch of product right before the sales date, or iterate off-build.”

Getting to Blastoff

Iterate Your Way To Success