How Can Product Managers and UXers Help Each Other (and Why are Product Folks so Annoying Sometimes)?
The following article is based on a recent interview conducted by Lou Rosenfeld, Publisher of Rosenfeld Media from his podcast, The Rosenfeld Review. In this episode, Lou speaks with Rich Mironov, CEO, Mironov Consulting and a speaker at the new Design in Product Virtual Conference. The interview has been edited for clarity and length.
[Lou] I’d like to welcome to my guest, Rich Mironov. So Rich, how did you find yourself doing product management in an enterprise setting way back when?
[Rich] Completely accidentally. I was at a company called Tandem Computers and had come in on a strategy job, which was sort of ill-defined and not really interesting work. Somebody asked me if I wanted to be a product manager, and before I thought about it or asked what that was, I said, yes. These days, when somebody says they want to be in product management, I feel like it’s my obligation to argue the other side of that question for the first five minutes, because it’s all the responsibility and none of the authority. And so back to the psychology, we’re always trying to get the folks in every other department to agree to get on the same train and get the same thing shipped, but nobody works for us.
[Lou] Getting back to Tandem, you found yourself saying yes. Was this a moment of naivete that you look back on and nowadays you would tell yourself, no?
[Rich] I had fun doing it. I didn’t really know what it was for these first couple years and in those days, if we go back to the eighties, most product management really reported up through engineering. And so, we were much more of spec writers and product owners. So, I think I was lucky enough to start when it was a narrower, easier job. It helped that I was an engineer because that’s what they were really looking for.
[Lou] So you’re speaking at the Design and Product conference coming up really soon. It’s a new conference that we’re putting on at Rosenfeld Media taking place virtually on December 6th. It’s one day of really helping UX people and product people have a better conversation, because let’s face it, we don’t always. Understanding more of the UX side of things, there’s a lot of frustration, some of it fair, and some of it about the role of product folks not being the ones ultimately making decisions. And there’s so much opportunity for those two areas to just understand each other better, to work together better and to start speaking some of the same language.
Rich is one of our conference speakers and I know from talking with you, that you really see it as an exercise and maybe not so much psychology, but mediation. You see the person on the product side as really having a connection to many of the silos in an organization. And it’s a kind of unique place to be.
[Rich] I think that there’s a couple of root issues. One is that every single department in whatever company you’re in has this really short list of things they want from the product. And when you merge all those lists, you get something well beyond the capacity of your engineering and design team. And so, what that means for product folks is we are expecting every day to find some nice, polite, humane way to say no to 95% of all the stuff people want to give us and tell us is important. And that takes a lot of resilience and some thick skin. I think we’re trying to do a lot of intense filtering, because if even half of the interruptions I get a day are let through to the rest of the team, they’d get nothing else done. So how do we hold the line on whatever our plan was for the week and think about what we might consider next week when most of the fires are out?
If you slow it down just three days or four days, much of it evaporates and people move on. But if I let my designers and engineers get pelted the way my product managers get pelted every 13 minutes, they’d all resign. We don’t always get it right, but I think we bring a lot of heart to that. We bring a lot of patience, and we try to bring good filtering so that the rest of the team can do the work that they’ve signed up to do that they’re so excellent at.
[Lou] How do you maintain the ability to keep saying no and yet maintain the respect of the people you’re saying no to?
[Rich] I think if we turn it around, I don’t think the goal is to say no. I think the goal is to show what we’re doing that’s higher priority. There’s a phrase we use sometimes on the product side, which is called roadmap amnesia. It’s the effect that as soon as there’s something new I want, or a customer told me, or I saw an opportunity, my brain is wiped completely clean of everything else. And so, one of the first things I always do is I bring out the list of what we’re actually working on. Okay, here’s the five most important projects that we’re trying to get done this quarter. And you can just see the lights go on in the other person’s eyes because suddenly they see that making sure that we’re not violating GDPR for our European customers may in fact be more important than fixing this particular issue. Or if they’re on the sales side, sales teams don’t get paid unless they close the deal in front of them. And the fact that some other sales team had a bigger deal that got waved through isn’t of interest to them. Right? But if I can go back to the VP of sales and say, here are two of the huge deals. We’re supporting you this quarter, but if you want to sacrifice one of those two deals for this number five or number nine deal that’s smaller, we will do that for you, but you’ll make less money this quarter. There’s no engineering team hiding in my pockets. Everybody’s busy and so good product folks will start with the current plan and say, I would love to give you what you wanted. Help me figure out what we’ve already prioritized that’s less important than this. And then by the way, we’re going to need your help going to all those stakeholders and convincing them that they no longer want what they wanted, and they want what you want.
[Lou] What you’re doing obviously is you’re bringing in the reality of constraints. The fact that there’s not endless cycles of development and design and so forth that are available. I was talking with one of my people today who said, everything is code red. I don’t know what my priorities are, and I can feel that pain and I wish I could help better. This conversation helps me see that the constraints are time. Do you ever deal with things like a budget or a P&L?
[Rich] No, the money side usually belongs to sales and marketing, but the response I usually expect from execs who aren’t really steeped in the software side of the business are any sentence that includes the word “just.” As in, it’s probably only 10 lines of code. You can just do it, right? Product Management’s a lot like raising a kid because, version 1.0 isn’t very good. In the same way that your one-year-old can’t play the violin for the most part. But you’ve got a plan to make your product big and strong and go to university. And that means really watching out for and protecting your product from all of the really good suggestions that aren’t good and all of the shortcuts which aren’t short so that we can deliver stuff the customers love and keep in business. We have to love our products the way we love our kids because ultimately, we’re doing this because the product wants to be great and the product wants to survive, and people want to use the product to succeed. Not really just because it’s going to make the company money, right? If we were trying to make the company money, we’d have put up a crypto coin exchange last year.
[Lou] I want to just jump back to the roadmap. That’s sort of the Bible here. We need them for the reasons you’ve covered to help us understand what our constraints are and so forth. But we’re dealing today with so much uncertainty I’ve been fond of saying, in such cases you, you’ve got to make your own certainty. Are you finding roadmaps helpful even though conditions in the marketplace are so topsy-turvy and uncertain?
[Rich] Things are moving faster. We talk about roadmaps, strategy, and vision, and we don’t anchor them, right? And so, I would be using phrases like the three-month roadmap, because certainly in the enterprise space, we should probably be 90% sure what we’re going to build in the next three months because there’s a lot of moving parts. And if we have to change something, but I pegged the three months at 90% and I pegged the six months at 70%. I think you need a 12-month strategy so that you can anchor your work in something. And I think you need a five-year vision. But vision’s not actionable so when somebody comes at me and says, we need to be in this other business, that’s like a 5-, 10- or 20-year trip. And I can go off and do whatever thinking you want to do, but here’s what we’re doing for the next three months. So, attaching time definitions to these means that a three-month roadmap is different from a 12-month strategy. And if you’re not making hard choices in the three to six-to-12-month window, you’re not going to ship anything.
[Lou] Let’s talk about the UX people and how they are struggling and succeeding in their work with product folks.
[Rich] One thought I’ve had is over the last decade or so, product management’s finally getting its own representation at the executive team. And product folks are actually getting representation in the big meeting with the big kids around the big kid table. And UX isn’t there yet. I hope it gets there but, in the meantime, what’s really important is if you’re not going to be in the room where it happens, you need champions. You need people who stand up and merchandise the good things you did and talk about your successes and show that you are making an impact. And so, when I look at the very clear partnership between product and UX, I think it’s really incumbent on us on the product side to share the mic and to show and tell all the really good things that our UX team is doing. If there’s nobody in that executive meeting who’s saying your name out loud and your department’s name out loud, you find out that you don’t get budget and staff next time. So, because we as product folks are now finally getting access to the big kids’ table, I think we’ve got to be the people who cheer on and celebrate the great work that UX does because UX isn’t in the room.
[Lou] How should the UX people be helping you? Are there things that UX people are dropping the ball on there?
[Rich] Yeah, I think so on both sides. And if you think about that forum, that moment, it’s really about some short sound bites and showing some piece of work that can be demoed in under 20 seconds. And the UXers who are doing really good work need to sit with the product folks and make sure that products are a good megaphone for them. That means either showing or creating assets. It means making sure the product knows when we’ve done something good. I’m always encouraging my folks to come back and say, let me see if I heard that right. Nobody in the executive suite cares about what process we followed. What they want to know is did it move the needle? Did we have an output? Did we have an outcome? Product folks are pretty good at boiling long sets of discussions down to a couple of sentences. But we need to be walked through it. Execs really like show rather than tell. So, if there’s some before and after picture or video clip so that we can have our representative walk in the room and say, let me show you something really cool and impressive and surprising that we learned from our UX partners, that makes something happen in the company you care about. So that’s both recognizing it, translating it, make sure we have the asset so that we’re not spending 42 minutes with some folks who don’t care.
[Lou] But does it ever go even further? Do you see product people or product managers having their UX peers actually design the entire presentation in a way so that the executives understand?
[Rich] Oh, sure. I think that’s a question of who’s good at it, and who’s got the time. In the same way, if we think about interviewing enterprise customers or users right now, sometimes the UX team organizes those calls, but I always want a product manager and an engineer on the call too. Even though we don’t want them to speak, we want them to listen because product and UX and engineering all have different brains. We hear different things. I’m not allowed to whine about a real shortage of highly talented UX folks and designers if I haven’t gone to bat for them 22 times to get the money and the tools that we need to have them be successful. On the other hand, most product managers are not UXers or designers. And the idea that we’re going to double assign somebody to be both product and UX, for me, it’s a failed strategy. So, if I want my product to grow up to be big and strong someday, I have to figure out how I’m going to get great designers and UXers on my team because otherwise, we’re going to have less great product and I’m going to be unhappy.
[Lou] How do you find the UX people and product people are getting on the same page so that they can actually communicate better? Is it just a matter of spending time together? Is there anything you’ve seen that’s really kind of helped speed that along?
[Rich] I try my best and I try to coach my product managers to try their best to avoid all the keywords and the special meanings. Nobody on my staff ever uses the acronym MVP more than once. The first time I take them around for a lecture around the parking lot for an hour and the second time they’re fired. Because every single person in the room has a different idea of what they think that means. And none of them go back to the source documents. So, if I say MVP, the next thing I have to do is explain what I meant and it’s different from what everybody else meant. I think a lot of the language gets in the way and when we’re talking about design systems, I honestly have no idea what one of those is. And then the most important thing for every team is we should do some bonding that’s not about the work. Let’s just all go out for dinner. That’s the moment when we all learn to trust each other. We laugh, we talk about our kids, our pets, our sports. It turns out we’re all very similar to each other. I think taking the team out for dinner and drinks that’s worth 20 hours of defining terms and looking at racy charts and wasting process moments.
[Lou] Well Rich, that advice is also worth quite a bit. That’s really golden and is something that’s accessible to anyone who’s listening to this podcast. Thanks!
Join us for Rosenfeld Media’s Design in Product, a new virtual conference scheduled for December 6. Learn more at https://rosenfeldmedia.com/events/futures/design-in-product/
The Rosenfeld Review podcast is brought to you by Rosenfeld Media. Please subscribe and listen to it on iTunes, Stitcher, or your favorite podcast platform. Tell a friend to have a listen and check out our website for more than 100 podcast interviews with other interesting people. You’ll find them all at RosenfeldReview.com.
