by Jared Goralnick
Conventional wisdom is if you want something done fast, you’re going to pay a premium. Or that if things are rushed, quality suffers. But in a product business, time is the most expensive and dangerous enemy.
There is a time to sprint, and not just because you want to work harder. Consider this:
An Exercise in Human Resources
Assuming 9 months of work to create a product, which would be the best hiring strategy?
- 1 developer working for 9 months
- 3 developers working for 3 months
- 5 developers working for (just under) 2 months
- 9 developers working for 1 month
I’d bet most people would go with the middle options, but why?
- Their gut would tell them to dismiss the first option: 9 months seems too long to wait, maybe the market will have changed, perhaps having only one developer would put them at risk
- They’d probably dismiss the last option: 9 developers is probably really expensive, and it’d likely be difficult to catch a big mistake and alter it without spending too much on rework
The last option is a bit extreme, and for all but the most experienced of project managers with the most firm and well-thought specifications it’s likely unreasonable. Chances are the middle two are the best options. Both for the reasons above (which you likely considered) and also for a set of reasons that I want to stress below.
But I will also come back to this…as I’d be willing to bet most people (who aren’t answering this as a purely intellectual exercise) have actually chosen option 1 (solo entrepreneurs who build your own product, this is especially true for you). Now let’s talk about all the reasons this is a bad decision, and in what cases the last option might even be the best one.
A Month Costs A Lot of Money
If you don’t know your monthly burn (the monthly expenses for your company) then, well, figure them out. Depending on the size of your company, you might want to include your personal expenses in these numbers as well. Anyhow, hold onto this number.
If you’re like most companies, you’ll find that a lot of this number comprises money that just seems to disappear every month—most of it may be salaries, but a lot of it is fixed/variable expenses you wish didn’t exist (insurance, office space, transportation, food, infrastructure, etc). Maybe it’s just 2,000, maybe it’s 6,000, maybe it’s 12,000…but whatever it is, it’s significant.
Nevermind interest fees. Or the fact that it’s a month of your life.
And of course there’s the the frustrating fact that you can’t put your head down and focus for too long (1 month? 2 months? 4 months?) without allowing the real world to haunt you with its responsibilities, risks, and bills.
Consider this: if you could cut three months of (non-payroll) expenses out of your project by making the project three months faster, how much more would you have available for developers? How much sooner would your project be ready?
Solos: if you have $60,000 to work with, and gave yourself a year to build your product, consider how much faster and more relevant your product would be with other people on your team…and how much sooner you’d realize whether you were going down the right path and…
Time Flies By…and So Does Your Competition
If you’re in a competitive or quickly changing industry (like, say, web applications) then time matters. I’ve learned of dozens of companies that have “validated” our market since I started working on AwayFind. If I decide to slow down for a while, many of our core features would no longer be novel, let alone remarkable.
Cutting edge is no longer a quaint thought. Every 6 months there’s a metamorphosis in which technologies are available (and which businesses are making money of them to do what you want to do).
Time Commitments Take Time
If you’re still chipping away at the same problem a year from now would you feel good about it? If your team members also lacked that sense of completion, would they still be there?
When time goes by, there’s a chance you’re going to wander off. There’s a VERY good chance someone in your team will move on. So it’s in your interest to get as much done as possible while you have them.
But What About Slow Growth and Learning?
My team worked on AwayFind for a very long time, not putting many hours into it in the beginning. These are our actual hours (Y axis) over 2 years (X axis):
This shape represents a company that wasn’t so sure how much time it wanted to put into its product, particularly when there was another (i.e., a real ;-) source of income (our consulting business). It also shows a company that incubated a lot of information before realizing how to respond to customers and try again.
Let’s just assume that I didn’t have another business. If I were paying 5,000 per month in fixed expenses then that would’ve been $5,000 x25 = $125,000. If we had moved faster, I could have had access to some of that money.
I will admit that I learned a lot about building a web application and grew many relationships over this two year period. While the purpose of AwayFind hasn’t changed (escape interruptions while still being responsive), its technology and experience are the difference between MS-DOS 2.11 and Windows 7.
But there are periods on this graph where we could’ve and should’ve moved faster.
So When Do You Sprint?
If you look closely at that graph, you’ll see the last dip before the hours went pretty-much straight up (the dip was May 09). From that point onward we’ve mostly been chipping away in product development. Leading up to the first launch we also could’ve beefed up our product development, much more than you see here—it would’ve saved us months and probably $15-25k.
In the last few months I’ve hired 2 full time developers, a Director of Communications, and worked with several consultants.
I couldn’t have just tossed those people in at any time, but as soon as it became clear that there were multiple months of work for a new person, I’ve added that person.
Right now we’re sprinting. We need to improve the UX on a number of areas, we need to better connect to certain email providers, we need to finish our marketing site.
I see very clearly what needs to happen on the product side, so I just want to move as quickly as possible to get there.
Back to the Exercise from Before…and the Right Answer
The more crystal clear your specifications and needs become, the better in a position you are to divide the tasks amongst multiple people and move as quickly as possible.
Of course, this assumes that you can find the right people for the right price, and that you know how to manage them. All those things are easier said than done. But those are relationships and skills that every entrepreneur can benefit from.
We all have a fundamental understanding of how to “control costs.” But we don’t always know how to “control time,” particularly in relation to how time affects costs and our position in the market. Next time you’re ready to sprint, do it–you’ll save a lot of money, hit your market, and have a better chance for success.
You should really subscribe to Technotheory via 
email or rss.
Good post. It’s good to get peoples thoughts on the subject, especially for product people like myself. However, people should be wary of looking at the problem from a purely financial point of view. While we’re talking about relatively small groups of people, the idea of the Mythical Man Month still holds true.
I like that you mentioned “as soon as it became clear that there were multiple months of work for a new person, I’ve added that person”. Just hope that distinction is clear to others.
Thanks for the perspective!
Thanks, Nick. You’re right that much of this post shouldn’t be taken to heart without strong clarity on the part of the PM/CEO.
I began to write this post without any caveat about clarity–mostly touting working fast–but that’s just not good advice–that there are many times when we need to slow down and figure things out without burning people’s time on the wrong effort.
However, once you know that there’s a straight path from X to Y that takes 100 hours, getting those hours out of the way in the shortest calendar span is very helpful.
Jared – A great and thoughtful piece!
I agree with everything you say about how to think about the costs and opportunities that result in deciding to sprint vs. spread out a project. Here are two caveats I’d add:
1. If you sprint, know when to stop sprinting. Very often sprints aren’t called off when they should be. Especially if talented people have been hired for the sprint phase, owners often keep them around because they don’t want to let good people go (or have a reluctance to terminate them) or keep thinking up new things for them to do, whether or not they are core to the business objectives. So sprints can often run into massive cost overruns after the initial sprint period.
2. Usually sprints are built on the premise that the work path is pretty well defined at that point. But there are still times during a sprint where it would be best to turn the direction or revise plans, regardless of the sunk costs. So it would benefit any owner before starting a sprint to really work through the contingencies that might call for a change in direction, rather than getting swept up in the adrenaline of the sprint and the reluctance to think about making any changes.
Again, really like the way you have laid out the issues so clearly!
Really appreciate your thoughts here, Victoria. These are great caveats : ).
First of all thank you for this informative article, I was just wondering what where your “Soaring Signs” that encouraged you or enlightened this is the time to start “Sprinting” with your startup?