Karen and Ritzie talk about: Product Management and UX - Overlap, Boundaries, and Collaboration

Hey everybody, my name is Ritzy. Today we're gonna be talking about product management versus UX management. I'm here with Karen. Karen, please, for those that don't know you, who are you? What do you do?

What's up? What's up? My name is Karen. I am a senior UX designer. I'm about almost a month in, so it's week 4. I'm still, still fresh, still getting to know the lay of the land. And, you know, I'm just, been a really joy, real joy working with Ritzy. So we're here chatting and I couldn't be happier. So. Glad to meet y'all. I'm not from the South. I just said y'all.

Karen and I have worked together for a few years actually at a previous company and starting as, I guess both of us as designers and then I got moved to manager and we've solved some big problems and designed some big features. So we have quite a history. But getting into the product management versus UX management, Karen, what, how would you describe product management? As a whole.

Okay, so based on my experiences and what I understand, product, product management, um, I feel like sometimes it's a little mushy-mushy with project management. The product management is, um, somebody who guides every step of a product's life cycle, right? And what that means is, um, everything from like the genesis or like the concepting of a product to the development and execution of it and a lot of the things in between. I think it's just the overarching organizational, like, function that guides every step. So that to me is product management. They see end-to-end and any continuation of the product. What about you? Any thoughts there?

I think you nailed it. I think that differentiating factor between a product management and a Project manager, I think that is the difference, as you mentioned, with the product manager. They own a product from end to end, which is a continuous, it's a product, right? It keeps going, you keep enhancing it, you keep working on it in comparison to a project which has an end, right? We do work from here to here. And I think that product owner does, or the product manager, they manage the product from concept to delivery, like you said. But how does UX fit into that in your, your idea, whether it's a UX manager or a designer, how do they, how do they collaborate with that product manager?

Well, I really think that UX designers, if we're talking about UX designers specifically, or just, you know, anybody working within UX, could be researchers too, is that at least at the lead or like the higher level, they are I think there's like, it's kind of jargon, but like thought partners, right, with the product managers and anybody else who's kind of collaborating and creating this product together. I feel like a UX, UX is a piece of that, right? And I just see it as an equation. I don't know that it's often the case in many corporations or organizations and whatnot, but UX management should be part of the overall product management in my mind, or the practice of management, right? I think UX specifically is just like the, you know, the design-related or strategy design-related activities that goes into the product itself.

I like how— I loved how you called it the thought partner, right? Like, that was a cool description, it's like they, they work together to kind of figure out that, that strategic thinking and direction with a product manager who helps kind of the, take the, the thought into reality in a sense, right? Where UX is more conceptual while the, the product manager helps the actual building. I sometimes use like architecture, right? Where we are more of the architect. UX is more of the architect. We're doing the blueprint. But the blueprint is not the building, right? Someone's got to build the building. Someone's got to tell the construction workers how to, you know, where the land is and stuff like that. And that's kind of, to me, what the product manager does in comparison to us, where we figure out, okay, where there's going to be rooms, how tall is it going to be, you know, things like that.

That's one of my favorite analogies, and I'm so glad you brought it up because it really does paint the picture, right? And I think it's a reminder that UX whether it's, you know, all the different phases of design process, right, from research, I mean, discovery research and actually creating prototypes for testing, whether it's UX is essentially creating those assets to fill, to create the blueprint and the different deliverables needed for engineers, for example, to build something. And I think product managers are overseeing all of that. So I think we touched on project management. I think that Though that specifically is more like the knowledge base and the skills, the tools and techniques that go into delivering something of value. And I think that both product management and UX management, you know, require project management. And so that's where it gets really interesting to me is like, where is the overlap or, you know, the boundaries or, you know, if there are any or you know, what the differences are and the similarities and how each apply to get to where they want to go.

And where are those boundaries? I mean, based on, on like previous experiences, I know, or I've seen where UX is doing some project management work, like I've touched the backlog in the past. But sometimes, you know, that can be, I've also had areas where I've never even seen the backlog, you know, so in your experiences, I'd love to know what you've seen in terms of those different roles and how they've connected in that, in that regard?

The connection between product management and user experience?

Yeah, yeah.

I think we really got an insider's look, especially working with like, what is it, TFS and all of the different programs and having to step in to fill some of the gaps that we saw and some of the needs based on, you know, circumstances there and I don't know.

