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.