Chapter 41: Training: Accidental Entrepreneur (Four Pillars of Products)

“?????? ??????????? ????? ?????????

????????? ???? ??????”. — ??????????? (666)

“If those who have planned (a project or product) possess  firmness (in planning and executing it) they will obtain what

 they have desired as they have desired it”. — Thirukkural (666)

As I learned about building teams and designing products early in my career, I had various opportunities to learn the business aspect of developing products. I have seen people make this process very complicated or have a singular focus on development without understanding the business implications. Based on my childhood experiences with the family business and early engagements with business folks at my first job, I formulated the following four key pillars. These pillars help define and develop successful products both technologically and business-wise. 

(Important) Features: All products have many features. Some of them are key for product usage and others are filler features that keep the product properly working. It is key for developers and project managers to understand and classify the features into these two categories. By identifying these, it helps the team prioritize and execute efficiently. Main product features also help drive the uniqueness of the product and build differentiation with the competitors. 

        Let me give an example of this critical vs good to have product features and how the projects ended up later. Rockwell semiconductor was a dominant player in DSP (Digital Signal Processor) world during the early years of the Internet. They had built a product that was used in nearly all the Modem solutions. Wanting to conquer the world with follow-up products, the team, and architects with minimal input from the customer-facing team came up with a product plan. That project went on for many years with many interactions. We ran into consistent issues due to a lack of clear product definition and urgency or pressure from customers. On the other hand, another parallel team got into to developing a targeted product with clear customer requirements and feature set. I joined that team during the development process, and we executed flawlessly within a year and sold millions of units next few years. This product was used by many cellphone developers to build the first GSM handsets including the South Korean conglomerate. This project gave me so much experience to learn and apply my learnings later at my startups and during my current job as a sales engineer.

Performance: The performance of a product can mean many things. It could be just speed (frequency) or the number of channels it can handle (scale) or how quick the response is received (latency) and more. Understanding the product need of the market and how the competition has their product implemented helps architect the solutions efficiently.

         Another example from early in my career applies can be applied here. When I graduated from Stanford University and was looking for a job, I talked to many engineers in Silicon Valley who were working at large processor companies. While their job was interesting and working on key projects made them feel good. Since the product was already dominating the market, those companies didn’t want to make drastic changes to the architecture. Their changes were incremental. On the other hand, my first job gave me the freedom to explore the design space and make big changes. Using the freedom, I learned to build scalable products without many restrictions and a fresh way of thinking. One such area was for me to achieve the end goal to get scalable products with a small team. We achieved this by knowing what the performance end customer would want and architecting a product to meet that. For example, to handle many users, either we could increase the frequency of the product to insane speed or parallelize the operations and add multiple instances of it. The second approach works in many scenarios where applications could be rewritten to use parallel solutions. Performance is important but it doesn’t always mean increasing speed.

Connection: No product works in a vacuum. Any solution would need to work within an existing framework or need to be designed to work with new interfaces. As a project manager or implementation engineer, it is important to understand the overall environment and where the product fits within that environment. Many of my colleagues were interested in working in the core of the technology which was technologically rewarding. Lack of exposure to the system-level understanding reduced their interactions with customers and customer-facing teams. 

         Since I joined the GSM project late, I was assigned to work on the serial and parallel interfaces which brought in the data for processing and sending back the processed data. That particular area was not very high technology or complex. On the other hand, if it were to not work with other products with a specific protocol, the entire product wouldn’t work. Both importance of the interface and customer-facing interactions gave me so much to learn and apply in the future.

Cost: Finally, all products need to be built within certain expense and the cost or price of the product needs to be reasonable for customers to be able to afford. Knowing these early in the product definition and development gives management to plan the project effectively. In case the development or product cost exceeds end-customer requirements, it allows negotiating or setting the expectations right up front.

         I remember some early negotiations with customers who were buying a product for a set amount. Our product cost was double that amount while providing four times better performance. I, working with the marketing person, articulated the per-channel price actually half of the current solution, and our solution, in addition to cheaper cost, reduce the real estate needed to implement overall solutions, that approach worked like a champ, and we won the customer over. Thinking and articulating TCO (Total Cost of Ownership) would help us and others understand the “value” you bring to the table.

My experiences of articulating value and implementing the right product for identified customers worked every time. I tend to use terminology that’s not a rocket science when people overthink solutions to given problem. Understand critical features, define the required performance, ensure interoperability, and finally, the justifiable cost for customers to pay for the product, it becomes easier to build a company. Yeah, it is not rocket science after all.