There are two types of B2B SaaS companies on this planet: B2B companies that customize the software for their customers, and B2B companies that don’t do customizations.
Apart from being profitable, whether on-demand customizations of software are offered is the most significant differentiation between B2B SaaS companies in every industry. It is also often the reason for the hyper-slow death of many B2B startups.
This is the so-called “one-size-fits-all” model. In this model, you’re offering a set of features available to the broader audience and no options for the customers to request or add custom features.
This approach can work perfectly in some industries, where the user needs are fairly uniform. It can also be an excellent way for small startups to achieve hyper-growth, given that they have managed to nail the user experience and the distribution channel(s).
The customization model allows customers to make feature requests. This basically means that there’s an arrangement for customers to, under certain conditions, request a custom feature for their own needs.
These custom features might end up being public features available for everyone or hidden behind a feature flag until the end of times. Feature flagging is a practice of creating a set of configurations in the codebase that expose specific features to selected customers using the software, so that the company doesn’t need to maintain multiple codebases for the same application.
There is an insane number of practical variations of the Customization model. Here are the top three differentiators that I have noticed in these variations:
Contractual Obligations - Does your contract legally binds you in some way to accept feature request? And if so, is there a time pressure, such as “need to evaluate feature request within 10 working days”?
Gateway - Does the customer needs to be on a specific pricing tier to have the possibility to make a feature request?
Communication lines - Are the requests made through software, are there dedicated communication people (e.g., Account Managers) for these requests, or do the customers have direct access to the Product team?
Many companies do a mixed model, but their philosophy is more oriented toward the standardization model. What’s differentiating the best of them is the DIY approach they offer to their customers.
Hubspot is a great example of this. In essence, Hubspot offers a CRM for SMBs (although they do have an ‘Enterprise’ tier). For each *Property*(think of a text field) of a *View*(think of a screen in the app) in the CRM, you can customize those properties on your own through the UI, which makes a lot of sense. A counterexample of this is a company that provides CRM, and each new *Property*on an object requires coding by their development team.
Another way companies like Hubspot excel in this mixed model is by allowing users to create their own *Modules*. Essentially, it is a way for companies using Hubspot to render their custom code inside Hubspot. Do you want it? Here’s how you code it.
When do startups have to choose a model?
The truth is that there’s no uniform pattern when this decision is made.
Some startups make this decision before ever writing the first line of code. They choose to target a market that is used to tight business deals that are paired with integrations. I have seen some startups get dragged into this because they have landed one whale-sized enterprise customer, which threats feature requests as a modus operandi.
Some startups do precisely the opposite - after customizing for a while, they realize that they can’t scale it, and then pivot to the standardization model.
The formula for profitability is quite simple, and already well-covered on the internet. If your deal sizes are small, you need a high amount of deals. If your deals are big, you probably don’t need that many deals to make your company profitable.
If the deals are big, in most industries, feature requests for SaaS products are a must. Enterprise companies can’t make the most out of the software without their customizations. In the long run, well-customized software is a strategic advantage for an Enterprise company.
On the other hand, if your deals are small, you won’t have the resources to invest in features that would prevent a few customers from churning. Instead, you will most likely pour your resources into a feature set covering the wider audience and your marketing/sales machine. This is often the quickest way to a Product-Market Fit.
Each of the models has its own challenges. Here’s my view on the most common pitfalls and how to avoid them. Please bear in mind that this is not an exhaustive list by any means.
Standardization Pitfalls Product market fit - This is an evergreen product management topic. A common pitfall in this model that leads to lousy product-market fit is not listening to your customers. While it’s perfectly fine to choose not to implement customer feature requests or feedback into the app, you should still be aware of it. This often happens because people misunderstood quotes from Steve Jobs or Basecamp about not taking feature requests, and took this as a dogmatic mantra. Even Basecamp suggests that you read the customer feedback before you decide to throw it away.
Communications - You know who likes being rejected? Nobody. It sucks. That is why when you reject customers’ feature request, you need to stay polite while managing their expectations. Having a good communications person (whether it’s an Account Manager or a Social Media Specialist) can soften the blow. Also, having a public Roadmap sometimes helps because customers feel that the software they’re paying for is being improved in other ways.
Ignoring churn - A customer just churned? If the business is running well enough, it’s easy to get tempted into ignoring the fact that somebody just opted in for a competitor. It’s a sin not converting a churned customer into a learning experience.
Customization Pitfalls Leverage - How big is your biggest deal? Is it 5% of total revenue, or 40% of total revenue? If you can end up in a situation that you won’t be able to pay some of your employees if your biggest deal just churned, you’re in a bad position. You probably don’t need me to tell you that. What you need is to find a way to get out of this position as soon as possible. Otherwise, those customers will have too big leverage over your product, and you’ll end up running an outsourcing company instead of a product company. While it’s acceptable to be in this situation once you’re just starting the business, if you’re in round B and still battling this problem, you might want to start thinking about raising early-round C and investing resources to grow more deals of a similar size. Or selling your business to that customer and doing something else with your life.
Wrong business model - Whatever you do, ensure that it’s worth your while. It’s okay if an Account Executive, in alignment with the Product Management team, occasionally slips in a small feature request as a part of a big deal. That’s relationship building, similar to sending a customer cookies and a Christmas card. What is not okay is constantly accepting feature requests which are not worth your while. If you’re not charging customers enough, or are accepting feature requests which wouldn’t be usable to other customers, why are you doing it?
Commitments - Whatever you do, don’t commit to specific developer hours for feature requests or, even worse, a number of features. I’ve seen contracts where the customer is entitled to 20 development hours per quarter. The idea is that they will require small tweaks now and then. Do you know how it ended up? As a never-ending dance why one massive feature couldn’t be developed in 20 hours.
Committing to a number of features in a contract is even worse. “Feature” is not a unit of measure. Building a feature could take anywhere between a few development hours to a few quarters. Rest assured that enterprise customers will likely have complex requests, which will lean towards the latter. Lack of process**- Ensure that you define a feature request review process, so that endless emails don’t eat up your team’s time. Also, it’s helpful to ensure that acceptance and prioritization decisions are not made ad-hoc. For example, the prioritization process should always consider parameters such as:
• How likely is it that this customer will churn?
• How long until the contract renewal?
• Will this feature be useful to other customers?
Not making is reusable - If multiple customers frequently require similar tweaks, why don’t you make it configurable? Under certain circumstances, this can allow you to shift to the mixed model.
What Model Should my Startup use?
While this is a complex decision, three key factors should be considered:
1. What kind of a model does the industry I operate require? Do enterprises dominate it, or are there a lot of SMBs?
2. Do I want to spend my life maintaining personal relationships with other companies?
3. What kind of talent my company has, and can hire? Can I build a team that can form great personal relationships with customers, a team of great marketers, or both?
Whatever you choose, remember that no model is wrong. No business is wrong, as long as it’s moral, respects law, and generates profit. But it will impact you every day you enter the office.