Four foundations for a SaaS business model

So far in this series we’ve shared the story of a white label client’s explosive growth following their cloud launch on Platform.sh. We also looked at why some applications successfully make the journey to SaaS and some don’t.

We might not all be lucky enough to achieve a magnitude of growth in two years like the company from my first article. But there’s no reason not to shape our business model with smart-growth strategies specific to SaaS companies. These strategies, which I call the four foundations, are Strategy, SaaSify Everything, Buy Versus Build, and Service Is King.

1. Strategy, Strategy, Strategy!

The definition of strategy we will be considering adheres to foundational thinking rather than executional thinking. Foundational thinking sets direction, mapping out a path of least resistance to greatness. Executional thinking then sets you off in that direction at an accelerated pace. Unless you’re offering an exceptional product that sells itself, developing a strategy around this foundational thinking can make the difference between make or break.

The degree of success your business will experience is highly determined by the strategic mapping of your product offer to your chosen markets and by how expertly you are able to connect the two. I can’t emphasise how important it is to spend enough time defining the detailed route you plan on taking along with your assumptions; I’d also suggest the following order of priority, each point being largely dependent on the previous:

Business planning

When creating a business plan, an organization needs to be very clear when mapping ideas, activity, reasoning, and assumptions to sales growth. The logic holding the business plan together should be razor sharp and your defense of it watertight. As such, your regular board reporting should comprise a short analysis for each quarterly period that validates this plan, proves the assumptions, and makes corrections to them where the data obviates.

Verbalising your thoughts to colleagues may well generate a wow effect, and presenting them in slides may be persuasive, but writing them all down in a living document will provide ultimate visibility, transparency, and accountability. There should be no escape and nothing hidden; everything should be subject to scrutiny.

Seeing round corners

Nobody can tell the future, of course, but I have a neat trick that has got me about as close as is possible to seeing round the corners of time to make better strategic decisions. It has everything to do with the assumptions one makes during the above business planning process. And the more experience one has, the better the assumptions should become.

The important details that manifest themselves within your assumptions cannot be whatever’s in your head at the time you need to provide them, as they may inevitably become subject to creep, sometimes for the wrong reasons. Write them down, declare your position, allow others to validate them with you.

Personally speaking, I have always made detailed notes about my thinking, which has enabled me to go back to prior decisions and plans, re-visit assumptions, and work out which ones held up and how they related to results. Reflecting on why I derived those assumptions—and their subsequent accuracy—has given me a lot more certainty in my ability to “see round corners.”

Product strategy

Product strategy sits at the heart of your business case—it’s your raison d’etre—and it requires that attribute sets (features and capability) be strongly geared to specific customer types, use cases, and sectors. Clients will pay for you to solve their problems. If you can also offer additional value at the same time, they will choose you over the competition. Examples of this might be the implementation of your product against other related business processes or the prospect of more advanced features on your roadmap.

Supporting the value of these attributes with metrics—to help frame or measure potential gains—will help the sales process, as well as reveal feature possibilities for improving your differentiation.

Your product direction need not be too rigid though—it can meander a little—so don’t let technical purism get in the way of requirements that represent money-making value. You may well have set out to build something square in shape, but if it costs $100,000 to make it slightly oblong for a short-term 10x return, then it needs serious consideration. If you’re still a start-up, then this cash will be important. Of course, the deciding criteria is the trade-off between new ARR and the risk of pushing back medium-term goals, thus letting in the competition.

Target market definition

With your competition as a useful reference point, define your various positioning plus target market combinations; there may only be one to start with. Are you building products to solve problems for the individual or a team? Do they exist within small-medium companies, as well as enterprise? There will likely be different selling overheads to consider for each. Also, are your primary targets in hard-to-reach sectors with hard-to-achieve requirements? And where geographically are they most concentrated? It’s always tempting to take too broad a view of your market and go chasing everything.

Channels and direct sales

Channels and direct sales go hand in hand. Whereas an internal sales team is more expensive to build, partners will drive business on a completely different cost basis. So treating partners well allows them to accelerate growth for you.

You always need in-house sales of course—direct or indirect. And critical to faster success will be experienced tacticians: sales process experts able to derive clever deal winning strategies and then make them happen. Beachhead customers give you enormous leverage, whether they allow you to reference them or not.

Important hires here are sales managers that can apply the above experience to key deals surfaced by the wider team. If you can afford one or two uber sales people, do it. It’ll raise everybody’s game.

An acute awareness of timing and opportunity

Things move fast. It’s very easy to get blindsided by copycats or technologies coming out of left field. You just can’t hang around, so be adaptive, keep scanning for opportunities, seize them, and rework that business plan. Maybe a competitor takes a tumble—stop everything and grab their customers before somebody else does. And if you see your competitors winning large deals you thought were yours, find out what their edge is and equalise it quickly.

Whether it’s a full pivot or just course correction, be bold.

1. Don’t just cloudify your app, SaaSify EVERYTHING

Don’t be satisfied with just cloudifying your product. Giving your customers a new way to access the same thing they were using before—but in the cloud!—isn’t enough. Take the opportunity to change the user experience for everybody touching your product, such that the perception of the value you’re now offering is entirely new. This will get you properly noticed and set you apart from your rivals.

Who else will appreciate a better experience with your app ?

End users

The faster your users can get new features, the more business value they will perceive in the app. Service stability is a given, of course, and must never be interrupted, so paying a premium to ensure this will always be money well spent.

Developers and site administrators

If your app or framework allows for enhancements, there’s a whole ‘developer’ persona you need to be thinking about, thousands of voices even. The more enhancement work your clients need, the higher the engagement the dev teams will have with your product and the more their opinions will count. Many apps have digital agency ecosystems earning a living from their implementation. Make their developers’ lives happier, and you will have that crowd voting your way during the client’s decision-making process. Get them all on your side!

Digital agencies

If digital agencies are able to accelerate their development velocity, get super-fast client signoff, and deploy changes safely, then their end-user clients will get faster time-to-market for the new features and pay less for them. Maintaining a constant stream of high-quality changes into the live service becomes a game-changer for clients—ecommerce especially—enabling them to react quicker to the analytics and peak events that drive deeper engagement and optimize revenue. This is good for the agency in two ways: they not only improve their standing with the client, but they also make more money from the productivity gains.

DevOps and systems administrators

Solving time-consuming hosting challenges allows experienced engineers to focus away from operational problems and towards systems and process improvement. After all, the goal of DevOps is to enable a faster flow of planned work into production whilst preserving stability, performance, and security. Spending time reacting to problems means less attention is being paid to putting the right upstream practices in place, leading to output from development teams causing problems downstream in QA, operations, and security. In other words, planned work put through poor DevOps processes results in unplanned work, and the more planned work that goes into the funnel, the more unplanned work that comes out. It’s a vicious circle, broken only by freeing up DevOps to work on higher value activity.

White label clients

Our white label clients don’t need to put much effort into selling the benefits of a superior development/deployment experience. Tens of thousands of their ecosystem developers embrace this new value immediately, starting right from the free trial. Positive chatter from developer communities can create background buzz that simply effervesces new clients.

1. Buy versus build

Time really is money. For any software vendor, nowhere is this of greater significance than in the development team. The quicker they build new stuff, the sooner you win new deals.

With the dev team already burdened by so many priorities, how do we approach the trade-off between buying application componentry, cloud infrastructure being just one example, versus letting the dev team build it themselves?

Core IP is 10X value; generic functions are not

The important prologue here is to differentiate between core IP, representing your application’s value to a particular sector or process, and generic functionality. The former comprises specific concepts, content, and process knowledge that enable you to differentiate and get a 10X return on your coding effort. Examples of the latter would be authentication, search, look-up, performance monitoring, logging, and the cloud infrastructure itself. For some applications there will be obscure but critical functions that the engineering team will be tempted to build themselves, despite their availability in product form already. This is not a good idea.

First off, building something you could have bought, such as a cloud infrastructure, requires a lot more time and energy, whereas buying it will get you there faster. When you’re in start-up mode, the earlier you can establish sellable value the better. Call it a first-mover advantage: the best place to always be is setting the pace, offering new capability ahead of the pack.

