Back to resources

Understanding a Product Domain

Personal Growth
Impact
Coaching / Training / Mentorship

4 June, 2021

Sailendra Kumar
Sailendra Kumar

Vice President - Product Management & Design at IndeedFlex ( Indeed.com)

Sailendra Kumar, VP Product Management & Design at IndeedFlex, recalls being promoted into a new role that required a significant domain knowledge he was yet to acquire.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

I was passed for Promotion. What now ?

26 January

Passing for promotion happens to everyone in their career lifespan. If someone does not had to go through the situation, consider them they are unique and blessed. Managing disappointment and handling situations in professional setting when things don’t pan out, is an important life skill.

Changing A Company
Handling Promotion
Feelings Aside
Feedback
Coaching / Training / Mentorship
Fairness
Career Path
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

The art of Happiness

20 January

Happiness is a choice. Our upbringing and the surroundings have made it conditional. The first step is to get over the hump is self-awareness. Self-awareness is a journey by itself. The ability to identify what we can control, and we can’t is important.

Personal Growth
Career Path
Health / Stress / Burn-Out
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Software Development as a Martial Art

6 December

There is a life philosophy in Jiu-Jitsu that resonates with me as a software engineer; Jiu-Jitsu is all about solving problems - the ultimate goal is learning.

Coaching / Training / Mentorship
Sanjin Celeski

Sanjin Celeski

Engineering Manager at Banque Saudi Fransi

How I failed at my startup

14 October

There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Mission / Vision / Charter
Scaling Team
Building A Team
Impact
Strategy
Prioritization
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

High Performance Team in Action

13 October

A high performance team refers to “ a group of goal-focused individuals with specialized expertise and complementary skills who collaborate, innovate and produce consistently superior results.”

Managing Expectations
Building A Team
Company Culture
Feedback
Coaching / Training / Mentorship
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan