The Line Between Us is Not a Divider

Audrey Cheng at UXDX APAC. Video: https://www.youtube.com/watch?v=ltU5O7kH2mw

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.

Friction between product managers and designers

[00:00:00] Hi, I'm Audrey Cheng. I'm the CPO at SnapComms, an Everbridge company. We're a market leader in critical event management tools that help organizations to save lives and keep businesses running. I'm also the ex-VP of Product at Pushpay, and in both of my roles I've had the opportunity to lead both UX design and product management. Today I'm going to give a talk about the friction that can often exist between product managers and designers, how to decrease the friction and build positive partnerships, and how to really embrace the tension between us so that we can build better products.

[00:00:31] My talk is called The Line Between Us is Not a Divider. While I believe that it is important to have strong relationships between product, design and engineering, today I'm going to focus specifically on the relationship between UX design and product management, because I believe there are some unique challenges that come from the overlap in some of our skillsets.

[00:00:52] The friction: building products that help people, and that people love using, is not easy. As part of a development team, we often need to navigate the complex relationships of cross-functional teams, where people are coming to the table with very different expertise and different perspectives. Sometimes this can result in the team suffering from friction and fractured relationships due to misunderstanding and lack of alignment.

[00:01:20] The friction can be caused by a number of things. It could be caused by thinking about who's responsible for representing the customer, who decides on the priorities, what gets cut, whose responsibility it is to interview, who decides on scope and approach. This friction can often result in us feeling like we're not part of a team, and that we're moving more towards being in competition with each other than being part of a team working towards a common goal. When we stop feeling like we're in a team where our expertise and perspectives are valued, we don't feel heard, and we don't know why people don't understand our perspective. We end up feeling like we're butting our heads against a brick wall, and hoping, I guess, you'll eventually get it.

[00:02:07] What's the problem that results from all of that? When we start feeling like we're more in competition with each other than working together as a team, we stop bringing our perspectives to the table. We stop feeling like we can openly discuss a different perspective of what we believe is truly important to solving the customer's problem. We feel we can't be passionate about having a discussion about an idea or perspective, for fear of being seen as difficult or just not getting it. When that happens, we don't feel aligned to the direction and approach that's chosen, and then we don't feel passionate about what we're doing and we don't bring our best work. Ultimately, what results from that is that our customers suffer, because we don't end up building the best product that we can together.

[00:02:57] I love this quote by Paul Rand: "Confusion and misunderstanding is the result of the absence of common language." I really feel that this speaks to the heart of the problem. I believe that the tension doesn't result from us not valuing each other and the expertise and experience that we as designers and product managers bring to the table. It often results from the very different knowledge base that we all start from. We often assume that everyone has the same information and knows what we know, so it's frustrating when it seems like the other person can't get what we think is obvious.

Empathy and learning what designers need

[00:03:39] How do you transform negative friction into positive tension? The things that I have found through my experience that make a strong product and design partnership are empathy and valuing each other, shared context early and often, regular communication, and trusted relationships.

[00:04:03] When I think about empathy, I also think about equality. I think about really understanding and learning values, drivers and challenges, much like we think about our customers and what we try to learn from our customers. It's important that we embrace and celebrate expertise and not be afraid of different perspectives. The reason we can be a strong team is because we do have different perspectives, and the perspectives that challenge us push and pull our ideas to become even better and push the boundaries of where they could actually lead us. And co-working practices help to reinforce the everyday connection and working together.

[00:04:47] My own personal experience with this was when I took on the responsibility, for the first time, of overseeing the UX research and UX design practice. Being a product manager, I really didn't know how to lead the design team. Even having worked alongside them for so many years, I didn't know what was meaningful in their work. I didn't know what they valued, what was important to them, or what they needed to feel successful and feel like they were doing their best work. So I spent a lot of time learning, reading books, going to meetups, talking to designers and design leaders, and spending more time one-to-one with the designers on my team, talking about what was working well, what was not working well, and what they needed.

[00:05:35] I found two key things from those conversations. One is that, generally, designers didn't know how to get their ideas on the roadmap. When they found some key insights, they didn't know how to convince stakeholders that it was important and why. The second thing I found was that they all felt that by the time they were looped into projects or initiatives, it was so late that everyone had more context than they had. They were constantly feeling like they were playing catch-up, they were not looped into a lot of the context that was already there, and people assumed they knew what had already been found.

[00:06:10] One designer said to me, "Without the right context, we can build a very usable wrong thing." That always stuck with me, about how important it is to have the right information in front of you to make the right decisions. I have seen designers passionately champion going in one direction, and when they realized they were missing information, they knew they would have changed the direction they had gone in. So context is so important.

[00:06:48] Some of the things I took away from all of this were that designers need to be brought into problem discovery early, we need to create a space at the table for design, and designers needed to understand what was important to stakeholders to get buy-in. So I set about implementing some processes that helped us adapt and address some of these problems.

Sharing context: planning and research together

