The Product Manager Onboarding Cascade

Congratulations — you’ve hired a new product manager to your team! You’ve spent months reading through resumes, meeting great product people, doing interview exercises, and now you finally have someone signed and starting next week.

One of the most common things I see when people are onboarding new product managers is that they want to send them all the docs. On one hand, this makes sense: you need a product manager to get up to speed on your business, your sales cycle, your pricing, your users and their needs, all past research that has been done, all future work that is planned — the list goes on and on.

But on the other hand — if you simply create that long list that shares all of this at once — that new product manager is going to be swimming in things they don’t have enough context to understand. They may read it all, but they won’t be able to truly absorb it just yet. My recommendation: introduce the right content, at the right time.

When I onboard a new product manager, no matter what company it is at, I follow the same high-level process: I structure the first week starting at the “top” and giving them context on the company, and then each day it cascades into more and more detail. I share documents that are relevant when we’ve covered that level — for example, I wouldn’t share a roadmap about what their team is working on if we haven’t yet covered the context of where we sit in the organization or what the company priorities are. A typical first week looks like:

• Day 1: Company background: share a bit of background and history on the company, as well as share about the current company priorities or investment areas. It may be helpful to draw a high-level org chart.
• Day 2: Business background: this role will likely sit within a specific business unit with its own set of complexities: share more history about how this business operates, how they make money. You may consider doing a Business Model Canvas exercise to help structure this conversation.
• Day 3: Product Area context: at most companies I’ve worked at, there’s another layer here such as a product area or program of work. It can be helpful to share more about who all the different teams are in this space, who are the key stakeholders, who are the best people to reach out to learn more. It may be helpful to ramp them up on your high level vision, strategy, OKRs, and success metrics at this level. You can skip this if you work in a smaller or more flat organization.
• Day 4: Product Practices: before diving into the specifics of team’s work, I take this day to share a bit about how we do product management — what do good product practices look like in this role? I share about our values, our principles, and specific practices for product management, and share about how we also adapt and evolve those over time. I go through the product manager career framework.
• Day 5: Team context: on Friday, we finally dive deeper into context about their specific team. I enlist help from their new team members on this day so that they can go into the right level of depth!

Each day we expand on what we covered the previous day, but go one level deeper. The goal for that first week is to be able to connect the company goals to what their team is working on. Yes, this will only be a thin slice of the larger context, but we will have gone deep on the one path most relevant to them. From there, over the next few weeks, they can fill in more details and eventually start to also expand horizontally, learning about other groups or teams beyond their own. I also ensure we prioritize a conversation about the individual and their growth once we’ve set this context.

I have found that when you do this the first week and refrain from document overload, that by the second week when those documents start flying at them, they at least have some context to put those in. This helps new product managers build the mental models they need to be successful from day 1!