What sort of realistic expectations should you set when onboarding a new product manager to your team?
Onboarding a new product manager to my team next week. I’m not really sure what sort of expectations to set for the first few months. Has anyone got any advice?
Depending on role (my experience is with younger PMs, in a B2B PaaS/ML space) and what you mean by “expectations”…
I would generally go with a 30/60/90 day plan, my goal is to leave them “productively alone” as quickly as possible. I.e. get the doing stuff that counts, without my supervision.
I work loosely the plan but, full disclosure, this is mostly for show IMHO as I have never actually managed to stick to one (people move at different paces for different things). However HR and the junior PMs seem to get confidence from having one and I haven’t had the need/time to optimise beyond it.
Within the first 30 days I want them to:
For me this means
Within 60 days I want them to:
For me this means
Within 90 days:
For me this means
@MichaelYoffe, You sound like a really good manager. I’ve gotten none of this when starting a new PM job and this would be really amazing and I’d feel totally set up for success.
Be the change you want to see in your org - consider it as a side project with your boss as a way to improve the onboarding experience for those that follow you.
It’s these kinds of experiences/initiatives that actually help you more than you think for leadership positions later because you know this pain and you know how it can be addressed.
@Maria, Agree with your sentiment, but I’ve had 6 bosses in a year, which gives you a bit of a glimpse of where I work 
job searching currently. Would be cool to get a manager with half of what OP laid out.
@MichaelYoffe, Thank you. I didn’t have this either and I wanted to make the onboarding experience as good as I can possibly make it. It won’t be perfect though.
On this, the best thing I can recommend is to talk to your leader in Technical/Customer Support, ask them to allow for your new hires to do a week rotation in Tech Support. And yes, that means actually onboard first as tech support, do calls (while being shadowed by a tech lead).
Doing that for a week is like understanding the product on steroids; you get live questions from your customers, understand them and try to solve them. Some of them will be easy, but you’ll get enough curveballs to understand real gaps in the product too, enough so that it becomes something you think about when you go to what the org hired you to do.
The reason why I caution against talking to Sales right off the bat without enough time hanging with the PMs first and treat it as more of a case-by-case or ‘if you’re talking to Sales, talk to these specific trusted people first’ is that depending on the culture within the company, if you’re not careful, Sales is going to the advantage of this situation and eat your new hire alive because they’re going to make it look like the product is more uncompetitive than it really is because they’re struggling to sell it. They can smell the fresh blood and insecurity from the imposter syndrome a mile away. This misleading sense of panic then carries and colours the new PM’s opinion that risks them becoming a conduit for Sales to get what they want. And the thing is, everyone’s got an agenda when it comes to talking to Product.
Something I also do is that I ask new PM’s after 30 days to take one of the team’s Weekly PM meetings to straight up talk about what worked and what didn’t work during their onboarding. Their observations and things to improve the process. In a very meta sort of way, the onboarding process is an internal product for your team and your org as a whole. There’s always room for improvement and even though nobody likes to think about it, the metrics for it are also pretty clear as well. It’s just that nobody really thinks about it as much because it’s not often that it happens.
However, looking at the job market right now and the amount of staff rotation going on, nailing an onboarding experience that gets people hit the ground running is critical to product teams right now, so it might be wise to look at it with a more focused lens.
Thank you soooooo much for this! Really helpful. Even if a person is joining as a new PM, they can use this as their plan.
I wish I had a manager like you when I got started!
@MichaelYoffe, Really helpful comment. Thank you for this.
I have a question: When you mean understanding the tech stack, do you mean the end-to-end technical implementation aspects or having a broad idea of the system design and the “why’s” of the technical aspect?
@DonovanOkang,
A bit of both, depending on their area of interest and the maturity of their tech knowledge.
Remembering that my goal is to get them set up and productive as quickly as possible, at the start I just want them to understand enough to guide the process.
For example, as we work with ML and it’s a more specialist area, I would send them to an architect to understand how our pipeline works, then to engineer developing a model from scratch, then someone working to improve the accuracy/cost of a model. This should give them enough system knowledge to draw out some flow diagrams and “speak the language” of engineering.
After most sessions we would catch up, run through what they have learned and I will push and probe them. I don’t expect engineering to give them an unbiased view, but I use this to show them how they have to manage stakeholders.
Then we talk about the “whys” - ML is a relatively expensive way (getting cheaper) to solve a problem, it’s like a really dumb intern given a spreadsheet, we can tolerate false positives/negatives in most cases, cost and spiral when we try and achieve perfect… Just broad rules really.
The more senior, the more I expect them to get stuck into the data and challenge the engineering team to go to “uncomfortable” places. But at the start, if they can say “Semantic Role Labelling” and understand what it means in concept and mock up some data-in-data-out flows, I am happy.
Thanks for all the nice comments on my post everyone, it’s really affirming to hear the approach my team and I are developing looks valuable.
A small reminder that it is easy to sound “fully resolved” in a comment - we are by no means perfect and this is just a summary of something really complicated.
@MariaWilson, I like the quote “be the change that you want to see in the world” - so if you find the ideas interesting, I’m happy to talk more about them. Feel free to DM.
Context matters a lot. Are they brand new to product management? New to career? What is the product/industry? How big is your company? I’ve been a PM in several different companies and ramp up time, structure, and what could be considered realistic expectations were quite different at each. It also varies by level of course. At one place I was expected to contribute meaningfully in less than 60 days, while another was around 9 months before I was asked to contribute.
One approach you might consider is to ask them to put together a 30-60-90 day plan, with milestones for each window of time. Then coach them on it to make it more realistic for your context.
@Naomi, Yes, they are new to product management but have some exposure to it in their previous role.
Thank you.
@NaomiNwosu, what were the sizes of the org in the 60 days vs 9 months scenario?
@Ahmad 60 days was about 2500 employees, ~$1B in revenue. 9 months was about 10k employees, ~$7B in revenue. Oddly enough, same industry.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.