Is it your job to solve the problem, come up with all the features and the functionality and hand that off to the team or are you prioritizing problems and the features/improvements are a collaboration and come from anyone in the team?
(I am curious if the team is empowered and design is a leading role, or just a service position - they just do the UX/UI).
As a PM, it’s not really your job to come up with the solutions, but it is your responsibility to figure out which are the best solutions to solve. A true empowered team comes up with solutions together - and by that I mean your whole org. You have the knowledge of smart people around you, so work with them and tap into their knowledge.
You shouldn’t treat anyone in your team as a “hand off” - work with them, not next to them. That is what leads to silo’d teams and creates misunderstandings.
@Marco, I didn’t say that this is how I think and work, but I wondered it is in everyone else’s company.
It depends; there’s definitely a mix of both for me. Sometimes a solve for a problem or new feature addition is relatively straight-forward and doesn’t really warrant a ton of discussion. Sometimes stakeholders will come with their own ideas, and I synthesize them a bit with other feedback I’ve heard (if applicable) around similar types of problems, and then bring forth that idea.
But, it’s foolish to think I’ve got all the right answers. Typically when I think I’ve got a good solve, I’ll run it by some other partners (engineering, UX, and another PM or two) and see if they’ve got better ideas. Larger problems warrant a larger group brainstorming how to solve it.
I always try to think about my engineering and UX partners. UX folks want to be creative, and so do a lot of engineers. If I just feed them exactly what we ‘should’ do, we’re limited by my creativity and insight, and not letting others flex some muscles that ultimately will build better products in the long run. It’s important to include others in your ideation process.
@Nathan, Totally, that last point is something I’ve learned myself recently, being sure to initiate brainstorming with the group instead of just proposing a solution myself.
Anyone on the team can have a great idea. It’s the pm’s job to spot them, nurture them, plan research, scope them and create a strategy to make it real and go get buy-in.
Healthy team collaboration and engagement often start from each member of the team feeling their ownership. Your role is to lead by presenting a tangible vision (this is to create clarity, not solution) so that your team can come up with the best solution out of their expertise.
Now pragmatically speaking, you may do some early work (rough visual mock, etc) to bring people from abstraction to practical problem solving space. But once you get there, unless you don’t have UX/eng partners, you let others do what they are good at.
The fact that you even expect to come up with features and solutions as a product manager is a huge red flag. You frame the problems - others solve them. PMs attempting to solve anything and everything instead of the engineers, and designers, is cancerous. You’re not Steve Jobs. Stop pretending to be. Any org where UX is a “service” position, is a company to be avoided and likely builds shit products.
@Lawrence, I never said I expect that. I made the post so people like you can share how it works in their org (hence the post title).
At my org -
Share ideas - everyone involved in the product
Decide which problems to go after - PM
Ideate & decide on a high-level solution - Scope guardrails are set by product, design leads the ideation/solutioning, but it’s really a collaboration between product, design, engineering.
Design the solution - Design, but with frequent feedback from product & engineering to ensure feasibility/viability.
This is similar to what is followed at my org. on a smaller scale however.
It makes sense that deep collaborations result in a constant feedback loop between UX and PM where PM can ofcourse give recommendations about Y(say a userflow) and UX can either agree or disagree. At the same time the PM should have the mindfulness to take a step back and not push back depending on the depth/breadth of their knowledge about Y.
It also about the teams synergy overall and how comfortable they are accepting a solution over ego/politics, which is often the case as your scorecard maybe dependent on it.
What do mean by “just do the UX/UI”?
A bad company will have no UX researchers or designers, maybe the PM or PO does what you mentioned and passes it to a UI Designer.
A good process would be to have the UX Designers solve the problem, and do the UI themselves.
While its possible to have someone “just do the UI”, it’s not possible to have someone “just do the UX”. UX is defining and solving problems.
Also, “UX/UI” is a stupid, misleading term. UI is a small segment of the overall UX work. It’s like saying “my favorite fruit/banana”.
Using it sort of highlights a lack of understanding what the two terms are.
@Donovan, I didn’t give my opinion here, but wanted people like you share their experience. In many companies it works in a way that design is just about making it work and look good. In some (worse ones) it’s even the management that dictate the product feature and the PM is more or less just a project manager that needs to make sure it happens soon.
I agree 100% (as most would probably do in this sub) and work like that with my team - that’s how PMing like “in the books” (and many companies I know). I’d like my whole company to function like that, but unfortunately the VP of Product believes PMs should do all the research, decide on solutions and functionality. Design is, quote: “how things are surfaced in the app”. So, he doesn’t push back when other PMs just constantly design a solution and come with the final (often weak) result to engineers or designers, which can be very frustrating for the team.
Anyways, Thank you all for taking time to post your insights.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.