One of the most frustrating parts of the Product manager role is getting the resources necessary to succeed. Our eyes are bigger than our stomachs and no matter how many resources are assigned to the team, it turns out that the goal of meeting a deadline, or adding one more feature requires.... just a little bit more.
Resource constraints, and working through them, are the lifeblood of the Product role. Most of the time, brutally prioritizing into the smallest MVP feature will lead to better success as it leads to a more iterative approach of development. Yet, there are times when even the smallest feature requires resources that the individual PM's team doesn't have or when the critical resource is owned by another team. This frequently occurs when an end-to-end feature requires 90% of the work from a single team, but the last 10% requires a different team. The worst case scenario is if that feature doesn't have the buy in from both teams leading to an unfinished or unpolished feature, a loss of engineering time, and a terrible user experience.
So how can the PM get the resources to make the project a success?
Taking a step back
Building a relationship
Laying out the problem
Finding a common ground solution
Expressing appreciation
1. Taking a step back
It can be tempting to start just by asking, "Hey, we need some of your team's time on the XYZ project. Could you help?" The problem with this approach is that it's too easy for the person to waive the request off, "Sorry, we're busy." This leads into an immediate conflict scenario and creates barriers to a final resolution where the project is resources and the relationship is strengthened.
Taking a step back before going into the conversation allows for reflection on the best way to handle the situation.
2. Building the relationship
Admittedly, this one is easier before the resource negotiation starts, but is still possible to do in a meeting invite or slack message. Making friends starts with curiosity -- "how are you doing" is the most well-known, but basically any "how" question can help start a dialogue.
- How is your latest project coming along?
- How did you manage to pull off that last launch so well?
"Who", "What", "Where" and "When" questions can be easy to answer in curt answers, so those aren't great openers. And "Why" questions can put the other person on the defensive. "How" questions, on the other hand, often help the other person jump into a story. It provides an understanding of that person's mindset and brainspace and sometimes gives an insight that becomes critical for the following resource discussion.
3. Laying out the problem
What's the real problem that's blocking the path? Hint: The problem always starts with "our users" or "our customers." This sets up the problem and likely the solution will be jointly owned.
Examples:
"Our users want to search for books based on how long the book is."
"Our customers are unable to see the checkout flow."
The second part is why it matters, and any evidence supporting it:
Examples:
"Our users want to search for books based on how long the book is, this is the biggest request from the user community right now."
"Our customers are unable to see the checkout flow, and that is causing our revenue to drop."
Importantly, no where in the laying out of the problem is the answer included. By letting the other person come up with the solution, it makes them feel like they own the problem, which ultimately leads to them helping with the solution. (This is hard, and I've made this mistake more times than I care to admit)
4. Finding a common ground solution
If the other person is bought in to the problem, this is the moment when solutions come flying out. If one of those is the solution, then, Hooray! Next steps are identified and the customer problem is well on its way to being fixed.
Sometimes, there's silence. The "What do you want me to do about it" look. Then it's back to steps 2 and 3:
Example:
Do you think this is a problem? How do you think we should solve it?
This goes back to the "How" questions. It simultaneously builds the relationship because it's a request for advice and it's a step towards identifying the next steps. If the other person is reticent, it's even more important to stop talking and listen to what that person is saying. If it's not an easy conversation, I like to start a google doc and type out what the person is saying during this time. The goal is to find a mutual path forward and not a confrontational or combative conversation.
But what if the solution doesn't work? For example, facing an answer like "well, why don't your engineers build this XYZ feature themselves," answering with agreement and asking another question can move to a better solution.
i.e. "Yes, my team could definitely do this. We have a project in flight that is going to finish in three weeks and then we can start on this. It seems like a heavy price to pay since by then we will have lost $x in revenue, do you think there is a way that we could solve it earlier to reduce the revenue loss?"
This process can be cumbersome. It takes time and defies quick answers. However, the time spent during this process is gained in a longer term win for customers as the best solution can be identified.
5. Expressing appreciation
No matter the outcome of this negotiation, it's important that it ends on a positive note and that the other person feels good about the discussion. If it's a good outcome, finding ways to surface the other person's contributions will make the next time there's a resource issue that much easier to handle. And if it's not the ideal outcome, it may make the next conversation about this issue or another issue, easier to handle. There will always be the "next one" to do even better.
Comments