Top 4 Questions To Answer Before Product Scaling!
VP Engineering - 04 August 2016 - 12min
VP Engineering - 04 August 2016 - 12min
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 process capabilities, when it comes to 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 software development 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 my development team had already built the system to scale considering a certain level, the drastic growth would have caused us more grief than happiness. Instead, my team members put in a plan to continuously scale the product based on evolving business priorities and ended up managing the show efficiently.
While every new product and business situation has its own set of nuances, a few important considerations go a long way in efficiently scaling your digital products.
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 mustn’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 which is market- fit 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.
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 not 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.
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:
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 initial 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 have always used the sale day example on e-commerce apps to highlight this point. When the volume in traffic hits multiples 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 will leave you with a lingering thought. Do you think you have nailed it? If yes, then have you scaled it?