Accidental Entrepreneur: 10 Points to Consider When Building Scalable Products
Hi Everyone,
Welcome to my 33rd weekly article as this week is called “10 Points To Consider When Building Scalable Products”.
In this article, I go over key concepts to build products that can succeed at scale.
Also be sure to check out my Youtube channel for this week’s vlog.
Feel free share with friends/family that would get value out of this type of content.
My goal is to be able empower folks to go after their goals and reach their full potential!
“எண்ணித் துணிக கருமம் துணிந்தபின்
எண்ணுவம் என்பது இழுக்கு” (467)
“Every plan of action should follow a well considered decision made after examining all aspects of the problem, and analyzing possible solutions, and finally arriving at the best solution possible, under the circumstances.” (Thirukkural 467)
Last week I had an opportunity to share my experience with a multinational startup on how to think from the beginning to build products that can scale. This topic is close to my heart as I have built multiple products for enterprise markets that were successfully executed and qualified for major enterprise customers. I went back and reviewed the team & my mindset during early planning and later during implementation time and finally brought it to market. The following ten points stood out.
- Build From Foundation: Foundational knowledge comes from two areas. First one is having team members with good theoretical knowledge and education to solve problems. Second one is understanding the market or customer problem and being able to dissect the problem to provide solutions which make sense to the customer that cna be built with minimal resistance.
As an example, at our first company we built a VoIP (Voice over Internet Protocol) product. The foundation for the VoIP product is Digital Signal Processing (DSP) which was the education of three of the founders and two of my co-founders had PhD in the area.
2. Tear Down to Foundation: As the problem is understood and torn down to foundational principles, it’s easier to solve the problem creatively by using simpler approaches. In addition, when a person encounters issues, it’s easier to go down to the foundational level and troubleshoot the issues.
During one of the projects, we ran into some quality issues when we had to build at scale. The product was working fine at small numbers of production. I assembled a team of key engineers, as we went back and broke down to foundational units. We then identified the areas which were done correctly and areas where there were some doubts. This allowed us to go after smaller areas to focus and solve the specific problem. This helped us find the root cause within a few months vs it could have taken many quarters and brought down the entire company.
3. Less is More: In software projects there is a saying that the “best code is the code never written” or in the hardware world we say that “The best component is the component never used”.
Once we ran into a major quality issue with one of the blocks of design in our company. We were getting so many issues and the design kept patching with additional code. After a while, one of the engineers suggested that he would take the design and rewrite it in simpler form in a few weeks. That was the best decision we ever made which helped us reduce time and resources.
4. Document, Document, Document: People tend to think that when they work at a startup, coding and building a product is enough. This is a completely wrong mindset. It is important to have “enough relevant” documentation to back track and analyze the results. These documentation should be very much targeted and concise.
I remember one scenario where one engineer who was resistant to documenting his work kept telling us to trust his work and not to worry about it. We ran into a key issue and he wasn’t around to analyze the problem. It took us weeks to just understand his code and resolve the problem. Since then I don’t excuse anyone from creating basic documents.
5. Review Often and Refine the Approach: At the beginning of a project, everything starts with the best estimate and whatever is known at that point. It is important, as the project moves forward, to review and refine the next steps.
People always talk about the success of my companies, yet what they don’t understand is how many small mistakes we made and corrected. Sooner we identify the mistakes and make corrective actions to help reduce the development cost and time to market. This is one of the areas I pride myself in. It doesn’t mean that I had all the answers but I used experts and peer reviews to catch these mistakes early and course correct sooner.
6. Scale in mind from Beginning: When planning for resources and time, it is important to understand the potential size of the market and product volume. Knowing the scale of the product and reliability requirements, provides managers/technical leads with clear goals.
In enterprise markets, when products are deployed, it is important that products have uptime and are error free most of the time. It is measured in terms of number of nines in reliability terms, for example enterprise level products need to meet a minimum 6 nines (99.9999%) quality matrix. Having people with this kind of experience and planning for qualification at this scale is key for success.
7. Systematic Releases: At startups or large companies, there are always some kind of limitations; It could be resources or time or market window. On the other hand, product managers and customers would need all the features. It is important to build the framework such a way that a product can be launched with minimal required features, commonly known as MVP (Minimum Viable Product), and incrementally add additional features as the market feedback comes back.
8. Multi Source Components/Libraries: On a small scale, we can beg and borrow components from suppliers. When it becomes a qualified product for large enterprises, the first thing the procurement team looks for is the material sourcing. The reason for that is that one component can stop a company from producing the entire product. As for libraries or code, it is important to use code which is matured and well tested. Thinking about this from the beginning would reduce the heartache when ready to produce at scale.
9. Quality over Complexity: Many tend to think that having a complex solution is “cool” and prevents others from entering the market. From my experience, it is great to solve complex problems, but the solution needs to be simple. I wrote about this on one of my earlier articles, KISS (Keep it Simple, Stupid). I have worked with people who want to solve issues with complex algorithms and complex equations. At the end of the day, we were building a business and wanted to sell millions of it. Here is where quality overtakes complexity any day.
10. Debuggability vs Compaction: Code can be written very tightly with convoluted statements. These would work great most of the time. When a product is deployed on a large scale, due to various environmental factors, the product might fail. At that time, debugging the code in a production environment is not easy. This is where I tend to focus on the projects. By adding enough debug capabilities and writing codes which can be easily analyzed help overcome product issues.
These are my ten major considerations for developers and mid level managers and technical leads to consider when building a product for scale. Having these thoughts from the beginning and continuing to validate these points would help overcome unforeseen issues quicker. I am a sucker for meaningful processes, continuous validation/checking and quality product development. This reduces unnecessary stress and scalable results every time.
Thank you everyone for the continued support on this journey, & in order to improve the content I have out together a brief survey with a couple questions that shouldn’t take up more than a couple minutes.