With those, like, I know a lot of the times we filled the gaps, right? Like we would do, like we would fill in some of the feature, we'd fill in, um, some of the details. Um, at one point we were doing development, we were doing, um, all kinds of things, but obviously I, I know it gets a little, uh, intrusive into other people's jobs in a sense.

Absolutely. And I, you know, I feel a little bit like that right now. And so I'm still kind of like exploring and trying to figure that out. And I don't know that it's best practices based on what I've learned, right? And so, and you know, maybe the same for you as well. So I don't know that it's industry best practices. So And actually would love it if, you know, anybody listening out there has insights, feel free to chime in and, you know, add in the comments. But yeah, I think what really works for me is being communicative and I think really transparent about what's going on, what I'm having to do and, you know, allowing my manager to have insight on that too and just visibility in a lot of different, tasks that need to be done to some extent. I think it becomes really important and also almost inevitable as the team is scaling and there's not necessarily like a product manager. And so I think that's where designers or a lead designer had to step in and kind of fill those shoes and dance around with our Scrum Master to try to figure out, you know, how projects were being scheduled and who's allocated to what and what needs to move based on you know, what was happening in each sprint. So I don't know if I have an answer to that. I mean, it's just the boundaries are a little muddy, I think, in my mind and maybe yours and, you know, many others. We have our own definitions of how much project management or product management we should be doing as UX designers and what that breakdown looks like.

You know, it's interesting too, because thinking about our timeline and our previous experiences, we went from where UX was very siloed, we, we stepped back completely and said, we're gonna do all of our, our stuff over here. We're gonna manage our backlog completely different. Remember, we were using features for enablers. Like, we are not gonna connect with you at all where we were, we transitioned completely away from that to literally connected to the, the product where we were doing all of, we were managing almost all the entire backlog. We were filling out the features. We were filling out our stories where you would look at theirs and they'd be blank or you know, it would, it was done, you know, differently. And I think there's, you know, just in more exploration, there still needs to come kind of be both where UX owns its work, but the product manager needs to take it from there and start connecting the rest of the dots. You know, it needs to make sure that the Scrum teams that are building the stuff has the right information. They have the understanding, but I do think they do need some of the UX understanding that we go through the documentation, understanding the problem. Some of the predispositions, things like that to help fulfill that. It's, I've run into a problem where people think like, they're, they have, like, only they can touch this file, right? This kind of this, whether it's a feature, only they can touch it. They become like possessive or they need to lead it. But, you know, sometimes you get more, you have to like get the sources from other people, a collaborative event. If you lead, if you look in like Scaled Agile Framework, it says like, it's owned, features are owned by the product, the product owners. But where are they getting the problem from?

Right, right.

It should be from, from research, right? It should be, they're gonna have to get the links to the prototypes from the UX designers. They're gonna have to connect the stories with the developers and manage those stories and stuff. So it's, I do think it's a collaborative event. And more recently, we've actually moved our, our documentation from, you know, where we were doing, we used to do it in Confluence, then we started doing it in, in ADO, Azure DevOps or TFS. And now we're pulling it back and saying we need, we need that information for UX from the enabler side to transfer it over to, to like the UI designer. We need to try to keep that together with our understanding. We don't necessarily, we shouldn't be filling it out for the product, the product manager or product owner. If they want it, they can still come to the Figma file and get it, copy paste, still do the same thing. But we need that from the enabler, you know, the conceptual level to the visual designer, right? Because you're still kind of taking that information, right? As you're creating the, the concept and you pulled the research from these apps, the visual designer still needs that knowledge. They still need to see the same things so that they can use that to inspire the, the actual high fidelity and what's going to be built, the blueprint, if you will.

Absolutely. And actually, you triggered something as you were speaking. I was thinking of product management as the resource hub, right? Like, they're the connectors. They're talking to all different kinds of teams within the organization and pinpointing the people and the key facts and insights and drawing them out and putting them together. Hopefully, like some sort of documentation, right? And helping to track and monitor that in this living document, like you said, which is accessible, but also, you know, like, what is it, modifiable or editable by other people too that are heavily involved. And so you're right about them being this huge collaborator because they really are like the connector, the collaborator, facilitator. Um, overseer. So these are huge issues, right? And but I also feel like if everybody else is, you know, chiming in and helping put the pieces together, it's— it really is just like a team effort also, dependent upon how they're setting things up and how they're in their management style, right? Um, and the relationships and connections that they have with people at the organization. So, yeah, I really, I see it as, as something that's really, really interesting because I think no matter which organization or company that I move to, there's always some sort of, there's this, this piece of it that always needs a little bit of like tweaking and a little bit of love, right? Or a lot of love. And it's just an ongoing, I think, process to to work on it iteratively. So I found that really interesting, and it's because we're dealing with people, right? And so any time there's people and different people involved, there's many different layers. And yeah, I feel like that's what keeps it interesting, but it could also be a source of, you know, all different kinds of feelings and frustrations based on the circumstances. Right.

