Imposter syndrome and Product Management

For PMs, chasing numbers and metrics becomes second nature. The absence of a method to quantify one’s competence thus becomes a cause of cognitive dissonance. Your actual abilities (competence) and your perception/awareness of these abilities (manifested via confidence) rarely display a linear correlation.

The Dunning Kruger effect (refer diagram) explains this dissonance in a very easy to understand manner. Knowledge of this curve has kept me humble while at the peak of Mount Stupid and has often helped me persevere through the rut of the Valley of Despair.

Stay in the Valley of Despair long enough — and you risk the danger of “Imposter Syndrome” creeping in. My goal with this post is for my future self to avoid falling victim to imposter syndrome, and to have a list of observed best practices and tenets to find my way out.

1: Acknowledge you’re in a rut and open up

This past year at Flipkart was a great learning opportunity from seasoned Product Managers who tackle tough and easy problems alike. No two days in the job are similar, and there exists no playbook for anyone. Yet, everyone seems to deliver consistently while having a level head and an accurate grasp of their abilities. It can get intimidating to open up about your failures when you’re in such company.

I distinctly remember my first time in the valley of despair and being pulled out of it by my manager Chidambar Kulkarni. He pointed out the survivorship bias in what I saw — only the good things — and how the errors and missteps of others aren’t discussed as much. All the seemingly impeccable PMs are prone to their fair share of mistakes. Even our bosses.

In a parallel universe with unapproachable peers/seniors, I would have dwelled on my mistake longer instead of focusing on learning from it. Inching towards imposter syndrome instead of the slope of enlightenment.

2: Identify the output variables

While it may be difficult to articulate a traditional objective function, penning down the desired improvement you want to see in yourself is a great step to becoming more competent. Your inner monologue instead of “I suck” becomes “I suck at XYZ.”

These output variables could be tactical and change over time. But at any moment, you should have a goal you are trying to get better at. Some standards my peers inspired me to chase were:

• talk about systems and design choices with authority
• to be the de facto person people turn to when there’s a bug
• converge discussions when the room is too scattered
• to be a more vocal source of ideas

3: Account for the input variables

While each output variable will have a different set of input variables mapped to it, I find that most of them fall into one of four buckets. Here I try to spell out certain tenets that I have seen the best PMs follow within these domains. Sticking to these core principles will ensure smooth translation from input to output.

Product thinking

• Always start from the user. As a PM, the core value you bring is knowledge of the user. Their preference, their taste, their pain points, and their aspirations. If you want to build credibility in any room, talk about the user. In any engineering discussion, you may not add any technical insights, but if you can call out how users would interact with the product, you will certainly influence technical choices and discussions.

While talking about User, you can talk about any of these:

User behavior

Suboptimal experience

Competitors

Scarcity/surplus of any resource (eg. attention, time, money)

• Focusing on the “Why” is what makes a great PM. Spend ample time in the problem space to unearth more perspectives and pain points. No part of the solution (aka the “What”) should ever come as a surprise. Everything should flow from and tie back to the “Why.”
• Always double-triple check your hunches and hypothesis with data. Knowing the macro-level metrics (DAU, CTR, CVR, GMV, etc) should enable you to do back of the envelope calculations.
• Problem-solving is a subset of Product Thinking. However, all the frameworks you learn in B-School get tossed out in the real world. Be comfortable on the whiteboard and structure custom frameworks for each problem with the help of people in the room. It’s okay to act like a facilitator.

Execution

• Always be on top of your calendar. End each day by running through the next day’s calendar — anticipate problems and prioritize, plan, and solve them before they surface.
• Over-communicate. Even if you were in discussion with people you meet multiple times a day every day, it’s a great practice to keep everyone in the loop. Something I picked from Mihir Shah from my team is to send out detailed MoMs immediately after meetings — when the context is fresh in everyone’s minds, and any discrepancies can be called out then and there.
• Be the biggest bug basher of your product. Anmol Srivastava from our team would constantly post screenshots of bugs and issues. This keeps issues from snowballing — and keeps everyone on their toes.
• For big meetings, identify the disruptors and get alignment with them (eg. show them the deck!) before the meeting. This helps prevent tangential discussions. Another good practice for big meetings is to leave the room with a catchy elevator pitch type summary so that everyone’s on the same page.

Leadership

• Be willing to have tough conversations just when the issues arise. My boss Amit Velingkar will go out of his way to help you in your personal and professional development, but would also always be the first person to round you up and call you out on any issues. There’s a fine line between being your friend and being your manager. Having these tough conversations helps create the right atmosphere for a team.
• Spend a lot of time with your team. It could be as simple as grabbing lunch/chai together every day or be a recurring time slot on your calendar to discuss problems and progress. Taking an interest in routine activities of your team members helps foster relationships and opens windows for feedback and interesting conversation. This was something I picked from Devansh Jain — how to be informal, but with a check.
• When delegating, it’s always great to talk about the big picture and how the particular task is going to add to the common goal. If it is a task where the person fails, don’t rush to solve it for them. Instead, find the reason it didn’t work out — be patient and let people learn from their mistakes. Shankar Indrakanti and I worked together on a lot of projects together and the way he seamlessly divided tasks was motivating and made me want to do his trust justice.
• Protect your team. Always! Protect their time; don’t take up throwaway work. Empower and enable them to be bold and take decisions. When things don’t work out, step in at the right moment, and intervene as necessary. This attitude exemplified by Varun Sharma is something that has left a mark on me.

Domain and Tech

Since my learnings in this bucket were about the niche of Recommendations, I shall leave out this part. However, there was a very astute remark made by Vikram Sharma from our team that I would want to keep as a broad tenet here:

• Knowledge is power. But you don’t always need power to get work done. You can also work with trust (the same way you trust your Doctor). Find ways to make your team trust you.

4: Put it in practice

The beautiful thing about these competencies is how they flow into each other. Getting better at Product Thinking will enable you to ask tough questions and learn about your Domain & Tech better. Knowing both the user and your domain would make you a better leader. Which would, in turn, mean that you will be able to execute things smoother. When you execute more, it opens up space to learn more from the feedback and get better at Product thinking again. And so the cycle goes on.

5: Seek constant feedback

Once you put things in motion, it is critical to keep an eye out for where things aren’t hitting the mark. The way to do that is to actively seek feedback and take on every challenge as a learning opportunity.

This feedback cycle is also very useful for seasoned PMs. Over time, they develop extraordinary abilities that may come off as intimidating to someone early in their career. They may also trivialize problems that seem easy to them. Keeping a pulse on the team’s confidence and competence levels will foster a culture of development and learning.

Concluding thoughts

“Imposter Syndrome” is a recurrent theme in my conversations with PMs across the industry. At different stages of their careers, in different domains, I have found people grappling with this topic. Hopefully, there was some takeaway for you even if you haven’t had this thought yet. And if that’s the case, is it possible that you aren’t getting out of your comfort zone enough?

This entire post is a compilation of things I have learned from the Flipkart folks around me. I am grateful for their mentorship and guidance that helped me gain confidence in my time as a Product Manager here.