Secondly, faster time-to-value heavily depends on your engineering team building core IP that will win you more sales, sooner, and at bigger deal values. Winning reference customers soon after launch and bringing revenue forward by several months boosts a VC’s confidence and further bolsters your credibility with potential clients. Allowing engineers to distract themselves with curiosity initiatives, i.e., building generic functions, will rarely see a justifiable return on investment. And getting a DIY project wrong can severely detract from your customer value. After all, you’re meant to be taking away the headaches that come with running software, not charging your customers premium rates for a migraine.

However, history repeats itself, and questionable decisions to build stuff will continue to be made. My advice to those in C-level oversight roles is that when such decisions do happen, insist on design criteria that allow for easy replaceability. The earlier you move back to an external solution, the closer you get to 100% focus on your core IP. QED.

For less technical C-level roles though, it can be notoriously difficult to change an engineer’s mind and pointless going over all the data points to argue it out with them. Better to change their frame of reference and come at the decision-making process from a different angle:

Are we building business value?

Ask yourself, “Is what we're about to build game-changing for us, will it deliver 10X, what will be the overhead of supporting it, and will it just slow us down?”

The only good reason to build your own code is if you expect to get a measurable 10X return on it, be that revenue, new customers, or cost savings. Are you providing attributes that reveal a better user experience, better performance, or a higher degree of functional relevance? Are the attributes game-changing for the business or the customer? If not, then why are you taking your best engineers away from doing something that might be? Pay for an external service already!

The third-party options may look expensive, but consider the opportunity cost of diverting talent to something that’s not core-IP:

• Resources diverted from the core IP—and its 10X return!
• Energy wasted maintaining components you should instead be planning to replace
• A slower pace of iteration when it needs to be getting faster

If it’s non-core IP and you have to do it, build-to-replace! If you keep it for the long term, maintenance costs will be super-high because you’ll be trying to keep pace with COTS vendors doing the same thing but better. And if the team fails to follow best practices, they’re just planting landmines that are bound to get stepped on in future.

Beware the lion’s den

Engineers love a challenge. Any decent engineer can give you several good reasons to build something rather than buy it. And when it only takes a couple of days to put up a prototype, they’ve proved it before you’ve even started the discussion!

However, a prototype isn’t the endgame. The specification you decide to build will have limitations and won’t be anything close to most products on the market. Your engineering team likely has little expertise in this area, so they will overestimate what can be done in one year and underestimate what really needs to be done in two. It will all take longer to figure it out, obvious features will get missed, and longer-term costs will soar.

You’ll want to nip this in the bud. During the evaluation period, ask the team to take a close look at what’s missing from the prototype. You’ll likely stumble through a huge list with potentially hundreds of missing features. Then ask, “Once it’s built, how are we expecting this function to scale out with volume?” Unless you’re confident of getting close to third-party product quality, you’ll inevitably miss things that will hurt you later on. You’re not a specialist product vendor, so don’t try to be one.

Having looked at what the team can do and what it will take to get a basic implementation, return to what the team should be doing. Get back to that 10X!

You’re losing valuable R&D by working on anything that’s not game changing IP. My advice is to challenge every ‘build, don’t buy’ decision, but do not try to convince them: that battle is hard to win. Your job is to make sure they understand the problem differently.

When you don’t know what you don’t know, let the market tell you

If you’ve managed to stimulate a review of third-party options, then you’re on the brink of quite a lot of unexpected business value. Deep-diving into different vendors’ products will provide valuable insight into how they overcame some of the problems you didn’t even know existed. If you do decide to build, this will prove useful.

Calculate the R&D effort needed to achieve this level of knowledge through trial and error. Now offset it against the 10X. The answer will probably be something like “Yeah, let’s pick a product and leave the heavy lifting to somebody else.” Even if you spend time testing three products against your use case and two don’t work, you’re achieving better medium-term business value than making a premature decision to build.

Finding a provider may not be a breeze. Don’t think it’s as easy as spending a bit of time on Google or Wikipedia searching for that perfect fit. Staying power may start to drop off, so keep the team motivated to complete a thorough search.

Once you find a third-party option—and even after you’ve taken the time to make it work properly—your engineering team should recognize that they would never have been able to develop the solution they discovered. And that’s a big learning in itself. If you’re building generic components internally, you will never be able to compete with another SaaS product.

