I think they are doing it wrong then. You do the cheap parts independently. Then you pair down to fewer choices and transfer resources to fewer groups.

You repeat this multiple times depending on your resources. When things get really expensive, you should be down to one idea.

I'd imagine that this can be pretty tricky with more complex systems, where the buy-in for even getting off the ground can be pretty high. In software, that's usually not the case, but I can imagine a number other instances where it wouldn't work. This seems like it would show up the most when the problem isn't a greenfield where getting the first 90% working is the hard part, but on the other end, where the difference comes from optimizing the last 10%, which can be really expensive (i.e. figuring out how to profitably and effectively take production from 1000 parts to 10,000 parts can be much more difficult and costly than moving from 100 to 1000).

Having seen a couple of Jobs interviews, it seemed like he was very well informed of all the trade-offs he was asking. He had some idea how all the bits in his project would scale (in various ways - with more users, programmers, parts, etc) even if he didn't like getting his hands dirty with the work of actually doing it.

> In our case, making two teams work independently on the same problem just created a situation where each team had half as many resources.

You got it. Not to mention that you're incentivizing them to hoard work/attention/resources from one another, or engage in other organizational anti-patterns that would obviously be/become problems to solve if you didn't put the artificial "constraint" of internal competition in the way.

This is very interesting. Just because a technique works for situation A doesn't mean it works for situation B. Also, maybe this ex-Apple CEO didn't have the capability to pull it off.