The Business of Software Wiki

A part of Joel on Software, and a companion to the Business of Software discussion group.

A Development Journey

One of the hardest things about the development of any product is building what the customer wants. Sure, big organizations with huge research and development budgets can hire focus groups, do market studies, and generally spend a lot of time and money figuring out what to build, how to update what they have, etc. Unfortunately, this won't work for most mISV's. In fact, to even consider this path will lead you towards burning a lot of cash, time, and losing the one thing you do have... nimbleness.

When large organizations begin development on a new product, there are a ridiculous number of hoops that have to be jumped through. There are managers, VP's, market analysts, investors, etc that have some sort of say in what you'd like to do and - quite often - how you're going to do it. I think of it as steering the Titanic.  Making any sort of course change quickly is essentially impossible. There's just too much inertia, too much effort being used just to make you go, expending more to turn drastically is unlikely at best. Of course, there are some benefits to this effort... odds are developers don't have to figure out all the UI issues, they don't need to worry about branding, pay the rent, and run the website too. Tiny course corrections are quite easy to make but unless you see the iceberg in time, they're not enough. So once these efforts are underway, you have to somehow combine all the foresight you have with all of the institutional strength/focus and make the whole thing happen... unless you're Steve Jobs.

A small company has the exact opposite problem. You don't have the time, money, effort, attention, or staff to do much of this but you need many of the same aspects... because if you build a product no one is buying, you're going to rejoin the working world in short order.

So how does a small company make this happen?

Many mISV's start off as consulting shops and there are some simple reasons for this. It pays the bills, you can build up a network of contacts, and you can spread your risk among a variety of projects and companies. But there's a bigger, more fundamental reason why this can be good: You already have a paying customer.

Don't underestimate the value of that. Stop and say to yourself: "Yes, there is a market for this product and here are some of the features some customers would require." Most likely this version is a prototype, filled with their custom requirements, and has some less-than-perfect design aspects which must be sorted out. Regardless, you have a functional version which you may be able to build upon. So no, you're not done, in fact it's just starting.

First, you need to review the legal agreements. Do you own the code? Can the customer resell it? Can you resell it? Can you resell it to customers in that industry? Is the code clean of third party libraries that may make distribution/selling difficult? Before you move any further, you have to figure out this one. Review your contracts, review your email, and talk to an attorney if anything is unclear, vague, or questionable.

Next, you need to figure out who your next customer is. Sure, going to your first customer's biggest competitor might be an easy sale, but you're not going to make friends. In fact, if there's anything vague or open to interpretation from above, this is the way to cause problems for yourself. Instead, look at organizations that do similar things in different industries. Or even much smaller competitors in the same industry. For example, if you manage to sell something to a Fortune 500 company, selling to a competitor with a single location isn't likely to make their radar.

Next, you need to figure out what that customer wants. It's entirely possible that you'll be in a position to hand them a CD and walk away, but let's get real. There were numerous custom things that you did for the first customer that customer n and n+1 won't want. Some of these will be customizations, some of them will be removing customizations. This is a balancing act and where you decide to plant yourself on this spectrum will determine if you continue to be a consultantcy or become a software vendor. I can't pretend to answer this one for you... it will be up to you based on the costs, the customer profile, ability to sell those customizations, and a variety of other aspects specific to your situation. Choose carefully.

Finally, you need to make the next sale. For some you may already have the customer knocking on your door. For others, you're going to have to convince them that your product serves their need. Regardless of which one you have, the sales process could take a while. If your product is priced relatively cheaply - to fall under that magical "petty cash" limit - you probably won't have any problems and could sell immediately. If it's a larger purchase, there will have to be approvals, PO's, and a variety of other dark arts not covered here.

So in case you couldn't tell, this is how the first of CaseySoftware's latest products has worked out. It initially started as a prototype, was rolled out for a number of beta customers, and now is becoming a real product with a development roadmap, marketing, and a steady stream of sales. It's the first in a long time... but it's definitely not the last.

This content is provided under Creative Commons - Attribution-NonCommercial-ShareAlike 2.5 - by D. Keith Casey Jr. of CaseySoftware, LLC.