Aligning Product & Team Objectives with UX

Carmen Broomes, Mackenzie Guinon, Lori Neff, Rory Madden at UXDX Community: USA East. Video: https://youtu.be/xbdyK2IL7hg

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.

The role boundary between product and UX

[00:00:00] Rory: We're going to be talking about aligning product and team objectives with UX. Welcome back, Carmen and Mackenzie.

[00:00:09] Carmen: Thank you.

[00:00:12] Rory: One of the things that has come up in pretty much all of these talks is that there might be an appetite for UX to focus on the customer, and then there's always the competing business tension of just trying to get new features out and get something done. I saw a study recently where they asked PMs, product managers, and UX people what their roles were, and I think there was something like an 80% overlap in what people said they were responsible for. If I take Marty Cagan's view, where he talks about product and doesn't really mention UX separately, he says product is responsible for desirability and viability. But is UX responsible for desirability, with the research? So what is your view? Carmen, I'll start with you. How do you structure the role boundary between product and UX within your organization?

[00:01:11] Carmen: We partner really closely. One of the things we've done at Handshake is partner really closely with them to plan our research initiatives quarterly. I would say that, for a startup especially, we operate pretty strategically, which is great, because we're able to really get a sense of where the company is trying to go and what we're trying to accomplish in the next three months, the next six months, the next year. The benefit of being able to do that, especially as UX researchers, is that we can plan pretty far ahead.

[00:01:51] One of the things we really try to do is our research, especially when we're talking about more discovery-type research, at least one or two quarters ahead of time. As long as we have an understanding of where the business is trying to go, which we do, which is great, then we can align our work to it. Sometimes it may end up telling the business, "Hey, we need to shift gears," but that's okay. And sometimes it's in support of the business objectives. But as long as we're working ahead and we understand the business objectives, we can really come to them with insights. I think Mackenzie and I have both been pretty successful in that, with our insights being used to influence the product roadmap.

[00:02:46] Rory: Great. Just to summarize and recap: you have product being very strategic and giving guidance on where the direction is going, and so you're able to research ahead of time on that.

[00:03:01] Carmen: Sorry, go ahead. Yeah, I think it's a little bit of both, a partnership. We may do research to influence product and influence product strategy. They may also come to us with things they have. So I think it's a partnership. It's not necessarily that they're only defining the roadmap. They are definitely doing a lot of the leadership in that regard, but our insights are being used to influence the direction, the product strategy and the work that they do.

[00:03:41] It really is a partnership. It's us working really closely with them, understanding their business objectives, as I mentioned before, asking great questions, working with them on understanding what we know and what we don't know. If we move forward with this feature, do we know enough to move forward and make that decision? And if we don't, how can we partner closely with them to help get the answers to those questions?

[00:04:11] Rory: Great, thanks. Lori, would you be able to share, in your context, what the role of product and UX is and how that's structured at Optum?

[00:04:23] Lori: How it's structured at Optum: it's a real partnership. If you can get everybody engaged throughout the entire software development life cycle, and definitely in that research portion, setting that up, and understanding what it's going to take to really infuse accessibility into the process. Because if you delay accessibility until later, it's frustrating. If you delay UX until later, it's frustrating. And product has the insight that lends itself to what you are really trying to accomplish. You can't have any one without the other. It's got to have a very, very strong foundation and relationship. So the more you can do to keep that communication strong and early, the better.

When research changes the roadmap

[00:05:33] Rory: Excellent. I just want to jump back to Scott's talk earlier, where he was saying you can't define a roadmap very strictly, because you're going to learn as you go, and you're going to find out that things you had assumed are incorrect. Mackenzie, maybe you want to take this, we'll give Carmen a break. If you're planning out and doing all of your research ahead of time in line with your strategic goals, what happens when things start shifting and you start learning that things are different?

