What role do PM/POs have in a company that has Product designers (UX/UI)

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.

8 Likes

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

8 Likes

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.

7 Likes

@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.

6 Likes

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.

5 Likes

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?”

4 Likes

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!

3 Likes

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).

2 Likes

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:

  • each team has two streams: Discovery & delivery.
  • Discovery stream’s objective is to keep growing our understanding about the external factors (users, market, stakeholders etc.) and manage the roadmap based on this and the feedback from the delivery team.
  • Delivery stream’s objective is to keep growing our understanding of the tech space (what’s possible, what tools are there, how to use them, their limitations and strengths etc.) and manage day to day delivery of the roadmap.
  • These teams must overlap - At least 1 person from Discovery works very closely with Delivery, and at least 1 person from Delivery works very closely with Discovery (they are not the same person)
  • They can overlap more is certain specific products, or from time to time if the situation requires it, but I find that if the Discovery delivers their outcomes well, Delivery is less and less keen to get involved, and vice versa, a trust develops. But do not let them drift completely, at least 1 must be there (as per point above)

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:

  • You talk a lot to agree outcomes. What do we need to achieve in 1 year, 6 months, 3 months
  • simple backlog, in progress, done board
  • You need to talk regularly to refine the backlog - what do we all agree needs doing
  • You need to talk regularly to agree who’s doing what, depending on what other commitments and time is available
  • You all help each other. Help is needed in Testing before release - we all test. Help is needed in user interviews - we all help. etc.

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!

1 Like

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