This is someone who has either not only drunk the kool aid, but is already on their way back from the store with another carful of it, or someone with very limited experience of business. I have worked for many, many businesses whose competitive advantage is not being fast, but in this author's view, being fast is the only advantage there is. Competence, cost, quality, reliability? Just fairy tales.
However, part way through this breathless look-at-me, the author clearly describes the advantage of a simple price scheme (We offered one price of $50 per employee per year... We just wanted to be able to tell people, “We may not be free, but we’ll be the simplest decision you ever made.”). This actual advantage is then smothered under the breathless fact that it was decided quickly; he made a good decision quickly, and that it was done quickly is apparently more important than being right. What a mess of text, and a mess of self-contradiction. Clearly, someone has decided the correct answer, "speed", and is now trying to mash evidence to fit.
I enjoyed the 'GM is slow' comment. While that may be true in terms of innovation, it is the opposite when it comes to manufacturing. I've worked in those plants where the 'speed above all else' sentiment is eerily similar to this article, and is largely the reason I chose a different career path.
The one thing I take away from this is the accountability perspective. It's ok to ask why things will take the amount of time projected. Things often do get tacked on that don't need to be.
> All else being equal, the fastest company in any market will win.
So, that's why we all still use AOL? And why Microsoft never had to worry since it built Office? Why PayPal squashed Venmo? The point is really that all else are never equal. Speed to market is A factor, but it's not the only factor, or even the most important factor today. Look at Box, vs. Dropbox, vs. Copy, vs... The market is big enough for multiple identical services. Users pick the one that works the best for them.
And I certainly agree asking questions is a GREAT way to start documenting all the stuff that has to go into a project. I'd add a bullet point, "Way more hours than I want for... explaining why setting up Vagrant is important... explaining why unit tests save time, for the 900th time... explaining why QA is needed..."
Things don't often get tracked that ought to be, but PLEASE do not send more meeting requests to your entire dev team asking them to justify to marketing or sales why we need the basic steps we ask for.
(This article hits a bit close to home today, as I'm literally in a meeting with 15 people where only 2 people are talking and I literally just had to defend QA marketing guy who clearly doesn't get it. And the topic... "How we can organize our team to be more efficient.")
AOL might have been first but then they just seem to have quit. They didn't keep up with the times. Their whole paradigm was terrible out of date. They were in the ISP market but extremely slow and it killed them.
Lotus 1-2-3 was before Excel but Lotus took a long time to release new versions while Office did not. You'll notice that MS isn't super quick with releases now, but they do churn out new versions with some regularity.
Business doesn't have a finish line so companies have to start and stay fast. This is why technical debt is a problem; sometimes you need technical debt to get something out the door fast, but it will slow down future releases so you need to get it under control.
There are many ways to get ahead. Bureaucracy sucks.
But just saying, "Speed man, speed... that's the good stuff..." It's only true when it's paired with customer demand, high quality, and all the other things users demand.
ICQ vs. AIM? I can't actually think of a single example of a product being first to market and that making them better than the challengers. Getting to market... no question, that's great. Blowing away what exists in the market... that's what gets you customers. So inherently being first isn't advantageous since you're opening the door to others taking your idea and improving on it.
I'll say again, build the best thing you know how to build... if you don't build it great, people will notice. Nobody wants a quick and dirty solution once they see the well-designed, delightful, secure, improved, etc. solution.
Facebook > MySpace
Instagram > Facebook
Reddit > Digg
Any modern software language... nobody is like, "Man, give me some ASP VB, that came out before Rails or Node... it must be better." We evolve. Speed, it may be a factor. But what you build has to survive past launch. Do your best to give it the legs it needs... and maintain it as vigorously as you can. ROI is in planning.
tl;dr version: There is an opportunity cost for the time you spend in decisions. If the decision is really the most valuable use of that time, take the time to make the decision. If not, make the best decision you can in the next 10 minutes, and move on.
It's hard enough to get proper time for planning technical projects without this kind of crap.
Guess what, planning time does save time and lowers your cost of ownership. ROI-wise, planning time is the best gift you can give your project.
But... then someone is like, "Speed, I hear speed is good... move faster. Dependencies... fuck 'em... I don't understand 'em anyway so fuck 'em. Let's just go as fast as we can and we'll worry about everything we should have worried about up front over the next few years after all our devs quit because they're tired of working on shitty code that was rushed through."
This article so rubs me the wrong way. "Technical debt? What's that?!"
Anything worth doing, is worth doing right. To the best of your ability. Doing things right takes time. Take your time, do things right.