In the big companies today we have product designers. People that came from the UX/UI role but now have all the product/business mindset.
They know how to keep track of task, they know how to measure the success of a feature.
How do you work with them? Its like PM/PO overlaps with product designers, but designers have a plus, they design/prototype/animate etc.
Melissa Perri explains the way it is supposed to work, “Product Owner is a role in an agile process, Product Manager is the job.”
However, at many companies, the practice is that the PO focuses on the internal and more tactical or inbound, while the PM focuses on the external and strategic or outbound.
As for the split of responsibilities, like others have mentioned, it’s a team sport so they should be shared since we all want the product to be a success. You need to build a trusting relationship where you can have healthy debate and tight collaboration, and defer to each other along these lines:
Product: Value and Business Viability
Design: Usability
Eng: Feasibility
While it’s true that modern product designers have that business mindset along with a design skill set, it doesn’t mean the role of PM can be replaced by PDs. Overlapping skill set means (should mean) better communication between the two parties. For example, we don’t need to communicate and sell the idea of talking to users or why discovery is beneficial.
The common question that arise is who owns what if both PM n PD does almost the same thing, especially when it comes down to tracking metrics for success? The answer is, both and neither.
It’s actually highly unproductive to fight over ownership of responsibility (and in some cases, documents). To build a successful product requires team work. The responsibility of roadmap, metric for success, and etc, should have contribution from both PM and PD.
@JesusRojas, You are so right! The problem that I’m facing in the last 3 companies is that PMs and POs “do the same job”. And for worst, no one has any documentation, any idea of how we are going to set the success metrics. And always try to have the last word on design things, like… mmmm that cta should say XXX or isn’t better to have that text inside this or that.
As far as I know in LATAM I’m not finding any PM or PO that works in the roadmap, prioritization etc. Its like business waterfalls something and product only take that and ask UX/UI to make it as fast as possible.
Teresa Torres and Marty Cagan talk about a Product Trio:
Design Lead
Tech Lead
Product Manager
This article from End Game provides an overview of the roles and responsibilities.
In my past life the PO acted as the Scrum Master and owned the agile process and ceremonies and documentation.
This may seem reductive to your overall problem. But I’m always curious about PMs who need to be the top of the hierarchy?
Maybe I’m a bad leader. But I’m more than happy to let someone take decisions or responsibilities off my plate. If someone makes the decisions on Design, I get to focus on logic and support.
I’d probably ask, why can’t you own a product while they own the design? Or, “why can’t you own the product while someone at an equal level to you owns the design?”
Hello @JoelSchulman,
I think about this as well, and this is what I came up with. (Feel free to disagree)
Product Manager oversees multiple products in a suite and a PO manages one of them. The PM coordinates PI planning with the POs on the shared FY vision and roadmap.
Product Designer ensures the unified experience is consistent between products within the suite and tracks the UX maturity score and SUS score. Has vision on the design system, workflows, accessibility score and coordinates with Dev manager on UAT.
PM is focused on collective health of the suite for business success. Monitors dependency report between ALL shared services. Makes sure each PO is tracking release management with QA ahead of code freeze for client presentation.
PO is focused on delivering specific commitments and releases. Monitors dependencies specific to their workflow, but nothing else. Relies on PM to coordinate with other POs.
PD coordinates with UX Researchers and Designers specific to each product. Ensures UX is two Sprints ahead of Dev for usability testing and prototype handoff. Maintains business vision with PM and facilitates product demos for stakeholder feedback.
Everyone is aligned to the specific fix version, so no one goes outside of operational parameters. Even though UX might come up with an innovative solution, they can’t deviate outside of the technical debt of the Dev team without presenting it and submitting a change request form on the feature release so everyone can adjust.
No one works in a vacuum. Transparency is paramount. If there are problems, an impact report has to be submitted for executive review.
Everyone has to operate within their budget envelope.
Finance team works with Sales for closed loop analysis to measure business impact on ROI.
Project Manager works with PEO to make sure everyone is tracking correctly and in the correct fix version.
Dependency Reporting is vital for the roadmap.
Reporting is broken up based on Strategic Leadership. (1.) Executive team looks at budget. (2.) Product team looks at dependency report. (3.) Sales team monitors planned release date and participates as SMEs and assists with usability recruitment.
Good luck and I hope this POV helped!
I am a design lead-turned-pm and while the work may be similar, “how” you do the work is quite different especially for a large scale product. A PM is responsible for coming up with a vision/strategy/plan AND socialising it even before the concept work starts, in order to align with the broader product/org goals and to get the stakeholder buy-in.
When I was a design lead: I would pitch for the experience strategy for the given area I was responsible for, owning the design resourcing, guiding other designers, getting work done, aligning with design managers and pm and eng counterparts.
When I am a pm: experience strategy with input from my design partner, while also building partnerships with other stakeholders, aligning with org goals, defining priorities and metrics, tons of presentations, doing both development and process work for the team (unfortunately, sometimes product manager has to implement some process in order to deliver quality product).
I let people assume roles and take on responsibilities. I do not try to prescribe boundaries.
Over the years I’ve found this works best for me, bear with me as it’s a bit abstract:
Ok then, few examples:
Team 1: PM, 3 Devs
PM + most senior Dev = Discovery stream
PM + all Devs = Delivery stream
Team 2: PM, UXD, Tech Lead, 3 Devs
PM + UXD + Tech Lead = Disco
UXD + Tech Lead + all devs = Deli
Team 3: PM, BA, Delivery Manager, 5 devs
PM + BA + Delivery Manager = Disco
BA + Tech Lead + All devs = Deli
Once you established who is in the Disco team, you treat that team as a separate Agile team. You need:
I find that 1h weekly meeting with the DISCO team is all that is needed for these ceremonies. As for daily standup - your relationships in the team should be strong enough that you don’t really need it, all Disco people should be talking about when they see each other is progress on the Disco work, who needs help, is the progress good? keep each other accountable.
Product’s most important role is leadership, I found above approach let’s me shape the right outcomes, monitor them and constantly tweak, but at the same time benefiting from everyone’s experience, knowledge and intelligence. Team doesn’t have UXD? fine, we’ll need to handle without them, but when we get one - amazing, we can do so much more together!
Maybe this is my frustration speaking but it seems every function secretly feels like they can PM better than a PM. There are all kinds of trade offs PMs make to balance the feedback from different stakeholders against each other; design considerations are just one of many that need to be factored in.
For example designers have great product sense but the natural inclination tends to be to think holistically, that means working incrementally and scoping work to MVP is less of a strength. They also sometimes have trouble quantifying the business impact of what they feel are the objectively correct design decisions. As a result a pattern I’ve seen in teams led by design Is to overdo it on redesigns that tie up the Eng team for months without adding incremental value to users. then ultimately the projects don’t test well because they change so many things in the ux at once, only some of which actually helped users.
Doesn’t mean a designer can’t be a good PM but sorry, no, it doesn’t track that designers are PMs who can also design
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.