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.