There are many ways to determine "scalability" of a growth-stage software company. Scalability comes in several forms including the capacity of the company to sell a certain dollar amount of product per annum and repeatedly increase that amount in later periods. Increases in revenue can come from different places: (i) improvement in direct sales techniques, (ii) increased pull from the market, and (iii) price increases for products sold. I am focused here on the capacity of the firm to raise prices and hold those prices while depending primarily on a direct sales model.
The evolution of a software product/solution can take many shapes with many different results. Generally a company declares evolutionary leaps through something called a "version release". Version releases reflect some major change in the product significant enough for the vendor to say so. Version releases are the product vendor's periodic chance to justify to the market why old prices don't apply and new higher prices are justified. Some companies are extremely adept and well-known for developing hype around version releases (e.g. Apple, Microsoft). Most times media hype is software-speak for ("here comes the price increase"). The question becomes, “will the price increase fly or fall flat on its face?”
In software, there is a natural course for version releases divided between feature/functions and architecture. Early on, features and functions are the sales focus. "Our product can dig round holes relieving you from needing a shovel to do 1, 2 and 3." Later, architecture becomes economically relevant. Feature/function releases are designed generally to empower customers to do more. Architectural releases are mostly designed to empower customers to do more on their own: "With XWZ Product Version 7.0, our hole digger now runs on solar power so that you don't have to worry about the high price of oil."
In my experience the price-increase testing laboratory opens up after a company's first major architectural release. About 80% of what the market needs at that time is currently inside the function set and the vendor is now trying to get right with the IT department. Architectural releases many times are, in effect, a migration of their customers’ deployment services budget over to the product license budget – hopefully the release requires fewer resources to render useful. They should be oriented toward increasing a customer's independence (which is ironic because the increase in independence regularly causes the customer to "depend on this vendor for independence"). Many times the revenue line starts to lift dramatically (if there is really a market). The question is: "what happens next?"
Software companies that prosper are good at adding meaningful functional execution capabilities on top of initial core functions. You can track pricing momentum between version releases to see if creative genius and effective customer listening are occurring or if they have left the building. If a company has the ability to persistently raise prices for incremental version releases then you, as the investor, are on to something (manufacturers of high-end automobiles seem to be really good at this). Many times the starting point for all of this (the initial core functions) is hit or miss. In other words, the initial function set had to do something in a particular way in order to get the customers seeing and properly verbalizing additional functional requirements that lead to higher prices. Said another way, there is enough case history for the vendor to quantify value add, ROI etc...and communicate this in a way that sticks.
What makes this analysis particularly difficult is that most software deals over $300,000 are negotiated. As a result, comparing one deal to the next (enterprise vs. limited-use) for purposes of a finely-pointed pricing momentum analysis is complicate but it can be done.You really don’t have to know a lot about software to properly interpret the meaning of increasing price inelasticity. You just have to be aware that it is very indicative of the design and selling capabilities of a prospect company. Necessity will help you figure out what to do from there.
P.S. Once more selling comes from the channel, price can come down but the motive should be to increase volume. Therefore, the metrics watched should include volume variances per salesman.
No comments:
Post a Comment