No-nonsense game plan for first-time product managers

Congrats, you finally got your dream PM job! But… what now? Here are some pointers to plan your first few weeks — and beyond.

People come to product management from various career paths. It’s not an entry-level role, so you’ll typically have a few years of experience somewhere else, bump into product one way or another, and get hooked. Many PMs, including myself, have never gone through any formal training.

The thing is, once you’re a PM, you barely have anyone to ask how to do your job. You can’t be too honest with your team or your manager about not knowing what to do next. As the leader of your product team, you’re supposed to know your way around.

For the past few years, I’ve been coaching first-time product managers. As I can’t take on more mentees due to time constraints, I wrote down a quick guide here. No lingos, no ambiguous terms, no snobbish advice. Think of me as your fairy g̶o̶d̶productmother, or the manager you wish you could ask these questions to.

Sooo, what exactly am I supposed to do in my first few weeks?

1. Familiarise yourself with the existing work

When: First few days
Talk to: Your development team (engineers, designers, etc)

If you join an existing team, the team is likely to be in the middle of delivering something. Ask them about the motivation behind this feature/project. Understand what exactly is included in the project (how complex it is, ranging from a copy change to creating a completely new service), and understand what’s been done and what’s left to do. Make sure you are aware if there’s any deadline you need to adhere to.

Focus on understanding, don’t try to change anything yet.

This will allow you to start making sense of what the team talks about in standups. It also tells you how much time you have until they finish this piece of work, because it’s likely that they’ll turn to you to decide what they should work on next.

2. Understand how your team fits in the wider product organisation

When: First couple of weeks
Talk to: Fellow PMs and your manager

Assuming that you have more than one team, each team usually has their own goals or areas of the product they’re accountable for. Understand all of the other areas and how they all fit together. Try to create your own map, instead of just following the org chart.

Depending on how old the company is, the product org might have evolved. Try to also understand the historical context, the reason for past re-org(s), and how effective it’s been.

Now depending on how good your product org is, the map might or might not make sense. The vision and strategy of the product org might not be as clear as you wanted them to be. Make your judgement but refrain from sharing it until you have collected more data.

3. Understand your team’s mission, vision, strategy, and key metrics

When: Second or third week
Talk to: Your manager and some senior/tenured members of your team

You might have had a similar conversation about your team’s mission etc before you joined or on your first day. But at that time, you didn’t know anything and couldn’t make any judgement.

Now that you have talked to the other PMs and understand the bigger picture, you can have a more meaningful chat about your team’s mission with your manager.

Wait, I said that this article won’t be containing ambiguous lingos. In simpler terms, you have to understand:

• Why was the team created?
• How does it help the company’s and the product’s vision?
• In a year’s time, what should the product look like to make you describe it as successful?
• What are the metrics my team cares the most about? What are the control metrics (i.e. the metrics we aren’t trying to move directly, but we need to be mindful of — we don’t want to affect them negatively)?

It might or might not be clear. If it’s unclear, it’s on you to define it. I’d encourage you to write it down into a narrative document. Not a PowerPoint, not a chart, it has to be a simple Word doc. Only then you’ll find out how well you’ve understood it.

4. Have intro chats with the stakeholders

When: First few weeks
Talk to: The people that need you and you need (get the initial list from your manager)

Managing stakeholders is one of the trickiest parts of being a PM. If you have a chance to build a relationship before you need something from them, it will make a huge difference.

Have casual intro chats, and ask about what they do and how they typically interact with your team. Try to find something in common so you can build a personal connection. Try to sense if there’s historical beef between them and your team.

At the end of the chat, you can ask them if they can recommend anyone else to talk to.

5. Get to know your user and how they use your product

When: First few weeks
Talk to: User researcher/designer, data analyst/SWE

There are two parts to this: qualitative and quantitative insights.

On the qualitative side, you can check existing user research and documentation. If there’s none, you can chat with some friendly users directly. The goal is to understand:

• Who your users are
• What their pain points are
• What the value propositions of your product are

You can try to fill out the Value Proposition Canvas, a framework by Strategyzer to capture those insights.

Value proposition canvas by Strategyzer

