Every product manager and product owner I know is smart, hard-working, and dedicated to their organization’s success. Why, then, do developers AND business stakeholders still complain that Product Management is ineffective?
As a trainer of these roles and a product manager myself, I am genuinely curious to understand why this feedback is so pervasive. Regardless of how skilled I know the PMs and POs are, regardless of how effective I assess their process to be, our primary stakeholders are often not happy with their interactions with us.
Here are four areas that I always hear about, and some ideas that might help to get higher satisfaction scores from our two key stakeholder groups. The links below will help you jump straight to any areas that are hot buttons for you today!
- Developers (or business stakeholders) feel ignored
- Priorities are based on opinions
- Organization doesn’t understand the PM role
- Unrealistic expectations about scope and schedule
Developers feel ignored
…if our focus is on business; and business feels ignored if we spend too much time with Development. Yes, we are way too busy to spend as much time as we want with either side, especially if we spend as much time as we should with customers and prospective customers!
- Ensure that the time you do spend is “quality time”. Use every opportunity to remind our internal partners of the current strategy, and talk about current wins – any anecdotes you can share from the front lines will be appreciated. Build in “listening time”. Don’t respond defensively; be thoughtful and factual in your responses.
- Leverage the Product Owner role to extend your Development-facing time. If you are both the PM and the PO, then of course you’re overloaded and don’t have enough time for the rest of your business-facing responsibilities! In organizations that have managed to split off the PO role from PM, I hear over and over “I can’t get my PM to spend enough time with me.” If you have a PO (or 2 or 3), you may need to dedicate 10%-15% of your week to sharing context with them and answering their questions. This investment will decrease over time, and pay back massively as your PO becomes more empowered to represent customer needs and roadmap priorities to the team. They have to know what you are thinking and why.
Priorities appear to be based on opinions
…ours or or someone else’s opinion who they don’t care about. If your priorities are like a flag blowing in the wind, then you’re spending way too much time managing them and the various people who want to influence priorities.
- Establish priorities through a structured and transparent process. Not that the CEO or your GM can’t override them… but this should be rare, not typical.
- This is where PM leadership should step in and create a prioritization framework that can be applied across the organization. But if that doesn’t happen…
- Make YOUR process structured and transparent. Use cross-functional product team input to guide your structure. Make the process collaborative so that each function’s view-point is represented. Use product strategy as a key pillar of prioritization (you have one, right?). Use strategic bucketing to avoid prioritizing apples against oranges. Don’t make it so complicated that it requires lots of analysis to arrive at answers (see WSJF as a starting point!)
The organization doesn’t understand what you do
It doesn’t know the scope of the product management or product owner roles. I refer to this issue as “The elephant and the blind men” syndrome. Everyone sees some slice of the job; no one except PMs know the whole scope of the role. Scrum defines PO responsibilities that overlap product management responsibilities, further confusing the issue.
- This one needs PM leaders to step in and educate the organization. This starts at the top, with getting executive-level consensus on the scope of the roles. Often that means making sure that everyone understands what product managers will focus on as a priority, and what kinds of things may not get any attention. Keys to success here are working with the various functions to make sure important tasks don’t fall through the cracks, there is no overlap with existing responsibilities, and the focus areas are aligned with business goals and strategies.
- If the above approach isn’t going to happen, then you may be able to negotiate your own scope with your cross-functional product team. Use RACI and DACI tools to hep you clarify how the needed work will get done and how decisions will get made. Be open to feedback and changes through a regular Inspect and Adapt cycle.
Everyone is unrealistic about what can be accomplished
…in the time available with the current resources.
This is not a caused by a lack of skill or desire to perform. Everyone really, really wants to get everything done, deliver amazing results, and make all customers happy. This is a systemic issue: the process and tools need to be improved so that expectations are more in line with what is possible.
- Product Management’s job is to say “When” (and sometimes, to say “Never”). If you have a strategy, if you have a transparent and structured prioritization scheme (and everyone knows both of those things), then there should be very few surprises about what is being requested for delivery, and when. But then it’s up to Development to determine how much can be delivered in the requested time frame.
- My bias will be evident here: Agile and SAFe provide good techniques for doing better estimates. What does that have to do with Product Management? It doesn’t, directly. Estimating development work is Development’s job. But as PMs, we need to advocate for the use of these techniques: learn them, do your part, and respect the results when Development applies them.
- Apply Lean thinking to the process. Improving Development’s productivity through use of Agile techniques is all well and good, but it’s only part (and sometimes a very small part) of the process and problem. Try doing a value stream analysis on the “concept to cash” cycle in your organization to understand where the delays are, and shorten those delays. Sometimes our stakeholders demand that new requests be delivered in the next release, causing scope creep. But when the overall cycle time is reduced, waiting for the next release is far more tolerable. So go for shorter time frames, smaller batches, and attack delays across the entire process.
Product Management is a tough job, no doubt about it. But try a few of the ideas above and see if your stakeholders change their opinions!
I’m interested to know from you: are your stakeholder groups satisfied with Product Management and Product Owner performance? What are your secrets for success? Major challenges?