Product Models, Service Models, and Investor Valuations

Richard Mironov -

Almost every week, I have a conversation with executives at B2B software companies who don’t see a bright-line distinction between software license revenue and customization/implementation revenue.  Or why this distinction is essential to their investors.  But when I do product due diligence for SaaS-focused PE/VC firms, it's the very first thing I look at.  Let’s walk through my concern and illustrate it with some simplified investment outcomes.

IMHO, software product companies are fundamentally different from software services/outsourcing/custom development companies.  Said more strongly, I see them as incompatible organizations pursuing opposing business goals and profit models.  And very few companies can balance the two.  (See this 2015 talk and supporting blog series.)

What do I mean by software product vs software services?  A B2B software product company goes to great lengths to reduce/eliminate implementation projects, custom work, connectors to a single client’s unique application or database, bespoke machine learning models, on-site deployment, separate hosting, content moderation…  every kind of human intervention or assistance.  
Revenue is measured in licenses or user-seats or transactions or bandwidth or hotel reservations...  but not in consulting days or developer hours or use-it-or-lose-it prepaid service agreements.  
There’s one production multi-tenant code line with new users running the exact same bits as existing users.  The company doesn’t redeploy or hire more implementation specialists when new deals are signed. Fresh investments are mostly used to scale up Sales & Marketing.  Engineering & Design & Product focus on improving the overall product for the whole customer base, rather than client-specific work that is rarely adopted for broad general use.

B2B software services companies work the other side of the problem.  The underlying business model is charging for the time/effort/smarts of developers and technologists – working as closely to the single client’s specs and needs as possible.  What BigCorp demands, BigCorp gets.  Hitting revenue targets means finding more projects, expanding project scope, building unique artifacts, hiring and deploying more implementers and consultants.  Which means growing the services organization and keeping that team busy (i.e. billable). Building repeatable products isn’t as important as completing each individual project on time/on spec/on budget.  Major clients with major shopping lists come first.

This should be important to company execs because VC/PE investors attach wildly different valuations to pure SaaS license revenue versus service revenue.  My favorite PE firm values undiluted SaaS ARR at 6x to 15x (depending on lots of things) and implementation/services revenue at 1x or less.  Taking 8x as an anchor, that means $5M in SaaS ARR is worth $40M to investors or at IPO, while $5M in custom development work is worth about $4M.  A very big difference.

Why?  Because once a software product company finds product/market fit and gets near breakeven, every incremental SaaS license is almost entirely profit: the company doesn't need to hire more developers or implementors to sell the identical software bits to one more customer.  An incremental paid user or paid transaction is 95% margin after sales commissions and a small set-aside for technical support.

[If you’re planning never to sell your company or take outside investments, this whole argument may not matter.  Cashflow from services spends just like cashflow from licenses.  But growing your top line may still be much more efficient with a repeatable product model.]

Let’s Run the Numbers

If we close one B2/enterprise customer for $100k of pure SaaS license revenue plus $100k of custom implementation work:

($100k deal * 8x ) + ($100k services * 1x) = $900k investor exit value

Then, imagine that we give away all of the implementation work to a services partner, or engineer our product to need much less customization:

($100k deal * 8x) = $800k investor exit value

Roughly the same for our investors as doing all of the services work ourselves.

Now, let’s redeploy a few of the brilliant folks formerly doing post-sales implementation and project management into new account sales.  And we close one incremental license deal – again giving away all of the implementation and customer success revenue:

(2 deals * $100k/deal * 8x) = $1.6M investor exit value

And simplifying the selling/contract/implementation processes usually increases “sales velocity” – our ability to close dozens of cookie-cutter mid-sized deals with less total effort and more total revenue than whale-hunting.  

(12 deals * $70k /deal * 8x) = $6.7M investor exit value

Said another way, the closer we can get to frictionless, hands-off, zero-implementation B2B SaaS… the bigger our potential exit and happier our investors.  Even if we give away all of the professional services work.  A license to print money that’s more sustainable than crypto exchanges.

