Building Scalable Products

Building a great product is a balancing act. On one hand, you should get a minimum viable product out to your users quickly so as to get early feedback. On the other hand, you have to build a sustainable future for it. Keeping scaling in mind from the very beginning will help inform how you make key decisions on priorities, design and functionality. You’ll also be able to envision the features that your product would benefit from in the future.

​

For instance, would your product work as a current proof of concept in all regions you operate in or hope to expand to? Are there localisation considerations to keep in mind such as translations, cultural differences or patterns? Are there local expectations on payment types? What are the most popular messaging apps that might drastically change how you’d build and what you’d prioritize?

​

Keeping all of these considerations in mind, come up with a North Star vision of what your product would ideally look like in the future. This will help you visualise the actual scalable product, but also what it will take to make this a reality: your first and subsequent iterations, the product rollout, and so on. North Star visions are meant to be a guiding principle of the value your product can deliver, and to whom, even if the actual experience ends up being very different based on testing and user feedback.

​

The downside of not keeping scaling in mind earlier on is that you might rack up significant costs in the future, when you try to rework and refactor your product to make it scalable. Product managers are often responsible for trade-off decisions that result in reworking the product. They’d naturally want to get a product out as fast as possible to start testing. A software development example could be, a choice between a hacked experience that takes your engineers four weeks to build and a thorough solution (that your engineers would prefer) that would take eight weeks. It’s often difficult for a product manager to say no to the quicker option.

​

I often made this call earlier in my career. However, there are times when opting for the “quick fix” solution makes sense and times when it clearly doesn’t. Communicating with your engineering team on why a short-term solution may be the smarter choice is an important way for you to build trust with them. For example, a quick proof of concept would help verify that your product is addressing a real customer pain point, and whether this is a viable opportunity for the company. If successful, you can then invest in building a more robust solution. In cases where it makes sense to cut corners, you have to commit to your entire team – engineering, UX, and stakeholders – to go back and build a better product that we’re all proud of and can scale with our users.

​

Separating a great product from an excellent one depends on the metrics you define to be most important in measuring success. Some product managers or companies only care about growth and daily active users or signups. So, if users only browse and aren’t buying (yet), that may be fine for where their product and company is in their lifecycle, or the type of product sold. An equal product in functionality and objective experience may be below standards for an established competitor, who needs to demonstrate ROI or increase their customers’ lifetime value.

​

Personally, a winning product is one that has been built to solve problems for all of your potential users – in all regions and for all types of users be it tech savvy and technophobes, fully accessible, and mobile first. You can always optimise UX and make a product delightful to use, but when you have core issues around who is able to use it in the first place, you’ll be stuck working on it for far too long.

Creating a Replicable and Effective Product Development System

It’s not necessarily a structured process, but the questions I’d be asking myself as a product manager to create a scalable product are:

​

• Is this problem we’re solving a problem for all of our users, or a specific type of user?
• Will all users understand our solution and how to interact with the product?
• Does the messaging and touch interactions translate to all languages? Does the tone of voice hold after translating?
• Is it accessible? Does it work on screen readers, with keyboard only users, low sighted or colour-blind users?
• Is the code our team is writing built to iterate to future changes as we track usage and identify issues, opportunities or ideas we want to test?
• Do we have reporting and monitoring set up so we know how the product is working and how we’ll collect feedback from users beyond our standard metrics?
• Will we know if certain browsers are causing errors or blocking users?

​

Track these questions at each stage of product development. Keep them in mind as you prioritise a problem to solve. Then, brainstorm ideas with UX and Engineering, as you narrow towards a minimum viable product that your first users will interact with, or as you optimise an existing product.

​

Let’s Get Creative

Creativity can and should come from everyone in the company, and even friends, family and users. When you’re the product manager, you get so close to the product and its nuances that you can often lose sight of ideas and improvements that could solve a problem your users face. In fact, most of the biggest improvements our teams have made on products were ideas from our developers, designers, and stakeholders.

