On a recent trip to Europe, a prospect meeting reinforced a notion that I held to be important anyway! While most founders are quite confident in their product development capabilities, when it comes to product scaling many of them are fundamentally unclear over how to go about it.
I have come across many entrepreneurs who believe that scale is something they need to factor in, at the very beginning. Be it their MVP or a major milestone release, I see most of them scurrying over the product scaling quandary from day 1. Unfortunately, this leads most of them to fail.
Having worked with entrepreneurs through multiple stages of the business cycle, I often get asked about how and when to deal with the conundrum of scaling.
In my opinion, scaling isn’t something you do initially and in one go. It is a continuous process that begins after you have stabilized your MVP or a major product enhancement, and goes on till you arrive at the next big milestone. The very title of Nathan Furr’s bestselling book “Nail It Then Scale It” is forewarning enough for entrepreneurs and clearly suggests steering clear from the temptation to scale before time.
I am heading the product development for an ad serving platform that went from 2 billion hits a day to 15 billion hits a day in a year’s time. If we had already built the system to scale considering a certain level, the drastic growth would have caused us more grief than happiness. Instead, we put in a plan to continuously scale the product based on evolving business priorities and ended up managing the show efficiently.
While every product and business situation has its own set of nuances, a few important considerations go a long way in efficiently scaling your product.
#1: When to Scale.
2013’s Startup Genome Report came out with an alarming figure based on the analysis of about 3200 high growth start-ups. 74% of these start-ups failed due to premature scaling.
Premature scaling not only refers to scaling during the MVP stage, but also to scaling attempts during a major release or feature rollout.
So why musn’t you scale prematurely in either of the cases? The answer is simple. It’s a tall order, predicting whether an MVP / feature rollout will get a favorable response from your customers and what the business forecasts would look like. So if you do scale, you do it based on a hunch, not numbers. The best way hence, is to let your MVP / feature rollout stabilize, and then scale it as per the business requirements.
Having a great product is simply not enough these days. To stay on top of the game, you need to constantly innovate and improvise. That being said, continuous innovation is a costly game.
I recently read something on the depreciating value of innovation and it can be applied perfectly to time your scale activities. Rollout a part of your innovation/improvement initiative and allow it to follow the value curve right till its value begins to dip. When it does, scale up in terms of the remaining functionalities. That way, not only do you add value to your business constantly, but distribute the costs of doing so as well.
In short, you need to align your Product Scaling with your business forecast. So do forecast your business and then plan for Scaling your product accordingly.
# 2: What to Scale
In an ideal scenario, scaling the entire system and all components of your product in one go seems feasible and cost efficient. But reality is far removed from that.
Prioritization, is the key to successfully scaling your product and if you go with the flow, this shouldn’t be a tall order.
From a scaling perspective, it pays to breakdown larger systems into components and de-couple components to understand what is causing a bottleneck in your business and how. Not only will this help you prioritize what to scale first, it will also help you understand what level to scale up to.
#3: How to Scale
Scaling is not merely adding server space and being done with it. As a key factor of your product’s ability to succeed, it is an area where you can optimize your costs and efforts with the right approach. Some key parameters that help you choose the right approach include:
- Time involved and interdependencies: Faced with a situation once, where we needed to scale our product by quite a high multiple yet ensure that we optimized costs. We de-coupled individual modules, allowing them to be scaled individually and in parallel, thereby reducing the time and interdependencies associated with scaling.
- Costs and efforts involved: Picking up on prioritizing scalability requirements, I have come across situations, where simply using different caching layers and introducing distributed messaging queues have solved scaling dilemmas that would have otherwise entailed much costlier and time consuming endeavours.
- Optimization: while conventional definitions might suggest so, scaling isn’t always about adding on top of your existing setup. I recall an instance where we dropped from 700 to 300 server boxes, but operated at the same capacity. While we could have added on top of our existing server boxes, reducing them helped us optimize the system in terms of costs and maintainability.
- Availability: I remember a situation where the customer was ready for a costly solution for their database issues but couldn’t afford losing out on the up time. Putting the clutter aside, we adopted a simple approach of splitting the database vertically (partitioning) and horizontally (sharding). Not only was it much cheaper than we budgeted for but avoided the loss in availability from time consuming re-architectures.
#4: How Much to Scale
When it comes to product scaling the Big Bang approach never works. Since scaling is more of a continuous event throughout the course of your business, knowing “How Much” of it to do is critical.
As a generic formula, if X is the volume you are currently at. 10X is a good scale capacity to be at during the early stages, since growth in volumes is erratic. Towards business maturity a 3X scale capacity is ideal, as growth in volumes is relatively stable trajectory. In the event of a major enhancement, it is ideal to switch back to around 10X scale capacity as volumes might spike erratically and being unprepared would mean certain doom.
I’ve always used the sale day example on e-commerce apps to highlight this point. When the volume in traffic hits mutliples of its daily volumes, the applications inadvertently fail to perform. This is because nobody factors in the additional requirement to scale in such special situations.
Putting an end note to this article, I’ll leave you with a lingering thought. Do you think you have nailed it? If yes, then have you scaled it?
