Product Managers and UX Designers - A Match made in Heaven.. or maybe not?

Madhawan Misra at UXDX Community: Empathy-Driven Design: AI, Emotional Intelligence, and the PM-UX Partnership
. Video: https://youtu.be/9SBg6Kv3JnA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

A match made in heaven, or maybe not

[00:00:08] Cool, my title. I thought a lot about what my title should be. You will hear more about what I do, but in theory I feel UXDX doesn't get a lot of PMs. I feel designers and PMs have this love-hate relationship, and I thought that ideally it should be a match made in heaven. You work together, you come up with great ideas, you launch great products. But is that the case? I don't know, and that's why I thought, let's put this question in the title itself.

[00:00:38] A bit about me. My name is Madhawan, I'm an SPM, I work at Booking.com and I take care of the mobile platform. I've lived in a lot of places. I live in the Netherlands right now; before that I've lived in Taiwan, Malaysia, Singapore, India. Before joining Booking.com I was working as a PM at AirAsia, which is Southeast Asia's leading low-cost airline, and before that I was in a Belgian company called Barco. And in my previous life, I like to say, I was actually a developer, so I was doing hands-on coding, developing mobile apps.

[00:01:15] On a personal note, I love learning languages. I can speak Mandarin fluently, I can speak a bit of Spanish, and I'm trying to learn a bit of Dutch. I love talking about products. I was at the Zurich product management festival talking about career growth. Before that I was also at AEL [?] Manchester, where I talked about diversity in the workplace for product managers. So yeah, I love public speaking in general.

The anti-collaboration pattern

[00:01:39] Let's start today's topic with a very common scenario. I think most people here who work in feature teams would agree. Usually as a PM we would go to a developer, and we would have this Slack message or a meeting saying, "Hey, we're doing something really cool. I want to get this done. What do you think?" The developer would be like, "OK, your PRD looks good. Let me take a look at this and I'm going to get back to you on how things are." A week passes. I nudge the person: "Hey, what do you think?" And the developer is like, "Yeah, it looks good, everything is fine. There was some work needed, but not a lot of stuff to do."

[00:02:15] And there's a question which is usually thrown: "I noticed that you've got a couple of designs in there. When are we going to get those mocks ready?" That's a question which every PM hates, because somehow you're like, "Why don't you get the work started?" And this is often the reply: "You know what, it's not a lot of work on design. Just get started, you will get the design real soon."

[00:02:38] And here is the poor designer, there somewhere. There's a reason why I put them at the end, because they're usually somewhere saying, "Yeah, I'm hearing about this cool feature, but no one is approaching me. What's going to happen? Are you going to draw the design yourself?" And eventually I do go, with four days or three days, the minimum amount of time, and I go to the designer and say, "You know what, can I get a Figma, can I get a prototype for this amazing PRD?" And I drop a nice message saying, "By next week."

[00:03:14] I'm not a designer, but I can already feel the designer at that moment is like, "OK, but actually..." I'm pretty sure, based on my years working with designers and researchers and those folks, they have a lot of questions. Things like, "Hey, who are the people who are going to be using this? How can I actually help? Why are we doing this? Can you share with me the bigger picture?" Because I know how designers think. They are all about the bigger picture, trying to understand what the bigger problem is that we are trying to solve.

[00:03:44] And obviously as a PM, sometimes I'm like, "Please don't make something crazy. I want this to be rolled out. I've got OKRs to complete. Please don't slow us down." I will be honest, I've been at this stage, and I've heard this, and I can personally say that often I have this fear of going to a designer, expecting things to slow down. Of course I will tell you why it's so wrong, but often all of these things are in a PM's mind. And that is one of the big problems I will talk about: a lot of product managers don't actually see the designer as a core part. They don't consider them to be a partner in crime, but rather a support team which hopefully doesn't slow them down.

[00:04:34] I like to call this the anti-collaboration pattern, where eventually the designs are ready, and the developer is like, "What the hell? This is not part of the deal. I can't do this, this is so much work, these are animations, I can't do this." And the poor product manager at this moment is like, "Can I just die?" I promised everything to the developer, my VP of product is expecting a launch, and this is what I'm going to deal with. This might seem like I'm really overreacting, but this is true. In a lot of places this happens quite a lot, where devs and designers and PMs are never on the same page. And I can talk about amazing teams. I'm not going to name anyone, but think of the big-name products you use. It happens everywhere.