[00:07:13] That brings me to context. Sharing context is key. We quite often share context about our customers: which customers we're talking about, what problems we might be trying to solve. But sometimes what's missed are things like business objectives. What are our strategic objectives? What's the business value, including revenue and competitive market position? What are the constraints: time, resources, funding, technical? And one of the key areas I feel is often missed is goals and measurements: where are we headed, what are we trying to achieve, what are our financial goals, how will we measure the product?

[00:07:52] Quite often I see this missing, or, if product management is adept at measuring the performance of their product, it's not a shared responsibility with UX design. That makes it very difficult for designers to understand what they're trying to achieve, and what to measure in the journeys that they're creating. If we can share more context, we can really break down information silos, and if we can break down these silos, everyone can be armed and feel empowered to make stronger decisions with the information they have.

[00:08:26] Some of the things we changed to integrate sharing context into our work included planning. We decided to plan as a team. We would have a fortnightly meeting, a team of designers and product managers coming together in a regular planning session where everyone was equal and had an equal voice. It was an opportunity for all the product managers and designers to talk about what was new, what they had discovered, what they felt was important, and to reevaluate some of the priorities we had. It allowed us to have good, strong, robust discussions about what was on the roadmap and why it would be important. From there, it enabled us to gain some alignment before we had conversations with engineering about the direction we wanted to head in or changes we were thinking about, and to get their feedback and buy-in as well.

[00:09:19] We also implemented researching and interviewing together. For some this may feel a bit uncomfortable, but I do believe in democratized research. It's not because we don't value the expertise of UX researchers; it's because UX researchers are in short supply. If you're lucky enough to have someone on your team, it's likely that you have more research projects than you have experts to complete them. You can create a space for UX researchers to be more focused on complex initiatives, and get them to build capability across the team, if you train your team and build expertise across your people.

[00:10:02] We decided to train everyone on proper UX research practices. We felt that if everybody followed the same practices and the same process, we would trust each other more. We could devolve some of the responsibility to other members of the team, and it allowed us to work more cross-functionally, all be closer to the customer, and really build empathy for our customers. In a team, we could be taking on the role of leading the research, building the protocol together, and taking turns being the interviewer, observer or notetaker. This allowed different product managers and designers to take on the different roles within interviewing, and this is the best way to get people involved early and often and really build empathy for your customers. So we did a lot of alignment on training, in order to have an organization where lots of people were interviewing and conducting research.

Sharing insights and aligning on goals

[00:11:09] Another practice we implemented was sharing insights. Once we completed a piece of research, we wanted to share the insights, to help everyone gain an understanding and align on the customer problems and opportunities we had in front of us. We shared this with a cross-functional team of engineers, QA, researchers, UX designers and product managers, as well as data scientists. Quite often we would also share these with the leaders of our go-to-market teams and our customer-facing teams, as well as our senior leadership. This was not only to gain alignment on the priorities for customers and for our roadmap, but also to champion the work of UX research and UX design and the value that it brings to our product development.

[00:12:03] Finally, the last point on context is really around alignment on goals and outcomes. Product and financial goals is an area where strong alignment is required, but I often feel that product teams and UX designers are not strong in this area. If we know what needle we're trying to move, we all have a better understanding of how the work we are doing impacts those metrics. One of the things I did find was that we needed to upskill across the team to be able to do this. In particular, designers needed some coaching on how to measure the success of the journeys they were creating. That was an area we needed to focus on from a learning perspective, but it helped designers to understand the impact they were making on the product, and likewise to demonstrate the value they brought to the product.

[00:13:03] One tool I wanted to share today, which I found really useful in gaining alignment across the team, is Lean Canvas. It's a framework by Ash Maurya, and it's really helpful in framing up an idea. It's basically the story of the customer problem on a page: the business value in solving the problem, the go-to-market. It really encompasses all the metrics that the team is striving for, so I felt it was a really good framework for sharing context across the team.

Regular communication and co-design

[00:13:43] Once we introduced these practices across our team, we needed to make communication a priority. We needed a regular cadence to share new learnings and insights through our development process, and we wanted to work in the spirit of no surprises. Monthly, we had a regular touch point: a cross-functional meeting between engineering, QA, product management, UX research and UX design. We would talk about the things we had learned over the month, how our product was performing, some key wins and key learnings, as well as what was coming up for the month, in development, research and UX design. That really helped bring everybody into the picture across the portfolio of in-flight work, as well as give everyone context into what was happening in other areas of the product that might impact theirs.

[00:14:50] We also introduced co-design sessions: how might we solve hard problems? In this picture you can see our UX design team leading a co-design session with a team of PMs, engineers, data scientists, researchers and QA engineers. This cross-functional team is really rich when we think about some of the problems we were looking to solve. I remember one instance where our data scientists came along. We wanted to build out some reporting for our customers, and the data scientists had some really interesting ways of solving our customers' problem and representing the data. We ended up implementing some of those ideas. The designs didn't really end up turning into the wireframes; they were just the storytelling format for someone to express some ideas they had about how we might solve the customer's problems. That was one of the key ways we introduced dialogue into our process.

[00:15:52] And finally, reviewing early prototypes. I'm a fan of sharing work early; prototypes stimulate conversation. It's important to be able to talk about the problems that we're trying to solve, and a lot of us like to see something visual to spark a conversation, so I find sharing early prototypes really helpful for that. One of the things that's always really difficult for designers is that they take a lot of criticism, because people look at this and see it as a final design.

