Onboarding as a new PM: A high-level 6 week plan

Joining a fast growing, rapidly moving company as a new PM can be daunting for many — it surely was for me, when I joined Gojek as a Product Manager sometime back. I watched a zillion talks and read a gazillion books — still wasn’t easy. That said, I still found this talk and this book pretty useful — so you might want to check these out. I found the video’s application of the OODA framework very helpful and the book’s overall structure easy to adapt.

Nevertheless, I decided to write a post for all folks who take up a new PM role at a fast-paced (technology) company based on what I learned.

What this post is

This is a rough blueprint of what I would do in my next first 6 weeks in a new product role. While this is specifically for PMs, the advice here can be generalised to other roles as well with some mods.

What this post is not

This is not a detailed checklist of stuff you need to get done — the goal of this is to just provide a skeleton structure on how to approach the onboarding. Nor is this document set in stone — for eg: if you are moving to a new team within a company, for instance, you can skip the first bits.

Naturally, most of your first week will probably go in HR onboarding, understanding the tools, setting up your logins, etc. — the larger the org, the longer this is gonna take. So focus on finding your feet first and then start the actual onboarding. Take it easy. It can get overwhelming. Just make sure you follow a structure and try to document as much as you can.

💡 I suggest using this first week when you are waiting for access to tools and VPN configs to reach out to your interviewers and thank them for giving you an opportunity — ask to grab a cup of coffee with them. It helps to gain as much context as you can about the org, as I describe below.

TL; DR

The timelines are just indicative — your mileage may vary. Some of you may not have the luxury to spend six weeks onboarding. Some may actually have a detailed onboarding plan in place. Adapt to the context.

• Week 1: Onboarding and setting up.
• Week 2: Learn about the people first — find and understand the org structure, where you fit in, who the PICs for various teams are, who your team members are, who your sibling teams are, etc.
• Week 3: Next, learn about the features or products you’ll own — understand the architecture, the user journeys, the analytics streams, the dependencies, etc.
• Week 4: Then, learn about the processes — what are the team rituals, how does the team operate on a week-on-week basis, how do people report progress, what’s the planning like, etc.
• Week 5 and 6: Finally move to the priorities. Know the org level and team level goals, dive into the initiatives, understand how they tie back to the goals.
• Week 6 to 9: Pick a personal priority — a large, half-done, stalled initiative or a small needle mover. Figure out the next steps. Deliver on the project. Accrue a win.

People

• Know the org structure and understand how your team fits in.
• Find the people you will be working closely with and know what they do.
• Talk to as many people as possible in the org.

Every large company is structured in some fairly logical way. In all likelihood, you are going to be a part of a team that’s part of a larger group (which is probably part of an even larger group). Think of this as concentric circles with you at the centre, the inner most circle being your immediate team (your engineers, designers, analysts, etc.), the second circle being your group — your sister teams (PMs, engineers, leads, managers, etc.), the third circle being your sister groups — other groups your team functions with regularly, etc.

Your first job (after you’ve setup the required tools and configured your logins) is to know this structure, the responsibilities of the various teams in this structure, and the PICs for each team. Try scheduling 20-minute catchups with the key people at least till the second or third circle and get to know them, their responsibilities, their team’s charters, and what they are working on right now. (You’ll probably not understand a number of things — that’s perfectly fine! You are just getting a lay of the land now.)

By the end of Week 2, you should be able to draw the overall org structure, describe what each team in the org works on, how they depend on one another, name the PICs you would talk to for specific problems.

In parallel, perhaps in the second half of week 2, you should also start focusing on the Products you’ll own.

Products

• Know every single aspect of every single product you own.
• Know your customers and their known pain points.
• Dig into user research and usage metrics, and identify gaps in knowledge.
• Understand meta info like the North Star, the broader charter, key metrics, etc.

As a PM, depending on your level of seniority, you are likely to be responsible for a set of features, a product, a suite of products, or an entire business unit. Regardless of the size of the product pie you own, your next job is to make sure that you understand every single aspect of the product. API contracts, UI components, upstream/downstream dependencies, analytics pipes, and the end-end workflows.

You also want to understand your customers and the current state of the system — look for user research reports, usage dashboards, and user segmentation data to let you understand who your users are and how they are using the products currently. You also want to make a mental note of what’s missing here.

Some of these would be documented well but many of these likely aren’t. So your job here might be to skim through docs or pull the relevant team member and schedule walkthroughs with them. Ask the engineers to explain the architecture of your service and the overall flows. Ask your designer to explain the design language (if you use one) and the components therein. Ask your analyst to explain the data schemas.

