The First 30 Days

You realize this is nothing like what is written in most of the product management books

The first few days as a product manager can be really hard because you don’t know what exactly are you supposed to do, and the only reference you have is other PMs in your team. Likely, you won’t get to work on a product in the first 30 days.

So what should you do in these 30 days?

1. Understand the product. Here, horizontal knowledge is more helpful than vertical.
2. Spend time with fellow PMs, understand what they do; soon you may be collaborating!
3. Understand how the product team operates and what are the processes followed- E.g. How are sprints planned? What prioritization method is followed? How does the product life cycle look like?.
4. If you know what area you would be working on, start spending time with all the stakeholders and try to understand how they feel about the existing product.

The Next 30 Days

Working on your first product as a PM can be overwhelming

You may slip up initially but eventually, you can lessen that by asking the right questions, being more observant, getting well versed with the processes, and structuring your thought process.

How to make sure to do a good job while working on your first product?

1. Don’t judge too early- You might have immediate suggestions. Thoughts like why wasn’t this feature built earlier might come across your mind. Interrupt yourself there and try to understand the history of the product and why it has progressed in a certain way.
2. Revisit your thoughts every day- Initially, it may be hard to ask the right questions (Honestly, it will always be hard). However, you can get better at it. Run through your thoughts and try to understand the whys, whats, hows, and that’s when questions will start flooding into your mind. Eventually, you’ll be able to do this in realtime
3. Understand what can be measured- Data shouldn’t be used to back your product. That would imply confirmation bias towards the product. Data should be used as an illuminator to understand what should we build or what went wrong in what we built. “Which is that one data point that will shoot your own idea?” This is a critical thing that I learned from my Manager at Bounce. You can read an article on a talk he gave on How to build a culture of data-led decisions. Trust me, this will change your way of thinking about data!
4. Don’t be afraid to make mistakes or to accept them. You can’t escape from either! You have to acknowledge your mistakes to get better and honor the person who pointed it out. The benefit of receiving critical feedback in the early days of career is very huge
5. Take help from other PMs- They already know the dynamics within the team and across teams. Little guidance and some perspective does no harm.

What did the next 10 months teach me?

1. There is nothing called over-communication

It’s okay to repeat the same thing you’ve told earlier instead of assuming that your stakeholders would know. What we often feel is over-communication is the optimum amount. The chances of retaining the information also increase when you’ve repeated it multiple times

Consistency is very important while communicating. Try to develop a pattern that others can acknowledge well. Here, communicating cyclically and in a particular format helps. Documenting everything on the go and keeping it handy is an efficient approach to share information whenever required.

This approach helped when we had made a complex logic change which would decide how often and when we ask users to fill the NPS survey. I had multiple people across the company enquiring about it since NPS data is consumed by various teams. Having the logic well documented helped as I could share the same document every time someone wanted to understand how we collected NPS scores

Communicating necessarily doesn’t have to be a formal, concise email but casually catching up with your stakeholders, say over lunch, and making sure that they are aligned with you is important. Often PMs don’t succeed in communicating well when they are not comfortable with their responsibility. If you have clarity in your mind you should be able to propagate it to every stakeholder.

The relevance of communication increases with an increase in team sizes.

What about chances of miscommunication or ‘There is a communication gap’?

You’ve to do the job of making sure everyone who makes a call has the same understanding of what you have communicated.

While the above points may not be prevalent if you work in a small team (<50) it is always good to learn this early in career.

2. Colleagues who question you hard can shape your career

It is important to build a culture where people challenge each other’s ideas vigorously. As PM one should set up the environment comfortable enough for the engineer or any stakeholder to freely push back and speak up about vital ideas and problems. Engaging in open and intense debates helps one identify flaws in the approach and accommodate different point of views

You get better at asking questions by being questioned hard. Good questions trigger critical thought processes that help you act better.

3. Accepting Responsibility

Anyone and everyone can be a bystander but you.

You have to be the facilitator to support everyone so that they do their best. This means you would have to take responsibility and dive into each of the domains to some extent. You can’t be a watcher or instructor from outside. While all teams like design and engineering work independently yet you have a significant share of responsibility towards each of them to make sure they can do the right things at the right time with ease. Remove dependencies and unblock them as much as possible.

When you accept responsibilities with comfort, you earn your team’s trust. They find you reliable. You become a PM who makes their boss’s life easier by being someone who can be given full ownership with no uncertainty.

4. Empathy only for customers is not enough

Empathize. Not just with customers but your engineers. Think about how you can make their lives better. What do they want? Humanize yourself. A lot of PM Engineer relation is where engineers feel PMs are someone who are ‘above’ the engineers and tell them what to do. Don’t support this notion.

When things go wrong you’ve to be the person who says “We will fix this” instead of a person who would say “Engineering team has to fix it” You’ve to break barriers between engineering and product team and promote them to function as a one team working towards common goals of solving customer problems. Things, like including them in product decisions and acknowledging their opinion, are of much value.

Be grateful for all the times they worked to ship the best instead of criticizing the one time they couldn’t,

5. You don’t need to buy pizza for your team to get work done

The greatest motivation to work is contributing to success. Over time, I have realized that it is a false belief that people have to incentivized to perform best. Great teams and best products are built when every single member knows where they’re heading to and why? These are the people who look forward to challenges and are excited to tackle them.

As a PM it is important to set the direction for everyone and make them aware of their contribution and impact which will ensure that the team is ready to do whatever it requires to reach the goal.

6. Take stand! Don’t be a pushover.

Take stand as long as no one can prove you wrong. Open to be proven wrong. But don’t easily overcome your opinion because others disagree with it. Try your best to convey what led you to that thought process and convince the team. Get comfortable with disagreements.

One year into product management has been a period of infinite learning. Seeing customers happy and creating delightful experiences for them remain the best part of this journey and I look forward to more.