Understanding a Product Domain

Problem

A couple of years ago, I worked for an online travel company where I led the portfolio for online air products. One day I was approached by the CPO who told me that they were looking for a product leader for the platform. The platform consisted of consumer payments, data products, data science, analytics, and business intelligence for the entire company.

At that time, I had zero knowledge about payments. I had some understanding of data analysis, pivot tables, and SQL, but I didn’t know much about data science nor what data science products looked like. I was somewhat taken by surprise and asked my boss why they thought I would be the right fit for the role? As I learned, they thought that my structured way of thinking and ability to deep dive into any topic would make me an ideal fit for the role.

Actions taken

I took upon a challenge. Whenever I approach a new problem, I break it down into three pieces: people, processes, and product. Looking into these three pieces, I asked myself if I had sufficient knowledge to tackle any of them. Well, not at that moment, for sure. I knew I had to upgrade myself in a short period of time, no longer than a month or a month and a half.

The first thing I did was to define areas of work. I identified and delineated three large areas: the entire payments product team, the entire data products team, and BI & Analytics. Frankly, I knew so little about each of those areas. Payments are such a vast domain, and it is impossible to digest it within a three-hour-long course. My first go-to person was the current CTO, who I asked to help me understand essentials. He explained some core concepts such as three- or four-party models in a rather superficial way. Then I went to a PM for the payments product team, asking the same questions. They went a bit deeper, explaining multiple parties in the ecosystem, payment providers, different payment methods, etc.

However, that didn’t satisfy my curiosity. I knew I had to understand the domain more profoundly. Therefore, I visited one of the payment gateway providers located in India and arranged to stay in their office every day for three hours for the whole week. Their account manager was kind enough to schedule meetings with different parts of their business, and I had an opportunity to interview them, learning the ins and outs of the domain. I knew that if I couldn’t understand their business, I wouldn’t be able to build products for my users back in the UK.

By the end of the third week, I was able to understand what a good payment product should look like from a user’s point of view. I was also going through all the available user research documents to be able to understand what users required and how things looked from a backend standpoint. I had to marry these two perspectives and create a reliable and robust user-faced product.

I took the same approach to learn about data science. First, I enrolled in the core data science course, which was a coding course in Python. Though I was a product leader, I wanted to be hands-on. The course was meant to last three months, but I would spend six to seven hours every day after my office hours to complete it within a month. I was so curious to learn how the internals of data science and data products looked like that I didn’t mind working extra hours.

Becoming competent in the new domain allowed me to lead the team with confidence. I was able to understand the user's pain points and what kind of products could help solve those. I knew that if I couldn’t grasp, as a product leader, how a product is being built, I wouldn’t be able to solve user problems. Also, as a product leader, I was responsible for coaching, asking the right questions to the people -- PMs and others -- working on the team, and I wouldn't be able to do so if I didn't know the ins and outs of the domain. Finally, I am a curious person always on the lookout to learn something new. I am continuously learning, and that brings enormous joy in my life.

Lessons learned

• As a product leader, you shouldn’t approach problems at the surface level. You need to be competent and thoroughly familiar with all aspects of the domain to understand what your peers, reports, and engineers should be doing. If you are passionate about your work, you will be inspired to learn more and scratch things beyond the surface. You can’t remain at the surface and create an impact at the same time. To create an impact, you need to be passionate.
• Understand your strengths and weaknesses upfront. I knew my main strength was my ability to tackle any problem because I am driven by an insatiable thirst for knowledge. My mind is always open, open to learn and unlearn. Learning is a continuous effort that means constant upgrading and personal transformation.