Pivoting

(It will be interesting to see how things change with OS4's background processing. I'd guess users will continue to prefer for check-in based over continuous gps logging, though there may be some interesting/appealing applications of continuous logging. Haven't really looked into the specifics yet.)

This probably holds true for a lot of examples of companies that solved the wrong problem. When your competitors can evaluate your progress, it's much easier for them to position themselves according.

Not to disregard or in any way invalidate your point, which has been taken, but did Steve have a solution for the possible ear wax issue, or does his famed reality distortion field extend to ear wax as well? I'm generally not keen to use anyone else's earbuds, nor am I keen to lend mine to anyone else (and they're not even the kind that you need to wedge into your ear).

The best solution is the simplest one which solves 80% of the problem. Very important when creating a minimum viable product.

I am failing to remember who said: the perfect racing car falls apart the moment it crosses the finishing line - all others else are over-engineered. The point is that good engineering is appropriate engineering. All the things that PHBs sometimes think off as the geeks going off on their own obsessions - maintainability, clarity of design, low fault tolerance, high scaling ability - these are either good engineering or over-engineering depending on the stage of the lifecycle, the purpose of the project (air traffic control systems anyone?), the future staffing estimates and so on.

For example in my own area of acedemic-(ish) software engineering, maintainability absolutely trumps delivery dates. Clearly, if you are chasing ramen profitability, it may not.

Context matters.