It’s Done, Right?
28th December 2011 · 0 Comments
A friend this week passed along to me the Cult of Done Manifesto, which was first “poted” on the linked blog in March, 2009. Evidently proof reading was deferred to the post-done phase. Nonetheless this is a timely topic in that several projects in which I’m involved are fast approaching their launch dates.
Nothing focuses a development team on a deadline more acutely than the presence of a real customer and/or an investor who wants to acquire a working product. There are always more features to be considered and more final tests to be run, and there are inevitable environmental issues such as OS or other component upgrades that can impact even the most buttoned-up designs. However, at some point the risk of delay outweighs the risk of releasing a few mistakes.
Having grown up in the software business when almost none of the underlying elements worked as advertised, I came to respect our loyal Peachtree Software customers as beta testers. We didn’t in those times have the Internet to blast out instant updates, but we didn’t bring any business to its knees if its books were out of balance for a few days. The pressure is much more intense now that very large customer bases count on systems performing flawlessly, particularly with respect to security and money handling functions. Experimenting on end users in this context certainly has its perils.
A more mature company with other revenue streams may have the luxury of absorbing delays. Or, as in the case of RIM, we seem to be observing even a heavily entrenched brand being derailed by just that issue. If you’re at the startup stage, and particularly if your access to funding depends on filling customer orders, you have no cushion. When you’re at the “fume” stage, as Bob Metcalfe calls it, your options become mighty limited.
Lots of entrepreneurs deal with this by designing the proverbial “minimally viable product” and letting it loose into the wild. Sometimes that strategy works for things like apps that are not exactly mission critical. If your core concept resonates with a customer audience, you’ll get the chance to make updates and solidify your base. One of my favorite products is Evernote, and I’ve stuck with it through a bunch of “upgrades” that have at times almost rendered it unusable. But, that company seems to eventually get things right, and I have work-a-rounds for the bugs that affect me. Evernote is far beyond the MVP stage, but it’s a good example of something that resonates with users.
If on the other hand you’ve chosen to create something much more complicated and one where fatal errors can be fatal to your business plan, and you absolutely have to get it out the door, what is the answer? I think it’s just basic engineering problem solving. You’ve got to work back from a deadline and define exactly what has to be done and how it is going to get done, and just make it happen with whatever resources you can muster. You have to make all decisions on what to do next in the context of such a plan. I’m about halfway through the Steve Jobs biography as of this writing, and he was able to motivate his engineers to do the impossible on many occasions when product releases were due. And, as you know, he was generally unwilling to make any design sacrifices to make developers’ lives easier. You may have no one above you on the org chart that exerts that level of personal pressure, but you are the one who faces your customers and investors, and they’re just as persuasive. If necessary, pause for a moment to regroup, but only a moment, and then go forth on the plan.
I debated titling this post either “It’s Done, Right?” or “It’s Done Right?” The answer to both has to be “Yes.”
Tags: 400-bad-request, Angel Investor, browser, browser-sent
