In our second post on pricing models for founders, we take a deeper look at value driven pricing models for products startups and founders. The post has two parts. The first part establishes the case for value driven pricing. The second reviews pricing choices for an enterprise software firm focused on the banking sector. We look at a range of pricing models and their implications on profitability and long term prospects.
Goldman Sachs and my conversion to value.
My first reaction after stepping into Goldman Sachs offices in London was rooted in my years at the consulting firm I had just left.
I was interviewing for a pre-MBA internship and had walked across a wide tiled hallway to enter the main lobby of Goldman’s London headquarters. My old place of work, the building and all its tenants, could fit into the four floor high sunlit atrium I had walked into.
Working with Goldman made me question business models I had grown up with. How could a firm generate so much excess cash to use this much space for a statement? I came from a culture where we sat one on top of another to save money on rent. We flew economy everywhere, booked service apartments when traveling, cooked in the same apartments rather than eat outside and were stingy with cash because we had so little of it. To leave a desk un-utilized, let alone a floor was an unpardonable sin in my old world.
Goldman was not working off any version of the rule of three.
I spent the next four months working in London, taking the tube every day to Fleet Street. There was such a stark contrast between my previous employer and my current one. Some of these differences were expected. One was in London, the other in Karachi. One was a bulge bracket investment bank, the other a big 5 consulting firm. One’s average bonus pool allocation was $683,000 per employee per year, the other didn’t have bonuses or a pool. But I couldn’t help compare the two. The interview process, the handle with care treatment at every step, the focus on high quality work, the talent visible on every desk, the gym in the basement and the infinite amount of computing power available on tap for the right questions.
I wondered what it took to build a business like this. Goldman got paid what it asked for. Goldman picked clients and people it wanted to work with. How do you get to a place like that?
The right way to learn is to begin with the wrong way. It helps you appreciate the correct path when you find it. While Goldman wasn’t perfect, it was so out there in my world that it took me a while to parse it. There are businesses in the world not tied down by rule of three. You would appreciate this only after suffering at the hands of the rule.
How did Goldman make money? The same way it does now, twentyone years later. Goldman is a gate keeper to markets, capital and financing. It charges a fee for providing access to what lies beyond the gate.
Goldman does a few things well. It has access and credibility within networks of wealth across the world. It has a track record of doing what it does, well. While there have been exceptions, in circles that matter, the Goldman name carries weight.
The things Goldman does well are:
- Investment Banking. Raise funds from public and private markets across a range of financial instruments. Buy and sell businesses from public and private markets using different financing models. To do this well, one must have access, credibility and capacity to execute. Goldman has all three.
- Securities Trading. Buy and sell investment securities across markets and asset classes. Make markets in securities with large or small volumes. This requires access to markets and trading flows mixed with capacity to execute and trade opportunities as they arise.
- Investment management. Manage investments for individuals who trust Goldman name. Expertise and track record because of work Goldman does in other areas. Goldman is a custodian entrusted to keep wealth safe.
In investment banking, Goldman charges a fee for raising funds. Given the size of most transactions Goldman works on, the fee is respectable. Enough to feed a small town for a year but still competitive based on fees charged by other banks with similar profiles.
In securities trading, depending on the market, Goldman makes a small cut on both buying and selling securities.
When the volume is in hundreds of billions, two cents on every hundred dollar add up.
In investment management, Goldman charges a recurring fee for managing investment portfolios. If the pool of funds is substantial (it is) and it stays with Goldman (it does), Goldman does well.
Goldman’s function is that of a custodian and safe keeper. For many investors, it is not about market beating investment returns but trust and prestige. Even when the brand falters and makes mistakes, Goldman’s loyal followers stay.
Goldman also borrows and lends, just like a bank, but in a more profitable and efficient manner than a bank.
It took Goldman 150 years to get where it is today. 150 years of access, credibility, capacity building and getting better at execution. Markets and models evolved and changed across five generations. The Goldman name survived.
Goldman fees are not calculated using three times salaries and overheads. There is no link to what Goldman charges and its actual cost base. The really interesting insight? The ability of investment banking industry to charge value based pricing in competitive markets.
Goldman charges a small percentage of value it delivers to its clients. It is selective in clients it pitches to and elects to represent and deals it works on. Its expertise and its access to networks of financial markets is valued by clients. While we can’t all aim to be like Goldman right off starting blocks and Goldman had had its own share of challenges, it represents a useful benchmark to look at it for value-based pricing.
What is that benchmark? Specialization, not generalization. That is one way you can charge using value versus actual costs. Not easy, requires patience, track record, experience, focus and commitment. If it sounds like a lot of work and years of slog, it is. There are not short cuts.
Value based pricing beats cost plus every time. Given a choice between the two, opt for markets, opportunities and customers that allow you to charge for the value you deliver, rather than costs you incur.
Pricing models for software products.
Alchemy Technologies wrote software for banking industry in Pakistan. The firm didn’t start off as a software developer. It began as a risk training and consulting business.
A training client asked if they could use models Alchemy covered in training sessions. Alchemy said no. Training models were for illustrative and educational use and needed to be validated for local market applications. The client then asked if Alchemy could build one for them that was tested for local markets. They once again received the same answer. Alchemy was in the training business. It had no interest in building a technology product.
Five such conversation with five different clients later, Alchemy asked about budgets. The intent and payment capacity was there. The next question was, would it be worth it?
Client answers made writing the pricing and valuation application an attractive proposition. Internal estimates put the effort to write the code behind the product around US$10,000 and a few man years of effort. The clients would pay five times as much.
Alchemy already had a dozen qualified prospects who had expressed an interest in buying the product. Sales estimates projected a revenue stream of US$ 200,000 over 4 years. This was multiples of Alchemy’s annual billing. The opportunity required the firm to shift gears and scale. The question was which pricing model to use.
In the software product business, there are multiple business models.
Enterprise sales work off the assumption that clients would continue to need upgrades, new features and real time support. After the implementation phase is over, the firm selling the software can charge them for support. The challenge is to ensure that the implementation phase closes and support contract kicks in. Sharp clients keep on extending implementation window and increasing scope by minute amounts. Before you know you have been on the client site for 5 years and the project is still waiting to go live.
While upfront license sales revenues are substantial, the enterprise market is attractive because of recurring maintenance revenues. Support revenues come in as long as clients use the software.
Sometimes customers try to run applications without support. Within banking industry regulatory compliance, internal audit and disruption to business function make such decisions unlikely. As a vendor you must work hard to find customers who run applications without paying for continuing support.
Depending on the product, its importance to core business, negotiating strength and standing of vendor, support contracts run between 8% to 20% of original license value per year. Structured well they represent an important recurring stream of revenues.
One question we therefore always ask businesses focused on enterprise sales is clients paying support to breakeven.
If our annual budget for salaries, overheads and administrative expenses runs at $200,000 a year, and support revenues on a typical contract run at $10,000 a year, how many clients do we need to breakeven?
We need 20 clients to break even on support revenues. This assumes support running at 10% a year and licensing value for the product at $100,000 in a single lifetime license payment. There are refinements to these estimates. You can elect to charge for a Disaster Recovery site license (DR site license). It’s a small percentage of the primary license but it is additional revenue. You can charge by servers or users, modules or reports or a mix of the above.
While enterprise customers may nickel and dime you on price, when the time comes for service, they need you to rollout the royal treatment.
You should always price support at full utilization. Given limits on what you can charge for annual support, a high license price is important. High license revenues subsidize client implementations and help locks support revenues at higher levels.
The likelihood of a client staying on support depends on how crucial the application is to their core business. Does it impact their ability to generate new business, fulfill regulatory requirements, a crucial piece of operations management, run internal plumbing or is just a nice to have. If business users work with the product on a daily basis, it will stay on support. If they don’t, they will find something that they do use on a daily basis and switch to that.
A third challenge is product pivots and customization. No one plans or budgets for them but they will derail your original roadmap and timelines. The rule of nine come in handy again. Three times your original budget. Then three times your three times budget. This is the amount you need to commit and invest. This is what your pricing model needs to recoup in licensing revenues from customers.
An alternate model is to add more products to the mix and cross sell them to the same client. If product extensions are within reach, it helps to have more than one item to sell during a pitch.
If we could sell three separate products at $100,000 license and $10,000 support contract per year to each client, support revenues would run at $30,000 a year per client. With twenty clients on support, yearly support revenues would top up $600,000 per year. Even getting ten clients on support would leave us with a comfortable surplus over annual expenses.
A third variation is to ditch the onetime license fee model. Replace it with an annual rental model known as Software as a Service or SaaS. This makes the product more affordable, reduces budget linked purchase hurdles, provides greater revenue predictability and increases recurring revenues.
For services focused businesses SaaS models can be a first step in wrapping their services in a product wrapper and charging for them on a per use basis.
The Life Time Value of customers on support, assuming a ten year shelf life for a product in banking space is more than value of original license. The key is number of customers and the ability to retain them. Increasing consolidation in banking sector leads to clients being acquired all the time.
In Alchemy’s case 6 of the 8 clients it sold the software to were acquired within three years of software sale. Acquiring banks tend to use their own technology given their comfort with their own tools, vendors and stacks.
SaaS models perform much better when viewed under customer traction and Life Time Value lens. The initial sale is the big negotiation milestone. Locking down recurring payments for three or four years at inception is easier than convincing customers to switch to a different model later on. It require a mind shift on part of customers and teams selling and servicing software. Hence you will find most technology companies in transition working with mixed models. Old customers on one time licensing. Newer customers on SaaS. Once the transition is complete, it increases survival odds of vendors and service quality levels for customers.
For SaaS, the $100,000 license can be distributed over three years to reduce annual cost of ownership for clients. The implementation fee increased by 30% because there would be no subsidy from the one time license payment.
If a relationship was lost in under three years, a firm would lose money under SaaS compared to original licensing plus implementation fee model. If a relationship survived four years, a firm would break even. For every year, beyond the fourth year, if customers use the software and pay the annual SaaS rental, a firm makes money.
For a software product seller on the licensing model, the initial leap of faith is the assessment that paying relationship with each customer under SaaS will survive the crucial four year mark. This transition from one time higher licensing revenues to lower recurring annual revenues often needs to be financed from external sources. Sometimes a mix of the two models can also help ease the transition.
Which model did Alchemy use?
For banking customers with smaller balance sheets and younger data set, Alchemy offered the SaaS model. Risk teams at these banks didn’t have the bandwidth to capture data, run models, run reports, validate them and then run the cycle again next month.
For these customers Alchemy took monthly data set and returned reports stacks with excel validation sheets. It charged a bundled quarterly fee that included cost of quarterly product rental and resources used to generate and validate reports. The rental amount was the one time license fee distributed over eight quarters.
For banking customers with established risk teams, Alchemy sold the one time license with annual training and support components.
Both models worked off value, not costs. By the time Alchemy closed its first customer it had a documented business case for the value of service / product combo it was offering to banking clients. It was also lucky to have a benchmark set by bigger players in its market. Given its lower cost base, a customized solution for local regulations, accessibility of its subject matter team and its flexible pricing Alchemy locked in a foot hold in its core market.
Because pricing was set at a high level on day one, the baseline was already established. As Alchemy rolled out new features and modules with incremental effort, they were sold as additional modules, priced at the same level. Profitability jumped as customers opted for newer functionality and features.
The one mistake that Alchemy did make was not running the math on support contracts early enough. Or linking its models to the consolidation wave playing out in its local market. If someone had explained the model to them early on, they would have realized the local market was not big enough to live off support revenues.
When the product was initially launched, the market included 40 banks and an additional 20 financial institutions. By the time the consolidation wave was over only 28 were left standing.
By the time Alchemy figured this out and started expanding in the region, the world had changed. The banking sector ran head-first into the Global Financial Crisis. Faced with more serious problems than technology, banks deferred major capital expenses. Central bankers eased the regulatory burden to improve the odds of survival for banks in their system.
How off were initial estimates?
Over its life Alchemy’s flagship product grew to a million lines of code, consumed one hundred man years of resources and cost just under US$250,000 to build. The product took 8 years to fully mature and reach feature stability. In its final form it was deployed in three markets across two different continents.
The original estimate was US$ 10,000 and three man years. The team that came up with the initial estimate was not a green team. Between themselves, they had been in the enterprise software business for more than a decade. But their assessment of client requirements, system integration effort, user training and implementation support was off the mark.
The product and its derivatives generated ten times the amount in revenue and spun off three new lines of businesses for Alchemy. Ten years later there is still nothing that compare with the configuration, feature set and reach offered by the combined platform in its space. From a profitability, contribution margin and market share perspective it was an unqualified success.
All this was possible because it started off with a simple question. What is it worth to our customers to build what is needed? Once we established that customers were willing to pay for value, all new feature discussions started off at the same point. Is it worth it for our customers to have this feature? Like Goldman, the rule of three didn’t make an appearance in any pricing discussions.
Effort estimates for the first implementation were off by 5 times in terms of costs and by 25 times in terms of effort over the 8 year life cycle. The longest running implementation stayed on support for 8 years. A total of 12 licenses were sold to banking customers in the region.
Lessons learnt from the first implementation were put to work in the next eleven implementations. Profitability generated from follow on implementations made it possible for Alchemy to expand in other product areas and offer services beyond its original remit which are still offered today.