Building great products is tough. Premature optimization will probably kill it.

This thought came to me watching interviews with the original iPhone team. The original iPhone was a marvel in design and took many little adjustments and iterations to get right before it saw the light of day. To move quickly, the team programmed it on a breadboard attached to a Macintosh Pro G5. This meant performance was a secondary concern. At First.

Most teams would've opted to build the phone and figure out what UI they could fit in a 412mhz processor with 128mb of RAM. Not Apple. They built the best product they could and then squeezed it down into a smaller device. I'm sure some things were left on the design room floor. It is a monstrously more powerful machine after all. But getting the fundamentals right was more important. Speed would be solved later.

That's because picking one metric helps decide your north star, your point of focus. Picking two north stars pushes you to prematurely compromise on something that doesn't even really exist yet.

This doesn't just come up for companies like Apple. It also springs up in smaller teams. One example in programming is Docker image sizes. It's more convenient to have a slim docker image size. However, it's not strictly paramount. Spending time on getting a 500mb image down to 400mb is extremely wasteful if you don't have any customers yet. Solve that problem first. It's more important.

Are there any premature optimizations happening in your organization?

I do recommend the full interview with both Scott Forstall and the OG iPhone team. You can watch it below (~2hr):