[00:05:24] And eventually no one is happy. Because I work in technical teams, I see that developers often feel that they're just changing stuff: they implement something and then they have to change something. PMs feel like they're just hoping and praying they can get a design ready, because they don't really validate stuff. And designers feel that they can't really contribute. They are basically doing stuff for their PM, but they don't really get the chance to showcase what they can do.

[00:05:52] I got this from ChatGPT. Let's be honest, I could never create something like this, but this is actually what I imagine a room would be where no one is happy. There is an amazing roadmap and there is an amazing design idea, but they're all isolated. And I think this is actually what happens quite a lot. So I thought about how I can help my product managers and designers solve this better.

[00:06:24] If anyone wonders what the impact on the product is, I've got two product reviews here. I didn't mention the company, but if you read them you can clearly see how customers are complaining about the design being off. For me this is a typical example of a lack of collaboration, of developers, PMs and designers just being on different thought processes altogether.

Launching the AirAsia wallet

[00:06:53] So I thought, let's retrospect. Let's see what goes wrong and how we can not do these things, because the reason why I'm here, and hopefully the viewers are here, is to ensure we don't make these mistakes. I'm going to talk about a product which I launched when I was at AirAsia. It was our own in-house wallet. It's quite common: you can add money and you can spend on things within the app. We had quite tight timelines, a couple of months. It might look long, but for a product to be launched and go to market, it's a tight timeline. We had a lot of moving parts. Remember, we had finance and payments and marketing, and usually with a wallet you have legal things as well.

[00:07:35] And there was vagueness. We were not sure what was to be delivered and what might change. Scope kept changing, typical product stuff. If you work with product teams, you know when there is something new, things do change. I'm going to talk through this journey where I committed some of those mistakes which I mentioned, but I would also like to explain how I overcame those mistakes, and how you as a designer can also work better with product managers.

Embed design in the heart of the product life cycle

[00:08:07] So I'm going to talk about learnings. The first learning, and for me this is so important, is that product managers, and organizations in general, need to embed design in the heart of the product life cycle. It's got to be there very early. If I look at this product life cycle, and this is a very generic one, but you know the drill: you think of an idea, you develop a concept, you start developing, you roll something out. Often I realize that designers are involved during development, when everything is ready and you have decided the metrics and everything else. But I truly believe that the right point to involve them is much earlier. It's got to be when you're creating the idea, when you are validating the idea. I get it that PMs have more business context, but designers always have a lot of input. They understand the user problems you are trying to solve. So the message would be: get your designers involved, and if you're a designer, try to be involved much earlier.

[00:09:09] And I got this amazing picture from ChatGPT. I love this. It's called the plant growth metaphor. Essentially the picture on the left shows that if designers come in too late, everything is done in isolation and you don't get the fruits, while if they are involved early and things are much more collaborative, you can have those amazing fruits. So again, the learning for us was that we involved designers and research from day zero, not even day one. Even when we were developing this, they were involved. I gave use cases and motivation; designers gave thought on designs and the flow and the bigger picture. We did validation, and we had bi-weekly updates. Again, earlier and more frequent is always better.

The trust equation

[00:09:52] The second part. I'm not a big fan of models, but this McKinsey model is something which I really like. McKinsey has a lot of useless models; this one is really good. It's called the trust equation, and I think it doesn't matter if you're a designer or a product manager or anywhere. If you have stakeholders and people you work together with, this is really important. Basically, trust is built by credibility, reliability and intimacy, and it's decreased if you are self-oriented. Apply this everywhere, with everyone you work with, and you will realize how easy it is to develop trust.

[00:10:32] In our case, since it was a PM and design relationship, we decided the best way to develop this trust was again by thinking of all those things. Credibility is extremely important. If you're a product manager, give the bigger picture. If you're a designer, think already about what kind of user problems the picture is trying to solve and what kind of behaviors you would expect. Reliability: if you promise something, deliver. If you're a product manager, give those updates; let the designers know where we are. If you're a designer, stick to your timelines, explain how things are, get your design reviews done. Don't wait for product managers to nudge you.