​

The job of the product manager is to take in all of these ideas and identify the ones worth exploring, based on the long-term vision of the product. If the idea comes from an internal stakeholder or team member, the product manager should coach them to help turn the idea into a hypothesis. This hypothesis can then be tested to validate the idea.

​

At any given time, a product manager likely has 85 ideas in their backlog. Given unlimited time and resources, they’d love to test all of them. The real craft of product management is identifying the six of those 85 that need to be prioritised in the short to medium term, and why. Being able to justify why someone’s idea isn’t going to be prioritised or doesn’t fit with the product’s vision is just as essential. Transparency builds trust – both in the relationship and the vision.

​

However, if someone’s idea can be written as a strong hypothesis with supporting data showing that the problem is large and impacts a meaningful set of users, prioritise that idea and test it.

​

The product manager’s job is applying the principles of product management to prioritise which problem to solve. You don’t need to dream up new ideas yourself. The more your core team and stakeholders feel heard and involved in building a product and experience, the better engaged and energised everyone will be.

​

There are several ways to brainstorm creative ideas while keeping scalability in mind. Google Design Sprints are very popular, and our teams have found them incredibly effective. Read up on the wealth of material available on their strategy. A slightly simpler way is to conduct product teardowns, test-and-learn ideation sessions with mixed audiences outside your core team, test-a-thons, and hack-a-thons. These sessions can yield unique ideas and problems. You can then apply product principles to them, and see if there are some larger ideas that can be prioritised.

Feature Prioritisation

Depending on what stage your product or company is in, feature prioritisation will vary. If you’re trying to achieve hyper growth or are still working to prove the market and the idea, focusing on scalability may not be necessary. Factors you may want to consider here would be what markets you’re currently in, and those you believe you should expand to in the next 12 months.

​

What would happen if you achieved sudden growth? Could traffic or sales spikes be handled effectively with current technology? Will your solution be adaptable to new markets and different cultures and languages, or is there investment needed to localise for new markets? That could be investment in data centres that can support traffic from other regions in the world, improved localised language or relevant payment types. As you can see, there are several considerations that could influence your prioritisation.

​

All Hands In

Customer support, sales, and other supporting teams are essential partners in building a scalable product. They are your front lines, working with customers who might call in or need help. It’s not enough to build a product that your customers can understand and use. You should consider how your support teams will need to interact with your customers and troubleshoot anything you launch. Setting these teams up for success is equally important to getting your product into the hands of customers. That way, everyone can help create a great experience.

​

Another important element of this relationship is the feedback a product manager can collect from these groups. Being on the front lines, these teams hear everything that’s going well and everything that isn’t: bugs, rough interaction flows, and confusing messaging.

​

Scaling Globally

Scaling globally requires several similar considerations to the considerations of a product manager during the development process. How will our product localise to other markets? Bear in mind, localisation is so much more than just translation. There are several services that can translate languages and even cache common words and phrases to speed up development. However, are these translations the correct usage of local languages for these markets? Tone of voice and how a local would communicate are equally vital aspects to consider. After translation, are the product onboarding experience and directions still customer-centric and effective?

​

Other considerations with global products could be understanding the local expectations for any product, in order for it to be usable. If your product collects payment, will you offer local payment types or credit card only? If messaging integration is part of the experience, will you rely on SMS or integrate with WhatsApp, WeChat, Messenger, Line, or Telegram? All of this will depend on the market.

​

Finally, a product manager needs to take their brand strength in their local market into account. A well-known company in the US may have intrinsic trust with the majority of customers. They therefore won’t need to use trust and confidence messaging around their security and payments. When the same company expands to markets in Asia, they may need to have more explicit explanations. This way, a customer in Thailand can trust this site and provide their personal details with confidence that they’ll receive the product or service as expected.

