Abstracting Complexity as a PM Skill

One of my recent favourite PM interview questions is to pick a technical term that the candidate has thrown around casually while describing their previous experience; and ask them to describe what that means (or how it works) to someone non-technical. Yesterday I had asked a candidate to explain kafka to me, and another to make me understand monoliths vs microservices.

This helps me evaluate three important PM skills (esp Platform PMs) – the ability to abstract out complexity, bring clarity and the ability to communicate it based on the audience. This really tests the candidates mettle in all these three areas. I give them time to compose their ideas and then explain to me.

An added bonus is – you will also know if they are just throwing around tech terms without understanding them. If they are truthful and acknowledge this, I give them another chance to pick any technical (or deep expertise) areas on their own.

My ikigai – Product, People, and Tech

I have been thinking a lot about what gives me energy, what I can contribute to the world, and what will still make me money – in short, what is my ikigai (the Japanese concept about which you can read here). I have realized that the intersection of product, people and technology is what gets me to this state. In this long piece (and it has been a while since I wrote a long piece), I am going to be writing different facets of these three circles that I am excited about. I am writing this primarily for myself, so that I can introspect now, and later (if/when I re-read it). 

Technology: If I go by journey chronology, my journey starts with technology. My PhD in Computer engineering took me down some deep research rabbit holes on how to do high level synthesis of VLSI circuits optimizing on static leakage power. It was a world when techniques to reduce dynamic power (or the power that is consumed when electronic circuits are running) was just saturating, and the research in the field of leakage power (or the power that is ‘leaked’ even when circuits were not being used) was just beginning. If you are old enough, you would remember that feature phones would start dying on you at the end of the day, even if you did not use them at all. My research focused on how to design circuitry to reduce this power – which was super important for portable electronics that was just picking up. Doing research taught me resilience, persistence, and the power of positivity (you get knocked down so many times with paper rejects!). Fun fact – My advisor Dr. Katkoori was a huge shell scripting fan, and it rubbed on to me – my entire MS dissertation was a multi-hundred line csh script 😀

This is how beautiful LaTeX type-set research documents looked like. This is a screenshot from my doctoral dissertation.

Right after my dissertation, I joined Cadence Design Systems, where I continued working on power optimization, but this time on production quality software, which crunched circuits of millions of transistors, with almost every known VLSI design house using our software (Samsung, Sony, Texas Instruments, Broadcom, nvidia, apple, to name a few). After a few years, I moved on to Synopsys, where I worked on synthesis tools for FPGA (think of it as configurable VLSI circuits). The focus in both of these roles was writing high performance and scalable code in C/C++. These complex algorithms synthesized the VLSI designs for the latest and greatest chips of the time (and to this day).

Towards the end, I landed a new charter to create a new group called Reusable Components team, to focus on building high performance libraries for several common components that were being written/used across the dozen odd product lines in Synopsys. This was almost like Technical Product Management (TPM) where there was much to be discovered / negotiated / deployed between large product groups that worked in silos. This was also when I created the TPAC (Technical Publications Advisory Council), where we encouraged, reviewed, and rewarded engineers for submitting patents and technical papers.

This is how CAD tools looked back in the day. I wouldnt be surprised if they look the same now. The code on the left is RTL code in verilog. img src utah.edu

This work in Cadence and Synopsys taught me to write solid high performance code. I learnt the subtle art of managing and working with super bright engineers. It also gave me the attitude that any new technology can be learnt and applied, once you have the fundamentals right.  

Product: My jump into Product was purely accidental. I have been blogging for upwards of 18 years. And circa 2010ish, I started writing about interesting products, businesses, and just ideas that just came into me. I was writing about branding/advertising fails (like the mast-kalandar brand in Bangalore around that time). I wrote about products that the travel industry and the upcoming ecommerce industry should implement. One fine summer evening, when I was driving back from work, in the quintessential traffic of Bangalore, I got a cold call from the CEO of goibibo, who wanted to talk about a series that I had written about standardized budget accommodations in India (this was before Oyo, Treebo, Fab etc). We spoke for an hour about what I had written. I was just happy that someone had read my blog (yay!). The next two days, I spent my time (in traffic) happily talking to two other folks. And a week later, I was offered a leadership position to lead Flights at goibibo. I learnt all about product management in consumer startups, from folks at goibibo, and the community (thank you TPF and headstarters). 

web archive of my blog circa 2005. Note metafilter, lifehacker, lifehack.org etc for all the OG folks of that time.

Startups: And then on, I spent some time in goibibo, stayzilla, shotang, and finally ended up doing what I think was closest to being a founder, without the funding responsibilities (ixigo was our parent company). I created and ran travenues – an aviation SaaS ecommerce platform for close to three years. As a tight high performance team, we created magic. Our first paying customer was SpiceJet and we created their entire ecommerce platform from scratch, and as a fully configurable SaaS product. (This still exists in the form of SG’s current android, iOS, PWA, and desktop apps). With CoVid the aviation industry was hit hard, and our prospect funnel disappeared. We ended up selling our IP to SpiceJet and exiting. 

