While most founders are quite confident in their product development capabilities, when it comes to product scaling, many of them are fundamentally unclear about how to go about it.

Many entrepreneurs believe that scaling products is something they must consider from the beginning. Whether it is their MVP or a major milestone release, I often see most of them scurrying over the product scaling quandary from day one. Unfortunately, this approach leads most of them to failure.

Product 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 continues until the next big milestone. The very title of Nathan Furr’s bestselling book “Nail It Then Scale It” is a warning for entrepreneurs, advising them to steer clear of the temptation to scale before it is time.

At Talentica Software, I frequently lead the product development process for various customers. In one notable project, an ad-serving platform rapidly grew from two billion hits daily to 15 billion hits daily within a year. If we had built the system to scale considering a certain level beforehand, the drastic growth would have brought more grief than happiness. We successfully achieved this rapid scale by working closely with the product owners, understanding the business’s key performance indicators (KPIs), and translating them into actionable product KPIs. This ensured alignment with overarching business goals and helped scale the product accordingly.

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.

When to Scale

Premature product scaling is a common pitfall for startups, not only at the MVP stage, but also during a major release or feature rollout.

For example, I worked with an early-stage startup trying to build an MVP for an analytics platform and insisted on developing a scalable system from the beginning. This required significantly more time to set up the architecture and infrastructure, as well as more development time. Unfortunately, the startup faced challenges in achieving product-market fit and eventually shut down its operations. The mistake: spending time and money building a scalable platform before validating their idea.

In a separate instance, we were helping a client build an advertising platform from the ground up. The platform quickly reached the mark of 1 million ad requests per day and continued to grow exponentially. Despite this fast-paced growth, we focused on scaling the platform optimally based on the business forecast for the next 6-12 months by tweaking the architecture and bringing the right technology at the right time. This approach proved successful for the next 15+ years, and now the platform is serving over 100 billion ad requests and processing over 200TB daily.

In short, you need to align your product scaling with your business forecast. So, forecast your business and plan to scale your product accordingly.

What to Scale

In an ideal scenario, scaling the entire system and all components of your product simultaneously may seem feasible and cost-efficient. However, the practical aspects of implementing a full-system scale often make it impossible. Prioritization is the key to successfully scaling your product.

Let me share a real-life situation I managed for a leading wireless network company. The company aimed to harness AI using data collected from access points. However, the performance of the systems made it difficult to do so in real-time. While one option was to rewrite the entire product, doing it quickly without affecting existing customers proved challenging. Instead, we decided to identify the bottlenecks in the process and optimize the performance of the data ingestion module, which was slow in capturing the data from access points. This drastically improved the performance and gave us the time necessary to fix other modules.

From a scaling perspective, it pays to break down larger systems into components and decouple them to understand what is causing a bottleneck in your business and how. This will not only help you prioritize what to scale first but will also help you decide what level to scale up to.

How to Scale

Scaling is not merely adding server space and being done with it. As a key factor in 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:

  • The 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 decoupled 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 encountered 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 endeavors.
  • Optimization: While conventional definitions might suggest so, scaling isn’t always about adding to 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 to lose out on the uptime. 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 it avoided the loss in availability from time-consuming re-architectures.
How Much to Scale

In an ideal world, you would have unlimited resources to keep your product future-ready. However, in reality, decision-makers work with constraints such as budget and time. Failing to develop the product in the right way by keeping both these factors in check can lower the chances of realizing a positive return on investment (ROI).

A few years back, I worked with a competition platform that aimed to scale to reach children nationwide. Considering the time required to capture the entire market, we suggested an incremental approach. They came up with priority markets and the number of children they wanted to target within the first 6 months. We forecasted the scale required to handle it but built the system to handle 10x of the forecasted scale.

When it comes to product scaling, the ‘big bang’ approach never works. Scaling is a continuous event throughout your business, and knowing how much of it to do is critical.

As a generic formula, if X is the volume you are currently at, having a 10X scale capacity during the early stages is good since growth in volumes is erratic. Towards business maturity, a 3X scale capacity is ideal, as growth in volumes is a 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 could mean certain doom.

I’ve always used the ‘sale day’ example on e-commerce apps to highlight this point. When the traffic volume hits multiples of its daily volumes, applications often fail to perform because nobody factors in the additional requirements to scale in such special situations.

I’ll leave you with a lingering thought. Do you think you have nailed it? If yes, then have you scaled it?

You might also like…