PM Onboarding - Same Organization, New Area

Onboarding is a crucial process of incorporating a new person into a team, product, or domain (for simplicity, let's generalize all that as "area"). The purpose is to align or increase performance as soon as possible after the unavoidable drop due to a structure change. If approached wrongly, it may cause substantial trouble, especially when you dive into a new area as a product manager (PM).

Whether it is a new or same organization, new role, or new area - the approach to onboarding will vary. Here, we talk about horizontal growth within an organization, keeping your role but acquiring a new "area" (for simplicity, let's use this term to generalize one or several products, teams, lines of business, etc). That is the situation I am currently in, so I have something to reflect on. Also, most onboarding guides focus on vertical growth with a new role in another business. So, it is a good topic to uncover.

I follow the patterns of 3 key knowledge types in product management suggested in the "Building Products for Enterprise" book (I wrote about it here): organizational, product, and market knowledge. So, let's construct the onboarding strategy for each.

Organizational knowledge - Headstart

When you start in another company, you must catch up quickly and demonstrate your best. When you move within the enterprise, you have a significant advantage.

You know some people. Some people know you. Some people trust your expertise. You still need to prove that you can work in the new area. But your legacy will serve you, depending on your past success and prominence.

You know and follow the established processes. You don't need to read boring brochures or watch uninspiring lectures.

If you have worked there for some time, you understand the power dynamics. You also know your stakeholders and how to deal with them.

Now, in the new area, you have new stakeholders. You need to build a bridge between you. They likely don't consider your successful legacy from the start. So please don't be arrogant.

The team you joined (they are stakeholders, too) might have existed for a long time. The PM change is as stressful for them as any other change. You must be very cautious in presenting yourself and with your first actions.

As a product manager, you have your tools and ways of doing things. First, quoting Matt LeMay's book (here), "Don't break the rules; change them." And change them with great patience by investing time in understanding how the team operates and why.

Another trick is that you might inherit current stakeholders from a previous area. Even though you are the same people with the same relationships, now they probably have a different perspective on you.

Spend time identifying that perspective with the implied expectations. Then, keep revisiting and re-arranging your interactions: some may play a more prominent role and have a more significant influence, and some may be less relevant, but you still need to be in touch with them.

Product knowledge - Free from bias and conflict of interest

While working in an enterprise, there is a chance that you've already interacted with the area you are now in charge of. You might have biases towards that area depending on your experience of those interactions.

You'd better not underestimate the complexity by expecting quickly rich success as soon as you arrive in shiny armor. If you do, lucky you - I want to learn that from you. For the rest, mere mortals, including me, reset your knowledge of the area and product and start from scratch, free from biases.

You might also have been a stakeholder (or continue to be a stakeholder, as in my case) in that area before joining it as a PM, which can lead to a conflict of interest.

You can prioritize your stakeholder interest or the interests of a stakeholder group you were part of. Of course, it is at the cost of the others. Even though that may lead to some short-term gains, it is damaging in the long term. And I am not mentioning spoiling relationships as a PM with your new stakeholders. Please avoid that by having a holistic view of such things.

Beyond that, do the usual onboarding activities: learn a product by trying to use it (even though you may not be a target audience), read the documentation, ask questions to the team, talk to users, talk to experts, etc.

Market knowledge - Don't pretend to know something

It's a similar situation here: having your previous experience, you might already know something about the new area's market. This is less likely if it is a new market and more likely if it is another line of business.

The same advice applies here: don't be biased. The rules you know might not work here.

For example, I move from API to UI platform as a new area. Even though they are both platforms for developers who build insurance products, they are different worlds. As different worlds, they speak different languages, have their own context and history, worship other things, and have different world views.

My decade-old pet project experience as a Front-end developer does not give me any valuable knowledge, so I don't pretend I know something. I only admit there is a long way to go.

Market knowledge takes the longest to acquire. You can't download all information about competitors, trends, and historical contexts and store it in your brain, so take your time.

Summary

Acquiring a new area as a product manager within your current organization gives you an evident advantage over a new hire. However, you'd better use it wisely:

• Leverage your existing knowledge of an organization.
• Embrace new stakeholders and revisit your relationships with current ones.
• Don't be arrogant with the team; don't break things.
• Avoid conflict of interest.
• Learn how to use your new product and how others use it.
• Don't pretend you know something.
• Invest in market research.

Take care,

Ilya