I love how you, I love how you describe the, the products, the product managers as connectors because I, I completely agree. I feel like that's the, the primary area is making sure that everyone has what they need in order to create a successful product.

Yes.

Right? And, and pull those connectors to, to together, which is very similar to what UX needs. Right? They still need to understand what they're trying, what the business is trying to fulfill. They still need to understand the technical feasibility, whether the, the solution is actually buildable. Affable, as well as the user need. Right? In which I feel the, from the UX standpoint, the user need is the primary, is, is a primary need. From the product standpoint though, the user need is, is less important. They don't need to focus on that. They need to focus on making sure that the solution that the UX team has put together from those understandings is gonna be able to be implemented. Right? They still need to know it. Don't get me wrong. But it's less of a, the level of primary use case from each becomes different.

Do you think it's more like people-centric then? People-centric management?

In a sense, yeah. I would say that as a product manager that it's connecting the people that are actually working on it while I guess UX is connecting the user to the product.

There's like a funny analogy that popped into my mind is, are they then kind of like event planning or like wedding planning? Product management. Yeah, I mean, yeah, I guess.

I think, I think product management, like, since getting more into it and starting to do it and, you know, actually implementing it into my, like, life of events, I realized how much it actually utilizes that. We need to know what we're going to do by when. We need to know, um, how, you know, how long it's going to take to get there. We need to be able to schedule the amount of things, right? Oh, I need to make sure that the, the clothes are ready so that I can, um, we can go to the event, right? And the event's gonna be this long. And then after that, you know, we're gonna have to do this. Like, it's, it's still the same thing. I need to make sure the UX is ready so the development can start. It's, it's a very similar thing. It's, it's really being able to track. Well, yeah, wedding planning, you know, any kind of like, like life management is very similar to product management.

Absolutely. And I, I think, you know, you and I kind of, we talked about it before, but we love how much UX, the design process, but also like product management in and of itself translates so much into real life, right? Or any personal lives and different parts of our lives. And, um, just the, the application part is, is just really awesome because we get to put it into practice all the time. Um, I wonder, and I wanna, I'm gonna ask you about your experiences of like How do you, how do you deal with like the overlaps and keeping boundaries, or do you keep boundaries at all while you're managing a UX team and having to partake in product management sometimes?

Yeah, it's, you know, luckily I've gotten, I've gotten the ability to, I've gotten the ability to work with people that are open, that are open to trying things. So luckily I have been able to explore and show some things and argue my point. Luckily I've built good enough relationships. I feel like that's a very important thing for any team to become successful is the relationship that you have, the team of teams mentality, you know? And, you know, I've gotten the ability to talk, talk it out, explain my point, whether I've drawn it out and they're, you know, willing to take the leap of faith and trust me to do it. I would be really happy if there there were others that tried, you know, kind of pushed for that. But I feel like they, there are kind of others that do, which maybe spark my, you know, my idea that does it, right? It does. I feel like it is a bit of a collaborative process, but I will say there are some areas that as an individual contributor, that's where things get messy, right? Because I may, as a designer, I've had companies like that are very, where I'm working with a PM that's very prescriptive or like a product owner, you know, that's very prescriptive. It should be like this. And And then I've had ones that don't have any opinion at all that are just like, okay, give me the design when it's done. I take your word for it. And, you know, both of those experiences are completely tough because then you have to have the argument when they, when they're prescriptive, right? Well, what about this? What about this? I don't think we should go that way. I'll explore it. And then you have to connect, you know, like you still have to listen to them, but still make them feel heard, but evaluate their solution and see. But those are some of my experiences. What about you, Karen? Same, same question. How's the collaborative event been at either the individual contributor level or even seeing it at the management level?