The full travenues story -> https://x.com/gcmouli/status/1285555910379618305?s=20

Microsoft: I joined Microsoft where I have been doing enterprise grade Product Management for the last three years. I have worked on established products such as Outlook and on ultra-large-scale API platforms such as the exchange mail/calendar APIs. In recent years, I have been working on a 0-1 product called Microsoft Places that is solving for the future of hybrid work. I head product for the scenarios that the India team works on. For the sake of completeness, I should include the two years that I spent at Microsoft in the middle of my Synopsys stint, one year of which was disastrous. Being a PM with the Bing team during the time, when the Yahoo! Team-technology-swap happened, took a toll on me. The negativity and the culture mismatch was unnerving, and I went back to Synopsys.

Tech-friendly: Being a technology person in a product leadership role has helped me significantly. I can understand and speak with Engineers and Engineering Managers in their language, which establishes trust very quickly. It also has the hidden side benefit of being able to get better estimates from engineering teams. This is a boon and a bane. There have been times when I have had to learn to tell myself that as a product person, I need to be more mindful of my outcome and the engineering process should not be my problem.

Design-friendly: I had led design in both Stayzilla and Travenues. This educated me significantly on the differences in mind-set and the creative ways of designers. I got to learn how and what levels of autonomy that designers need to bring out their best, and how to build trust with them to trade-off between tactical vs creative work items.  

We did significant redesigns on the home page and on the search page.

People: I contemplated hard on writing this as the first section, because it is so dear to me, but the flow of how I came to be what I am today would not have been clear, if I had done so. 

Creating, growing, leading, and managing high performance teams. Since my early days, I had been doing this in Cadence, Synopsys, and Microsoft. I interviewed, coordinated interview squads, created hiring processes and the likes. I grew my team in goibibo. With the help of my then boss Pankaj Gupta (ex-twitter and a bunch of other great companies, now with Coinbase), I helped do a full-scale org redesign at Stayzilla. We created pods, assigned appropriate lead PMs, set rigorous standup cadences, ship cycles, and right-sized the PM team. We also had to reset the entire design team. I had to rehire almost the full team and was interim head of design for some time. I also headed the awesome content team. There was so much I learnt from Pankaj during this time. I got a chance to do the pod redesign again at Shotang. 

The rockstar team that created magic. We had so much fun doing that. Thats the whole point.

I was part of hiring the entire travenues team. This team was probably the closest tight knit team that I have ever worked with. We created magic (yes, I am repeating myself, but it was!). I even got to bring in my designer and a front-end lead from Stayzilla into travenues. I learnt so much about communicating effectively, client negotiations, high stakes stakeholder management, and dealing with customers. I learnt pitching to customers and creating relationships in the aviation ecosystem at conferences and other opportunities.   

Cross-geographic / cross-cultural interactions. I derive a lot of energy in working with folks across different cultures and geographies. I have worked very closely with teams from the US, Europe, Singapore, Korea, and Japan. It excites me a lot to get to work with people, understand their culture, and get to know them closely. To this day, I enjoy seeing the joy in people’s faces when I do something close to their culture (eg suffixing my Japanese sales counterpart name with the customer ‘san’ salutation). Given my education in the US, I have, in most cases, been the person who will understand the western culture, and get things done with the mothership. This extends to working with folks from different parts of India as well, of course. My Hindi is a unique blend of street cred Mumbaiyya and  respectful salutations from Delhi.  

