You may want to start at the first part of this blog series.

Software Pricing makes no sense

Joel Spolsky did a great post about how software product pricing is insane called Camels and Rubber Duckies.  Go ahead and read it.  He will get you to agree with him, and then change the argument so you are left even more confused to product pricing.  It is a great article.

Extracting the Maximum Profit per User

In all business you want to extract the maximum profit per user possible.  If the user was willing to pay $15,000 for your software why did you sell it to him at $199?  Because attempting to get that type of per user maximum profit is really, really hard.  You will end up with an entire office of salesman who only take calls from people about their needs, and then try to get the most out of them.  In today’s age I don’t see how any software company can think that will work for long.  Eventually the pricing will get leaked somewhere, so people have a ballpark number.  Then if they come to you and get something totally different they will be miffed.

Big Companies should pay Big Prices

I have to agree with Joel Spolsky that having a Corporate edition at any price is a bad idea.  You will end up with a megacorp that should have paid you 10,000 developer licenses only buying that one corporate license.  You just lost a huge amount of money for zero gain.  Give them a deal, but don't give them the farm. 

We have some very, very large companies using VistaDB that only paid us around $5,000.  The costs to support such an organization are far more than what you made.  In a few cases the support was very low, but the company still got away with $150,000 or more in software for that one Corporate license fee.  Bad idea. 

It sounds good and you think you will get more people to step up into that bracket who maybe don’t usually buy at that level.  But it doesn’t work that way at all.  The people who really are in that bracket just end up getting the deal of century on your product.

Charge flat licensing, and corporate buyers should have to ask for a special price (minimum 50 units, or something like that).  Keep the pricing very flat, it makes all users think they are equal and simplifies things tremendously.

Flat Pricing with a twist

One trend I see a lot today with companies like Dev Express and Telerik is a flat all you can eat price that is supposed to be per developer.  But almost every company I talk to that uses their tools tells me they only bought one and all share it.  So those companies must be setting their prices high enough to cover this possibility, and then discounting to companies that really do buy the correct number of licenses.

Basically if your minimum price point is something you can still make a profit at you are in good shape.  It is when you are counting on scale, or making things up in volume you get into trouble.  Make sure your price is something you can actually make a profit on for each and every single customer.

StackOverflow has a site called Stack Exchange where you can host your own site likes theirs branded to be your own.  People freaked when they first saw the pricing.  It was explained as simple as you have to be able to make money on it from day 1, when economies of scale kick in (if they ever do) then you discount the software.  I like that model a lot.  Now I think they are taking on Venture Capital and trying to do some much bigger things.

One commenter on a previous blog post said I was lamenting the death of the company through these posts.  That is not the point at all.  The point of these posts are to help other small businesses learn some of the lessons I learned the hard way, and to hopefully avoid making some of the same mistakes.

I don’t care if you have a tool that only 100 people a year will buy, or a tool for the mass market, all these same lessons apply.  And since over 70% of all VistaDB customers are also small business, MicroISV, hobbyists trying to make extra cash, whatever; I thought these lessons should be shared.

Updates can’t be free

VistaDB 3.2, 3.3, 3.4, 3.5, and even 4.0 were all free to subscribers.  500+ new features.  Each of them could have been a major release.  In fact there were so many features that they should have been new releases, each with upgrade fees associated.

Subscriptions failed

Instead I bumped minors and kept giving them for free as a part of the subscription model.  You have to be able to get that constant revenue stream, and upgrades are one part of that.  Subscriptions for something like this don't work.  4.0 was the first major upgrade, and as a result most users are still afraid of it and will not move.  If I had called it 3.6 they would have all moved to it without a second thought.  If I had trained users from day 1 that upgrades are all the same (minimal API breakage, always upgrading because of improvements and design changes) then things might have been different.

Subscriptions for minor builds would have been fine, but the major releases and additions should have generated a lot more revenue.  The 3.4 version cost us around $200,000 to produce, but almost no one had to pay for it.  Bad combination, then when subscribers got it, they stopped renewing their subscriptions as some critical “good enough” line had been crossed.

Small Upgrade Fees

If I had instead charged $99 to upgrade to each of those releases we would have generated 5 times the revenue than the subscription model.  That is a huge number.  Even if a major number of people didn’t step up at each one, they would have eventually wanted something in one of the later versions and had to pay for it.