[00:11:17] And intimacy, which is: meet often. It's a pet peeve of mine where I see the interaction between designers and PMs is so inorganic. It's just meeting when you have to meet them. The meetings should be much more often, and also meet in good and bad times. Don't just meet when you're having an amazing time; even if things are wrong, go and nudge your designers. And again, don't be selfish. Don't disrespect designers; think of them as a team. There's a typo here: it's not "don't talk about their importance," it's "do talk about their importance." It's very important that you as a product manager let your leaders know how important designers are. Give them timely feedback. Don't isolate designers.

[00:12:00] So essentially you can build trust if you're credible, if you're reliable, if you have intimacy and if you're not selfish. We did this at AirAsia, where we had data sources and the PRD up to date. Designers always kept me involved in their feedback sessions. When I was managing things upwards, I kept design decisions clear. We had a lot of interaction. So build this trust and you're going to go a long way.

Clear boundaries

[00:12:27] My third point is about clear boundaries. Again, I feel all the things which I'm saying can be so generic. You could use it for PM and EM, PM and researcher, designer and designer; it could be applied to any two people. But essentially, have clear boundaries. I've got this generic one, but the key message is: don't be afraid to draw boundaries. I know it's counterintuitive when you want to work together, but boundaries are really useful because then you have a very clear separation. You need to have boundaries on what the timelines are, who owns what, what kind of data you need.

[00:13:03] Saying no is OK. This was a huge thing, where we accepted that at times you're going to give difficult news. Take breaks. When you're tired, just cancel a meeting and say, "I just want to think about this piece of work." Share your frustrations. It's so common in projects that people don't share frustrations, and in the end it shows in their design, or if you're a product manager, it shows during your product reviews. And be open in communication. You need to make ground rules, where the first rule is that a PM could ask a stupid question and a designer could ask anything. So be open in communication.

[00:13:42] I think at AirAsia we did that quite well. I was preparing the why and the what, I was owning the data, I was doing stakeholder management. My role was to take care of priorities and expectations, while my designers were taking care of deliveries and reviews and feedback loops and all of the good stuff. So really setting up very clear boundaries is extremely important, and this will help you avoid chaos. Often a problem comes and you're not sure who owns it and who should be taking the first step on it. But this way, if you have the trust, it's quite clear who owns what.

Build the bridge between design and engineering

[00:14:20] And then, I love Gordon Ramsay and I love this one. This might be very specific, but I also feel that often, at least in my teams, I used to see, and I will show my picture, that I am the person in the middle, but actually I shouldn't be there. A common scenario which happened to me during my sprints is that a dev would ask me, "Hey, I need the right icon, I need the right animation," and then I would ask my designer, "You know what, could you do that?" And then I would get a reverse Uno card played on me, which is, "Can I know for which OS?" It used to really bug me, because ideally I shouldn't be there. These are two people who can communicate with each other.

[00:15:03] But the reality is, I think their work is at opposite ends of the spectrum. Engineers are extremely technical and they need really concrete information, while designers can be a bit more high level. But I think one of the things a good product manager should do is to initiate the bridge. I'm not saying you shouldn't be there, but often, when these questions are asked, you could just enable that bridge for engineers to speak with your designers. And I can tell you, it's such a huge shift in mindset, because once your designers start speaking a bit of tech language, and once your engineers start understanding a bit of how design works, you will feel so much better as a product manager.

[00:16:00] I know this talk is not for PMs, but I'm speaking to all the designers who are here: don't be afraid to ask questions of your engineers. If you think that font is not correct, if you think that this animation is too slow, you should have the capacity to speak to a developer and straight up say, "Hey, there is something off." How I did this: there are some common meetings. If you're a product manager, you meet with your developers in stand-ups and groomings, and if you're a designer, you probably have a design PM sync or a design review. Try to get people into these meetings, where you can say, "Hey, why don't we have a designer join our stand-up today, very quickly, so that the question can be answered?" Why don't we have a developer join a design PM sync, where he can get clarity on this question?