Teaching, mentoring and community. I learnt most of my product management from working alongside awesome people in startups and meeting up with other people, through communities like The Product Folks and Headstarters. I love to teach. I have been teaching since graduate school. I participate in a lot of panel discussions, do talks, and attend meet-ups as part of PM communities in Bangalore. I have been meeting interesting people for breakfast (as part of what I call #dosaWithMouli) for the last 8 years. This is an agenda-less breakfast where we discuss the vagaries of our career arcs, how we have learnt what we know, what excites us, and many more things. 

My latest talk – Conducted a storytelling workshop at HSX 2023.

Leading style. Leading and growing people/teams is an integral part of my work identity now. It gives me immense joy, and makes me purposeful. I lead people with a balance of structured outcomes, and friendly trust. Radical candor and transparency is a must in my books. If a team member has to always keep guessing what I am thinking, then things are broken. I strive for this mutual trust, without which either of us cannot stand in for each other. I am strong believer that I do my best work when I am having fun, and I try my best to bring in the same with my team.

Culture. They say leave the best for the last, and culture incidentally has landed here. I am one of the strongest believers that culture is what makes people do 10x impact things. I can write a whole blog post on this, but essentially –  setting up people for success, getting the team working seamlessly together, organic transparency and mutual trust, confidence in the team. Culture builds over time but needs to be nurtured from day zero. Culture cannot be built by going to forced team lunches, or t-shirts. Culture needs to be breathed in every day, every minute, and it cannot be forced. Pragmatically, there might be a minority of people who might not subscribe to everything that I described above, but as long as the collective goodness of the ones steeped in it overrides the people who do not subscribe, it wins. Culture also involves continuously be aware of some people going completely against the grain, and taking efforts to align.


End-note: I had been wanting to write this for a while. Why do I want to write this? I tell this story to a lot of people, and almost all of them have said, I should write it down. There is one other reason – I believed that when I do write this down, it would make me think, and boy, it sure made me think. If you have gotten to this point, I applaud your patience, and the interest that you showed in reading my story and who I am. If we are not connected on Linkedin, please do reach out. I am very active on twitter/x as well.

Empathy and PMs

http://coachfogs.blogspot.in/

I have been thinking about this word for quite a bit of time these days. Whenever I am talking to folks and describing my definition of being a Product Manager – almost every trait distills down to this one word – Empathy.

Now, let me try and recollect and jot them down here –

  1. Stakeholder management – One of the key traits that I believe a PM should have. The cliche’ phrase of PM being the CEO of a product, imho loosely translates to this. Unless you are empathetic to the various parties (product, tech, marketing, operations, leadership, …), you will not be able to get them on to the same page. You need to empathetic to the tech team as to why they are resisting a decision ~ perhaps this would involve tossing out a lot of code that they just wrote; you need to understand how they feel. You need to be empathetic to the operations team ~ perhaps they are short staffed during a certain time and they cannot handle so many escalations. You need to feel this issue. And so on.
  2. Customer empathy – this is a given. A PM should be the biggest voice of the customer within the company. This might be a bit contrary to the first point, but customer empathy trumps empathy within the teams. You do not care if code needs to be rewritten, or more support staff needs to be hired, but if the customer experience is affected, it is unacceptable.
  3. Strategy Roadmapping  – this is empathy at a different plane. A product leader needs to sense the emotions of the founding/executive team and the investors (if any), to see what would deliver the best RoI for these stakeholders. Too aggressive a roadmap might seem awesome to the investors, but not to the leadership team, but too sluggish a roadmap might make the investors lose confidence. This is extremely important. This is in most cases unspoken and very subtle.
  4. Project Management – lets face it. This is a part of a Product Managers job ~ in varying degrees depending on the org. Good PMs exhibit a bias towards action(shipping) and make a dent here. While strategy/road-mapping is part of steering the ship, project management is choreographing the drum-beat of releases. You cannot do either of these without a deep sense of empathy to the executors.

And for those who are wondering if empathy is a key trait only for PMs, nope, check out Rand Fishkin’s blog where he says –

The best skill I’ve developed and the one that’s served me best as a founder, a CEO, and a marketer is empathy.

I offer coaching/training on PM empathy. If interested, please ping me on gcmouli at gmail.

 

Demo day at Shotang

Earlier this month, we, at Shotang, held our first demo day. It was a Friday afternoon event on our terrace. We could not have had better weather that day. The intent of this event is to showcase the technology and the product that is being built to enable the first large scale retail distribution platform. This would hence enable all the functions of the Shotang family to literally play with the product and gain a deeper understanding.

This was driven by the awesome product team at Shotang, ably supported by the equally awesome tech team. The product team coined a name for the demo day as well – Shotgun. We ran with a Wild West theme through the communications.

This being the first demo day, the event focused on the journey of an order on the Shotang platform. We wanted everyone to experience the full flow – from the retailer placing an order through the Shotang retailer app, to how it flows through the seller dashboard ecosystem, and the falcon logistics apps, which powers our pickers and the delivery executives.

We had set up POD stations on the terrace – one each for the retailer experience, seller experience, and the logistics platform. Engineers and PMs manned these booths and explained the flows with pride. There was a complete test bed that had been created on a test city, where guests could place orders, and trace their order through the entire platform.

It so happens that in a company such as Shotang, day to day agility forces each function in the company to focus deeply on their own domains. For example, the corporate finance team spends its waking days poring over the sales and spends numbers, but often do not get enough visibility into the actual product. Similarly for other teams such as our customer delight team, our commercial finance team, alliances team, and so on.

What did we get out of this?

  • Singular pride for each PM and engineer who showcased the products that they develop. You should have seen the energy on the floor.
  • Zonal leaders (P&L owners) from each of the 7 cities that we are live in, got insights into what is the current state of product and tech, and what is in store for the future.
  • Greater visibility on the amount of tech that goes in to developing our platform
  • Increased empathy for our end customer and what she goes through.
  • So much feedback that came in from non-tech folks on improvements that could be made with respect to user interfaces.

Moving forward:

We intend to have a Shotgun event every month. Product and tech developments since the previous month would be demonstrated. We would sync the event to the monthly planning meeting of the Zonal managers. We anticipate that the local field leaders and the zonal leaders would take back to their respective field teams, the latest developments and future plans.

At the end of the day, It is also a fun event, where we celebrate all the hard work that has gone in, to do, what we all love doing – ship!