[00:06:09] Mackenzie: I love this question. Pre-UX, before I even knew what those two beautiful letters meant together, I worked as a sustainability consultant. Traditionally, the shortest strategic plan I ever did for a client was 50 years, and I did up to 250-year plans for roadmaps. The sustainability space is incredibly comfortable with "things will change, we will learn more". Then I moved back into tech and was working in two-week agile sprints. It was like moving to another country, another culture.

[00:06:45] So I've always felt extremely comfortable that because we put something on a slide, or in a spreadsheet, or put a visual roadmap to something, it's not set in stone. Literally, I can change the slide so easily, watch me. But I do try to have empathy with my stakeholders, knowing that not everyone comes from that perspective, and things can feel like fire when things change.

[00:07:07] There's a lot of work I try to do. I will say Handshake, as Carmen said, is one of the most strategic places I've ever worked, even for a small company. So when she says we're doing research in line with the business strategy, we're doing research on assumptions made in the business strategy. And because Carmen set up this incredible air cover and expectation-setting around what we are prepared to find, for the most part the business is ready for us to come back with new information on assumptions we made.

[00:07:37] I was in a really powerful meeting this week, and I left individual feedback with a VP who I think landed the plane for people being very stressed that the roadmap seemed to be going off. He said, "I hear we learned something new. I want to congratulate everyone in the room for learning something new, and it sounds like we need to change the roadmap." I just didn't want to let that moment go unnoticed, because I think we get very obsessed with "but we wrote it down".

[00:08:08] I just want to say to everyone: just because it will change is not a reason not to do it. We do it to learn, and going through that ritual of changing the roadmap and learning from what we've learned is the practice. I don't know if that answers your question, but I really like acknowledging to this group that roadmaps change. It's not a reason not to do them, not to believe in them and do our best. It's a balance: you can put things down, you can go explore them, you can learn, and you can shift.

Moving from fixed plans to learning and iterating

[00:08:42] Rory: Great. You touched on one of the challenges I've seen in some places, and it comes back to culture, I guess. In places where it's very much "we'll do a big project, we'll plan it all out, we'll do it all", the most important thing is scope management. You want to avoid scope creep. And then you're flipping it on its head and saying, no, if we learn something new, we have to take it on board and adjust. I've seen that it's very difficult from a personal perspective. People really can't handle that, because it's like "Who Moved My Cheese?": you were telling me to do this, and now the next day you're telling me to do something else. So it's an open question: have you found that in your organizations, and how have you dealt with it? Does anybody want to volunteer to take that one on before I nominate somebody?

[00:09:39] Lori: I can talk about that a little bit. Sometimes when I come onto a project, accessibility is new to the project and to the team members, and you don't get a good start with really inclusive design or whatever. But changing that mindset, you have to try and make things open. And now I've forgotten the original question.

[00:10:15] Rory: It was about moving from a culture where it's very fixed to a culture where it's "let's learn and iterate". Some people can find that very challenging, because they prefer "tell me what to do and I'll go do that", and you keep changing the priorities on them.

[00:10:32] Lori: Right. People see me coming from accessibility and they're like, "Oh no, now we've got to do everything boring, and I've got to change this beautiful design that we've come up with." No, no, this is great. I like to reiterate what you were saying, Mackenzie: change is good. You learn about opportunities I wouldn't have thought of before when you start to open up to that change. And it's nice to have that longer-term vision sometimes. I like what you're talking about, 250 years from now, because that allows you to pivot a little bit more and have a bit more room to take a slightly different approach. Okay, we're going to go around the rocks now, but we're still going to be able to get to Canada eventually. That flexibility is hard to learn, so always have that gentle approach, and that curiosity everybody's been talking about on these calls today.

[00:11:44] Rory: Anything to add, Carmen or Mackenzie?

[00:11:48] Carmen: No.

When a business decision isn't good for users

[00:11:51] Rory: I'll move on to another question, because there's one I always love. It's the beefy product versus UX one, and I touched on it in Lori's question. What happens when there's a business-focused decision that is not good for users? It's going to make money, but it's not necessarily a great thing for the users. Have you experienced that, and how do you handle it? Maybe I'll start with Carmen.