You also need to understand meta info about your products / core team — the North Star and other key metrics, external vendor dependencies, how you’re charged for such usage, internal dependencies, who owns those, etc.

Ideally, by the end of week 3, you should be able to answer any question about your products — what does a specific key in the API contract stand for, which vendor are we most dependent on for service A, what kind of data do we have on flow X, etc. Depending on the breadth of your charter, this could take longer or shorter. Again, take it easy. But be persistent in following up with your team to learn more about the products you own.

💡 Important: If you have any opinions on the products themselves, keep them to yourself. You haven’t been here since Adam and your opinions (particularly if they are critical) are likely to be half-baked. They’re also likely to be perceived poorly because you don’t yet have credibility.

Processes

• Know the daily, weekly, and monthly rituals of your team and company.
• Understand how teams plan for and report progress.
• Try to fathom why teams have a specific process in place.

By this time (sometime in your week 4), you should have a decent idea of how the team operates — what the team rituals are, if there’s a structured process or if it’s mostly ad-hoc product development, how the team plans its sprints, etc. But your next step is to formally assimilate all of this info — down from the time the daily stand ups happen to how the team reviews progress.

What’s the sequence of product development in the company? How do teams decide what to work on? In a large-ish company, there’s very likely a logical sequence of events from idea → execution and at least a semblance of a link between the strategy and the initiatives the team is working on.

💡 As with the products, it’s very important not to suggest changes to processes at this point.

Priorities

• Know the org level goals and team level goals for the short term.
• Understand the key initiatives being worked on and how they tie back to the OKRs/KPIs.
• Dig into the initiatives, understand the problem and solution spaces, success metrics, etc. (RTFD)
• Find out where each initiative stands, blockers (if any), and the immediate next steps.

In all likelihood, by the time you join, the team is working on a predefined strategy and a set of initiatives. There’s likely to be org level goals and team level goals. Understand how the initiatives the team is working on tie back to the broader goals of the team and the company. For each initiative, understand the problem being tackled, the hypothesis being proposed, the evidence backing the hypothesis, the constraints and risks, etc. — in short, read the PRDs and one-pagers (if available). This is your week 5 and 6.

These are the projects and priorities you are going to be working on and delivering, for the foreseeable future — so it’s very important to spend time understanding them. By this point, people would start expecting you to have a good sense of what’s happening in each initiative, what the gaps in the product experience are, and even offer up ideas on what you could potentially do to move the needle. Make sure you can offer sensible insights or at least not look like an idiot.

💡 On the People front, it’s also prudent now to set up recurring 1–1s with your core team, your manager (hopefully you already have this in place), and your sibling teams. Don’t change any processes just yet.

Personal Priority

• From the list of initiatives and priorities, pick one priority for yourself.
• Deliver on a part of a large, slow-moving project or a full small initiative.
• Accumulate a win for the team and yourself.

Now that you are well established in the org — people probably recognise your name, you are automatically tagged in relevant threads, and your status updates become richer — it’s time for you to actually deliver something.

Pick a project that you see as stalled which you can potentially unblock or a small initiative that you can deliver. Map out a path to realisation for that initiative, consult with your team, and go ahead and deliver it. Here, the goal is not to pick the most difficult project with the maximum number of blockers or to optimise for visibility. You need to pick a project that you are at least 70% confident about delivering in around 3 weeks. You are in week 7 by now, and it’s time to showcase a win.

At the end of the day, your credibility is going to be measured by how well you can work cross-functionally and deliver on the team’s priorities. Your team needs to know that you can walk the talk, roll up the sleeves, and actually execute.

💡 Once you have delivered a win for the team, they will view you more favourably. If there are any opinions on the products or processes, this is the time to gently talk about them and proffer suggestions on how to improve. Again, be polite, measured, and ready to be wrong.

Closing thoughts

By week 9, you are no longer a new PM. You have now ramped up to the org, delivered (or at least delivering) a project that’s deemed a priority for the team. You know the people well, the rituals are now your rituals, the products are your turfs, and the team is your home. By now, hopefully you have set yourself up for success. The goal then is to continue building on that momentum. I’ve offered my thoughts on that, in this Twitter thread.

As someone in a relatively senior role for a first-time PM in a large organisation, I had my share of ups and downs in my first few weeks. I survived thanks to the patience of my team, my manager, and my extended team who were all kind enough to handhold and course correct me whenever I went astray or did random things. Hopefully, this rough plan lets you have a structure in place for the first few weeks, which can be pretty chaotic. Good luck!

This post first appeared on my blog. If you made it this far and found it useful, consider sharing it with your friends! You can also follow me on Twitter.