He's referring to Loopt (and others I suppose) when he says "The other companies built elaborate infrastructures: e.g they partnered with wireless carriers so that users’ locations could be tracked in the background without having to “check-in”."
This is the kind of mistake that burns so badly. You find yourself saying something like "You mean you just ask them to update their location manually and that works?"
It reminds me of when Ballmer was bragging about how sharing songs via WiFi on the Zune could get you a date. Then Steve Jobs recommended simply giving one earbud to the girl.
The differencing between trying to untie the The Gordian Knot and taking a sword to it.
To be fair to loopt, the market changed between 2005 when they launched and 2009 (ish) when foursquare launched. 5 years ago people weren't nearly as comfortable with the idea of location based social networks. Loopt and the deals that they signed probably had a big hand in making the concept more familiar and paved the way for many of it's competitors. The popularity of twitter might have also had something to do with it.
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.
The timing of the iPhone (its OS and its app store ecosystem) played a significant role in the check-in model, I think, as it encouraged developers to [finally] sidestep the carriers, and also prevented background processing. Though this is kinda irrelevant to Chris' bigger point of pivoting towards a perceived advantage.
(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.)
Google Latitude on the Android follows the continuous logging model. It's interesting but for very different reasons than Foursquare. Foursquare's appeal to me is more keeping a record of interesting places I go and sharing that with others. Latitude's appeal is, oh, where are my friends right now.
... Then Steve Jobs recommended simply giving one earbud to the girl.
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).
I was actually thinking of it the other way around, the comfort factor of a girl that I assumedly don't know very well being offered my ear buds and the potential awkwardness that this may engender, regardless of the actual condition of my hypothetical ear buds (which would be very clean) or my general rule about no one using my own ear buds (to which there are admittedly some rare exceptions, with people whom I know well enough). But I guess judging by the downvote, not Steve or anyone else must think this way. Message received.
#2 is a big one. If there's one HN ethos that I disagree with, it's the idea that a better engineered solution is always a better solution (full stop). Unless you have infinite time and developers, that's not true.
A better engineered solution is always a better solution. What he is describing is over-engineering.
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.
I'm certain that over time, our product would have evolved through user feedback and bug fixes. But he's definitely referring to the products that did launch, because I am also considering the products that we thought would create market share yet went south. This is where Chris's rule #1 applies.
How is this counteracted by asking whether they would build the product the same way were they to start over? It seems it would do the opposite: Bring all the warts to their attention and make them rewrite the code even though it works perfectly well.
What if your business is going pretty much like you expected? I am actually kind of stressed out that things are going smoothly, does that mean I am not finding the weakness in my business fast enough? Or are things actually going smoothly?
There's also the danger of pivoting too fast. Don't continually half-ass things without letting them bake and mature. Something's to be said about following through and executing your vision, right?
The startup that I work for started out as a video upload site. On a whim one of the developers added the ability to use an embed code instead of uploading a video from your computer. When that became popular, it got promoted more and more until now, where there isn't even the option of uploading your own videos anymore. I always thought that was a hell of a pivot.
This is the kind of mistake that burns so badly. You find yourself saying something like "You mean you just ask them to update their location manually and that works?"
It reminds me of when Ballmer was bragging about how sharing songs via WiFi on the Zune could get you a date. Then Steve Jobs recommended simply giving one earbud to the girl.
The differencing between trying to untie the The Gordian Knot and taking a sword to it.