The average VistaDB customer spent a whopping $450 over a three year period.  If we had charged $279 for the base, and $99 for each upgrade the number would have risen to $779.  Think very carefully about the long term sales and upgrade model you choose for your product.

Product Planning

Start a product plan, and what new versions you will release and when.  Then box in features for those versions.  Make sure you are always providing value for each release, but make sure you can also charge for that value.  If people are not willing to pay you for anything except your base product, then maybe the product is “good enough” and you should just sell it as is, move on to another niche.  Doesn’t mean you kill the product, but it just stays where it is. 

I look at Codebase as a good example.  It has been at 6.x for at least 10 years.  There is no reason to go beyond where it is today, it works and has the features people want.  Keep selling it and recoup your costs over the long term.

Unfortunately for us the ADO.Net provider space is not that stable.  New technologies, extensions, Entity Framework, LINQ, all have come out recently and you simply have to support them to be considered current in this space.  That really points to the fact that VistaDB is not a niche, but I will get into more of that in another post.

See the first part of this series here.

Can’t include free support

Support cannot be included.  You can't afford it for a product like this.  It is too big.  Teaching ADO.Net, data binding, database design, etc is too much. 

On average I spent almost $1000 per user in tech support during year two.  That meant they were paying $250-500 per developer and we were losing money big time. 

Free tech support is an open invitation to every compiler error message "The error message says you are missing a file, did you check if the file exists?".  I had mistakenly thought that it would drop over time as documentation came up (2300 pages of help exist), and as the forums picked up.  It never dropped.  People who are solo coders want someone else to bounce ideas off, play out designs, etc.  They end up hitting whatever vendors they can get free support from in order to have that sounding board.  That is all consulting, not tech support.  Big mistake on my part.

Users often send us huge complicated TSQL statements “This doesn’t work”.  What doesn’t?  Bad results, bad data, doesn’t even compile?  Usually it comes down to the fact that they don’t understand what it does either “A third party tool built that T-SQL statement, so that is what I have to run”.  This lack of SQL knowledge hurts because we spent so very much time trying to teach people another language (TSQL).

LINQ would be better

I do think that LINQ is a better query language because if you get the language you are working in, then LINQ should be syntax for operating over result sets.  It is not hard to pick up, but it is a mindset change for those who have a good SQL knowledge.  Get over it, you will have to learn it at some point, and then SQL seems sort of quaint (like good old DOS machines).

Outsource it?

The most common answer I got was that US labor was too expensive to do this type of support, outsource to Bulgaria, Russia, India, like the big guys do.  Not my style. 

I am about as patriotic towards my country as you can get (USA).  I would rather have American programmers  and tech support, than outsource.  And to do that people have to be willing to pay a premium.  This is how the Telerik and DevExpress get away with their pricing.  Almost nothing is done in the US except sales and marketing.  Every question I ever got from them was in smaller countries in Eastern Europe. 

Users Fight Support Fees

Users will fight support fees every step of the way.  They will complain about how the docs should explain it to them (they usually do, but the user has not read them or things a help file search means looking on Google for their answer).

ADO.NET is not a niche

I now see what some of my mentors tried to tell me.  ADO.Net is not a niche, it is a technology platform from Microsoft that they just so happen to expose to third parties.  You will have no say in the direction, messaging, etc of your core product (being ADO.Net compatible).  More on this in a later post.

I have been speaking with Peter Vogel (The VistaDB Story) for his blog on Visual Studio Magazine.  It is apparently quite uncommon for a company going through what we have to be so open and transparent about the process. 

I have been spending a lot of time lately packing, fixing up things around the house, etc (too much time to think).  I have a couple of things I would like to blog about.  These are things I would have done differently, or things that I would like to pass on to other small business owners. 

Micropreneur Academy

First, if you are a small shop that doesn’t have a lot of people to mentor you or bounce ideas I highly recommend you sign up and participate with the Micropreneur Academy.  This is a fantastic site for individual startups to learn, bounce ideas off others, find a mentor to help you through troubled spots, and lots more.  They have a very unique training system that breaks things up into lessons, and then activities for you to perform.  I have found them to be extremely high quality.