[00:16:46] The important part is that once that silo breaks down, the interaction becomes much smoother. I think this is very important. This really worked for me, where we got these two people much more independent. So like I said, encourage that direct communication, even though it's difficult. Get them in the same meeting, get them in the same room. It's chaotic, but it really works. And let them develop their own boundaries. Just like PMs and designers have boundaries, designers and tech will also have boundaries, but it enables that close collaboration which all organizations want. Being in leadership, we always say that data scientists and researchers and designers and marketing and product marketing should speak with each other, but these are the things we can do to enable that, and you will also save yourself a lot of headache.

Key takeaways

[00:17:42] I'm getting to the end of my presentation. This is to prove it did work: that's our wallet, which we did launch. Everything was fine. This is just showing that it did work and I'm not making things up. And here are some key takeaways, because I always like to finish with things you can do from tomorrow, which means that tomorrow, when you start working, you can start making these changes. First, communicate more: communicate early, communicate frequently. Have that trust and respect. Think of what others expect from you and what you expect from them. Embed design into your product life cycle; don't wait for that last moment. Have that feeling of togetherness, where you win together and you lose together. And be transparent: be transparent when you're working with tight timelines, and be transparent when you don't need designers and you can actually give them more time to do what they like.

[00:18:38] I think this is the end of my talk. I'm more than happy to answer any questions and more than happy to share my slides. Here's a QR code if you do want to add me on LinkedIn. That is the end of my talk. I think we have exactly 11 minutes to go for Q&A, so Rory, happy to take any questions.

Q&A

[00:18:55] Rory: Brilliant, thank you very much, Madhawan. Everybody out there, if you have any questions, please do write them in and I'll put those questions through. The first question I'm going to start with is a difficult one. It's all well and good saying get people involved earlier, it's all well and good saying we should engage people more, but then we get the budget question. It costs money to get people involved, and the whole point is, well, we need to do this quick and lean, and that's not efficient. So how do you handle the budget question?

[00:19:36] Madhawan: That's a really nice one to get started, Rory. I would love to be very frank, and I will try to be as frank as I can. Being someone who has gone through these things, you need to show it works. My biggest way to get approval of budget is to show cases. I can tell you we have had projects where, because of budget, we had to share, and there's a whole debate of decentralized versus centralized designers. But we had projects where we decided, "Hey, let's not have any designer and let's go with it," and I can tell you we didn't do very well. We did launch it, but we had to spend a lot of time reiterating with designers to show that, nah, it's not good.

[00:20:16] So to answer your question, have sponsors where you have done great work, where you show the value of designers. And when you go into those meetings with leadership, make it clear what the impact of not having a designer would be. Maybe you can get an MVP, maybe you can get an increment, but eventually, if your target is to be there, you will need specialty. So I would say look for good cases where you have won, and try to formulate what the contribution could be. Usually the first couple of times it's difficult, but once you actually start showing the value, it eases out. I get it, not every project will get a full-time design team; you might need to share resources. But it's still better than having a PM draw designs. So I would still say it's worth fighting for.

[00:21:05] Rory: And should people go for full-time design? Should that be the goal, or should they start with part-time?

[00:21:14] Madhawan: Look, again, every org does it differently. If it's a much more mature organization, I can understand that they would have the luxury of a huge design department. I have been in situations where I had to share designers. So I would say there is no perfect answer. If you do have scarcity of resources, having a centralized model, where you can have designers for each project, is good, because then each designer works on A and B and C. But I think eventually I like the decentralized pattern, because if you have one designer for one product, that designer doesn't feel like a support team. He is there, and he would be able to work with you on roadmaps. So there is no perfect answer, but you could always consider having a shared approach to start off, and once you see that you are doing quite well and you want to reach the scale of millions, then you would probably benefit from a much more dedicated resource.

[00:22:15] Rory: Great. We do have a comment rather than a question from Paul, just saying, "I'm a PM with a UX design background. Honestly, I think PMs without at least some basic UX design skills are like fish out of water."

