You have more agency than you think!
Here's a phrase that I started using quite regularly, to help people to remember that they don't need to be victims of their circumstances:
You have more agency than you think! You just have to figure out how to 'nudge' things in such a way that is not as contentious, that is not perceived as defensive or not "wanting to play ball".
(Side note: this happens to be part of the message from my upcoming talk at the Online Scrum Master Summit, as shared last time here. Yes, here I am again quite shamelessly "selling myself".)
But that wasn't the reason for deciding to write about it, there's something else that got my attention recently, so I thought of further elaborating on the overarching theme. The other day,
's Newsletter presented a guest post with a kind of counterargumentation in the whole Feature (Factory) x Empowered Product team debate by .It was quite an insightful piece, and I agree with him that defining the work of PMs in a context that is still output-oriented as the work of a Project Manager is a stretch – there's much more work that goes just simply into better understand the feature the stakeholder wants and even try to influence how to approach it from a solution standpoint.
And while I also agree with the challenges indicated when a PM tries to move towards outcome-oriented in the same context, I got a bit of a sense of a risk of falling victim to your own circumstances (full disclosure: I am not a paid subscriber, so coudn't get to the advice Ben would give to PMs in a feature-based request context, and chances are he covered some of the elements I am going to articulate there, I just can't know…).
Since I do have firsthand experience in the matter, I thought of offering some perspective on how I try to coach PMs to gently move towards outcome-based, without being too upfront and confrontational to the current ways of working (feature-based request).
Start with YES, but learn to say not now and/or not that way
Many people say that the biggest skill a PM should learn is to say 'no'. And yes, there's a lot to it, but an upfront 'no' will always feel contentious to the other end. Is there an alternative? I frame my way of looking at it as stated in the heading. To be clear, when I say start with 'yes', I am not implying at all to just go with the feature request as-is, but rather approach the request with empathy:
Engaging by presenting a positive attitude to ideas and opinions from others;
We all want to be right, and part of the role of a PM, the way I see it, is to know how to steer that human tendency in a way that is channeled to what matters most, which is to solve the problem we are set to solve;
The role of PM is being (i.e., current state) the "owner of the product", which is quite different from being the "owner of truth".
That's only effective if followed by learning to defer commitment until we know more about what we should really do, gently trying to 'nudge' the process in a way that there's openness to question the current request.
A quite powerful way to do that is to understand the underlying 'why', but again bluntly asking that might come across as too confrontational. A more nuanced way is to ask the requester to "tell more…", what are they really up to, and what is the working theory in their minds that is leading them to propose that solution (output) right on. Can we then later focus on the deeper level of where they are coming from instead? Can we figure out what needs to change in terms of behavior, and then prioritize that instead (keeping the solution space open for grabs for the time being)?
Change the conversation by grounding decisions in value (or acceptable proxy of it)
I find that quite a game-changer is when PMs learn to ground their decision-making in value or proxies of it (including metrics). If we can speak that language, the conversation about whether to invest in certain features or not becomes naturally less emotional. To force that rigor and discipline is something in the realm of the influence of PMs that they perhaps do not always realize (the agency they can have).
Stakeholders would probably appreciate over time that change of conversation grounded in more concrete things like value, metrics, and things like that. It's either that or they are just too much a HiPPO (highest paid person opinion) figure... And if the latter is the case, maybe the next tip can come in handy.
If you have to commit, put on clear guardrails
Chances are that sometimes you will just have to run with the last "brilliant" idea of your (favorite?) HiPPO. So the question becomes how to do that in such a way that you are not risking a downward spiral in case that feature is so off. The key here is to try to agree to some clear guardrails, such as to invest some small-ish level of effort and set success criteria to be used to decide later on whether to further pursue that route or go back to the drawing board.
Think of it as accepting to include an option to your work portfolio of bets that you know upfront it's quite risky. Sometimes you just have to try it and see how it goes. And for as long as there's clarity to prevent entering into a rabbit hole, that can be even a strategy to win over trust that can help over time to change the conversation towards focusing on the outcome first, then let the PM and the team figure out the possible options (output) to go after.
******
So, there you go! I hope this gives some insight on how to act upon the agency you should have as a PM, and level up your game in a way that hopefully overtime wins over the overarching organization too. It's a worthwhile (uphill) battle to take, and maybe you'll never fully get to a truly empowered product team setup. But it can be a much more fulfilling work experience overall. Life is messy… and nuanced, and there's probably something like a spectrum between those two extremes (Feature team x Product team).
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.