Yeah, it's— there were some similarities as you were talking. I was thinking about how it really kind of depends on the person that you're working with, really, because everybody works a little differently. There are some people who give you the green light and give you freedom and autonomy and let you kind of run things and are just there for support. Of course, chiming in with their expertise too when needed and giving you, you know, appropriate support, but not really, you know, like not micromanaging, but like rigid in their management, right? There's no inflexible guardrails, for example, like the lines are dotted. It's not a solid double double solid line. And there's some others who, they are, they are more opinionated. Maybe they've been there longer, maybe they've experienced, had different experiences where, you know, there's more of a defined journey in, you know, the steps they take when, when they like, when they manage people and, you know, when they're Yeah, managing the different steps within a product, right? And yeah, I think it really just kind of depends on, on the relationship between the people. And I think in my personal experience, I've been pretty fortunate. I think people have been receptive and open, especially in the beginning, in joining is just They're open to feedback and insights and doing things differently. Change is always a little bit slow, right? It takes a little bit of time to adjust. But they're more often than not open to hearing about best practices, right? And seeing what's going to work better because what's currently in place now maybe isn't the best thing, most conducive to what's happening in the organization. Or they're scaling, right? Things are changing, um, the team is growing and maybe they're growing really fast and they recognize that change needs to happen. They just don't know, you know, maybe how or when and need a little bit of guidance there. So, um, I mean, I'll say it again, it's the collaborative spirit. It's people working together and figuring it out, and that's, that's a journey.

I have an interview question. This is— so I've gotten this question in my interviewing stage. It's when, when someone's not being, I guess, collaborative, or, uh, you maybe you presented a solution that they don't agree with, right? They're telling you they wanna do it this way. How, how, what techniques do you use to help, um, sell your direction, um, or your solution?

Mm, that's a fantastic question. Um, and I'm glad people are asking that in the interview. It's a really important, it's a good question. Um, I think What I'd like to do is, it goes back to how to work with people, right? People want to be heard. They want to feel like they're contributing, maybe, right? The fact that they're speaking up, they want to be part of the conversation, participate and add value in that way. I think I would, I like to ask them, why, um, they prefer a certain way or why they do things the way they do. Um, and I'll do it respectfully, right? And it's just really just to get a better understanding of where they're coming from and maybe get some more contextual information, maybe some historical knowledge too with the way that things were running, for example. Um, and yeah, just try to get an understanding of where they're at. My way, probably. I mean, even though, for example, this new idea, um, that I'm trying to get buy-in to test out, um, is still a biased, um, suggestion, right? Because it's based on what I believe in, and other people have different beliefs. So I think it really is just, um, coming together to understand, right, why we want to do what we want to do, and then deciding, okay, well, next steps, like what is most realistic given our circumstances? Um, can we come to an agreement that we can test it out, test a new idea out and see how, how it pans out and iterate from there? Um, and make it known that it's, you know, it's not going to be a permanent move. We're just, we're open to ideas and that's just, we're trying to keep trying to keep like the, the osmosis, right? This is, this is team environment and, um, you know, there isn't really a right way to do things, um, but maybe just a better way to do things, um, given the time. And so yeah, I mean, I would just start from there and just hear them out.

And I, I, I love your, your people-like-centered approach to it too, like, uh, getting to the root cause right? Getting, asking why and trying to understand their, the reasoning there, they're pitching or pushing for that solution so, so hard. I, I thought that was amazing answer for that. And then even, even finishing it with research, right? Like saying that the solution is to be tested, right? Which I thought that was great too, because that's what you want to, you want to go to, you want to figure it out whether it's not about your solution or your solution to buy solutions. It's about which solution is best for the user. So it doesn't, either solution is all biased or hypothetical until it's tested. So that was a great answer. Nailed it.

But I'm gonna swing it. What was your answer?

Oh, for me, so I, I do, you know, pretty similar too. I, I try to understand, it's also cheating since you answered. I'm obviously gonna steal your answer and throw it, throw it back. But yeah, I try to understand their answer too. I, I try to make sure that they're listened to. I take their, their experiences, their solution, as well as anyone else's solution into consideration before even jumping into solutions. Right? I just say, that sounds like a good idea. You know, I'll keep that in mind when we're designing it. I try to understand, you know, why do you think that they should, you know, why is they want to delete that? Or why is they want to do this action? Or why do you, you know, what are they trying to do by doing that? But I, a lot of times that I've noticed this is different that people get hung up on like stopping their solution or halting solutions. I don't mind you describing it in a solution or in UI, like in a, in an interface description. I'm, because sometimes it helps to just describe what they're trying to achieve.

Right.

