Why Building Great Product Demands More Than Just Technical Chops Conversation With Akshay Rana

When I look back on my journey, it looks like a mix of both, a series of fortunate pivots and a bit of planned journey.

One of the most fortunate pivots happened early on in this journey during my undergrad. I initially enrolled into Industrial engineering, and I was quite happy with the choice, since at the time my interest was more towards building tangible products than digital ones. The first semester of engineering allowed us to take up subjects across different streams, and it was only later when I scored high marks in computer science, I felt I had a knack for the subject and even enjoyed building digital products. I was fortunate that I got a chance before my second semester to change my engineering stream and I ended up joining computer engineering. This was the most fortunate pivot that ended up changing the entire trajectory of my career.

While I was completing my undergrad, I had three wishes that I wanted to fulfill as part of my professional career. First, I was quite inspired by Steve jobs and hence wanted to try out entrepreneurship and start my own venture. Second, I learnt about the role of a product manager which was still in its nascence and loved the challenge of figuring out how to make digital products work. I wanted to go down that road and learn how to build successful products. Third, I wanted to round out my overall business acumen and wanted to pursue an MBA. I had these three professional wishes at the time I completed my undergrad but my challenge was I wasn’t sure in what order these milestones would be achieved. And now when I look back, I see I ended up fulfilling all three of my wishes but not in the order that I would have expected.

After a brief stint helping a startup in operations and then joining TCS, I jumped headlong into building my own startup. I had a 1.5 year journey of testing, building, pivoting, and learning which formed the basis of my professional personality. I did not end up building a successful multi-million valuation startup but I wore many hats, learnt while doing, and perceived the world from such close proximity that is difficult to experience while being employed. I learnt that the only foundation for any successful business is building products that people want, and there are no shortcuts to finding product market fit.

This experience prepared me for the next leg of my professional career, when I fulfilled my second wish and joined a vehicle rental startup in Bangalore as a product manager. I could clearly see how my experience as a startup founder helped differentiate me from other PMs on the team, as I never hesitated to get my hands dirty, and go on the ground to discover problems and speak to our users. I continued to build on this skill throughout my career as a PM with that startup and later with a Fortune 50 retailer, before I finally decided to pursue an MBA and move to the UK, to fulfill my third wish. I had a plethora of professional experience by this time which helped me during my one year MBA programme, and then after completing the MBA I decided to continue building on my foundation as a PM by joining a global SaaS company in London.

So as you can see, I’ve had a series of fortunate pivots, with a bit of planning but I am only able to connect the dots looking backwards.

The trick to staying technically credible with engineering teams across distinct domains is to not pretend to be an expert in those domains, and have a learning mindset while speaking with engineers and domain experts on your teams. My background as a computer engineer allows me to grasp technical details at an abstract level and translate it into simpler language that helps connect the dots between technical architecture and its business utility. Also, being a PM you are in a unique position where on one side you are speaking with people who are highly technical but find it difficult to translate the utility of their work for overall business, and on the other side speaking with business leaders, customer executives, and other departments who are in touch with the day to day aspect of running the business and find it difficult to understand how technical work connects to what they are doing. As a PM, it is important for me to keep this big picture in mind, while interacting with any team member and adjusting my communication style.

With regards to specific domain knowledge, I believe it is now easier than ever to grasp high level working details for any domain with different LLMs. Earlier you had to rely on finding papers and credible documents and spend a long time scanning through them, but today you can get all that done in a short amount of time and in a more structured way by asking the right questions to LLMs, and staying curious. The one thing to always keep in mind as a PM, is that my job is not to have an expert level knowledge about each domain, but enough knowledge to have an informed discussion with different stakeholders, which allows me to grasp the limitations and possibilities from technical aspect, and also, best practices, and guidelines from the domain knowledge perspective.

I focus on the following three things whenever I shift domains and am required to ramp up quickly - Problems, People and Processes.

Problems relate to grasping the top customer problems that product is trying to solve for, and also ongoing issues that users face while using the product. It is important to get a quick grasp on these so that everything else can be oriented around the stuff that really matters.

The process aspect relates to gaining domain knowledge, where my priority is to go breadth first instead of going in-depth at the beginning. You perform competitor analysis, read papers and news about the domain, and try to form a mental model of how your product fits into the overall domain. I also try to get an understanding of the internal processes followed within the company to extract maximum knowledge of how product development processes are followed in this specific domain. What I’ve realised is that product management process mostly remains the same, but you need to tweak how it is implemented based on different domains, and the priority often changes based on different domains, like in cybersecurity, adding friction can be a tool, whereas in SaaS onboarding, removing friction is what is preferred.

The people aspect is often the most under-appreciated part when we are joining a new product domain. We often schedule 1:1 and introductory calls which end up becoming a general chat about people’s background. But I’ve realised that besides forming those strong early connections at the human level, you can also utilise these conversations to learn what different people in the organisation know about the domain, so that you have a mental model of how much knowledge different people carry. An example would be, customer executives often have a lot of information about customer problems, and also have a lot of domain knowledge which can be useful for a new PM during onboarding. Hence having those conversations with different team members becomes really important.

Finally, having shifted across different domains, I’ve realised that it is often not lack of domain knowledge that hampers people in performing well in the PM role. While following the information trail within the company and outside, you start connecting dots at a larger level, which is what is often missing for people in different departments, and then as PM you apply your PM processes on top of it, to enable effective product delivery, irrespective what domain you are working within.

The setups have both similarities and differences.