[00:12:25] Carmen: Yes, I have. That is hard. I think that's why we talked about sensitivity and empathy in the presentation we gave. That sensitivity piece is so important. What I like to do in those situations is embed researchers working directly and closely with the product teams as much as possible, so they start to develop empathy for our users and our customers.

[00:12:59] The other thing I've done in the past: sometimes the monetary benefit of things doesn't align with customer satisfaction, and you may see NPS go down. We can have a long discussion about NPS, okay, I won't get into that. But what I do want to call out is understanding what your company measures and using that within the conversation. Revenue is a huge part of our metrics. It's part of how a business defines success. But the other piece is customer satisfaction. So where can you pull that from? Whether it's us as researchers, or support. I've also used support for that: really partnering closely with our support team, understanding tickets, how many tickets, getting product teams access to the tool support uses so they can go and see all the support tickets. I think empathy is the best way of doing that, because it can be a challenge, and I've experienced that a couple of times in my career.

[00:14:27] Rory: Great. I'm thinking back to some personal experience. There's an airline in Europe that's very famous for low cost. That's their whole thing: they're a cost-conscious carrier. But in some ways they're antagonistic towards their customers, like they try to make things difficult. There was an example where, if you book multiple people and don't buy a seat, they will separate you. Fantastic for the business, because more people are paying for seats and they're making more money. But obviously it's a negative for customer satisfaction, because people know that if they book two people, or their family, they're going to have to buy seats in order to sit together.

[00:15:13] But for that company, that is what they're known for, and people don't care because they've got the price leadership. What do you do in a situation like that? Have you had an experience in UX, or the same argument could be made for accessibility, where they don't really care? How do you deal with it when the business is saying, "Look, it's not that important to us"?

[00:15:44] Mackenzie: I have a thought on that. One of the best pieces of advice I ever got from a fellow researcher in an applied space was: don't delude yourself into thinking you're doing magical work outside of the work of a business. We work for the business, and by working here I share some of the values and culture the business has put its stake in the ground on. I think I know the airline you're referring to, and it has put its stake in the ground that what it values above all else is cost-cutting measures. I don't know if they sit around having ideas about how to be antagonistic, because that sounds intentional.

[00:16:22] I got my MBA, and one of my favorite case studies we ever did was around an airline in the US, Southwest Airlines. It started in the Southwest, and what I found so fascinating is that when they did the market research, they said, "We are not competing with airlines. We're competing with bus travel. We're only going to fly as far as bus travel, and we're going to treat people like they're on a bus." So people file in, people move by number. To this day, and I grew up flying Southwest, the people are hilarious. The people who greet you and see you and take care of you are funny, and they do training in all sorts of caring things. But they funnel you in like cattle and they funnel you out like cattle. People who did not grow up flying like that, who fly United and others, find it despicable: "I will not be treated like a cow when I fly." I find it delightful.

[00:17:14] So if I went and worked for this company you're referring to, I'd remember that I can try to make an individual difference, organize at a low level and manage up the best I can to change things. But by working under an umbrella that big, with a culture that strong, I co-own the values. I would be hard-pressed to take a job there and say I'm going to single-handedly make it better for our users, when it sounds like antagonizing our users is almost in our values. I don't know if that's the answer, but it sounds built into the DNA, and I would hesitate to individually fight that fight.

Dark patterns and holding to values

[00:17:55] Carmen: I love this subject, by the way. I don't know if Mackenzie knows this, because I have talked so much about dark patterns in UX. We know they are everywhere. I'm pretty passionate about this subject because I do think that we as UX professionals should hold ourselves accountable to some ethics, some values, whatever our values and ethics are.

