top of page

A framework for ramping up in a new team or company

In my 11 years of working as a Product Manager so far, my current team at Shopify is the 20th or so team I've supported in my career. Each team has been a new group of people to meet, set of relationships to build, subject matter to learn about, and problem space to make sense of and set clear goals around.

This amount of context switching is more typical than it may seem for a Product Manager's career. Between team rotations early in your career, supporting multiple contiguous teams as you earn more influence, going through reorgs, switching companies, and so on, you quickly get exposure to many different configurations of people to work with and problems to work on.

Hitting the ground running with each new team can feel like a daunting task. Especially when you join a new company, but even within the same company as you start to support new teams. After all, getting this right early on is important if you want to effectively contribute to the team's strategy and impact!

Here are some tactics that I've developed throughout my career to hit the ground running as quickly as possible on a new team:

People

 

Whenever I join a new team, my first goal is to meet everyone I'll be working with and talk through the below 4 things. I take notes on everything that I learn in a private "1:1s" doc that I keep to myself.

A) Context

 

"What should I know about our team, the broader org, and the company as a whole?"

  1. This is story time. Let the person guide the way - history of the team, current priorities, technical details of key products that the team contributes to, etc.

  2. I always leave this open-ended early on and over time as I get more context, I start to develop a set of specific knowledge gaps that I try to fill with subsequent conversations.

B) Advice

 

"What advice do you have for me to be successful in my role?"

  1. Everyone on the team, no matter how long they've been on it or what their role is, will have something valuable here.

  2. Advice isn't only tactics or mental models to be more effective at my job. Advice is also a window into how they view their work and our team, how they (and possibly the company at large) view the role of the Product Manager, and what they think the team needs most support on.

C) Help

 

"How can I be most helpful to you? Anything I can do, starting this week or later on, to make your life easier?"

  1. Anything at all that's a reasonable time investment on my end and genuinely helpful to my teammate is a great candidate to build rapport early on and establish trust.

  2. This also helps to quickly pick up on recurring themes throughout the team. Is there not enough documentation of what the team's goals and key projects are? Is there a relationship with an XFN partner that needs some extra love? Does the team's org leadership not understand or believe in the team's current direction? Any of the above or more become key areas to focus on for fast impact.

D) What else?

 

"Who else should I meet? What else should I read?"

  1. I'll then go talk to all those people, and repeat #1-4 until there's no one else left to talk to and no major docs to add to my reading list.

  2. At this point I can PageRank which people are going to be most relevant to my role to build close relationships with, and which docs are going to be most important to prioritize reading first.

Product

 

Understanding of the how product (what the goals are, current state of the world, how things work, etc.) has hopefully already started to come together through conversations with teammates. Beyond that, I focus on:

  1. Going through all the key docs that were recommended to me

  2. Doing longer deep dives with leaders on the team about the tech stack, key operations and support flows, and retrospectives of recent key projects

  3. Get in front of our users by participating in some user research studies, answering customer support tickets, etc.

  4. I add all of this to a doc titled "Hadar's ramp up doc for {New Team}", and share this out with everyone I've been meeting with. Here's the template I use: hadardor.com/ramp-up-template

  5. I ask folks to comment in liberally, correcting my understanding of things and adding more context or resources to read. This helps me over a quick period of time to make sure that I have context on all the most important areas to my team

Impact

 

Driving impact early on depends on the needs of your team, so naturally isn't as clear cut. Here's how I approach this on every new team:

  1. Set clear expectations with my leadership team (manager, org leaders, etc.) on what is most important to focus on early on, how to quickly grow into the overall scope I've been hired for, and how we'll measure the success of my ramp up.

  2. Solve people and process problems as early as possible. If the team needs their execution streamlined, if there are stakeholder relationships that could be more productive, etc., that's an immediate area where I try to add value so that everyone else around me can be more productive.

  3. Take on some starter tasks based on my leadership team's priorities and the answers from teammates on how I could best make their lives easier. These can be defining scope for the next project on the roadmap, aligning expectations on a current workstream with partner teams, etc.

  4. Figure out with my function leads counterparts (engineering manager, data science manager, ops manager, etc.) how I can best partner to facilitate the career growth of all the people in our team

  5. After the above are under control, start to think more proactively about what the team's next big bets could be. Start to socialize this with teammates and refine it over time. This will come in handy soon enough when it's time to plan the continuation of the team's strategy :)

bottom of page