It can be frustrating as a Product Owner to have limited interactions with external users and have to rely on others to share customer pain points and wants. As a PO, I have no interactions with outside users and must rely on product managers to communicate client needs and pain points, which is not what I signed up for. I think it’s demoralizing. PMs are frequently a bottleneck for me in terms of getting quick client feedback. How would you handle such a situation?
Limitations in getting Customer Feedback due to PMs
Yes. You clean up the backlog and unblock the blockers for the developers. Give the big boys the job of dealing with customers. That’s the way.
RELAX, JUST KIDDING.
Nevertheless, at a smaller organization, PM/PO/PjM exist on a spectrum, and you’ll likely be asked to wear all of the hats depending on the time of day and the task at hand. In a larger organization, you definitely won’t have enough time to divide between talking to consumers and talking to engineers.
That being said, your PM is not doing a very good job if they are a bottleneck for the information you require. You should strike up a conversation with them to determine how to obtain the data you require quickly and in adequate quantities.
Or, you could crush them because they are weak and place them on the massive product totem pole. You are you.
I’ve never worked for a company where the PO function existed. Although working as a PM for more than ten years, I have no idea what’s going on. The key to a thorough grasp of pain concerns and frequently to nailing the solution is customer discovery. Why would anyone who interacts with the product ever desire to be cut off from that?
In other words, you’re not crazy. What’s the next step for you? Why don’t you guys just have PMs who handle both PM and PO tasks instead of operating in this manner? Can’t you just like bypass your PMs and talk to your customers directly?
(Also, could someone perhaps clarify the justification for separating POs from customer input?)
Here are a few suggestions to help you overcome this challenge:
- Communicate with your PMs: Have an open and honest conversation with your product managers about your need for customer feedback and your frustration with the current situation. Discuss ways in which you can work together to improve the process, such as setting up regular meetings to review customer feedback or finding ways for you to directly interact with users.
- Attend user research sessions: If your organization conducts user research sessions, ask if you can attend them to observe and listen to users firsthand. This will give you the opportunity to gather customer feedback and better understand their pain points and wants.
- Conduct user surveys: If you don’t have direct access to external users, consider conducting user surveys to gather feedback on specific features or pain points. This can help you gather data and insights to inform your product decisions.
- Network with other stakeholders: Look for opportunities to network with other stakeholders in your organization who may have direct contact with users, such as customer support or sales teams. They may be able to provide valuable insights and feedback that can help inform your product decisions.
Remember, as a product owner, your goal is to create products that meet the needs and wants of your customers. While it can be frustrating to have limited interactions with external users, there are still ways to gather customer feedback and use it to inform your product decisions.
I was the PM in this type of situation. In our case, we worked with multiple PO’s and teams. The PMs managed the larger roadmap and worked with sales and marketing and internal leadership. Our PO’s handled the user stories and working with technical teams and business owners. We did try to include the PO in customer conversations and discovery though.
Interesting @TinaGreist. What are the benefits of this approach for your product? I assume a big part of it is allowing the PMs and POs to focus on their unique roles instead of having, say, user stories getting short-changed because of a distracting sales call. What else?
I don’t work there anymore and neither do most of the people that I worked with. So I can’t necessarily endorse the plan! It was a large company. Tens of thousands of employees. My product was supported by a few thousand employees. It was in Ed tech and served both B2B and B2C.
We adopted Scaled Agile, which calls for the PM/PO split, but it was same breakdown even before that. Our product team was very small. 2 PMs with 16+ teams. There were a dozen or more POs who were originally Business Analysts who were part of the technology department. Product was its own division.
As for benefits to the product itself. It was a complex piece and the internal business teams required a ton of support. Most of my time was spent working with internal business teams. A PO would have never had time to work with developers. And the business teams would never have known which of the POs to turn to with their questions.
PMs in organisations with both should be considering the long term and keeping a wider strategy in mind. 3 months to 3 years is a possibility. They outline the main issue to be resolved (objectives, success measures). They devote a lot of effort to engaging the market and pursuing ROI, projections, and other things.
The POs will be focusing on how to break down that big issue, and they’ll need to collaborate with the team and users to find a solution. Obviously, PM will sign off.
This is generalizing a lot, but it gets the point across. While not all locations or products require it, those with large teams and numerous interdependencies do.
I think my product/org qualifies as large and complex with lots of interdependencies. I think we might have a version of this, though. We don’t call them PM/PO, but we have a Sr. Director who owns the product; he has managers under him who collaborate with him and one another on the vision, strategy, OKRs, and roadmap prioritization. Then the PMs who report to those managers are leading execution, user stories, etc. The difference is that everyone at all levels is talking to customers and contributing to strategy, working with sales, etc. I guess what I’m saying is that our PMs (in our case, our managers) do what you described as PM work, but our POs do PO work and some PM work, if that makes sense.
This makes sense, it actually seems pretty similar but with different titling. For us it goes Dir Product, and then that lead has Product Mangers, Product Owners, and Product Analysts (like Business/System Analysts)
I must have over-generalized, because our POs do all the things you do. The POs have strategic insight into lots of things the PM may not, and they’re engaging with sales and users in different ways.
This was interesting, it’s always good to hear how it’s done at other places.
I have seen organizations where PMs do the discovery and roadmap, and POs the execution.
The more execution side of things can include analyzing requirements, writing requirements, documenting requirements and design approvals, acceptance criteria, system flow charts, impact analysis, test plans, running scrum sessions, managing the timeline, resources etc.
@BinaCampos, 80% of what you listed there is straight program / project management and has nothing to do with product.
I was wondering why so many people here seem to be working at places that have POs when I’ve yet to find a single company IRL that does that. If project management is just the newest role people figured out that could attract for candidates for by mislabeling it as a product role, that would explain it, I guess.
Great summary @MichellePlowman! I would say PO is project management with some level of product ownership.
With regards to the question whether PO is a true product role. Well, in many organizations, PMs are not truly empowered (not ideal), and doing heavy project management work too.
Unfortunately OP this may be what you signed up for. Here in AU it is common to see Product Owners as a delivery focused role.
Alot of orgs will have only PMs who do strategy and delivery, but larger/more advanced teams have split out PO, with that focus on delivery and shipping. I’m a PM but being in a smaller team we don’t have POs and I enjoy the PO work a lot!
But IMO this is where POs have amazing opportunity to facilitate change through process, and can and/or are best suited take on more of an agile coaching, agile practice lead role within technology teams AND in educating the wider org.
Sounds like your working with SAFe. Good luck did that for a year as PO with an incompetent PM. Product was a disaster. His most valuable input was “we need a feature with this name”, more he couldn’t provide. If you’re getting actually customer input; I’m jealous. I left the company.
My life is to short for SAFe