[00:22:31] Madhawan: Yeah, look, I do agree that most PMs should have basic UX, and I think most of us do. But I think it's also what works against us. A lot of PMs think that it's a simple UI and a simple mock which they can make. But that's my point: design is not just about mocks and UI. It's much more about understanding user behavior and getting the bigger picture. Everyone loves things like conversions and bookings and getting those great numbers, and I really do believe that having a great design sense is something where designers can contribute a lot. So I think sometimes we can be our own enemies by thinking that we could handle that, but then we realize that we never thought of this flow, and we never thought about how we make our products much more inclusive. There are a lot of things now if you're looking to target millions and have products across geographies.

[00:23:26] Rory: Great. Another thorny one: what about people who don't want to collaborate as closely? It's great to say we should get everybody involved and everybody wants to do it, but I've worked with some people who are like, "No, I don't want to do that. You just tell me. That's your job."

[00:23:48] Madhawan: Yeah, look, I have also had these kinds of people. What I said is very ideal. If the person can do their job well, it should be fine. Here is what I believe. I get it, every person is different. But living and working with that is going to be difficult in the long run. Again, I would really try to show the value; I believe in doing things. So if you can show and explain, "Look, you want to work on your own, and it's fine, but do you want to spend hours reiterating, or do you just want to get in the room and get this done?" That often moves the needle.

[00:24:32] Because even as PMs, I've had people who are like, "I don't want to attend a meeting, just send me a Google Doc," and then you spend hours on that Google Doc, and then you ask yourself, "We could have done this in half an hour if he was just sitting in a room." So why don't you and the designer and a developer sit in a room and get that sorted out? And everyone loves free time. You get two hours of free time, you can go out there. So maybe just prove that if you want to be alone you can, but then you're going to be spending a lot more time, and I think no one wants to spend more time on things which they can do quicker.

[00:25:05] Rory: Yeah, that's a great approach to it. We have another question from Patrick, and I'll just summarize a little bit. He's saying he has a great PM-UX relationship but not so great a PM-engineering relationship. What's your advice in such a situation?

[00:25:21] Madhawan: I need to do another talk for that, Patrick. I could speak for hours about that. Look, it cannot be quick, because PMs and engineers are quite different. I like to call it, and I hope my EM is not here, a different dinosaur, because it's much more different. I think a lot of these things apply, but it's a bit different, because usually the expectations are different. I think EMs are a lot more about tight estimations and ensuring that their developers are not working on things which are never going to go live. I would love to connect with you separately. I have so much experience working with directors of technology and EMs. I would say the process is the same, but there are nuances, and those nuances are quite big. But essentially, again, be transparent, develop that trust, and also involve engineers early. Don't just go to them with a PRD saying, "Get a developer for me, and I want it delivered in a month." That's probably not going to work very well. But maybe that's a different topic for me to talk about one day.

[00:26:34] Rory: Excellent. Yeah, it's a difficult one. And on that, actually, one of the things that a developer might often say, and I know this from my development days as well, is that context switching is really disruptive. You can be really focused on something, you're really thinking deeply, and then somebody taps you on the shoulder and you lose it all, and it takes you a while to get back in. So back to your points about more frequent and constant communication, how do you find that balance between over-communication and too frequent?

[00:27:07] Madhawan: That is a very good point, and this is where I feel it's the team who needs to decide that. I know people who want over-communication, but I also know people who, like you mentioned, do not like context switching. I can tell you at AirAsia we had a weekly one, and no one liked it because it was too much. Then we had a monthly one, but that was too infrequent, and eventually we settled on once every two weeks. So again, you iterate and you try to work out what's best for you. But I totally agree that context switching is real. Maybe I can do it very fast because part of my job does involve meeting with everyone, but find your own balance by optimizing it. The TL;DR is: don't do it just because you have to set up a meeting, don't do it just because there has to be a recurring meeting. Do it when you feel that everyone involved can contribute, and then that will take care of context switching. So decide what suits everyone best. Play around with it a bit.

[00:28:11] Rory: Brilliant. Well, I think that pretty much takes us to time, so I just want to thank you once again for sharing. I thought it was a great, interesting, topical talk, and we had a lot of engagement as well. So thank you very much.

[00:28:24] Madhawan: Thank you so much, and I'm more than happy to take questions on LinkedIn or any other platform. Thanks again, folks, for joining.