First, the similarities are that both require the PM to actively manage communication across stakeholders, and keep on top of the product roadmap. Even if it stays the same for quarter and year (Fortune 50), versus getting changed in near term (small SaaS), the PM needs to communicate consistently and keep everyone updated. Another similarity is the focus on execution and delivery is required in both the setups. While in an ideal world a PM would not have to be involved in execution, the reality is that since the PM is responsible for the outcomes, oftentimes it falls on the PM to keep track of the delivery and push the teams to actively remove blockers and keep things moving. This happens in both Fortune 50 and SaaS.

Now, the differences are in terms of resources you have available to make something happen. For e.g. I had an entire legal department in Fortune 50, and different domain experts whom I could rely on for a second opinion. Whereas in a small SaaS setup, you are yourself responsible and oftentimes while you are researching you become the most knowledgeable person in the room.

Another clear difference as a company size grows bigger is that product domain becomes extremely compartmentalized, and PM ends up owning a smaller part of a user journey. I’ve seen work getting planned ahead for next quarters, and year in Fortune 50 compared to SaaS, where I’ve seen plans being more flexible and getting moved more.

I feel both the setups are demanding in their own right. I am personally inclined towards working on a fast paced setup which is easier to find in a smaller SaaS company, as compared to larger companies where there can be a lack of flexibility and maneuverability.

From where I sit, I see AI is increasingly becoming more and more ingrained in our day to day work, but it has its pros and cons.

Some of the positive aspects of AI usage are that a lot of context that used to stay behind confluence docs and was siloed across different platforms, is now much more easily accessible to everyone on the team. What this has resulted is people starting to make more informed decisions. Earlier it used to take a lot of time for research, or customer executives depended on PMs to provide technical context, but now they are able to get that directly from apps like dust, that consolidate information from different parts of the company, including docs, messaging platforms, code, etc. One caveat is that there is a possibility of these systems hallucinating, so common sense is much more important now more than before to validate before any such information is shared publicly or used to make critical decisions.

One of the biggest negative impacts that I’ve seen in product work due to AI, is there is a shift happening towards focusing on quantity of work versus quality of work. PMs are increasingly churning out multiple PRDs, but sometimes at the expense of basic common sense. Instead of simplifying complexity for everyone, AI generated documents are adding more complexity with their smart-sounding gibberish, and multiple versions of the document that are hard to read. Also, one of the core skills of a PM was to read and get clarity, but now a lot of PMs are relying on AI generated summaries and building their entire product thinking on the basis of that. This is just resulting in more lazy thinking.

Also, the pressure to integrate AI in the workflow is not only intrinsic but often driven by leadership teams. The expectation is increasingly becoming that people are supposed to put out more work, but there are few leaders who are actually interested in verifying the quality of the work. Another issue is with PMs who are treating vibe coded softwares as production ready apps are causing more harm than good for the product. It creates a false sense of completion in front of the leadership who believe that they can click through the prototype so it is not too far off from delivery. From a design perspective, these PMs are skipping the design and customer validation steps and directly sending these prototypes to engineering teams to develop. All these issues are resulting in poor products being churned out, which I am calling ‘Slopware’, and basically turning the users as testers who are finding bugs and issues with the production code.

Overall, I feel AI has a huge potential to aid product workflows, but the first principles of product management still remain the same. A good PM will be able to super charge their delivery while still retaining the core thinking part and ensuring everything is well through. A poor PM can easily outsource all these decisions to an LLM, and then the entire company suffers due to their lazy thinking.

I strongly believe India is already leading at a global level in terms of product thinking. I increasingly see a lot of people from Indian and South-east Asian backgrounds doing incredible product work at a global stage.

Having said that, as a Product Manager from India, I frequently observe how our country's high power distance and strong hierarchical culture shape how we behave in organizations, especially in front of people with authority. A common pattern that I’ve seen across PMs from this region is that they often find it difficult to push back against people in authority or in teams of mixed races and cultures. Pushing back is an important skill for a PM, and our Indian culture programs us to subdue this part of our personality. Hence, overcoming this habit was one of the biggest challenges that PMs from India could face, and something that I’ve also faced myself during my early career.

Another thing that PMs from India need to keep in mind, is to keep questioning things from a common sense perspective, and not abandon it by relying too heavily on AI systems to do this on their behalf. We are great at adopting new systems and processes, but it should not come at the expense of losing product thinking, which I believe is more important in today’s world than ever before.

The convergence of creator economy, enterprise SaaS, and AI tooling in the near term is resulting in early adopters creating their own automated workflows that replace certain SaaS tools partially or fully. I am increasingly seeing examples of not so technical people starting to use tools like Claude to build their own custom automations. In the next five years I believe this trend is only going to expand, as coding becomes simpler and the cost of paying for SaaS tools versus creating these tools inhouse gets balanced out. Some critical functionals like payments might still remain in the hands of SaaS providers, but any less critical functionality is at the risk of being coded away internally by users.

Now a second order effect of this is that even though people are able to create these automations internally, the burden of keeping them up to date and support would fall on people themselves. Today when you purchase a SaaS tool, you also get support and an implicit expectation that new updates will keep on trickling down, but when this is replaced by inhouse developed softwares, the burden of support and upkeep would also fall on the individuals and companies themselves. I see this becoming a massive challenge in the next 5 years and would require a reimagining of how software is treated within the companies where they may need to account for separate infrastructure and costs to maintain such inhouse softwares, if this ends up becoming a more widely accepted phenomenon.