On the quantitative side, familiarise yourself with your key metrics and how it’s performing. After a few weeks, you’re supposed to know these metrics on the top of your head.

At the very least, you have to know:

• Your number of users and number of monthly/weekly active users
• Performance rate of your product

If somebody comes to you and says, ‘We have a bug impacting 5,000 users’, you need to be able to quickly make sense of whether it’s a high or low number. If somebody says ‘Our engagement this week is 35%’, you need to know whether it’s good or bad.

6. Decide on the next piece of work

When: Depends on how long the last piece of work takes
Talk to: Your manager and some senior/tenured members of your team

Now you get to make your first decision as a PM. This could feel daunting, but worry not!

Don’t commit to doing a big project. (Unless it’s being pushed top-down, in that case, you might want to say explicitly to your manager, ‘As I understand it, this is quite a big piece of work, but I haven’t been here long enough to make a judgement of its value. If this is what the business needs, I’ll deliver it, but I just want to call out this caveat.’)

But if you can, avoid big projects and try to get a quick win that you can deliver in one sprint. It probably comes from existing tickets in the backlog that you choose to prioritise based on your previous chats.

Doing smaller tickets with quick wins brings some benefits:

• It’s low-risk. Even if it turns out to not be the most valuable thing to work on, you only waste one sprint.
• It can give you some visibility. You can shout about the release and get the praises (that you humbly pass down to your team).
• It gives you a confidence boost. Getting something released is your first milestone as a PM and you did it! Yay.

What am I supposed to be doing during the development time?

Your engineers will be busy coding all day and you’re left drumming your fingers alone, unsure what to do.

There are two phases of product development, Discovery and Delivery. Discovery is about making sure you’re building the right thing, whilst Delivery is about making sure you’re building it in the right way.

The above activities (chats with various people and understanding your users) is a part of Discovery.

The engineers are typically responsible for the Delivery side, but as a PM, you’re still accountable. Depending on how good your engineers are and whether you have a good tech lead or engineering manager, your contribution to the Delivery side could cover:

1. Holding them to account to deliver on time, or to create a plan if they’re lagging behind
2. Clarifying business requirements or motivation behind the feature
3. Giving them the bigger picture or longer-term vision
4. Making tradeoff decisions

I personally think #1 shouldn’t be a PM’s job (if you’re lucky enough to have a strong technical partner such as an Engineering Manager or a Tech Lead, they should fill this role), but you’ll be the one getting asked by the leadership team, so you still need to know where they are.

You’ll find that you’ll have to do #2 again and again. When you’re tired of saying it, they’ll start hearing it.

#3 is important because depending on what the vision of the feature is, the engineers could build it in different ways.

In doing 1–3, make sure that you don’t fall into the parent-child relationship trap. Example below:

I wrote about this comprehensively in this article.

I’ll give an example for #4. When building the features, the engineers have to consider all sorts of edge cases. Imagine if you’re building a ‘balance’ feature (you know, the thing that shows you how much money you have left). For some reason, the data pipeline behind the balance is not sending anything for a day. Your engineer might ask you what to do in this case. Do you want it to a) create an estimated balance or b) keep the balance as is, but add an explainer ‘Last updated two days ago’?

In that case, you have to make a judgement call depending on how your users use the ‘balance’ feature and the cost of each option. As you’re still new, it’s okay to validate your decision with your manager or more senior PM, but do it in a way that shows that you’ve done your homework.

Ok, I feel like I understand the basics now. What else should I do?

Now you’re getting to the juicy part of product management. This is how you can bring 10x value to your company, not just 10% improvement. This is also how you get to be a more senior PM. Whilst the first two sections above are concrete activities, this section could feel a bit abstract. It’s not something that you do once in the beginning — you’re maintaining living documentation of your understanding.

Take the time to:

• Understand the competitive landscape
• Understand the customer’s jobs-to-be-done and their unsolved needs
• Understand your industry trend

I’ve covered these in my other articles — check them out!

👋 Hi, I’m Debbie. I’ve been building products and solving customer problems in tech companies for over a decade. I write about how a PM can bring 10x value to their company, not just 10% improvement. Stay ahead of the game and get insights delivered straight to your inbox — subscribe to my newsletter today!