Five Things You Need to Do
to Become a Software Product Company

(From the www.softwaremarketsolution.com archives)

Overview

Well, you've gotten funded or you've bootstrapped yourself into a going concern. You're meeting payroll, maybe even making some money. You've got some happy customers who are willing to pay for your software. You have plenty of busy developers who are frantically customizing your software to ensure your happy customers stay happy.

But something is wrong. You're not growing as fast as your business plan projected, or even at all. Month to month, you seem to be spinning your wheels. What is the problem?

The problem is that you're selling programming services, not products. If selling your coding abilities is what you want to do, fine, but is that what your business plan calls for?

If it isn't, here are five things you need to do to get back on track.

First, think retail. No, we're not saying your high-end business intelligence program that provides a Grand Unified Look into Every Nook and Cranny of the Enterprise should be boxed up and sold at CompUSA for $89.95. But a retail product is designed to be scaleable; that is, it is the same exact solution to a problem being sold to many people. And only if your software is scaleable to many businesses and people without significant modification can it be called a product. Is your product scaleable?

The second thing you need to do is stop hiring engineers. You are a product company. If 90% of your revenue is being plowed back into R&D, stop. If you are planning to hire five more coders to help you meet the feature requests of your top three customers, stop.

Instead, hire some sales people now. Sales people sell things; that is their reason for being, and they enjoy doing it. Programmers code, that is their reason for being, and they enjoy doing it. Programmers, however, are not particularly good at selling things. If your R&D group gets grouchy at the prospect of all these suits running around talking at high speed into cell phones, tell them their hiring budget will not be increased until the suits are selling. This will help them focus on business realities and take an interest in what makes a company succeed--sales.

Now, while you're doing that, hire some marketing types at the same time. No, we don't mean a bunch of guys with helmet hair who are going to endlessly discuss "branding" and "momentum" and "events". You need a Marcom person, someone who can write, spell, and has a sense of design. You need a product manager, at least one, someone who can help coordinate the feature requests coming in from your happy customers, your sales people and your developers. You need a PR person, or a good agency that will work at a reasonable price, because good PR is the cheapest form of advertising out there. And you need marketing because if your sales people are acting like product managers, doing Marcom and creating PR they're not selling.

The third thing you must do is start selling what is, not what will be. Do not let the perfect and unobtainable become the enemy of the adequate and available. If you have a salesrep who insists on selling features you do not have because "the deal won't close without them," here's a recommended surefire cure. Sit them in front of a development workstation, open up a compiler or IDE and tell them they are now responsible for coding the new feature into the product. Throw a good book on object-oriented programming onto the desk to help emphasize the point. Make them sit there for a couple of hours while the programmers laugh at them before you relent and let them get up. They'll get the message.

Of course, your clients probably really do want new features and capabilities in your products. Ladies and gentlemen, that's what "subscription," and "maintenance" and "upgrade" programs are for. Have the product manager you just hired work with your sales and development group to figure out what new bells and whistles offer you the best revenue opportunities. Make sure your sales people sell those subscriptions and maintenance agreements. Make sure your marketing group can communicate compelling reasons for your customers to want to buy those subscription and maintenance programs.

The fourth step is to reduce the many (code bases) to the one. Remember, your goal as a product company is one size fits all. That's one reason to take a good hard look at web-based applications. No, you probably won't be able to charge more for them over traditional client applications. And no, nothing about the web makes applications better; in fact, the opposite is probably true. Desktop applications are more flexible and powerful than web-based ones.

But web-based applications do tend to shrink multiple lines of code to one. And that may be a reason to build that interface around a browser.

The final thing you need to do is productize customization if you feel you need to still be in that game. If the market you're targeting with your software wants your program to have four little rubber feet when it only has two, that's what APIs and macro and scripting languages are for. Charge for all customization. Better yet, consider developing a good marketing program that encourages others to treat your product like a platform. Open up your APIs. Publish your scripting language. Document your macros.

The result of this strategy is that your sales will increase as smart developers figure out how to penetrate new markets using your product as a foundation. You will also be able to partner with developers to provide customization while you focus on product sales. You will create a universe of influencers and advocates who will help offload unwanted customization issues from your sales and marketing efforts. And you will be able to continue to focus on selling your one solution to many people. Because that's what product companies do.