You have this great B2B software idea and you create a startup around it. You are validating and ideating and possibly showing to a few prospects or conducting proof of concepts (POC).
To get early customers up and running, you do what it takes to set your product up and running. In some cases the customers need Feature X to make it work. You oblige. The next customer wants Feature Y. You oblige. And you continue to do that for the first 5-10 customers.
You are entering the trap of customizations. You are not alone. Almost all B2B software startups will go through this stage. It’s by design as your customers are enterprises. (hence the emphasis on B2B in this article)
Customizations are very costly as you start to grow beyond that 5-10 customer range. It’s hard to manage and maintain the custom pieces of the code. Every customer will have their own code base. Any new features you build will need to be tested against each customer version. Often the features will be in conflict of each other. This is wasteful and takes away valuable engineering time. You will not have the time and resources to actually build a scalable product for more repeatable customers because you will always be playing catch up.
This is a perfect moment to escape this trap before it’s too late. After the very initial custom POCs, it is really hard to claw back into product mode.
The most basic principle from a product perspective is to have a single code base. A single code base is easy to manage, scalable and flexible. And it’s the only way to ensure you are building a scalable product and are able to release frequently.
The needs of enterprise customers are quite unique even within a specific industry or domain. Requests for feature X or Y will not go away. So how do you resolve this conundrum?
Productization framework is a better approach. Your product should be flexible to accommodate the myriad needs and use cases of your target customers. Think in terms of productizing everything…well, almost everything.
When you productize, a new customer can be set up with a few dials rather than custom code. Easy to manage and maintain and opens the possibility of new use cases. It’s hard for the very first POCs as you are still discovering and validating, but the patterns start emerging after a few POCs.
Some feature requests may sound very specific to a customer. First ask if this is something other customers may also be able to benefit from? If yes, then design the feature as a product by making it parameterized.
To illustrate a simple example,
Customer 1, cost of sales is commissions of 40%
Customer 2, cost of sales of commissions of 20% of recurring rev + 40% for non recurring rev
Customer 3, cost of sales is commissions of 20% for direct sales and 36% for indirect sales
The above rules can be parameterized in a settings area in your product. Now all you have to do is to set the settings for each customer. A customer success person will be able to do that easily – much cheaper than engineers writing custom code.
Then there are certain features that are highly specific to a customer.
To illustrate
Customer 1 uses a proprietary home grown application to manage inventory data
Customer 2 uses excel to manage commissions pay out
In these cases, there is no way these should be productized. These will be considered as candidates for customizations. Now ideally you want your customers to pay for features that are very specific to them.
Productization Framework
However, this is easier said than done. How do you implement this? There is no right or even a single answer.
This framework is a good starting point when making decisions about your product. The framework consists of these parts.
- Value Proposition
- Key Features
- Roadmap
Start with the core value propositions of your company and your product. What are the top 3 –5 values your customers will obtain from your solution. List them out.
These are the reasons your company and your product exist. These value propositions should be roughly in the order of priority. How do you decide priority?
The first one is the core value prop without which nothing will exist. This is the value prop that you have validated in early customer discovery. You are sure that this is a big enough value that customers will use your product as it solves their biggest pain point. The early early adopters will use this product just for this value prop even if other bells and whistles are missing.
The next value prop is based on what the early early adopters and the next set of early adopters might want. This will also come from your validation interviews. And so on.
Now you have a roughly prioritized set of value propositions. Not set in stone but a first draft.
Next, identify the top features for each value proposition. Keep it at a high level. Don’t think in terms of epics or stories just yet.
Also list out out the table stake requirements such as user management, data integration, migration etc.
Convert it into a roadmap. Typically, I prefer the roadmap into these buckets – Immediate, Next, Future.
This is the current state of your roadmap. It will change over time. Notice, there are no dates or release plan. A roadmap is meant to be a sequence of your priorities.
Applying the framework
Now comes the hard part. New customer requests are coming. They want X and Y and Z (in addition to what you have already planned to build).
There are two decisions to make.
- Are these requests productizable?
- When can we deliver them?
Review each request, including customizations already done.
First check if the requirement fits into any of the value propositions that you listed earlier.
If the requirement fits into a value proposition, then add it to your roadmap. If the value proposition cannot be achieved without this feature then it should be prioritized, otherwise it can wait.
Communicate with the customer on where the feature fits into the roadmap. Ask if they can wait. You will be surprised how many of them will say yes. If they can wait, then great. Keep them informed of your progress.
One thing I learnt about enterprise customers is that most do not want their vendor to go out of their way to customize something specifically for them. They would rather have a stable product that works for all customers. In fact you can use this as an argument. Hey, I can certainly build this for you now even though it is not part of the roadmap yet. However it may impact the stability of the product. Expect the customer to respond…nah, we ‘d rather wait.
If they cannot wait, then ask if they are willing to pay to move the requirement up in the roadmap. Many will decline. Some may agree.
What if the requirement is not part of your value propositions? It is possible that perhaps this is an important feature. It is also possible that this requirement came from a customer who is not your target. Now you have a tough choice. You can fire the customer, not common but happens. Or negotiate with them to pay for the feature. Or add to your roadmap.
Your default answer should always be no. You have a defined roadmap and you will stick to it. Share a high level version of your roadmap (make sure to put a legal disclaimer). Unless the customer is willing to pay for expediting your roadmap, stick to your roadmap. Remember your north star goal, getting repeatable customers. Going on a side trip to accommodate a customer will reduce the momentum of your flywheel.
Use this as the basis of prioritization on an ongoing basis. Will there be gray zones? Absolutely. If you have identified your ideal customer profile diligently and your value propositions are clearly articulated, then the framework will be easier to follow and you will have fewer gray zones.
This framework will help you get out of the trap of becoming a customizations factory. You still have early customizations and they will take time to get out.
For B2B products, there will always be customizations needed. Especially those requirements that cannot or should not be productized. One suggestion is to have another team of cheaper resources that only does the non productizable customizations e.g. integration with custom databases, integration with in house applications, migration of datasets etc. And if you can get help from your customer’s IT team, even better.
Each startup will need to create their version of this framework. Having a framework is a great first step and half the battle.
