The cost of client specific customisation on SaaS products

When it comes to managing a SaaS product roadmap, consumer focussed SaaS product teams have it easy. Sure it’s not trivial to work out what to build at first.  But once they have established a product-market fit, the consumer-SaaS know who their customers are,  and can coordinate a good sampling of people to help them understand what to build next.

When you get into the small-medium business (SMB) or enterprise SaaS markets, this purity begins to disappear.  Some spine-chilling [to product managers] words like client funded feature, sponsored capacity, client customisations will find their way into your product priority discussions.

In the eyes of the survival-focussed founder, the CFO, or the less experienced product team, it’s hard to contain the excitement of this scenario.

“ Let me get this straight… we have clients who want to pay us for the privilege of building the features that already exist on our product roadmap. All I have to do is add some customisation here, or change a priority ordering there… this is amazing! ”

What could possibly be wrong with this scenario?!

Before I begin to answer this question, I want to make it clear that accepting client money for SaaS feature development is not always the wrong thing to do. There are going to be times when it makes sense and is precisely the right thing to do or the only way to survive. But realise that things can and likely will go wrong – nothing is free in life, and this is no exception. You need a very clever and strong product management focus to help you recognise the traps and guide you through the relationship without picking up a big penalty fee on your very tight SaaS baggage allowance¹.

So what can go wrong?

Fringe features – Anchors that are hard to shake

You can end-up under significant pressure to build features that have no rightful place in your product, the type of functionality that future clients are unlikely to use. This is not ideal as the total cost of ownership of the feature will end up being significant, every release cycle, every UI refresh, every framework version upgrade you will maintaining this product feature. Think of it as a tax on the initial decision, or more accurately, product debt. The more customised features that get added, the higher the cost of servicing the debt.

But a small number of customisations can’t be that bad?

You’re right, taking some money to build a single client-specific feature will probably not sink the ship, you might get away with 10’s of them if your product is selling well enough.

But a frequently seen darker side of this equation is often that Sales teams with targets can find themselves addicted to the short-term revenue streams. They are not tuned in to see the long-term damage that can be caused – it’s not readily apparent – just like product managers can’t likely balance a budget. A drug addiction parallel is strong but appropriate here as the long-term damage to SaaS product in a vicious cycle of custom build to short-term revenue, and the resulting Frankenstein product can be a nightmare to maintain.

How can minimise the impact of custom features?

The product management approach

A skilled team can help manage the client expectations, tightly scoping the level of customisation. Even better, we can shape the client towards a version of the feature which can be considered industry best-practice and hence could realistically (not just wishful thinking) end up being offered to other customers as part of the core SaaS offering or as an up-sell.

The technology approach

There are architectural patterns and API versioning techniques that allows to isolate the customisation. We loosely couple the customisation code from the cores SaaS platform and  reduce the lifetime cost of the custom feature.

OK, that’s a bit scary, so what else should I be aware of?

So far, we have outlined the more common scar-causing patterns you can see in mature SaaS businesses that have played the customisation game. But a bunch of other side-effects can turn up:

Configuration overload

Your product configuration options can become so complex that nobody understands the full array of settings you have and the interplay that they have with each other. This will slow everything down: implementation, development, sales, and product. You end-up at a point where no person can reason about proposed changes and their impact on your SaaS platform.

The right features left unidentified

The distraction of the custom client feature analysis phase distracts your product team from doing the higher-return task of working out the killer features that would provide the highest ROI in the market. This is what you should be spending your precious development resources on.

The right features delayed

The opportunity cost of building the customised features distracts you from delivering the features that provide value for the majority your clients – and reduces your medium-term SaaS sales pipeline and subscription revenue.

Technology team motivation

Your technology team does not like too much custom-domain complexity², especially if they did not create it themselves. So for future generations of your expensive developers, it makes their job hard, making them feel lost and ineffective with regular monotony. This hidden cost will erode productivity and hit at staff retention of your most talented staff.

Summary

When considering client specific customisation, ensure you have a good understanding of the cost/benefit trade-off.  If/when you do move forward, ensure you have tight management of the customer’s expectations, and leverage architectural patterns to isolate and minimise the maintenance cost of any fringe features you build.

 


Footnotes

¹ That was an attempt at an airline check-in counter gag – a call-out to the technical debt and operational debt that you will pick up if you take on too much customisation. You will own this debt forever, so don’t take it on likely.
² Custom-domain complexity refers to complexity as a result of your product design, rather than complexity from development frameworks and infrastructure. Interestingly developers have a higher tolerance for the later.

Leave a Reply

Your email address will not be published. Required fields are marked *