Onboarding as a Product Manager
Ah, the smell of a fresh MacBook — it’s your first day as Product Manager at Fun Company XYZ! Congrats on making it through the interview process, but now it’s time for bigger challenges.
It’s going to take a lot of Fun Company’s resources to get you up to speed, and you will of course be eager to take up all of the new stuff coming your way and soak it in. As you do, however, stop and think about how you can shape this process to get from taking up the team’s time and energy to being a net contributor as quickly as possible.
Reflecting on our own experiences and from conversations across the Yammer Product team, we have found that there are a three main activities to focus on in the first 30 days:
- Get to know to know the product
- Get to know the team process & culture
- Get to know the other teams
We will go through each of these in more detail.
1. Get to know the product, its users, and strategic vision
Definitely play with the product for yourself — a lot! This is easy to skip past, but you should pour many hours into this intentional exploration. Get to know the depths and limits of what it can do.
As you are delving into your product, get to know the users as well. Whether you were an active user before you joined the company or not, your personal perspective is always narrow and myopic. You need to understand why people use your product, what problems it solves for them, and what goals they have. Try to read (or watch!) existing research or user feedback your company already has, but keep in mind that nothing is better than observing real people using the product. If you can sit in on usability studies or take part in customer site visits, that is ideal.
In addition to getting this perspective of the individual user, it is also important to look at the aggregated view. What is the overall makeup of your user population? How often do they come back to the product, and what is the breakdown between very engaged and casual users? What does the conversion funnel look like, and how do users move through it? What features are often vs. rarely used? All of these will help you determine which potential changes have the greatest possible impact.
Lastly, to drive the development of the product, you have to completely buy into the strategic vision: What are the core beliefs that underlie the development? What product opinions does leadership hold? What long-term goals does the company aim to achieve, and how is “success” defined for the product and company? What is the story behind the global metrics this company has chosen? When and how have they changed?
While some of these might be written up and documented, nothing beats one-on-one conversations with the VP Product or CEO to get to the bottom of these questions. Try to schedule several of these conversations with as many people on the team and as high up the org chart as you can. Coming in as a new PM is your best chance to make sure you are fully aligned — any misalignment can lead to costly and painful readjustments later on.
2. Get to know the team process and culture
To be effective building products at your new company, it is essential that you really understand the end-to-end product development process: What is the scale and scope of a typical feature project? What stages does the process go through? What decision points are there? Does the team follow a specific development methodology?
Understand what formal meetings there are — depending on the culture of the company, there might be a lot or next to none. Unfortunately, the only way to discern which ones truly add value is sitting through them. After a few weeks, you will have a better idea of how to spend your time.
Read through a number of old product specs to get a feeling for how much detail is usually developed up front and how much is decided while building a feature. Read specs from several different PMs since the style, emphasis, and level of detail can vary quite a bit and give you a sense of the normal bounds.
You will also want to get to know the tools that are commonly used, where there is flexibility and where there is a dedicated system of record. For example, at Yammer, all team communication is done in Yammer (surprise!), but specs could be written in Office 365, Google docs, or Quip depending on the team’s preferences. All code lives in GitHub enterprise, but project teams are free to organize their tasks however they like — some use JIRA, some Trello, etc.
While you are learning all of this, take note of what you think could be improved — sometimes your fresh eyes will spot things that everyone else has long started ignoring. Resist the urge to point these ideas out to everyone right away though, until you fully understand why things are done the way they are — once you have that understanding, you will be much more effective at changing processes if there is indeed a better way to get them done.
3. Get to know the other teams
Since PMs operate as the hub of many different functions, it is important to discern the roles and responsibilities at these interfaces — especially, where the responsibility of the PM ends and that of the other function begins. Here are some questions worth asking:
- Design: How is design involved in the ideation phase of features? Who develops / decides on the workflow? Who sketches out initial wireframes?
- Research & analytics: How much central support is there for running user studies, surveys, or querying analytical data? Who designs A/B tests? How are quantitative success criteria defined for new features?
- Engineering: How deeply involved (or not) are PMs in architectural decisions? Who project manages the development — the PM or an engineering manager? How deeply involved are engineers in product / feature decisions?
- Marketing & sales: Who develops the product vision? Who is responsible for translating and prioritizing user and customer needs into the product roadmap, and how is it communicated? Who is responsible for defining launch plans and communication?
You can also use these questions as a great way to get to know influencers and decision makers from across the company — you’ll need to work effectively across so many teams! Set up informal meetings or coffee walks to dig into these topics, ideally, within the first few weeks. While you are having these conversations, also ask for what could be improved in the way the teams work together — as a new joiner you will get much more candid answers. Protip: ask your manager or mentor to recommend who you should meet with from the different teams; you can’t always pick out the decision makers from the org chart alone.
Conclusion: Get to your breakeven point as fast as possible
Remember that your goal at a new company is to become a Net Contributor as quickly as possible, meaning that your contribution to the company exceeds the resources the company is spending on onboarding you (e.g., explaining the testing frameworks, historical decisions, site architecture, everything!) Do your best to accelerate your learning in this time so you can start giving back to your org sooner.
Michael Watkins writes about this in his book The First 90 Days, where he teaches readers how to reach that breakeven point within the first three months. While the frameworks he presents may not work for everyone, the paradigm is a useful one to bear in mind:
The more intentional you are about what you need to learn in this initial period, the faster you can get to that breakeven moment, and the more impact you will have in the long run. But to do this, you’ll have to prioritize ruthlessly.
Elton John might as well have been singing about onboarding PMs in “The Circle of Life”:
From the day we arrive on this planet
And blinking, step into the sun
There’s more to see than can ever be seen
More to do than can ever be done
Don’t be a tumble weed! Nothing is easier than getting pulled along by all the meetings you need to shadow, early projects you jump on, and lower priority tasks to pick up.
Don’t rush past things that you need to know, but keep your eye on the bigger picture and the fundamentals required to make you an effective PM in your new environment.