Scalability isn’t always an issue that teams need to take care of. At least right away.

If you haven’t found a product/market fit yet, it’s probably more important to experiment with different features or offerings before planning how your app will go viral.

When you have a small pool of users, you can sometimes get away with doing things you plan to automate later. This allows you to run faster, and when you finally automate your processes outside of the loop, you will know exactly what to build because you will have the muscle memory to do it yourself.

While manual actions can help experiment with a prototype or MVP, they’re downright dangerous when you’re working with a mature product.

As a product manager, you should be looking for red flags that it’s time to think about scaling your software solution. Ask questions such as:

Have you accumulated too much technical debt?

Is complex code blocking simple updates?

Are you experiencing downtime or lag even with current usage?

Set up systems to track and flag scalability issues so you don’t add extra resources too soon or too late.

It can be difficult to purposefully build features that you know will break under pressure. However, keeping your team from building cool features because they don’t scale immediately is a bad idea.

Sometimes the “things that don’t scale” are manual processes. In other cases, they create technical debt—the “cost” of choosing a simple or limited option when a better choice would take longer and cost more.

Technical debt is a “necessary evil” when testing ideas or features and should not be avoided. However, just like taking out a large bank loan, you need to know how you are going to repay it.

Make sure you have systems to monitor scalability, keep track of tech debt or “things that don’t scale” in your PM tool, and review these as you plan your sprint. You don’t want to start building on a cracked foundation.

Knowing that you need to start addressing scalability issues is only half the battle. The rest contributes to your current backlog, roadmap, or code reviews, which is not always easy.

Scalability is not sexy. No one will praise you for doing it well, but you’ll face backlashes if you fail. 

However, the scale exaggerates the problems. What seems like a minor annoyance when serving dozens of customers can ruin your entire product when you move on to hundreds or thousands.

That’s why it’s a good idea to consider scalability from the start. This does not mean postponing your product launch to “improve” your infrastructure. But instead, every sprint should include the question: does it scale?

If this is not the case and you do not have an easy solution, document what you are doing and why.

Later, when you schedule the “scalability” sprint, you will have a list of issues to work on.

Articulate the goals of a solution’s scalability project to your team, brainstorm, ask for feedback and celebrate success.

As a product manager, you should step in and discuss with your team ways to optimize performance and achieve high-availability. Focus on processes required for scaling while keeping an eye on your team effort and providing guidance. Always have a strong Team/Tech Lead to support you.

Here’re some of your focus areas during a software scaling project:

• Sprint planning and retrospectives: as your product becomes more complex, so does your team. How will you keep your sprint planning process efficient?
• Feature prioritization: How will you balance prioritizing new features and resolving your tech debt?
• Recruitment and resource management. Scalability applies to both your team and your product. Do you have a clear process for recruiting or acquiring additional talents as needed?
• Setting OKRs and other team goals. Complex systems can hide your strategy and product vision. Do you have a process for better goal setting that keeps everyone focused on doing the right thing?
• Inter-team collaboration and communication. As your product scales, you will have more teams, managers, and collaboration opportunities. Do you have a communication plan for cooperation and communication between all stakeholders? How about a log to handle external requests?

As your product scales, you will inevitably attract a more diverse group of users. Understanding their needs is how you will keep up the momentum. But if your software team still needs to provide detailed requirements, they will be overwhelmed with work.

User interviews are a powerful tool for understanding how people use and interact with your product. They should be done by as many experienced people on your team as possible.

User interviews are the formal process of interacting with your users to understand their problems, habits, skills, and desires. User interviews are more than just casual conversation; they are targeted, recorded for research and future use, and provide helpful information to IT teams.

Give your team autonomy to conduct research and better understand the user. Or at least give them access to recorded user interviews to help prioritize future sprints.

Don’t assume that your development team will know how to integrate your software systems in a way that’s perfect for your business operations without spending reasonable time understanding your technology needs. Map the standard business processes in the systems to be integrated and define exactly what the systems need to do for each of the processes – what data is sent / received and when, where data should be entered by users and where it should be pulled automatically, etc.

Your tech consultants or you may have to spend an extra day or two ahead of time to come up with a simple plan, but your team will likely spend even more testing and resolving the same issues later. Do this ahead of time to control the time spent investigating, save on rework costs for your developers, and get a clearer picture of the total amount of money you will need to spend on work before processing your payroll. 

There is always a trade-off when it comes to scalability. If you’re a SaaS company sacrificing development speed to mitigate the risks of a potential burst of mainstream usage, you’re probably making a poor choice.

However, if you’re building a video game where uptime is more important than new features, this might be a compromise you’re willing to make.

Choose a path and stick to it.

Look for ways to automate your customer journey to make room for “critical” tasks.

Scalability is (usually) in the “important but not “urgent” section of your priority matrix. Unfortunately, there are often many “more urgent” tasks along the way. To give your team the space they need to focus on scalability, seek ways to automate the “urgent” parts of your product or customer journey.

Some common examples would be creating an account, messaging with a user, registering, reporting an error, or any other thing where users might need “urgent” technical assistance.

The knowledge base of your scalability processes is only good if it is up-to-date and readily available. The same applies to any other knowledge management effort.

Here are some tips to help your team get started with the documentation process:

• Create a Culture of Knowledge Sharing

Create a sense of psychological security when no one is afraid to ask questions or offer ideas. Sometimes it’s as simple as changing the language allowed in meetings to make it more inclusive or giving everyone the time and opportunity to contribute.

• Use the right tools

Use a simple knowledge management system (like wikis) that makes it easy for everyone to contribute and find the information they need.