This is my foreword to Bob Walsh's new book, Micro-ISV: From Vision to Reality.
How the heck did I become the poster child for the MicroISV movement?
Of all people. Sheesh.
When I started Fog Creek Software there was gonna be nothing “micro” about it. The plan was to build a big, multinational software company with offices in 120 countries and a skyscraper headquarters in Manhattan, complete with a heliport on the roof for quick access to the Hamptons. It might take a few decades–after all, we were going to be bootstrapped and we always planned to grow slowly and carefully–but our ambitions were anything but small.
Heck, I don’t even like the term MicroISV. The “ISV” part stands for Independent Software Vendor. It’s a made-up word, made up by Microsoft, to mean “software company that is not Microsoft,” or, more specifically, “software company that for some reason we have not yet bought or eliminated, probably because they are in some charming, twee line of business, like wedding table arrangements, the quaintness of which we are just way too cool to stoop down to, but you little people feel free to enjoy yourselves. Just remember to use .NET!”
It’s like that other term, legacy, that Microsoft uses to refer to all non-Microsoft software. So when they refer to Google, say, as a “legacy search engine” they are trying to imply that Google is merely “an old, crappy search engine that you’re still using by historical accident, until you bow to the inevitable and switch to MSN.” Whatever.
I prefer “software company,” and there’s nothing wrong with being a startup. Startup software company, that’s how we describe ourselves, and we don’t see any need to define ourselves in relation to Microsoft.
I suppose you’re reading this book because you want to start a small software company, and it’s a good book to read for that purpose, so let me use my pulpit here to provide you with my personal checklist of three things you should have before you start your Micro… ahem, startup software company. There are some other things you should do; Bob covers them pretty well in the rest of the book, but before you get started, here’s my contribution.
Number One. Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain. The other day I went to a presentation of six high tech startups and not one of them had a clear idea for what pain they were proposing to solve. I saw a startup that was building a way to set a time to meet your friends for coffee, a startup that wanted you to install a plug-in in your browser to track your every movement online in exchange for being able to delete things from that history, and a startup that wanted you to be able to leave text messages for your friend that were tied to a particular location (so if they ever walked past the same bar they could get a message you had left for them there). What they all had in common was that none of them solved a problem, and all of them were as doomed as a long-tailed cat in a room full of rocking chairs.
Number Two. Don’t start a business by yourself. I know, there are lots of successful one-person startups, but there are even more failed one-person startups. If you can’t even convince one friend that your idea has merit, um, maybe it doesn’t? Besides, it’s lonely and depressing and you won’t have anyone to bounce ideas off of. And when the going gets tough, which it will, as a one-person operation, you’ll just fold up shop. With two people, you’ll feel an obligation to your partner to push on through. P.S., cats do not count.
Number Three. Don’t expect much at first. People never know how much money they’re going to make in the first month when their product goes on sale. I remember five years ago, when we started selling FogBugz, we had no idea if the first month of sales would be $0 or $50,000. Both figures seemed just as likely to me. I have talked to enough entrepreneurs and have enough data now to give you a definitive answer for your startup.
That’s right, I have a crystal ball, and can now tell you the one fact that you need to know more than anything else: exactly how much money you’re going to make during the first month after your product goes live.
In the first month, you are going to make,
$364, if you do everything right. If you charge too little, you’re going to make $40. If you charge too much, you’re going to make $0. If you expect to make any more than that, you’re going to be really disappointed and you’re going to give up and get a job working for The Man and referring to us people in startup-land as “Legacy MicroISVs.”
That $364 sounds depressing, but it’s not, because you’ll soon discover the one fatal flaw that’s keeping 50% of your potential customers from whipping out their wallets, and then *tada!* you’ll be making $728 a month. And then you’ll work really hard and you’ll get some publicity and you’ll figure out how to use AdWords effectively and there will be a story about your company in the local wedding planner newsletter and tada! You’ll be making $1456 a month. And you’ll ship version 2.0, with spam filtering and a Common Lisp interpreter built in, and your customers will chat amongst themselves, and tada! You’ll be making $2912 a month. And you’ll tweak the pricing, add support contracts, ship version 3.0, and get mentioned by Jon Stewart on The Daily Show and tada! $5824 a month.
Now we’re cooking with fire. Project out a few years, and if you plug away at it, there’s no reason you can’t double your revenues every 12-18 months, so no matter how small you start, (detailed math formula omitted – Ed.), you’ll soon be building your own skyscraper in Manhattan with a heliport so you can get to that 20 acre Southampton spread in 30 minutes flat.
And that, I think, is the real joy of starting a company: creating something, all by yourself, and nurturing it and working on it and investing in it and watching it grow, and watching the investments pay off. It’s a hell of a journey, and I wouldn’t miss it for the world.
You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.