[00:18:25] I will say I have experience at a company where we had things that probably shouldn't have been the way they were. I don't think it was on purpose. But I was able to see change in that company. It took a while, it took years, but they did make change. I think if you work anywhere in UX today, the chances of you finding a dark pattern are unfortunately probably high. One of the things I love about Handshake, and I'll just take a minute to speak to it, is when you can set values in the early stages of the company about things you're not going to do, like "we're not going to do that", and you can get everyone to align around those values, that's pretty powerful. And you can use user research to do that too.

[00:19:23] Rory: Excellent. I love that topic because there is no right answer. In some businesses, I think it actually makes sense if that's their model. Some businesses are all about customer loyalty and success and happiness, and maybe if you're a price leader you don't need happiness as much, because you've got the cheapest price.

[00:19:45] Lori: Sorry, I was just going to add, because I was thinking, okay, there are the dark patterns, and I'm also trying to think of a more positive one. You know Balsamiq, the low-fidelity mock-up software? For the longest time they didn't update their prices, and people were asking for more and more features, and they said no. "We want to stay within this price range, and if we start to add feature after feature after feature, we won't be able to stay within that price range." So they stuck to their values in a positive way, I think. But it alienated some users, and they were like, "We're okay with that, because this stays true to who we are and our value system."

Upskilling teams in accessibility

[00:20:39] Rory: Excellent, great point. Coming back to aligning team objectives: you've convinced somebody, you've got a great product partner, and they're saying, "Okay, let's do this." But what skills or techniques do we use, and how do you help coach people who are bought in? Everybody's talking about there not being enough designers and researchers relative to the development team, so maybe some of the teams want to take on some of this stuff themselves. Do you have any tips for how to upskill them or train people to help them adopt it? Lori, I guess with accessibility this is a big one.

[00:21:26] Lori: Oh my gosh, okay. It's a big wild world out there in terms of learning about accessibility. When I'm on a team where it's newer and I'm coaching, I will start with the why, and then guide them to any resource I possibly can that addresses that why. Maybe I've got a brother who has a disability, or is neurodivergent, or whatever. Okay, cool, let's build on that. Or, I'm a developer and I want to augment my skill set. Okay, great, I've got so many resources I can set you up with. Basically, I want to build on what is motivating them already, and then say, "Here are the tools I'm going to point you towards," and leverage any stories I can, because those are really powerful and, again, get to that motivation. If I can get them to curiosity, they're going to start to do it themselves. Motivation is the beginning of that journey.

Democratizing research at Handshake

[00:22:45] Rory: Excellent. Would that be similar for some of the research things? I don't know the structure, but usually when I talk to people there's more research than there are people, and they wish they could be doing more. I've talked to a lot of companies that are starting to do a train-the-team model. Is that something you're looking at at Handshake, or are you centralizing your research? Mackenzie?

[00:23:12] Mackenzie: I might let you take it, Carmen, as the head, and I'll chime in on the things I'm excited about.

[00:23:20] Carmen: Okay, sure. Maybe we both take it, Mackenzie, because you are working on the training. Mackenzie and I are partnering really closely to help train especially our designers and product managers so they can run their own research, and I'll let Mackenzie talk a bit about some of the things she's been putting together. Most of you might be familiar with usertesting.com, for example. We have templates in place where designers are able to go in and run their own research with our support. We have set up one hour a week, which Mackenzie actually leads, so I'll let her talk about it, where they can come to her with any questions if they need help setting up usertesting.com.

[00:24:18] We have several people on our team who can actually interview pretty well. Some of them gained that skill set before we even came to the company, because there were no researchers. Others are learning that skill set through support and help from us. We do have a deck we give to people before they interview anyone, with how to avoid asking leading questions, and good tips about paraphrasing and things of that sort. But I'll let Mackenzie talk, because she's been doing a lot in this regard too.

[00:24:58] Mackenzie: Thank you, Carmen. A big thing in our charter, and something that helped me make the decision to join Handshake, was that Carmen believed in the democratization of research. As someone who not that long ago was on the outside and found my way in, I think there are a lot of skills you can leverage and deepen. We have a research prioritization and roadmap that we make really clear: incoming requests, what we're working on and which are prioritized. And we track what we say no to. I think that is really, really big. People are so focused on "look how much we do, even though we're limited". It's kind of neat to flip the script and say: what did we say no to, and why? We were working on the most important things.

