Issue #25: Managing feature requests from stakeholders, onboarding new PMs, and 5 things

Why asking for problems don't work, focusing on the important things during onboarding, and can I help you?

Hola friends! 👋

This week’s thoughts and feelings include:

1. What to do when stakeholders have feature requests

2. (FAKs or Folks.Ask.Kax) How does one successfully onboard a Product Manager onto a well-established team?

3. 5 things to help you this week

---

01 What to do when stakeholders have requests

Feature. Requests.

When put together, these two words elicit the most violent reactions from many Product Managers worldwide. 🫠

Us, Product Managers, are trained to think about problems and opportunities. So our natural tendency, when we receive feature requests from our stakeholders, is to push back. One way or another.

“Give us problems, not solutions,” we will say to stakeholders. ⚔️

But we won’t get we want. Instead, we’ll be labeled as being difficult. We’re a blocker. Best case scenario, some stakeholders will be able to frame “a lack of solution” into a problem. We can appreciate the attempt, but it’s still not what we’re looking for.

And it can be very frustrating, I get it.

But in the many years I’ve been working in Product Management, I have learned that it’s perfectly alright for stakeholders to have solution requests. And to expect them to bring problems to us is unrealistic.

But before you come at me with knives and pitchforks… 🔪🔱

Let’s also remember a few things:

1. Our stakeholders are not Product Managers. They’re not wired to think about user problems, like we are.

2. Ideas are easy to have. But understanding problems require a lot of work and input (e.g. data that will come research) that our stakeholders do not have the skillset for (but we do!)

So if we can’t ask them to give us problems, what can we do then?

• Speak the language they speak. Talk about the benefits and impact of their requests. If you do build the feature they’re asking for, what value would it provide for the customers/users and the company. Speak in outcomes.

  • And it’s a good opportunity to ask them for evidence. Why do they think this a good idea? Where is it coming from? Have they made any estimates for the potential impact they’re expecting?

• And since you’re already talking about outcomes and evidence, it’ll be easier to extract from here what problems the feature request was trying to solve in the first place.

Here’s an example:

You're a PM for a language learning marketplace. Students can choose their teachers to teach them a new language.

At the end of the day, the problems to solve were still surfaced from behind the feature request. But with less frustration from both sides.

From you, the PM — because you’re not hitting a wall when you ask for problems instead.

From them, the stakeholders — because they’re also not hitting a wall when the PMs immediately ask them for things that they don’t have nor know how to get in the first place.

Furthermore, what this method brings is the beginnings of a more open and collaborative relationship with your stakeholder.

By asking them questions that are relevant and relatable for them, you’re inviting them into your process of product building. You’re introducing to them the possibility that not all ideas are as they seem. That there are layers of assumptions behind these ideas that need to be unearthed for all of you to discover whether building the feature will be worth the effort it will cost your team.

Next step? Invite them to a conversation about what validating these ideas mean. :)

Got any more tips on how to manage stakeholders with requests? Leave them in the comment section below! 🙏

---

02 (FAKs or Folks.Ask.Kax)

How does one successfully onboard a Product Manager onto a well-established team?

Luckily, I just recently completed an onboarding so my steps are still pretty fresh in my brain 😎

The process of onboarding, for me, always has 3 participants.

1. The Manager

2. The Engineering Lead + Designer + Team

3. The incoming Product Manager

And each participant has their own responsibilities:

The Manager

The manager’s responsible for making sure that the onboarding PM is set up for success. That they focus on the most important thing during their first 3 months. And for me, that is learning about:

• The product and its users

• The market and the industry

• The organization, its people, and its goals

• The team’s context including ways of working

So I set a 30,60,90 day goal with the incoming PM. For example:

1. First 30 days. They know how the product works and how it contributes to the company ambitions. They know their users and understand what the market and industry looks like.

2. By the 60th day. They know their team, their challenges and their new team’s way of working. They should have met their stakeholders and know their motivations. At the same time, I would also expect them to be able to work on a pretty defined task. Nothing like working on a ticket to REALLY understand their team’s ways of working, and get their product muscles warmed up.

