Your Guide to Product Manager Onboarding

Before I start, the TL;DR version is here’s a link to the slide template to help you plan your onboarding to your next Product Management role.

I’ve been in full-time work for just over a decade now, and I’ve worked for or with over a dozen companies in that time.

Why am I telling you my (working) life story? Well, because I’ve packed in a lot of experience onboarding to new roles, products, and environments in my career to date.

It’s pretty daunting moving to a new company. While that will never disappear entirely, putting some structure around it can help whether it’s your first role or your fifth.

I’ve used the approach I’ll outline in this post explicitly for my last two roles — at Digital Directories (Qredible, Justifit and LegalePerMe) and most recently for The Keyholding Company, where I worked for 2 years from November 2020.

Given the nascency of product management at these organisations, I could not have been successful in my role without the proactivity of an onboarding plan. There were few ready-made sources of information to get up to speed with the company, customers or competition and no one dictated what I should do, when, and how.

As a hiring manager, proactivity is the number one trait that I look for. You can overcome most gaps in experience or skillset with proactivity, and so it’s the number one attribute I look for as a hiring manager. Use this article to be able to confidently discuss how you’ll get up to speed in a new role during the interview process, and then wow your new colleagues.

Before I get to the onboarding structure, I’d just like to take a moment to mention this all-too-popular phrase related to onboarding. If you’ll pardon my language, it’s BS.

To hit the ground running implies that you just ignore the specifics and nuances of your new role, team, company, and industry and just start delivering things. Let me explain.

The origin of the phrase ‘hit the ground running’ is a matter of some debate, but is generally considered to refer to troops deployed by parachute landing and immediately running, or other similar situations like someone fleeing from a dangerous incident. Oh, and by the way, the safest way for a paratrooper to land is by immediately rolling, not running. Take that!

There are two factors in these incidents that don’t exist for you on your MacBook Pro in your air-conditioned office in central London (or more recently, in your tracksuit bottoms and slippers in your guest bedroom) — fear for your life and/ or absolutely clear directions.

In the armed forces, there is a clear and absolute hierarchy of command and so this works. This hierarchy and structure need to be in place because the cost of failure — even a minor one — is probable death.

In an Agile product management environment, it’s not so clear. You might be given a vision, a strategy or even outcomes but that still does not give you an absolute path forward. If there is someone there telling you exactly what to do, how to do it and when then I’m afraid you’re a product manager in name only.

To hit the ground running implies that you just ignore the specifics and nuances of your new role

Many of you will have already heard the stat that 80% of product launches fail, and only 1 in 7 product ideas actually make it to the customer. That’s OK, but if you go flying off in one direction as soon as you start, I guarantee you will miss the important context. Small failures are a good thing in product development but don’t set yourself (and the team) up to fail through ignorance by skipping a deep onboarding.

One huge benefit of any new joiner is a fresh perspective, and asking anyone to ‘hit the ground running’ typically means giving them a roadmap and telling them to get on with it.

Don’t be fooled by thinking that being a product manager in an Agile world means you don’t plan. I am planning almost constantly, but the mantra above is crucial to your long-term success in product management and the success of the products that you look after, and this starts with effective onboarding.

Now that my rant about over-used and misleading idioms is over, let’s take a look at how you can set yourself up for long-term success and not fall into the trap of trying to do too much, too soon.

A 30–60–90 day plan is not a new concept, but it’s the one I’d recommend you use. The below plan and the steps within it are largely applicable whether you’re an Associate Product Manager or a Chief Product Officer.

I have used this approach in my last 3 roles and found it incredibly useful to make my onboarding more efficient, effective and even less stressful.

Let’s go through it. For each, I have defined a series of topics and goals.

The ultimate goal for your first 30 days is to get a feel for the business and get to know your teammates. It is not a time when you should have to deliver anything at all. It can be tempting to try and impress your new team and your boss by ‘contributing’ from the off but resist this temptation at all costs.

I’ve broken this stage into 5 sections which you can loosely consider to be in order, but in reality, you can structure them in whatever way you choose. It’s important to say that this is relevant even if you’re just moving teams in the same business, just pick and choose what you think is relevant, but a refresher is always useful.

I won’t go through every question as you can see them in the visual below, but to summarise:

Vision & Strategy — Do you understand the direction of the company, any known plans and how your product fits into it?

Meet the Team — Meet as many people as possible, and understand their challenges. Get to know those you’ll be working with.

Tools & Processes — Want to avoid awkwardly trying to add a user story live on a zoom call when you’ve got no idea what you’re doing? Onboard yourself with the tools that the company uses, and understand how they work.

Product & Tech — You need a base level of understanding of the product ecosystem to be able to make informed decisions in the not-too-distant future. If an architecture diagram doesn’t exist — make one!

Customers — Once you’ve got the internal elements down, it’s time to understand your customers. They’re kinda important.

Now that you’ve got your feet under the table and your head around the generalities, it’s time to dig a bit deeper.

After conducting more research, you’re ready to share some of the insight that you’ve gleaned with the rest of the team.

As a new member of the team, you’ll have the benefit of seeing things with a fresh pair of eyes — don’t underestimate just how powerful this can be. Notice a process that could be more efficient? Share your views. Think the objectives you’ve inherited for your product don’t quite line up? Voice it. Is something missing from a core User Experience? Keep calm and talk to people about it.

Use what you’ve learned to create a SWOT analysis, and suggest process improvements and refinements to your product’s strategy.

Your ‘fresh take’ will quickly be eroded as you become indoctrinated into how things are done, so don’t miss this moment to share what you’ve learned.

This one can be adapted depending on your role — particularly your seniority — but the theory holds. It’s time to go from being a net learner to a net contributor.

What am I going to work on?

If you’re in a leadership role, then the strategy probably refers to the overall product strategy for one or a suite of products. If you’re an individual contributor, it could be a strategy for a product, a feature, or merely your strategy to tackle an existing strategy.

How am I going to work on it?

You know what you need to achieve in the short term, but how are you going to go about it? By now, you should have a good sense of the pros and cons of existing processes, the different personalities in the team and the main pain points of your users.

You can use all this information to make a pragmatic assessment — how can I progress the what, while also influencing the how?* Only you can make this assessment based on the goals of the business and current progress against them. If the team are up against it to support sales targets, then hack for success. If there’s less pressure, maybe now is the time to put the foundations in place for future success.

*I’d say this only applies if you identify areas that could be an improvement but let’s be honest, no company is perfect and I’ve never failed to notice something that could be better.

I also defined goals across 4 categories for each of the 3 stages. These were learning, initiative, personal, and performance.

All of these will need to be tailored to you, and you’ll need to take the research you did for your interviews a bit further to have a go at this before you join, and then amend it in your first couple of weeks once you’ve somewhat got the lie of the land.

Learning Goals — What information will I absorb about the company, team, and role?

Initiative Goals — What will you I do to stand out?

Personal Goals — How will I integrate with the team?

Performance Goals — how will I measure success?

I found using the sections and individual questions within each stage as a checklist incredibly useful. 20 days into each stage I assessed myself using a good old-fashioned RAG status at a question, section and overall level.

I then did the same exercise at the end of each 30-day period and provided an overview to the leadership team.

That’s it, your onboarding is complete. I hope you found this article useful and I welcome any feedback you have on anything you’ve read!

I’ll end how I started, with a link to the slide template for you to download and use for your next role, or for onboarding people into your team. It’s a PowerPoint document so the formatting may be a little off if you choose to open and amend it in Google Slides.