Think about it: if the third-party solution is already successful in the market, then that vendor will have funding specifically for that. Even if they are just a great little start-up, they will quickly get there based on the total focus than they can give the solution. If it’s any good, they will get even more funding, and in two years they will scale to a staff of 50, whilst you’re stuck with a team of one or two! How can you possibly build something better than they can?

And here’s the catch-22 (or maybe it’s catch-44 because there’s two of them):

1. If you end up evaluating too many vendors, and none are quite good enough, then in all likelihood your engineering team set the bar too high. On the other hand, they now understand how difficult it was to build and should understand the value of buying it.

2. If you still can’t find the product that meets your requirements—because you’re looking for something that’s just too different—then you will be forced into developing specialist knowledge around this component. And when that start-up does happen, your engineers are at risk of jumping ship because the start-up will be paying top dollar for those unique skills!

To close, anecdotal evidence tells us that:

• 75% of the generic functions we build, we subsequently decide we shouldn’t have.
• 99.9% of companies should not be doing their own cloud infrastructure, unless you’re a specialist software vendor and only when you really need to.
• If you do build generic functions or create your own cloud, it needs to make a 10X difference to your business. If building does not equal differentiation, don’t do it. Find a good provider.

1. ”Service is king” is the mantra that runs through everything we do

Customers will be prepared to put up with all sorts of price/product inadequacies in return for the value you deliver. But if service levels are inconsistent and the resulting interactions with you to solve those problems is erratic, then customers will go away.

They won’t all leave immediately though. If your service is being used by subscribers for internal process efficiencies, then their willingness to tolerate service problems might be higher. If these problems touch their customers, however, they will quickly become uber sensitive—rightly so—and their perception of the overall size of the problem will be a multiple of their number of customers, plus some. The bigger the problem, the faster they will look to solve it by leaving.

What we refer to as good service shouldn’t be confined to just uptime or application availability. For enterprise offerings and enterprise customers, service includes the entire journey, from the moment they start evaluating your product through pilot implementation to wider roll-out.

Let’s look at the overall service experience in a little more detail:

• Product evaluation: The more that customers are saying—through case studies, quotes, and forums such as public Slack channels, G2, Wikipedia, and Google—the better.
• The first five minutes are critical for a trial. Enabling prospects to get going quickly and easily will avert activation issues.
• Training and onboarding services for larger companies requires you to have online content, backed up by people.
• Product quality and uptime: The fewer bugs there are and the less time the service spends being interrupted, the better.
• Communications channels need to be suited to your profile of support. Some interaction can be deferred to bots, but making it difficult to interact with humans when needed will create annoyance.
• Advisory services: For more invasive products that impact business process, offering some sort of consulting indicates the right level of intent-to-assist and therefore enterprise readiness.
• Access to management escalation path: Key customers will always need somebody to escalate to. And the bigger they are, the more senior the escalation path needs to be.

Needless to say, the larger the sale or the greater the strategic impact to the client’s business, the more of the above you need. A complete service experience will help you to assure your prospect during the sales process and then successfully deliver the product when operational.

The golden rule is always be proactive in your outreach, in your communications, and in your response to problems. Even when difficulties arise within your client relationships, letting your customers know that you care deeply and are doing everything you can to help will reduce the likelihood of churn.

Getting to the right place, faster

In summary, these four foundational tenets apply especially to SaaS vendors and should set you off in the right direction. As I said toward the beginning, what will now get you there faster is executional thinking, which is mainly about hiring good people to do their day jobs plus a ton of process improvement and project management across all disciplines: sales, channels, marketing, product engineering, support, finance, etc. I could spend time blogging about these executional activities, but it would all be too specific to my history. There is plenty of better content out there on the web anyway.

In my next blog, we’re looking at four major ROI scenarios. I will describe a combined savings of $40M over three years across a handful of customers and a combined gain of over $100M in new cloud revenue from a handful more. This should be of interest to any business looking to leverage their application management landscape (with a PaaS) and needing frameworks and metrics to support the business case for change. We will look at savings and gains, buy versus build, unit costs, and the growth business case.

In the meantime, if you’d like to open a conversation about your SaaS business model or the value of a PaaS cloud infrastructure on the rest of your business model, you can find me on LinkedIn or contact me at kieron.sambrook-smith@platform.sh.