You might, I might, you might not even get that same solution back at you when we see it, but at least I understand why and I make sure I have evidence to support why I don't, including if there's any user research, if there's any competitive analysis that, you know, meets the user's mental model, any visual inspiration, making sure that the flow makes Things like that. So I just make sure I come to say, if I go with a different route, with the amount of evidence to support my, you know, my, you know, my claim, right? A lot of the times they're coming in with a solution that's either been told to them or that was thought of quick that did not go through any types of research. While me as a UX designer, that's, that's the job, right? It's to gather all that other understanding is to know the user and put that, put it in their mindset as a, you know, as a professional in that area while theirs is to focus on getting something built. So, right. And, you know, I still will take their idea in consideration and they might not like, sometimes I've done that and not even had like, they, it's, there's no argument behind it. They're just like, oh, okay, that makes sense the way you did it. And it did incorporate my solution. I appreciate being part of the solution process because really that's what we're all coming, going to is trying to solve you know, great things. And it helps when your, your team is passionate about building good things for the user, seeing the reward of user satisfaction and giving, you know, building great products.

Yeah, I love that you brought up research too, because I mean, having data and having, you know, some facts to back you up and support the explanation is, you know, it's always gonna take you places. So, and that's what it takes sometimes is just a different way to deliver your information and to explain it, right, in greater detail so that, so that they can also be in a place of understanding. And, you know, maybe even meet in the middle as a result of that. So yeah, many, many personal experiences in that realm. Yeah.

Yeah. I, it's so funny. Like, one thing I think that has helped so much is pretty much just memorizing the brief front to back, right? I pretty much just go through the, the brief is how I solve it. I go through understanding the problem, predispositions, research, insight. Like I just go through, through that and it helps.

Yes.

Um, you know, basically fin the, you know, fin for the answer that I, that I've been pushing.

But absolutely.

Okay. I think we've covered, you know, the majority of what we had on the list. Is there any, anything else that you wanted to mention or say having thought and gone through this?

No, I mean, yeah, you're right, we pretty much covered it all. I think at the end of the day, this is all just learning. It's really, it's really interesting because, you know, after a certain number of, um, years in the, in industry and in working, it's— you just become more comfortable, maybe attuned to some of the pain points or friction areas of friction that come up, but It's totally just an ongoing process. And I think, you know, we could talk about it for a long time, but just for time's sake, I think we did hit upon, you know, some major points. So yeah, I'm happy with our conversation and this has been really fun. So thanks for having me.

Oh, thank you, Karen. I think it's great. And I think you hit on some great points. And like you said, I also could talk about it all day. It just gets me excited. I mean, I think we're UXing the process, right? Like we're going through breaking the process down and understanding it better. And I think there's some of these things don't have a lot of documentation or understanding. And it's a thing, it's always a growing field to, to be better. And I'm hoping, you know, with your insights and your experiences and mine and everyone else we talked to, it helps grow the industry and create great products and, you know, shared knowledge for everyone. I think there are companies that do, you know, that have a solid process well, that make better products. And I think there are some companies that don't know and are wing-dinging it, and I hope they get to watch this and say, oh, this is helpful. This is how UX works, and this is how it should be implemented into my company. And now they're keeping the user in the forefront and building successful products, and we're helping people grow.

So, right, right. Yeah, we do hope that people can extrapolate golden nuggets, and, you know, it's not a one-size-fits-all. So really, it's based on the use case of of each organization. But the foundational level, I feel like, you know, just having some core— what would you call it? Like, not beliefs, but just some understanding.

Some core understanding.

Right, right. I think that would be really helpful. So I don't know if people have anything to say or—

I've got a closing question for them.

Let's hear it.

I'd like to hear about your cross-functional nightmares. What are some areas that you are just like, oh, This is terrible. Please comment it below. I'd love to hear it. And maybe some of this information would've helped. But I'd love to hear your cross-functional nightmares and crazy situations you've had working with the cross-functional team, whether it's with the product team or the UX team, or depending on whatever side you're on, I'd love to hear about it. So feel, feel free to share in the comments and let us know.

And if you like what you see and you like what you hear, please, uh, click the like button, hit the bell icon, and subscribe because, you know, Mitzi's got a lot of stuff in his backlog and it's all worth hearing. So I'm excited for that personally.

And Karen, I'm sure you'll be back for more. This is a, this is a great topic and I, you know, look forward to it.

Thank you.

Thank you for joining. All right everyone, I appreciate you listening and have a good one until next time.