Your stakeholders will vary based on company size, maturity and industry. However, it’s likely that sales, acquisition marketing, brand marketing, retail, and customer support are all key stakeholders in some form. The company’s leadership, often up to and including the CEO, is closely tied to the products they sell. As a product manager, you’ll commonly interact with the top leadership in a company. You’ll need to be able to articulate your vision and defend your product priorities. That said, anyone internally can be considered a stakeholder if they have an interest in your product and how it will improve the company.

​

Getting the Buy-In

Always be proactive in communications with your stakeholders. Set up demos, roadshows, and meetings to collect feedback on your priorities in the coming months. This way, you’re engaging stakeholders in various forums so that they can better understand and buy into your vision for the product.

​

The ability to tell a story is one of the most crucial skills you should hone as a product manager. Storytelling conveys the problems you think are most important to solve, and builds the empathy for your customers within your stakeholders. Not all stakeholders may agree with your prioritisation of features and development, but if they understand the long-term vision, you’ll earn their buy-in and trust.

​

Alignment with all stakeholders won’t always be achieved or be maintained in the short term, however, buy-in on your long-term vision is important. There are different ways to reach the same long-term outcome. What helps greatly in achieving alignment is focusing the discussion on the outcome and value to customers, instead of disagreements on nuanced short-term decisions.

Building a Business Case for Scaling

A business case for scaling your current product likely touches on the same considerations you’d need to make when deciding which features to prioritise. Building a robust technical solution that can support hyper-growth is hard to size up as an opportunity. It’s almost a risk analysis – what would happen if we can’t scale with our current systems? What is the financial impact if our entire ecosystem went down for 24 hours, or even 60 minutes?

​

An interesting business case with scaling to additional markets is on local payment types. Do your current payment types show a path to growth in all markets or would adding payment types bring additional growth? Even quick napkin math can show how many additional customers a payment type may bring in. Industry data on popularity and usage of various payment types may open you up to untapped markets. Another way to estimate the usage would be to run a non-functional test: show the availability of a payment type, or ask current users if that payment type would impact their purchase decision. You could do this in a live AB test, or through market research.

​

Risks and Opportunities of Scaling

If you are able to build your product with scalability in mind from the beginning, opportunities for growth abound. You could move your performance in a growth market to a mature market, or even enter a new market that can be adapted locally.

​

Oftentimes, a new customer segment can begin using your product, but they may not have been the initial audience your team expected. The great thing about building and shipping products is that there are always surprises: how customers react, and what you learn about a product’s usage.

​

However, there are always risks in extending out your development if you are launching with a complete, already scalable product. Companies typically launch a ‘minimum viable product’ in order to gain valuable feedback from early users that help shape the product, or may even result in a pivot of the experience and solution. In that case, a lot of work could be thrown away if a very scalable, well-built product now needs to be re-thought entirely, because customers aren’t using it.

​

You should weigh these risks with your UX and engineering teams. Together, identify what level of scalability should be included initially, and if a faster solution to market might be more appropriate to prove the product’s value first.

1. Chat With Engineering Teams About Their Ideas

​

Separate from your usual meetings, ask your engineering team about the code and quality right now. Ask a few hypothetical questions around growth in usage, global rollouts or new features to understand the state your product is in, and what would cause problems down the road. Keep these discussions separate so that the team understands that you’re not immediately prioritizing all of these ideas. Rather this helps understand where you collectively stand, and what may help you scale in the future.

​

2. With Designers and the UX team, Audit Your Entire Product Experience

​

The “happy path” is where customers follow our ideal flow – everything works and they don’t get stuck at any point. The “unhappy path” is where things go wrong. Documenting the possible “unhappy” scenarios and how your system can help customers out of them is important. Think about error handling and timeout messaging, for instance.

​

3. Communicate Proactively With Stakeholders

​

When scaling your product, you’ll need to manage key stakeholders’ expectations and keep them informed of your vision. Be proactive about sharing information with them about how your users will benefit from the product, and build a strong business case for scaling. Make sure you’re connecting with them across various forums to get feedback.