Should you customize your startup product for every customer?
Well, you can, but your business probably won’t scale.
Startup -> Scaleup
Scaling your tech product business requires at least two things that need to scale when moving your business from startup to scaleup.
- Scaling your organisation — i.e. hiring more people.
- Scaling your tech — i.e. increasing your compute and data resources.
One of these things scales proportionally to the number of your customers, and the other scales proportionally to the number of customizations you build for your customers.
Do you know which is which?
OK, so what is wrong with building customizations to products?
A customization is a benefit/feature/capability that is specific to a single customer — often exclusively. As opposed to a configuration that has been specifically designed to be applied to all customers of a product. Customizations are often demanded, (and sometimes bought and paid for by customers), whereas configurations are deliberately designed into products. Configurations define the known variability of use cases of the products in any market.
Scarce Resources
Constraints shape everything we design in products, and they affect how we act, and how the products we build - actually behave.
A dilemma for small startups. Being constrained to small numbers of people doing paid work in the business, plus being constrained to small total addressable markets, plus being constrained by small amounts of capital injections. Impose some pretty excessive constraints on tech startups and founders in terms of being able to work on their product market fit for their product before they run out of capital. So, you could say that due to these tough small-scale constraints, we will see a disproportionate number of startups fall into well-known traps that other well-funded larger startups may be able to escape, with brute force, leveraging the larger capital amounts behind them, (and the consultants that they attract).
So, here is one interesting outcome (in the behavior of founders) being in the particular position of having highly constrained resources from day one.
The Build Trap
It is a fact of life that, in small startups, most tech founders (rightly or wrongly) will race to build as much product as they can (in terms of features), as fast as they can.
You can’t really blame them for thinking that this is the natural path to their success, given the way the industry emphasizes features at the core of its agile “delivery processes”, and given the “Do you have feature X?” type enquiries potential buyers ask them during all their sales interactions.
Lots of “features” seem to be the secret to unlocking a good product — but it really is not!
So, in spite of that truth, founders persist on this way for the first few years, thinking that more features -> drives more sales!
At some point down the track, that feature-driven development process will naturally slow down its rate of delivered features, since the product will at some point have a set of core features that are good enough to sustain most of the use cases of the product that should be there. But on the sales front, instead of honing this base feature set and improving its actual effectiveness in-market, and instead of doing more marketing to generate more sales and market share, founders fall into the trap of thinking that they need more features, to cover more customer problems to make more sales. It is a typical land-grab type domination strategy to take over the world.
So they proceed to try to expand their customer base by selling their under-cooked product to whoever and whomever they can — whoever will buy it. “Whatever those customers need, to make a sale to them, we will put in the product!”.
Why not right?: “perhaps there is a new market here we didn’t know about? These guys in this company obviously see some value our product, so why not spend some time and resources with them to see if we can land them, and other customers like them?”
Seems like a reasonable way to “feel around” the marketplace for new customer segments, right?
Well sure, it is “a way” to explore new markets for your product, no doubt. But, presumably you had a strategic target market to go after in the first place, did’nt you? If this new opportunity is not in that segment, then hopefully you are not then going to spend all your precious resources here discovering whether this segment can be expanded into, right?
“well, these guys want our product, but it doesn’t do everything they need it to do, so they are asking us to build some more features that they must have to buy and use our product. They are even prepared to pay us to build these features! Seems like reasonable business to me”! — said every tech founder!
And this is how the product customizations begin...
What is worse, is that this sales-driven-development strategy is often enacted off the back of the last sales coffee/conversation or email that a founder had with a random potential buyer or network contact.
Inevitably, particularly in the B2B plays, they find themselves entering the world of product customizations.
Customization versus Configuration.
You can legitimately design “configurations” in a tech product that can be tailored for each customer that is using the product — particularly multi-tenanted products. For example, company branding, logos, names, colors, layouts etc, and possibly even specific business rules, etc that are tailored to their specific needs — to make the product look and feel their own. These kinds of configurations are inevitable in most SaaS tech products, especially important in those that are due to be white-labelled. But these “configurations”, are very different than building and supporting bespoke/unique features/capabilities for a specific customer that only they can use, and that they have control of. Indicated in code, by conditional statements throughout the software like:
if (customerId == “AcmeLtd") then … else …Particularly features/capabilities that a specific customer has paid you to make for them, and has contracted that only they get exclusive access to. These are product customizations. If you got them to pay for it, that’s amazing sales prowess, congrats. But that is detrimental to your product business long term.
Fatal Attraction
It seems so alluring after all. Landing any early adopter who loves your new product is exciting and addictive. But, it’s especially alluring, when the opportunity is of landing a BIG sale from a large enterprise that is thinking of adopting your new product.
But this is a huge trap, and ultimately a rookie mistake.
Not only does this kind of opportunity charm the pants off a Founders ego, but it also seems like so much less work than going after many many more of the smaller opportunities for a single license here and there. It seems like such a no-brainer to a Founder, so they double down on it.
What generally happens with these larger deals is that they lead to the founder to having to accept long wish lists of features to add to customize “their” product, that the sale is now contingent on, and out come all the legal contracts.
Following your customer’s stated needs (aspiring to be customer-led), seems to be such an easier and more logical road to follow, than doing your own hard and meticulous predictive research, user research and marketing research on other customers in the market. It is also what the Service Provider business model is based upon, so it will feel absolutely natural to most Founders, who have grown up in that world.
So, let’s see the big-picture trap here. It is the presumed validation and confirmation bias of the Founder, from a large attractive customer, plus the attractiveness of a large financial payback, coupled with the certainty of satisfying at least one customer’s needs. Accumulating into -> one giant romance between the sales force and the BIG customer. But it is deadly for your product strategy.
Why is this so alluring in the first place? let’s break it down:
- Obviously it’s seen as less effort, focusing on one large customer is perceived as less effort than focusing on hundreds of smaller ones. Perceived cost savings!
- One solid validated bite on the hook, gives more certainty by validating our idea now, since it’s a “real” need by a “real” customer right now. Perceived validation!
- There’s a bias/belief that if the big fish love our brilliant startup idea, then we don’t have to care about all that effort in reshaping or honing it for a larger market (yet!). Perceived cost savings!
- The revenue from landing that “big fish” will look after our business for a while, and we can skip the pain and effort of doing more protracted product market fit work. (Which all seems so complicated and so hard, and so expensive right at this moment in time). We’re making money sooner and can skip validation and jump straight to scaling up! Perceived efficiency.
These kinds of propositions are unbelievably awesome for a founder and sales team! “They have a shot at passing Go, collecting a ton of revenue, and jumping straight to millionaire status right away!”
“Job done! — That was easy”.
“How hard can it be? right! — anyone can do this!”
But alas! Sorry. Sorry to burst your bubble, but not “anyone can do this”, because this is not what is being done by anyone. At least not in successful products seeking large-scale product market-fits. It is only done by people turning their potential Product company into a certain Services company.
A dose of reality
Not only are the sales cycles for these larger enterprise opportunities many orders of magnitude bigger in terms of time, effort, and resources, shortening your runway and capital reserves. But so are the expectations that those customers will demand on the problems that your product will now need to start resolving specifically for their business. They don’t give a shit about your product business or your product strategy. They only care about solving their specific problems. Their demands are going to be orders of magnitude larger and more complex than you can cope with right now— whether you know that upfront or not. They are in fact looking for a Services partner, not a Product partner.
Tech founders tend to ignore both of these “startup business killers” until it is far too late. They then go on to exhaust their resources and capital reserves chasing these things. Often ending up with a p̶r̶o̶d̶u̶c̶t̶ solution that cannot be sold to a larger market, because it no longer fits a large addressable target market.
Product versus Solution, do you understand the difference?
These large lucrative opportunities, if they ever do land (and you are lucky if they do), are simply not the early adopters of your product. They are going to kill your product and your startup business!
So, what are we saying here?
Can you explore and learn from these opportunities? Absolutely, you can, in small and very limited doses.
Should you try to sell to that mid-market customer you found out there? You can absolutely try, but expect it to exhaust your resources far faster than you might expect, and possibly cripple you beyond rescue. You are probably not yet ready to go there yet.
Can you service these customers real needs? Perhaps? But should you depend on actually landing them as a guaranteed line of revenue for your business long term? Don’t bet your company’s future on it!
Whether you can, or you actually do execute this strategy, with every step you take down that road, you are likely moving away from a scalable product business and into a bespoke solutions business.
It is still your call however and both are legitimate businesses. Just very different kinds of businesses. Nothing about them is the same, except maybe the founders who started them, and the idea behind them.
Do you have the resources?
Nonetheless, many, many, many founders optimistically proceed into the hell that this experience can be for them, tempted by the perceived outcome of it.
The first thing they discover is that the sales cycle for these opportunities takes ages. Months, even years, to land a single big deal, but the promise of landing that deal seems to nourish them enough to keep persisting on with it. (At least at the start it does)
The other thing they don’t realize is that the adoption of their product will be contingent on all the other things a mid-market player needs to see about your company and your product relative to the rest of the market and your competitors in it. And you probably aren’t ready to play in that mid-market game yet. You probably haven’t even reached the chasm yet. (viz: crossing the chasm), let alone prepared for the necessary siege required to cross it.
Let’s say that you even have a friendly contact at these particular opportunities. That might be a C-suite advocate or company rep trying to innovate, or even a trusted friend or old colleague of yours at the company. Even if they are highly trusted, and maybe even very optimistic about the success of the adoption of your product in their company. Regardless of that, depending on the size of this company, you will still have a whole corporate bureaucracy to move along before your product will be procured and rolled out fully, giving you access to the end-users to learn from. And that will take bucket loads of time and resources you simply don’t have right now, and can’t afford to burn on this.
A Shift in Strategy
Meanwhile, back in your startup, other market opportunities will be popping up and they will also demand your attention, and demand refined capabilities of your product. Resulting in more intense product discovery work in the market, costing you more capital. Those opportunities will require your time and focus too. That work is also hard grind, and you will (of course) be mentally comparing and prioritizing the impact of those smaller opportunities against the looming big opportunities that are so tantalizingly just right around the corner — yeah right!
This bias (for the larger opportunities and the shinier sales) can lead to valuable market intelligence being ignored and lost, about the product you should be building instead for the larger more lucrative market of smaller players, and genuine early adopters you may have relationships with.
Your long-term goal with the product venture is to find a large enough market to sustain and grow your revenue. Focusing on only a hand full of “big fish” isn’t leading you to discover the product you need now for that larger market (before you cross the chasm).
Is this really Product?
Let’s talk about this from a product development perspective now.
Let’s say that you avidly hunt the big opportunities, you engage your resources and people into those long cycles, and you start shaping the features and capabilities of your product in the direction of each of these large or individual opportunities. It seems like the logical right thing to do. right?
Wrong! this is short-sighted, and it’s NOT what product development is about.
1Building to customer-specific customizations in your product will change your product strategy over time, where you likely stop worrying about discovery, acquisition, retention, and referrals, and instead get focused on custom demanded features and one-off sales. Sales that you will assume will stick forever and “keep your lights on” for the foreseeable future. Too few eggs in your basket. It possibly changes your business strategy too, depending on whether a large addressable market (TAM) was in your business strategy or not — which probably was, if you have any investors onboard.
2 Custom, bespoke work is simply going to enrage your investors and drive them away, and with that the much-needed capital a product business necessarily needs to grow and scale. Why? because the economies of scale that generate the kinds of returns that your investors signed up for (5x — 20x over the next 3–10 years), just evaporated by you building your new Services business. There’s a good reason that tech investors don’t invest in Services businesses in the first place.
3 Building customer-specific customizations to your product (exclusive to a specific customer or not) dramatically increases the complexity of your product engineering and technical architecture, in ways you won’t expect. Like: managing which customers get access to which features, pricing complexity (for your customers), which features, which customers. Supporting all these bespoke options costs you a ton more money in administration and support that those customers didn’t pay you for in the first place. Furthermore, keeping quality high in engineering by testing all the new permutations of these custom features and their unique combinations, costs far too much. In most cases, after a while, your engineers will just give up on maintaining the integrity of these options in your software, and prioritise getting these customizations built and delivered in bespoke ways. Never mind that your tech architect probably didn’t account for this “platform capability” in the technical architecture of your product initially (since it would not have been in your product strategy months or years back). And since that is likely the case for you now, your now enlarged “big-ball-of-mud” core architecture (if you had one) just got an order of magnitude more complex to move within for your engineering team. And gets harder with every customization that is just bolted on the side of it. Hence, double-whammy! your engineering costs rise dramatically, and your delivery velocity grinds to a halt. Process and practice shortcuts are being taken necessarily to keep pace with sales demands, tech debt rises, and every process in your engineering and your support functions slow down as those people trudge through the mud at every step dealing with all these temperamental customizations. It is not obvious to you that you cannot fix this problem by adding more people (or replacing the existing ones — who look incompetent now), since the work of each and every person added is co-dependent on all the work of each of the other people, and now, no one can move independently and get anything done without breaking everyone else’s work. More things about your product just start to creek and break more and more. Pretty soon, you can’t deliver customizations in a timely manner to your customers anymore, and the ones that you have delivered to date are further compromised. The handful of customers who once loved you, that your business now depends on, will now begin churning. As they find other products (best-in-breed products) that do a better job than yours can.
4Who is actually negotiating these customizations in your business? and who is deciding to pursue these sales, that are contingent on delivering these customizations? If that’s your CEO, then you are in deep trouble already — that sales process simply won’t scale, and it is not what the CEO should be doing. The effort to negotiate these customizations, and tailor them (over several delivery cycles with a single customer) is a great deal of effort , it is an “Account Management” function — and certainly not the core focus of the CEO anyways. If you are looking to scale this business model with a single person doing all that account management customization and relationship work, then good luck with that! it does not scale!
That person has now become the biggest bottleneck of your future sales and revenue pipeline. They will be working their ass off, but that won’t help your product business scale. Sure, you can hire more account relationship people, but you are missing the point about how digital products actually scale to large markets.
Still not convinced?
All these activities may still seem like what you should be doing, and doing them to a small degree is sometimes what you need to do to bootstrap a startup tech business. No problem with that (in small tactical doses). But if you are hoping to grow your business out of this kind of strategy by repeating these behaviors long-term, AND this strategy is ultimately your means to scale your business. Then, I’m sorry to tell you this, but forget it, it won’t happen, it cannot happen like this. Your business and your tech product cannot scale like this. It is futile.
Building one-off customized solutions for individual clients, while very alluring (in terms of short-term revenue), is simply not product work at all. It is services work, and we have other very successful business and management models for doing that kind of work more effectively. Mixing those business models is a recipe for disaster — go see every Services company ever that tried to pivot into building Products — they failed to scale!
If building a Services business, building bespoke customized solutions for a small market is what you wanted to do then, fine go for it — great. That’s far easier to do.
You might think you are building a product, but you probably are not — by definition. You are in fact building a bespoke and tailored solution for a diminishingly smaller and smaller niche market. The more you do it, the more niche your solution and your business become. This can only scale one customer at a time, and one relationship at a time, and that can only scale one employee at a time.
Want x more customers? then hire x more people in your company to service them. That’s not how it works in product companies, only in Services companies.
When product companies onboard hundreds or thousands more customers onto their product, their engineering teams don’t have to change size at all. That's the whole idea behind economies of scale that you get in building products. But it does not work that way in solutions work. For solutions work, you need to hire more people to deal with your customizations and more people to manage those customer relationships, and that scales one person per x customers.
Custom solutions
It’s far too expensive to build one-off customized solutions and sell them to large markets. Have you seen how much a one-off custom solution costs to build and maintain? (even for a short period of time?). It is what most software teams in most Enterprises are doing today. Hundreds of people building lots of tools for their organisation.
Perhaps you have previously worked in a Services business, and know how that works best? Most likely! most people entering tech as entrepreneurs are now coming over to the product side from services business models. It’s all they know. Services might be the game you might know well over there. If that’s the case, you’ll need to learn to appreciate that the game of bespoke solutions is not the same game as the game of products. You don’t achieve economies of scale by building solutions and then trying to scale them up. It is far too expensive, far too niche, and that game does not require product market fit, and validation, and product research work. It just needs a couple of loyal customers who can use your business and skills to resolve a bunch of their immediate (and ongoing) problems. It requires you to get into the same orbit as them for a long period of time. Is not product.
The limitations of the Services model is exactly why most Service Provider companies (aka Solution Providers in tech) eventually turn to Product to save them in the first place (generally as their Founders age) — to make themselves recurring product revenue, that their Services business does not, and cannot generate for them.
If this strategy is what you feel is what your tech startup should be doing, then that’s cool — go for it. But go build a Services company structure to do that kind of bespoke work instead. This is not product work.
It does not look like product, it does not sell like product. You don’t need the same skillsets to do that kind of work that you need in product, and as a result you won’t be scaling it up to a large total addressable market like you need to in product.
You can call it product work if you want, but then you’ll just confuse everyone around you. You confuse those you hire, you confuse your organizational structure, and you’ll confuse your partners and your customers.
What about platform products?
So, what if, you really do think that you do have a killer product that needs to be customized by each and every customer that buys it?
That’s cool, they exist everywhere, and you are now looking at building an extensible platform for your customers, which would be a product, as long as you go about it the right ways.
If you are doing this, then you’ll need:
- A technical architecture that is extensible and scalable from day one. This will look and work vastly different from the typical product architecture that you would need for a non-platform product. This platform product requires its own dedicated team(s) and they will scale differently than the customizations teams described below.
- You’ll need to make and defend clear boundaries about what is core product and what is customization. You will be saying “NO” a lot more to customers, and instead directing them to your customizations function described below. You’ll be deciding whether you will invest and design, build and support this feature/capability long-term, or whether someone else needs to make and support this capability for them. You can scale your engineering around this quite well, if done expertly, and it won’t need to scale with every customer coming on board.
- Then, you’ll also need a consulting services and biz dev function of your startup (in your company or in partnership with others) who specialize in the integration work of your product (with other products), and building customer-specific customizations that integrate with your platform. Those people are going to start making demands on your product too, selfishly for their customers. They can’t be making product decisions for you at all.
Once you have this all setup, then, your customers will not only be purchasers of your core product, but they will also be investing in building customizations on your platform.
You will now have to serve a development community of partners building customizations against your platform— whether your company does that in-house or other partners do that for the customers. 2 different sets of customers to provide product to now. (buyers, and developers).
You’ve now got a marketplace for a platform to deal with, and you’ll need sufficient resources and people to cope with all of that from pretty much day one of your platform release.
This will be amazing for your bottom line if you get this far. Which is why so many people want to get into this space.
What about non-platform products?
Q Okay, so what if you are just a regular B2B or B2C product and not a platform yet? Should you sign up to do customizations for your early customers?
AThe truth? You might need to do a little bit of this to get started and get off the ground bootstrapping and exploring your target market— it is very risky and it will be resource hungry. But then again, so is having no customers in the early days of your business.
Recommend that those select opportunities, if you pursue them, are: #1 not big organisations (and not your mid-market TAM), #2 your product is not too innovative for them, and #3 its a very targeted use case for their people. #4 you can get out of the deal at any time, and you should always limit the opportunity cost (contractually) to some reasonable timebox.
Every improvement or feature request (that they request from you and your product) needs to be carefully considered and weighed up against your actual target market (TAM), as to whether its a customization, or on product strategy, and you’ll need to (politely) say NO a bunch of times — in reality.
Saying “NO” is to be embraced to protect your company and the integrity of your product. You’ll need a solid and predictable discovery and delivery pipeline to make those hard calls, so that you can say “NO” confidently knowing that it would have been bad for your product in the first place.
Expediting customizations for a specific customer, frequently (to win deals), will just cause grand chaos for your product and engineering functions. You’ll need some very rigorous and disciplined engineering practices to manage the custom customer-specific features (if you have any), as they will need to be designed and managed not to break or shape the core product (i.e. using plugins).
Q Should you engage large corporate customers as early adopters of your product?
A Presumably you understand what crossing the chasm actually means? as these kinds of companies traditionally are an unlikely fit for behaving like the early adopters that you want and need right in your early days, this side of the chasm. They will simply need more than you can provide right now. period.
So, the answer is NO, unless you are absolutely confident (along with financial guarantees) that the following won’t happen to you and your product (for the whole time period that you are relying on the revenue from them):
- Your advocate in that company (whoever they are) won’t move on from whatever position of influence they have (in that company), and get replaced with someone else, left to advocate for your company/product. If they do move on (and there is a high chance that they will at some point — the nature of enterprise careers) you will be back to square one with their replacement, and fitting your product (and credibility) into their new corporate strategy. Deal breaker.
- They are not going to apply a long (and ultimately unending) feature list of things that your product needs to do for them before they will buy it. Catch 22. This is a trap, because you will simply exhaust all your resources making that happen for them to their arbitrary satisfaction. Which you can’t ever achieve with your resources, based only on a very high-risk promise from them (that is very unlikely ever to be fulfilled).
- This won’t become your long term strategy to scale your business and reach more customers.