This flies in the face of how most B2B sales compensation plans work.  And how most B2B/enterprise sales executives think about revenue.  Typically they structure commissions so that “a dollar is a dollar is a dollar” and selling $100k of custom work is comp’d just as richly as $100k of license revenue.  In fact, service revenue is better because every B2B/enterprise prospect has a long list of unmet needs and missing features in our packaged software.  Selling add-on services, customization, consulting, training, security audits, and best-practices coaching is an obvious way to bulk up a software-only deal.  Good salespeople do what we pay them to do (not what product managers want them to do), so “a dollar is a dollar” is a billboard-sized invitation to sell more custom work.

Sounds like an easy transition: just stop comping the sales team on custom projects or implementation, and they’ll stop selling it.  
But in my experience, it’s devilishly hard to change from a services organization (or a half-and-half services-and-product organization) into a pure-play SaaS licensing org.  At the executive level, the decisions a service firm makes are directly opposite to what a software product company would do.  (e.g. “MegaCorp needs a special connector to a home-grown credit reporting system.”  Services firms say WE CAN START TODAY and product firms say NO THANKS.)

Here are the top objections I run into:

"Our Customers Demand Implementation Services and Custom Work"

In many markets, we’ve trained our customers to expect/demand lots of customization and lots of vendor services.  Especially in healthcare, finance, and military/government segments, it’s assumed.  Every hospital has a group of doctors (i.e. not software experts) who want their new patient systems to exactly duplicate the home-grown and horribly inefficient workflows they've accumulated since the 1980’s.  Every insurance company believes (incorrectly) that its back-office processes are a source of competitive advantage.  Despite all evidence to the contrary, every major bank tells me that its consumer portals and apps are best-in-class and boost consumer loyalty.  (If that were true, there’d be no need for B2B SaaS companies to supplement internal IT.)

You may be in such a market, or believe that you are.  If so, you’re in a lower-margin business with boom-bust hiring cycles, relentless pressure for new (bespoke) projects, software continuity/maintenance challenges, and much smaller exits.  Over and over, though, we’ve seen competitors with product DNA disrupt these markets with 10x cost savings and 10x faster implementations – by identifying and capturing the repeatable portion of customer problems.

Consider presenting this as a reasonable trade-off for prospects: “we can build exactly the system you asked for, including custom app hooks and copied-from-your-training-manual workflows and unique role-based access for $2.5M and 9-12 calendar months of implementation.  Or you can use the best-of-breed workflows and RBACs in our base system for $240k/year and be running within 6 weeks.  Since you’ve projected savings of $4-5M/year, that also delivers an incremental $3M+ in Year 1 that you won’t see with the longer timeline.”

Over time, we’ve often seen software companies with a frictionless product approach displace custom-built apps.  Partly, this is because packaged SaaS vendors can offer standard products at 1/5th or 1/20th of the build-your-own price… they amortize development across large numbers of customers (who each execute the identical multi-tenant bits).  And time-to-real-end-user-value is years shorter.  Many customers are willing to take more standard solutions if the price gap is big enough and a trusted vendor offers it.  So packaged SaaS is a looming competitive threat.

"But We Have A Number To Hit This Quarter, and Services is the Best Way to Get There"

A real concern, a very serious challenge.  We can invoice customers for services work as we go, but they won’t pay us for packaged SaaS solutions until those are finished and working well.  And it usually takes 2+ years to build competitive B2B software, so shifting from a services model to a repeatable product model creates a 3-4-5-6 quarter revenue hole.  There’s a lot of pressure to declare this quarter as the last one dominated by services, with painful company-wide changes pushed off to next quarter.  (And the one after that…)

So this frames a serious discussion between the CEO and Board/investors.  Can we agree to scale back current-year revenue commitments to double down on repeatable, packaged products?  What will that cost?  How do we manage product/market risk, since most new offerings fail?  Can we partner with some services-only firms and teach them how to implement our system?  How does that change our C-level decision-making, staffing, go-to-market processes, messaging? Are there product-model execs in the C-suite that have done this before, or mostly services-model execs unenthused about such a major change?

