How to Market Software Products
I haven’t talked about how to market software products in a broad spectrum before, have I? I’ve talked some about how to market SaaS, and I’ve talked about how to nurture leads and how to establish product lifecycle, but it’s all been about SaaS specifically. While SaaS and traditional software share a lot of similarities when it comes to marketing, design and business processes aside from the sales model, there are some differences where it counts. So, what’s to become of my readers who, while interested in SaaS, might also plan on doing some traditional software marketing, or who plan to market SaaS solutions to existing traditional customers?
Well, today I’ll talk about how to market software products in a binary scenario where both SaaS and traditional models may coexist or be making a transition. Some of this is repetition, given the shared tenets, but it’s worth looking at this from a larger, more distanced perspective. While some information is redundant, looking at this from this particular perspective will make you feel ok about using these shared traits across the board, without second guessing it. Mental association of context is a powerful thing, as any training professional will be the first to tell you.
So, first of all, let’s run over the basic rules that both share. The first is, you need to have a clearly defined demographic and userbase in mind, above all else. If you don’t know who the people you are selling to are, not only will your product work poorly, and your UX flow terribly, but you’ll not be able to sell it to very many people.
Why is this? Well, you have to let the customer know they’re part of your demographic, by identifying with them. Then, you have to make them aware this product does something they need, and finally that your alternative for this need is the best choice for them. This is marketing 101, but it bears driving home.
Second, you need to have their financial mindset in mind too. This can only be done when you’ve established your demographic (and related lesser demographics), and can predict how they buy, what they value and what they can and will afford to spend.
Now, where this becomes very disparate between traditional and SaaS models is what kind of filter you need to run this analysis through. With traditional software, your concern is more about how much multiple licenses cost, how much physical copies should cost, and what you plan to charge for updates, if anything. You shouldn’t charge for an update that isn’t a new retail distribution (new version), but of course if the updates are a lot of overhead, then you may have little choice.
In SaaS, it’s all about subscription rates and feature disparity between potential tiers of accounts and expenses. So, it’s a renewable commodity rather than a physical ownership purchase. This means that the overhead from above comes from a different location, that being your demo or freemium solutions.
So, as we can see from this brief analysis, the differences are small but significant, when it comes to how to market software products in such a binary fashion. It can be a logistics nightmare, but in many cases, having both models, or a slow parallel transition from one to the next in migration, is going to breed you less trouble in the long run!