Totally Revamp Pricing

The pricing model is such that you MUST be able to make money on what you sell now, not next year.  You can't count on people to renew their subscriptions.  The entire subscription model was a huge loss.  As a small company you can't afford that type of mistake.  I was assuming (bad word) that 50% of people would renew for 2-3 years.  The reality is only 5% renewed.   You have to ensure that you can support yourself on the revenue model.  I was thinking economies of scale would kick in, they don't.  You can't count on it, so don't put it in.  Charge higher and get fewer customers you can afford to support better, rather than lower price with lots of customers.

Joel Spolsky has talked about this quite a bit, but when I took over the company there was a pricing model in place and I didn’t want to change it.  I should have done it from day one, and just lived with the dip in sales at that time.

Charge a Premium

You have to be able to charge what it costs you to build something, or you can’t stay in business long.  People always want the cheapest thing possible, then they expect Nordstrom level customer service. 

One customer complained loudly about how we didn’t solve his issue and he was charging his customer $500,000 for this project.  He only spent $299 with us, and apparently we were the key to what he did.  Why not spend some of that budget on consulting with us if you need something, I asked.  No way, he already paid for the product and should not need consulting.

To Be Continued

I have several more of these, I will continue them in future posts.

I was speaking to a partner today about sales cycles and traffic for websites.  I thought I would take a few minutes to expand on what I told him, and to make it available to everyone.

Sales Cyclic Patterns

All products have cycles to their sales patterns.  When I did game software we were very much Q4 driven, over 90% of our sales came in the last few months of the year.  When I sold Spam Filtration software the cycle was very much driven by outbreaks of virus or spam attacks.  When major attacks happened, we would see large increases in sales.  You couldn’t really predict these, they just happened. 

Now that we sell API products the sales cycle and cycles of sales are totally different.

Sales Cycle

All products have a sales cycle, how long from when the customer hears about your product until they buy?  What steps do they take to make that decision?  From the customer they general start with a need and then they go looking for a product or service.  How they learn about you, and what steps they take are all part of the sales cycle. 

Cycles of Sales

When I say cycles of sales I mean to rhythms or patterns to sales for a product or service.   Most electronic games sell in the fourth quarter of the year for example.  Some products, like Tax Software, are seasonal in that there is a tax season when people expect to buy them. 

More...

How do you take time to do pure research on new technologies in a small company?  This is not a rhetorical question.  Small business teams rarely have the money to justify spending months on research.

It is usually a case of build what works and run with it, so when do you get the time to do that research?  Without ongoing research into new technologies and designs you have to find a way to fund those activities. Building a product by growing things in place is a good way to accrue a lot of technical debt that eventually leads to a fragile design or a complete rewrite.

How do other companies handle this?

Ok, this is my personal answer to the question; Your Mileage May Vary (YMMV). It may or may not be correct for everyone, or every situation.  I want to share parts of how I came to this conclusion in the hopes that it may help other small companies.

I have always believed that any product without continuous development is dead.  How can a product innovate without new work being done on it?  Only through investigation and application of technology can a company learn to innovate.  Otherwise you are just playing catch up with others in your market and telling the developers to do what you competitor just did.  Sure, maybe you improve it a bit, add some polish.  But without looking way ahead of the pack you will never leap frog anyone.

In large companies they usually handle this by having multiple teams.  Team A is on the current release, and Team B is looking at the next major.  Then they flip flop when Team B is ready for production Team A then goes into looking at the next major release.  Small businesses can’t afford to employ this strategy.

Some companies do this by having a long release cycle.  They release 1.0, then spend 2 years getting to 2.0, etc.  This leads to long cycles of no improvement in the product, but for some industries this is acceptable.

Most small companies iterate over their design making small improvements and adding customer features.  At some point it seems like “enough” changes and they rev the major.  Some small companies ignore the problem entirely and call everything Product 2009, Product 2010.  Basically telling you that they are all the same, but with some form of improvement over time.

There is nothing wrong with any of these strategies, but they don’t work in our scenario.  We have large research work to do in some fields that just can’t be iterated into the core product at all.  They are literally all or nothing scenarios. You could spend a year of effort to build it into the core engine only to discover it doesn’t work well.

More...