[00:16:26] It's really important to set the ground rules and let participants know that these are not final designs. These are early ideas, and we want to talk about the customer problem. It's important to really set these expectations, because designers often face really tough criticism of anything they put in front of people, because people feel these are their final ideas, and it can be difficult at times for designers to share their early thinking because of this criticism. So it's really important to set those expectations up front and ensure it's really for generating conversation. That's something I made a mistake with once, and my designers faced some pretty grueling criticism in one session. I had to apologize to them and reset the expectations amongst our engineering and product management team. So it's really important to use that as a tool for conversation, but equally important to set those ground rules.

Building a culture of trust

[00:17:28] The final point in terms of building a strong partnership between product management and design is this idea of a culture of trust. I think everything we have talked about already feeds into building this culture of trust, but I wanted to call it out a little further. In order to transform relationships to being collaborative, we need to introduce new ways of working and take a product approach, by testing and iterating. Like any relationship, it's hard work, so you need to persevere to build that trust.

[00:18:05] As I said, take a product approach. If something is not working, try something else. Not all the approaches I have mentioned today will necessarily work for you; it's just my experience of what has worked with my teams. I suggest you try some things and iterate on them. Maybe it doesn't work exactly that way for you, but adapt it to your own context. It really takes everyone on the team to be open to new ways of working and to new ideas. We all have to come to the table if we want to work in a really trusted team environment.

[00:18:44] For us, it's about sharing success and sharing failure. It's the idea of us being a team working towards a common goal, rather than feeling like we are on opposite teams, competing internally for recognition or for our ideas to be represented. Retro and iterate, as we talked about, and post-mortems: when things don't go the way we expected, let's understand and unpack the reasons why, and let's assume that everybody worked as hard as they could with the best intent. I like this quote from Brené Brown: "Vulnerability is the birthplace of innovation, creativity, and change." If we break down barriers, we can really spark creativity.

[00:19:26] I've often been asked what it takes to build trust. It's to be an ally, to ask for an opinion, to champion and value the expertise of your team. I also believe that you should see your cross-functional team as your first team. Your first team isn't the product management team. It isn't the design team. It isn't the engineering team. It's the team you work with towards a goal. That could be your lead product manager, your lead engineer and your lead designer, working together as a first team towards that goal, setting the right expectations about how you work together, finding the right balance, and reminding yourselves that everybody is working with the best intent and as hard as they can.

Learning together and aligning on practices

[00:20:15] One of the things I've found that puts everybody on the same playing field is learning together. One of the most vulnerable things you can do is to say, "Hey, actually I could upskill in this area. I don't know that." But if we can upskill the team as a whole, we're all the better for it. Not just in research, as I mentioned in the user research and interviewing section; other things we have trained together in are storytelling and public speaking, as well as metrics. When we're learning together about how to be better presenters, storytellers, and at metrics, there is no hierarchical structure. There is no competition in terms of "it's my idea or your idea". It's really about learning together. And the better we can be at storytelling and metrics, the better we can sell our ideas to our internal stakeholders.

[00:21:18] The last thing: aligning on practices is also very useful. As I talked about with the user research, when there are shared responsibilities, it's really important that we are practicing in a way we all agree on and are aligned on. Then it doesn't matter who's conducting, say, the interview. If we have aligned on the practice and everybody's been trained, then we value and trust the data that's been collected. I feel that's a really important way of building trust between each other: that we are capable, that we are working in the same vein, and that we're following the process. Some of these things are just about working on what makes sense for your team, testing and iterating.

The magic happens in the overlap

[00:22:03] I put it to you that we don't need to worry about the line between us and the differences we have. It really doesn't matter whose idea or whose decision it is; what matters is how we come to making that decision. Let's remove the personal friction and really embrace the professional tension that can exist, to create the best products we can for our users. I feel that the magic happens in the overlap, and I think as product managers and UX designers we do have an area of overlap: we passionately care about solving the customer's problem. And when we can bring our differences to the table and see that as a really positive thing, there's a lot of magic that happens. When I see teams together, we can see the bounds of ideas being pushed, and the creativity that comes from that is incredible.

[00:22:56] What are the results I've seen on my team? I've seen firsthand that when you can break down these barriers, the positive impact that UX designers can have on your team culture is incredible. I saw a shift from tactical, practical thinking to product managers creating space for exploration and experimentation. When the team culture is strong, it leads to more interesting ideas being brought forward, and the ability to have deeper, more challenging conversations in a safe and trusted environment. I find that my team is happier. The product outcomes are stronger. I have higher retention and a much more resilient team. I'm seeing shorter decision cycles, more empowered partnerships, focus, and diversity on the team. I'm still on this journey, so stay tuned.

[00:23:50] Finally, the key takeaways I hope you take from this talk: build empathy and understanding for each other. Share context in order to gain alignment; it's really important not to assume that people already know what you know. Regular communication supports buy-in to decision-making. And the culture of trust opens the door to creating better products for our customers. Thank you.