"But Our Software Is Designed To Need Lots Of Customization Rather Than Work Out Of The Box"

You bet.  Especially if we’ve spent years in a service model, solving a wide range of client problems with a 'software platform' that’s lightly documented and only we understand.  Each customer has their own code branch or hosting configuration; we’ve created scores of one-off features and unique controls; only a few of our technical long-timers really know how the underlying engine actually works; we don’t actually track exactly what’s in each client implementation; upgrading customers to our latest platform version is a nightmare of identifying and re-implementing the special things we did two years ago.  

Said another way, we may not have a 'product' as much as a collection of technical bits deployed variously by each client.  It probably needs complete rethinking / re-architecture/ re-implementation, which will be slow and painful and expensive and technical risky.  So in addition to our difficult financial discussion with investors (above), we’ll be making a big bet on rebuilding most of our tech while supporting all current paying customers.

I’ve watched a handful of these projects over the last few years, and each was much harder (slower, more expensive, less complete, with lots of technical surprises) than the company projected.  Averaging 2.5 to 4 years rather than 3 to 5 quarters as promised to the Board.  Not for the faint of heart.  But possible if the leadership doesn’t lose hope part-way into the rebuilding cycle.

"But We’re The Only People Who Really Know How To Implement Our Systems"

This is as much a product management failure as an engineering or go-to-market failure.  If we’re going to recruit outside firms as our implementation partners, our product needs to be partner-ready:

  • Active planning and crystal-clear decisions about which parts of our application can be extended/customized.  If we allow white labeling, then we should implement color choosers and client logo uploads.  If we decide not to allow white labeling, we have to resist all pressure from partners/customers to make exceptions.  Likewise languages, date/time formats, SSO, cloud storage vendors, delegated authority… we’re all-in or all-out.
  • Fully documented, tested, published, and maintained APIs that let partners extend relevant capabilities.  E.g. if we have a well-designed and well-implemented data import/export API, then partners can tie us to whatever obscure legacy system a customer might have.  (Bonus points: fully backward-version-compatible, no undocumented features, no “only we can do that.”)
  • Non-negotiable ownership of maintenance.  If a partner builds something wonderfully unique for a customer, they are responsible for charging ongoing support fees and fixing it when it breaks.  We open support cases only when the partner can show us that our bits may be misbehaving.  We don’t incorporate third party code into our core platform without product plans, code inspections, TOIs, rewrites as necessary.
  • Executive support for refusing bad-fit applications.  If we know that our product can’t support real-time video streaming (or HIPAA or datasets > 500 TB), then we have to block partners from proposing it.  Otherwise, our partners will (inevitably) push us into commitments we shouldn’t make.   We need to rehearse this with the exec team before that next deal arrives, while heads are clear.  I’ve seen dozens of companies fall into “no win/can’t do/kicking ourselves” failures because they didn’t anticipate what we all knew was coming.

"But Our Sales Team Is Better At Selling Services Than Packaged Products"

Not surprising, especially if we’ve been hitting our numbers and appropriately rewarding our salespeople for it.  But we have to align sales strategies with company goals (or company goals with sales strategies).  So this drives some very difficult C-level conversations:

  • How does our company make money and what do our investors expect?
  • On the go-to-market side, who’s eager and excited about a product-led model? Who’s going to have a bumpy transition?  How do we respectfully shrink our implementation/services team?  Will our services partners want to hire experts in our application?
  • Can we change the company’s primary metric from dollars to licenses or paid transactions?  At every SLT meeting, can we look at active users or new licenses or ARR leading indicators before the pipeline review?

Sound Byte

Identifying how our investors keep score is as important as identifying how our customers keep score.  Many of them make clear-cut distinctions between product ARR and services revenue.  (I strongly agree.)   So recognizing that distinction and understanding investor exit value are essential to B2B software leaders.