3. By the 90th day. They are autonomous enough to prioritize work for their team, define new requirements, contribute to doing some discovery work - Already productive and ready to start delivering value. More concretely, they should be able to plan the incoming quarter’s work with their team.

My priority for these first 90 days is for the onboarding Product Manager is learn, without the pressure of “delivering value” in the first 3 months. My thinking is that — The better they understand the context that they’re operating in, the better they will be able to deliver value in the future.

Having a 30, 60, 90 day plan also helps cut the onboarding process into smaller milestones that allow for iteration whenever necessary (which is always).

The Engineering Lead + Designer + Team

The team absolutely needs to be involved in onboarding the new Product Manager. Especially the Engineering Manager and the Designer. This will be their new team mate after all.

To make sure that this is a team and EM priority, I align with my Engineering and Design counterparts to make sure this is also a set expectation from their POVs.

The team should be able to walk the new PM through their context, their ways of working, and what they’re currently working on (and why).

More importantly, the Engineering Lead, the Designer, and the incoming PM (the trio) should start defining:

1. Their ways of working as a trio

2. Their expectations from one another

That’s why for me it’s important that the team is part of the onboarding. Having them take responsibility of integrating the new PM is also making them invested in the success of the onboarding.

The Incoming Product Manager

The most important thing the incoming PM needs to do is to approach things with curiosity. To suspend judgement and only seek to to want to understand why things are the way they are, and how they might impact the users, the product, the team, the business.

The 2nd most important thing the incoming PM needs to do is to build Trust. To get to know their collaborators, emphatize with their challenges, be excited for their ambitions, and to start creating meaningful connections.

It’s very tempting for new PMs to come in with their external experience and want to provide value immediately. Whether they be in the form of:

1. A new processes for the team and stakeholders

2. A vision and a strategy

But when these things are done without deep understanding of the context, they will be operating in they risk creating unnecessary friction. Besides, how do you define a vision and a strategy without the insights that only context understanding can bring?

***

Gartner says that 69% of employees are likely to stay with the company for at least 3 years if they experienced a great onboarding. And it makes a lot of sense.

A well thought of onboarding sets the tone for what kind of culture the new PM can expect in the company they are onboarding in. Is your organization setting up the new PM for success? Yes? Fantastic, then the result of the onboarding will reflect this.

However, onboarding is always a 2 way road. The PM also needs to position themselves well in order to maximize their onboarding period.

---

03 Five things to help you this week

If you only have time to read 5 things this week (aside from this newsletter), let it be these:

1. Don’t Forget That You Are More Than Your Job by Karen Comas. Karen Comas reflects on her almost 10 years in Meta and what she’s learned in those years.

2. Cristina and Jennii from Lead in Public writes about how to set the bar higher for your team and the importance of accountability.

3. You’ve probably heard of Apple’s Vision PRO. The reviews are starting to come out. Or more like first thoughts.

4. 10 Infrequently Asked Questions by Jessica Hagy

5. We always talk about Product-Market Fit. But PM-Organization Fit is also important. Julie Zhuo shares who might not be a good fit for an early-stage startup.

---

But before you go!

1. Are you struggling with your job search right now? Your application is being ignored? You get feedback along the lines of “We’re just looking for somebody with more experience”. Get my ULTIMATE GUIDE for creating a Sustainable Job Search system for the Modern Product Manager. And get cracking with 10% OFF.

2. My coaching calendar has some free slots starting in July! For the Product Managers and aspiring Product Leaders out there who are feeling stuck in their current role and unsure how to get to their next step. I’d love to help you. Let’s chat 💙

3. Hey, Women in Product! Are you writing too? I started a writing community with a bunch of other WIPs and we’re all about making sure we all achieve our writing goals and be each other’s biggest fans! If you're looking for a writing support group - we’re here for you!

---

💙
Kax

You can also find me on Twitter, Linkedin, and Instagram

If you’re enjoying this newsletter, how about sharing this with your friends or anybody else who might enjoy it too?