[00:25:44] In that model, which Carmen just referenced, we work with full engagement. At Handshake, Carmen and I have been working on the most foundational and generative projects, and then we are frequently in support roles for the more evaluative requests. So we're working on templates and training, very designer-centric at this point, for running more usability studies. We want designers to be empowered to test and get feedback on their own designs. But, as Carmen said, we also have a lot of people who have the ability to run interviews.

[00:26:18] What we're trying to do, and you referenced this earlier, is this overlap of what PMs do and what UXers do. I really want to be humble and say: I can do a lot, but why am I here, why am I a researcher here? Here are the places where the magic is, and I really want to be involved in these places. I want to support and upskill you so you can run the rest very autonomously, but bring me in here. I'm not trying to be a blocker. I'm not trying to slow you down. So we get really clear on crafting research questions and crafting scripts.

[00:26:52] In a previous organization, I would co-craft and talk about objectives, co-craft research questions and write up a guide. I would run the first session and they would take notes. The other person would run the second session and I would take notes. And I said, "If you're going to work with me like this, I need you to be really open to full and transparent feedback and direct critique at the end of that, and then you can run the rest." So it's really working in a model of: trust that I am coming in with expertise in certain areas. I'm here to empower you to do more, and this is to ensure that we have a high level of structure, sorry, of rigor, in what we output. Then we can really trust everything we're doing, and share and compare.

[00:27:39] I think I had one last thought on that, but I might have talked myself out of remembering it. I'm very excited that people can do and engage in this way, because Carmen and I are the mighty team of two. We are definitely not one-to-one, one-to-two, or anywhere near that. But I think we're working on the biggest, meatiest things, and we're really trying to be very inclusive, while not handing away our expertise by saying anyone can do what we do. We're really trying to be picky and choosy about where we contribute the most, and we hope you include us in that spot.

[00:28:18] Lori: I want to add to that, because I think that's such a huge point: that trust in your expertise, and vice versa. If I'm working with a designer who's building on a concept of behavioral design, how I want to manipulate, in the nicest possible way, my user into doing more fitness activities, for example, then I'm like, okay, how can we support this for all of our users, all of the members who are participating in this app? If you're emphasizing "I only have a couple of things left to go in my step journey today", then great, let's do that, and let's make sure that everybody is hearing that first, if I'm using a screen reader or whatever. It's that combination of: awesome, we're working together and leveraging each other's expertise. Trust. It's good, I love it.

[00:29:21] Carmen: I'm going to add more to this conversation. When we came to the team as UX researchers, they only had the marketing team, so a lot of the research that had been done was being done by the marketing team. So with us coming along, it was like, "Well, what does UX research do? How is that different from what the marketing team is doing?" But it's actually working out super well. We're partnering with them. The product marketing manager also conducts research. She's a marketing researcher too. We are working on a way of educating the business: here are the ways they will contribute, and here are the ways UX research will contribute. The beautiful thing about that is people are starting to see it, and we're going to be able to expose that more and learn a lot. But it's really a partnership. And I think Mackenzie talked a lot about it: as long as we're not in that battle mindset and we're working together, I think we are way more successful.

[00:30:32] Rory: Excellent. I might invite you back to share about your UX and marketing experience at a later date, because that's a really interesting overlap as well. Thank you very much. We're out of time, but thank you, Carmen, Mackenzie and Lori. That was a really great chat. To summarize: there are overlaps, but it's all about everybody bringing a slightly different skill set to the team and trying to get that balance going. I did like the "train and democratize", I think was the word you used. That's a great approach. I'm not sure if you've read Team Topologies, but they talk about enabling teams, and I think that's a great way of doing it: the enabling teams help the other teams to deliver. That's all we have time for, so thank you very much, and thank you for sharing your insights.