Product management & UX with Melissa Perri
A transcript of Episode 120 of UX Podcast. James Royal-Lawson and Per Axbom talk to Melissa Perri about the overlap between the two disciplines and discuss some of the issues surrounding their convergence.
Melissa was interviewed on UX Podcast in February 2016. She is currently working on her book The Build Trap and will be speaking at UXLx this May.
Transcript
James: Hi and welcome to UX Podcast, balancing business technology and users every other Friday from Stockholm, Sweden. I’m James Royal-Lawson.
Per: And I’m Per Axbom.
James: And this week, we are interviewing Melissa Perri.
Per: Yeah, it will be excellent fun. Melissa is talking at UXLx and if you have been a long-time listener to the show, you will know that this is the conference that we basically visit every year, and it was the starting point of the podcast that we visited it together —
James: Yeah.
Per: — back in the day.
James: In 2011.
Per: Yeah.
James: And we’ve partnered up with UXLx this year to bring you coverage before the event and, well, during and after the event as well.
Per: Yeah. So you’ll definitely want to check out the website ux-lx.com and see the speakers there. We’ll be talking to many of them and so tweet us. Type the questions you want us to ask and who you want us to talk to. Alan Cooper will be there. Dan Klyn of The Understanding Group, Amber Case who is a cyborg anthropologist, Abi Jones from Google, and more and more and more. So, it’ll be just great wide spectrum of different topics as per usual, and sunny Lisbon as well, always great fun, great nights.
James: You’re overselling it, Per. The point is —
Per: You can get to meet us.
James: The point is it always sells out, so don’t leave it too late to buy your ticket. You can get on the website now and — to be honest, if you haven’t bought a ticket before listening to this talk Melissa, then you will do afterwards.
Per: Yes. So Melissa is doing a full day workshop. Melissa is a product and UX consultant at her own company, ProdUX Labs. She’s a teacher. She’s a coach. She’s a speaker and she’s mostly famous I think for her talks and workshops on Lean UX which is what we shall be doing in Lisbon as well. And she coaches a lot as well and she coaches product managers to answer 2 important questions: Should we build this and why? So, let’s jump into the interview with Melissa. Start us off by telling us a bit about how did you get into this world, what did you do in school, what was your first job, why did you want to do UX?
Melissa: Yeah. It’s really funny because I started realising how all these like stars have aligned on my path here recently. It’s one of those things where when you’re in school or when you’re doing things, you don’t realise how it kind of relates to what you’ll do in the future. So, I guess my background is in operations research engineering so that’s why I studied at Cornell. So, I was very into like statistics and optimisation then. I was studying chemical engineering actually before that and I hated it. It was not anything like chemistry, which I liked. It was more like “Let’s figure out these calculations on pipes and stuff,” and I hated that.
So I got out of it and I tried to find like a more business-y engineering which was operations research. But at the same time, I was also working for Cornell marketing designing all the promotions and posters and stuff for the campus because I had studied in high school how to do Photoshop. So I always loved like this little component of design and I was doing engineering and I couldn’t really find something that fit me very well, like there was no career path that they told me about for, you know, UX or product management. So I had no idea what I wanted to do. Everybody was graduating from my program and either going into finance or supply chain management and I really don’t want to like work in a factory at Pepsi and optimise supply chain. That’s what people are doing.
So, it kind of started when my friend from college, he went to work at a company called Capital IQ and they said, “Hey, we’re hiring people. We’re coming to the campus to interview developers,” and I said, “I can kind of code, but I don’t really want to code. Can I talk to you guys?” And I explained my background to the hiring manager. They’re like, “Just come in, chat with us, it’ll be fine.” And I was explaining to him what I liked and he’s like, “Oh, you’re an engineer and you can do Photoshop, you could be a product manager for our company.” And I was like, “I have no idea what that is, but that sounds good.”
So, I learned at Capital IQ how to do product management in UX and at that time there was no differences about 10 years ago. I’m sure like UX existed as a — you know, as a principle back then but at the same time, we just kind of like shoved it all into one person at that company. And then the next company I went to is the same thing. I just found like everybody was a product manager and a UX designer and we just called them product managers.
James: Yeah. Yeah, 10 years ago, we didn’t really say — in business context anyway, UX didn’t exist really at all. We had lots of different names for what we did, but it was generally we knew what we were doing but we accepted whatever the company —
Melissa: Called you.
James: Called you, basically, yeah. So if I mentioned architect or interaction design or whatever, product manager in your case.
Melissa: Yup.
Per: I tracked it back to actually the first time I used UX on my blog was 2008, I believe.
Melissa: Oh, wow. Okay.
Per: Which is actually — that was when — I think someone from Adaptive Path was the only talk in Sweden.
Melissa: Yeah. That was right about that time, too, that I was at Capital IQ so —
James: I think I avoided it until after we started the podcast.
Per: Yeah. After we started the podcast.
James: So, yeah, 2011 or 2012 I think when I gave in.
Per: So, one of the reasons we’re talking to you now, of course, is that we’ll be meeting you in Lisbon in May and you’ll be doing a full day workshop there, which is a first for UXLx in full-day workshops. So what will people who attend your workshop learn?
James: Yeah, the workshop is called Lean Product Management for UX.
Melissa: Yes. So, yeah, I am pretty excited to teach this workshop. It’s geared towards trying to teach UX designers about product management. When they reach out to me from UX Lisbon about doing a workshop, they said they are seeing more and more UX designers trying to learn about product, which his really interesting to me. So, I kind of devised this 1-day workshop that focuses a lot on filling in the gaps for UXers to learn a little bit more about product management.
So, they’re going to learn about, you know, what makes good product metrics, how do we measure products, how do we merge that customer value and business value and find things that actually move the business forward, how do we actually do testing or hypothesis, how do we write hypotheses, how do we prioritise, how do we roadmaps. I think a lot of that kind of gets lost. I see companies also struggle with those things just in general with product management and that’s what I do, I come in and I coach them and I help them figure out how to prioritise things, how to think about it the right way, how to find customer problems.
And I think UX designers are uniquely positioned to be able to really grasp that stuff because they worry about the customer problems already. They’re always — they’re already thinking about the users, so they’re light years ahead of most of the people I work with. It’s just a matter of also getting them into the rhythm of considering the business values, seeing the objectives for that and really measuring strategically how these things are going to move our business forward.
James: Something that we’ve seen or noticed particularly on the podcast this last half year, we’ve had a few episodes and discussions around this kind of spectrum side of things. I mean we’ve called it — we’ve given it different names. I mean we’ve called everything from the device of UX to UX strategy or utility of the UX. But it all comes down to similar kind of things that this — you’ve got product manager on one side or customer’s experience and then UX on kind of our side. And a lot of people on this side either land grabbing or worrying about how they’re transitioning or understanding — starting to understand more about the product management world out there.
Melissa: Uh-hmm.
James: And it’s interesting to see you coming from the other side maybe more on this one.
Melissa: Yeah, it’s been really interesting too. I’ve seen the same thing and it’s funny because we call it like 14 different terms but I think we’re all talking about the same thing. And that’s just trying to find, you know, this balance of being strategic about solving our user’s problems. And that’s something that we started talking about and wrote a blog post on recently, is you know what’s the difference between product management in UX and how do we get into that and apparently struck a chord with a lot of people. It was one of those things. I just threw it together on a Sunday and then it blew up and I went “Wow! Okay.” People are upset about this. So I find —
James: Oh, they were upset. They’ll just kind of — like Per and I both shared the post but — so some people weren’t just kind of pleased with the content. They were actually upset with the content.
Melissa: No. So, it was more like they’re upset about the situation. They were actually very pleased with the content. I got so many emails in my inbox too that was like “Thank you so much for writing this because I’ve been having this debate at work for years and nobody will let me do like UX. They’re like ‘That’s not your job. You’re a product manager.’” Or product managers will be like — or UX designers will be like “They won’t let me make business decisions. They won’t let me, you know, influence and stuff.” And I think we have such a problem of separating the roles too drastically that we have no middle ground there. And it becomes a land grab.
I’m experiencing it with the companies I worked with too where we’ll have the UX design team whenever the product manager tries to suggest something that has to do with design or, you know, the flow of the app. They’ll be like “No, that’s our job. You’re not allowed to do that. Just stick to the business departments. Don’t get into solutions space. You’re in the problems space. That’s where you should focus.” And I think that’s a real detriment to companies, to not have that kind of collaboration.
To me, the best teams I’ve ever worked on or with, we don’t sit there and go “That’s not your job. You’re not allowed to do that.” You know, you have a team that works very closely together and if, you know, a developer wants to do user research this time, go do user research as long as you kind of know what you’re doing and you have an interest in it. I always find whoever wants to pick up those tasks and do it, it’s just for the better of the company to move that way.
James: Yeah, I mean it’s a real kick in the teeth for collaboration when you have that kind of boxing of roles with such defined edges to them.
Melissa: Yup. It’s too cut-and-dried people consider that. I have that problem too that when I go in and interview companies or I go in and I talk to people at these companies, they’ll make me choose. They’re like “Are you a UX designer or product manager?” Like last year I was talking to somebody at a company considering a job. And they were like, “Well, we need to know what team to put you on. It’s either product management or UX.” And I was like, “I do equally both of those things, like I designed all the UX part. I do all the product management. So I don’t know why you want me to choose between these things.”
And I haven’t really found any company that has a role. There are kind of these product designers who are coming up as well. I’ve seen that role out there a lot. I thought that was the way that was going to merge these roles. It sounds perfect, right? Like product and designer, just sounds like it merges it. But now I’m seeing companies treat that more as visual designer as well. They don’t — they put nice flashy terms on things, but they don’t understand what those roles are, like what they’re supposed to do.
Per: So it seems like the role names are causing confusion more than they’re helping.
Melissa: Yeah.
Per: The way we’ve been talking about product management on the show has actually been more around the fact that the UX or the term UX is being watered down because anyone is calling themselves a UX or even if you’re just doing wireframes and not user research or even if you’re an art director, you call yourself a UXer.
Melissa: Yeah.
Per: So you don’t really know what people do anymore when they say they’re in UX. We’ve been looking for a term that can help you define your role better which has been product manager. So that’s why we’ve been looking at it.
James: We also threw in the macro and micro-UX —
Per: Yeah.
James: — to try and help distinguish it.
Melissa: Interesting.
James: So micro-UX would be what we used to call interaction design and maybe the more deliverable side of things. We’ll get into the nitty-gritty of the end-results. Whereas macro-UX would be more broad-scaled and holistic and closer to product management.
Melissa: Yeah. That’s interesting too. I haven’t heard it split up before between my micro and macro, but I like the way you’re thinking of it that way. I think it’s just one of those things where you can’t completely remove product management from UX and you can’t completely remove UX from product management. Otherwise, you end up with terrible products. So it seems natural to me that you would want high collaboration in those areas where you make those decisions and yet I don’t see that happening.
I think it’s mostly though because people just don’t understand what UX is like you were saying. I’ve seen a lot of people from the agency world now call themselves UX designers and they’ll come in and — it’s like a different type of thing when you work from agencies. I’ve had that problem with consulting too. Every time I do a redesign for a company or I try to help them with their UX, they expect it just to be pretty and, you know, handed off and it’s been — I started consulting on my own like 2 years ago.
So, I’ve been kind of figuring out how to really see if, you know, my clients understand what user experience is before I engage in it because I personally don’t like, you know, not doing user research when I do this. That becomes a huge struggle. You think it wouldn’t be, but I’ll go in to talk to people about their website and they’ll be like “Yeah, we want it, you know, we want to completely do the UX. We want to make it a better experience. We want to have beautiful visual design.” I’m like “Okay, great. All this sounds fantastic. I need to talk to 5 of your customers so that we can start understanding where the problems are,” and they go “Oh, no, no, no. You don’t have to do that. That’s a waste of time. We already know what we want. We’ve talked to them about it.”
And then you get into these conversations with them while you’re working and, for example, one client I had where we’re doing a filter and they wanted to put these tags on the filter. They had to be able to go through it really fast. And they said, “Well, we have hundreds and hundreds of tags that you can choose from. We really need a sophisticated way to go through it.” So I designed it and they said, “Oh, no, it’s not big enough. People could tag up things up to 100 times.” And I said, “But are they? Like do you have any statistics or any like data or have you talked to them about how many tags they normally use?” “Oh, no, we don’t have that. But you should just design it so that they can do up to 100.” And I’m like, “That’s a waste of space. That’s — ”
You know, we can probably solve this debate. We could go on back and forth about it for days. I’m like “We can solve this debate in like 2 seconds if you just had data or if you just let me talk to somebody,” but they don’t see the value in doing that for contracting and I see that same kind of mentality in people who come from the agency world who are used to doing those visual designs or doing projects like this because, you know, it’s more about appeasing the client than it really is about appeasing the customer, and UX became a trendy thing to talk about.
I like the way people in the agency really do bring to life stuff like they always create really nice, very beautiful products, but they kind of lack that substance underneath if it’s a heavily visual design company that they’ve worked out before.
Per: That is the key to it all, isn’t it? That you actually as a UXer, you care about the data as well.
Melissa: Yeah.
Per: And not only data about the users but also data about what does it bring to the company in the end.
Melissa: Uh-hmm.
James: I think I’m a big advocate of the hypothesis with working, whether we call it lean or something else, it’s just —
Per: Scientific method.
James: Exactly, the scientific method. I think, you know, just having that approach is something that’s very healthy and as Per says, I think it — in my experience, it can be missing from a lot of projects, not just the agency side. I think it can be also when — several situations probably. Another example would be when you’re working with enterprise software where you’ve got an extra layer in between you and the customer because you’ve got the end-users but then you’ve got clients who actually buy — or the customers of the enterpriser organisation who buy it. So, I think that can be also difficult and difficult to find the data to back it up because you’ve got the sales process and the end-user process.
Melissa: That’s such a wonky process.
James: It’s different compared to if you’re working with a product, an app or a website where you’re actually driving it straight to the sales process to the end-users. Yeah, data is very useful I think in those situations when you’ve actually got the ability to get it.
Melissa: Yeah. And what I’ve noticed too is in those situations — I worked at a company that was a B2B software for SEO and I was, you know, the lead UX designer there. So, I was the only UX designer there, so I did the UX for everything. It was again one of those things where we had like 6 product managers and they would just shove things at me and make me design it and they didn’t understand what UX was. They only understand it as visual design.
But at that company as well, I found that salespeople would promise, you know, their clients pretty much whatever they wanted without really consulting about the UX on it or the tech. They’ll be like “Is this feasible?” And tech will go, “Yup, we can actually build that.” And then they go, “Okay, great. You’re building it.” You’re like, “Wait, wait, wait. Let’s have a conversation about this. Let’s actually figure it out.” And that’s — you know, it’s the nature of sale structures too, right? Salespeople get paid on how much they sell. So, if they sell a lot of stuff, that’s great like fantastic. They make a lot of money. But that doesn’t really work beneficially for UX.
So, I try to as well — what I really, really love doing is training salespeople on how to do user research and turn them into like a nice little swat user research team and have them go out and, you know, tell them the right questions like asked, have them not just try to solve people’s problems, but find out what those problems are and communicate that back. And if you can get into a drive like that, there’s a company that does it in England, it’s so valuable like they interact with customers all day and you have just this constant feedback of problems like coming in that you can actually work with the team to solve and I think that’s like the most beneficial way to do sales, and they’re good at it. Like they’re really good at talking to people and like prying out the information and they love it.
And, you know, there’s just this whole force that companies have that they could take advantage of but they’re not because they’re just trying to sell their thing very narrow-mindedly without actually exploring all the different ways that they — you know, all the different products they can make, all the solutions they could possibly come up with just by getting the information, just by getting those problems out.
James: Exactly understanding, so training the salespeople to understand the why of their sales leads rather than just provide a solution.
Melissa: Exactly. Yeah. They jump into it. It’s like — I was in that same company. I finally convinced them to let me do user research. That took a long time to convince. And I remember they gave me like the salesperson to go with me to the clients to babysit me and make sure like I didn’t say anything bad. So we were sitting in the room with one guy and he was telling me about his problems and I was like really excited because there was a lot of things we could solve. And the salesperson was sitting there trying to solve all his problems. “Well, you can that and you can do this and we have these products and we can build this for you and we could do that.” And I was like “Stop it. Can you please stop? Like I just need to do research.”
And what happens too is that the client, you know, would shut up. He would stop talking about his problems because he was just “Oh, they’re going to solve it anyway, so I don’t have to think about this.” And you lose all that wonderful dynamic and that feedback. So, that’s a struggle I see with a lot of enterprise clients. But I also see they’re like so well setup to do better testing. Whenever I do like my workshops on MVPs, I always get enterprise people there who are like, “Oh, but we can do MVP testing. We’re a B2B company, you know, we’re bigger. We have more risks associated with what we do.” I’m like, “Yeah. Well, that’s why you should be testing too because you do have higher risk.”
But I like the B2B companies because you know who your clients are like you can literally go to their office and sit down with them rather than consumer companies where if you want to get prospective clients, you have to go out on the streets and go to Starbucks and try to talk to people, you know. It’s really hard to find who your customers in that case. B2B companies, you literally can show up on their doorstep and like walk in.
So you’ve got all these people to talk to. They’re also pretty passionate about using your products because they usually help them when they’re working. So, we used to do testing with them and put feature flags on it so we would only turn it on for like a select 5 customers, let them try out new products, new MVP-type things, see if it worked, you know, and then we would go back and actually invest in building the whole things. And it’s so easy to do that with B2B companies but people are really scared about it because they think it’s — they think that it will provide a bad experience for the customers and that’s just not true.
Per: I really like what you’re saying, you’re at Lean UX and MVPs can be applied to any type of company, any type of organisation, whatever the size because that’s a debate we’ve been having with other interviewees is that it can’t be applied in larger organisations. It’s a start-up thing, and what do you have to say to that?
Melissa: Oh, no, I believe it could be applied everywhere. I’ve seen large companies adopting it as well and I think that’s smart. It’s just the systematic way to test your hypothesis. I think it’s kind of arrogant to assume that large companies don’t need to do that, right? They probably — they have a lot of cushion to fall back on which start-ups don’t. But, you know, they still are not always right and that’s the whole point of, you know, Lean UX, Lean product management. It’s just saying, “You know what? We don’t know everything. So we’re going to go out and actually find out what we don’t know before we commit to doing this and we’ll see if it’s a good idea or not.”
And I think everybody associates these principles as well with, you know, Eric Reese’s buttons to know where MVP stuff. And to me, like that’s not like a great MVP. I think it could be in a certain situation but for me like a minimum viable product is just the least amount of effort that you can do to learn and that can be in all sorts of things. It could be, you know, building some kind of functional prototype of your product. It could be building a minimal version, but I see that as leaders teaches of an MVP. I think the beginning stages of an MVP are, you know, quick tests to really see if people are interested. They could be pitches. They could be idea like Wizard of Oz sings all the time where they look real and on the background they’re all manual.
But it’s just trying to learn if people will want it and you can do that in any amount whatsoever. And the large corporations too, I always get asked these questions and they’re like “Well, it takes 3 years for us to ship something, so we can’t possibly do an MVP. You know, we can’t do these things that you’re talking about where you spin them around in a week or two.” I’m like “You don’t have to. You don’t have to spin something out in a week, but if it takes you 3 years to ship something and you could test something in a year and find out if you should spend the next 2 years building it, that’s pretty good like that’s a pretty good skill. You reduced it by a third.”
It’s not about, you know, doing things in a week or two. I push companies that are able to do that to do it as fast as possible but it’s just about taking that timeframe and instead of waiting 3 years to learn if somebody is going to like it or not, you do it as fast as you can. You do it in months. You do it in a year. You just break it down. And people don’t understand that when we talk about Lean and I think that’s why the word is kind of just falling out of favour a lot, which makes me sad because —
James: Like most of our words.
Melissa: Everything.
Per: Yeah.
Melissa: Yeah. And it’s just — it’s a lack of understanding.
James: Although in 6 months, it’s gone.
Melissa: Yeah. It’s just a lack of understanding with, you know, what does “agile” mean and what does “lean” mean. Everybody sees these surface things. Even user experience like we were talking about has become a buzzword. Nobody knows what it means anymore, but the principles are still so valuable. So, for me, like as a consultant and a coach, I try to like strip away all these buzz words that I use when I talk to people and I just try to talk about what you’re going to get out of using these techniques and that responds pretty well. People respond well to it.
Per: I like what you’re saying now about a quick experiment. It can be a year.
Melissa: Yeah.
Per: Because that’s what people generally don’t understand. When you say — usually when you hear people talking about Lean UX and they say, you do a quick experiment, it doesn’t have to cost much, you think days or weeks. So it has to be in relation to what the old project is.
Melissa: Yeah. If it’s an 8 billion dollar project and you can test something in 3 million dollars, it’s a pretty decent, you know, scale to look at. I think — yeah, it’s not about being cheap. It’s not about spinning things up mindlessly with no way to go. It’s just about trying to learn faster because when we take so long and put all our eggs in one basket with the solution and then release something after months or years, you know, we have all that lead time to learning. So it’s just about reducing that lead time and learning as fast as you can. That’s the whole point of this.
James: I think you could also — just thinking about it now as well that when you’re creating something to learn something, then it’s just about making something that’s shareable artefacts and you possibly don’t even need to share it with the end-users to learn stuff.
Melissa: Yup. Yeah.
James: I was thinking that you could share it with people inside the organisation. That’s I guess kind of potentially give you the insight you need to do another spin.
Melissa: Exactly. I think that’s huge like I would always advocate for trying to get it in front of customers as much as possible, but when I work with companies that are really, really far from doing that, I just try to get them to show it to somebody else, just anybody else, right? In their organisation, somebody who’s not on the product or tech team. Show it to the customer support people because they’re dealing with the questions all day and they could probably give you pretty good feedback on it. But I think that’s like the first step in trying to get people comfortable. Just show it to somebody else.
James: I think I even got a guy — one of the ones I did recently, one of the system testers came in and tried one of the things we were working on and that was excellent because they’re so good at knowing exactly — every single thing that this product did. They knew, because it was their job to systematically test it. So when they came in, they were trying questions about, you know, what would happen and, you know, we could quickly iterate and come back with a different version that was better fulfilling the purpose.
Melissa: Oh, that’s really cool. I like that.
Per: I have one system tester right now who is my best devil’s advocate. She’s questioning everything which is awesome. I like it.
Melissa: Yeah. I like people who ask questions. Anybody who asks good questions, I want on my team. I want people to keep going why, why, why, why. I think that’s the only way you get better, is if you assume that you don’t know all the answers and you want to find them out, you’re curious.
James: So you’ve been working with Lean UX for a while now, how has Lean UX changed over the years because I’m guessing it’s not the Holy Grail. We don’t stop here. I mean that development process has to change as well. Have you seen anything happened to it?
Melissa: Yeah. I guess when I was starting out in this area to like I said with the small experiments, we were all very much pushing people to test things as rapidly as possible and considering it in a week or so. And as I’ve been working with larger companies and bigger organisations, we’ve realised, you know, that scale could be very different. I think that’s been one of the — like we just talked about. I think that that’s been a big revelation for me. I think this notion of, you know, getting data-driven answers has really become more focused in Lean UX. I think a lot of that is coming up more people are understanding the importance of data from that.
I think it’s just going to keep evolving. In the future, I think our terms are going to change. That’s probably going to be the biggest thing because I think all these terms are a little bit falling out of favour, but we’re seeing more and more corporations actually take this on. They have different requirements. In the Lean UX community, I think at the beginning, we are very much focused on doing the practice. So how do you do Lean UX? How do you do design studios and, you know, tips from Jeff’s book.
Now, I think we’re all realising too that there’s so many organisational changes that have to happen in order to support this way of working, and I think that’s really the biggest shift that we’re seeing with Lean UX. I know myself and a lot of other practitioners have realised that we can’t just teach the tools. We have to teach people the way to think and we have to teach managers in the organisations and people who make those decisions about these practices and why they work from their business perspective.
So I’m seeing more people go into almost those management type consulting which sounds horrible to say because I know nobody likes management consultants, but they’re turning that to like train it and I myself have been working with a lot more executives in the companies I go into where, you know, you’re sitting down with a CEO. I work with a lot of, you know, very — I won’t call them start-ups anymore because they’ve been around for like 5 years and they’re profitable, but they’re in that transition where they’re — you know, they’ve grown so much like the one I’m working on right now is 500 people.
So, they’ve grown enough where the founders can’t make the decisions for the product anymore, right? They have to scale. They have to worry about other things. So I work with them a lot to get them comfortable and to understand, you know, let this come from the team. This is the way that they work. They have all these hypotheses they want to test. It’s okay for them to test. It’s okay for them not to have a year-long roadmap with buckets of product features because they’re going to find out what those features are by testing.
And getting management to understand that has been a real struggle and I think I’m learning myself more and more that I have to do a lot of convincing on that side. The teams usually buy into this pretty well, but convincing the management to step off a little bit to like rethink about how they consider product roadmaps. It’s not just, you know, a list of items to build over the next year. It’s not a Gantt chart. It’s more of a strategic direction the company wants to go in and areas to explore and build products around, but they’re full — all my product roadmaps are just full of hypotheses unless they’re validated.
If we validated something, we’re saying, “Okay, great. Let’s actually go build that. Let’s make sure it’s a nice robust solution for it in an iterative way where we’ll start minimal and keep adding on as we learn, but we validated it.” The other stuff is “Okay, we want to explore this area. We want to make sure this is a real problem. I’m going to test in it.” And we just kind of line up our hypotheses for the next quarter. That’s how we’ve been considering the product roadmaps instead of treating them like a Gantt chart.
James: An important skill there or question I have with that is how do you prioritise the different hypotheses?
Melissa: Oh. So I usually weight it. I have a different scale for every company, but what I’d normally teach is value versus effort. I think — no. I don’t keep the effort on there. Actually I take — everybody always says why don’t you prioritise against effort but I do strength of the customer problem versus value to the business. So I make these 2 axes on a chart and then I take every hypothesis and I say “If we solve this problem for users, is it a big enough problem? Is there a big enough market? For example, if you’re a B2B company, how many customers do you have that actually have that problem? How many companies are in your portfolio right now where you can actually take money for them to solve this problem?”
So we look at strength of customer problem and then the value to the business. So the value to the business is related to whatever KPI you’re solving for, your metric or key performance indicator. So, for example, if you’re doing retention and you’re solving a customer problem, you would look at it and say, “If we solve this problem for users, how much do we think will gain in retention? Like how many percentage points do we think will go up?” And we take a guess and this is all, you know, a little bit hypothetical until you prove it, but it does allow us to be a little bit more strategic about what we do and also see if there’s things on our roadmap that are not going to get us to that metric. That happens a lot. People will put things for, you know, acquisition when they really want to concentrate on retention. It’s like “This quarter we want to do retention. If we do acquisition, we’ll be a little bit too unfocused.” And you surface those things when you start prioritising.
I don’t do effort because I test everything with a minimum viable product usually. So to me there’s always usually a way to break things down into smaller chunks and we can kind of customise our effort depending on what we need. So that’s why I don’t go too much into effort, but I will try to see is this like an impossible thing to do versus a realistic thing to do. That’s kind of where I get on to it.
Per: When you’re saying acquisition and retention now, you’re referencing the pirate metrics I think.
Melissa: Yeah.
Per: Say them for me because I don’t know them like I know revenue —
Melissa: It’s acquisition, activation which means how do we have somebody make the first move on our platform and kind of become a customer. Revenue, retention, referral. So I teach all my clients to really like figure out which metrics they want to focus on and have teams organise around those metrics and try to solve them. That works really well because it provides a lot of focus on the team so you’re not going “Oh, I’ve got all these like ideas in the backlog. Let’s just build them.” You go through your backlog and you say, “What is our goal for the next quarter? All right, these things are — ” I don’t actually like backlogs either.
But you look at your things that you want to do and you’re like, “Ah, this goes to retention, right? Like so we’re going to look at these things.” None of this has anything to do with retention. We’re not going to worry about them now. We’ll worry about them next quarter. I think there’s — I like to have backlogs of hypotheses rather than feature ideas.
James: But that sounds much more healthy.
Melissa: Yeah.
James: Because it means it leaves the door open to decide exactly what you do.
Melissa: Exactly. I don’t like backlogs because people treat them as a promise that will actually get to it. And then I — I remember like my second job as a product manager, I had something like 2000 tickets in the backlog and I looked at it. It was a small company too. Been around for 6 months, we already have 2000 things in the backlog. And you’re looking at it and you’re going, you know, “I put this in here 6 months ago when we were starting. Now, you know, we’re a 60 million dollar business, it’s just not what we need anymore but it’s still in the backlog.” And they’re like “When are you going to get to it? When are you going to build it?” And I hate stuff like that.
So, and it just becomes a time sync, you know, always grooming it, always going back to it. So, I try to keep just like the last next 5 hypotheses we want to test in it and then split them out as we go and I’ve never let it go any longer than that.
Per: That’s a way more structured way working than I’m doing right now. I hate to admit. I love it.
Melissa: I don’t like — I’m very — I don’t like committing to things that we don’t know will work, so I think the backlogs always make people angsty like that. And I get into conversation with people I coach to about “How should we do backlog grooming?” I’m like “Can I see your backlog?” It’s got, you know, 400 tickets and I’m “How are you going to possibly groom this? This is going to take you — you know.” They’d say, “Oh, we want to go systematically through and make sure we have enough information.” I’m like “Do you even care about like 399 of these tickets right now? Like you’re going to — every sprint we do, you pretty much put something else in it anyway. Like when was the last time you grabbed something out of here?” They’re like “Maybe we grabbed 2 things out of the product backlog a month, right? Otherwise, we come up with new things to build.” So, I think they’re just a lot of overhead and a big time sync for most people rather than being a helpful thing.
James: I think that’s a good — that’s a good kind of metric to — or way of measuring it. If you ask someone how many do these do? What’s your burn rate of things in your backlog?” And say, “Well, it’s actually +20 every month.” “Well, there we are then. You need to alter the way you’re working because you’re not working in a sustainable manner.”
Melissa: Yeah. And then I see like a lot of debates and churn over that and you’re like this is a silly thing to like be fighting about especially within the team, like I’d rather have debates about our hypotheses and what we’re going to do for users and yet I see a lot of people debate how to — like how to groom a backlog or how to write user stories and like these aren’t debates like we need to just decide what to do and go on with it like that’s not creating more work for us, they’ll just not create a lot of overhead. This isn’t the point of why we’re here, right? We weren’t hired for this company to debate how to groom backlogs.
Per: I’m going to bring this to my team tomorrow.
Melissa: Let me know how it goes.
Per: I believe it’s time for our 1 to 7 scales, right?
Melissa: Alright.
James: I reckon it is.
Per: Yeah. Do you want to go first? Should I go first? So the way this works now — we have to explain it to listeners now. This is the first time.
James: Yup.
Melissa: Explain why 7.
Per: Yeah. We are really bad at closing interviews because we just go, “Okay, so we have to finish now,” which seems really rude when we do it usually. So this was a nice way of segueing into an ending of the interview. And we’ve thought of dozens of different ways of doing it as well, but — so in our backlog, we have others as well, but this is the one we want to go with now. James picked 2 questions. I picked 2 questions and it’s something that you will have to rate on a scale of 1 to 7. And we were afraid, James flagged that one, she’s going to want to talk about each of these questions as well and we’re going to say, no, you’re not allowed to talk about the questions when we ask, but you’re allowed to rate it. But you’re allowed to comment on it after we’ve asked all four of them.
Melissa: Okay.
James: We’re being fair. We’re being nice. So, I’ll go first then. On a scale of 1 to 7, how much of a UXer are you?
Melissa: Oohh, that’s a good one. I’d say 7.
James: Oh, yeah, we’ve got to say which one is most — oh, actually, 7 means completely and 1 means —
Melissa: What’s it — ?
James: You got it.
Melissa: What’s it weighed against? Is it like UX versus product? Or is it just UX in general?
James: Well, I’ll go into the second question.
Per: Now you’re talking about it.
James: Yeah. On a scale of 1 to 7, how much of a product manager are you?
Melissa: Oh, then I’d say 7. I’m both.
James: There we are then.
Per: Excellent. Okay, mine. On a scale of 1 to 7, how well do people generally understand the meaning of MVP?
Melissa: 1.
Per: And on a scale of 1 to 7, how important is your job title?
Melissa: 2.
James: We’ve gone —
Per: Interesting, yeah.
James: We’ve gone polarised on those —
Melissa: Yeah.
James: It’s all or nothing.
Melissa: Yeah. I think for like UX versus product, I don’t like choosing between them. I think I’m just a UX-y/product-y person, so I’m 100% both. And if you ask me how much of a visual designer I am, I will tell you none. I would be more like a 4. But — and then for the MVP, nobody knows what an MVP means. I scare people. When I say that word, I’ll come in and say, “Oh, we should really like do an MVP,” sometimes they slip and forget that I’m using the terms. And I said that too in one of my last clients, one of the developers there and he was like, “No, we can’t do that.” I was like, “What happened? What did I say? When did I offend you?”
James: Is that a problem actually? Everyone does think they know what an MVP is?
Melissa: Oh, completely.
James: Rather than not know because then it becomes their own interpretation.
Per: Yeah, yeah.
Melissa: I think they know what it is.
James: No one has the same definition, so it ends up just spiralling out of control.
Melissa: It’s really great too because when I teach the MVP workshop that I do, most people come out of it and they’re like, “Wow, that really changed my way of thinking about this stuff. I loved it.” But then other people come in thinking that they know what an MVP is like a minimum feature set is what they think and then they’ll be like, “Oh, this is terrible. You didn’t teach me how to prioritise my backlog to come up with a minimum feature set.” And I’m like, “You missed the entire point of this. Great.” But that’s what people want. I think it’s just more like also the way that we think in hypothesis is actually very uncomfortable for people. They’re not used to questioning what they know and what they don’t know. So they just want more of a recipe on how to build stuff, how to get it out rather than how to think about building it and how to approach that. I think it’s just a nature of human beings. So, it’s even like — it’s more of a battle than just even saying that people don’t understand what MVP is. It’s a whole way of challenging how people think.
Per: So, if people want to get in contact with you —
Melissa: Yeah.
Per: — is it Twitter?
Melissa: Yup, @lissijean on Twitter or you can send me an email melissa@produxlabs. I named my company ProdUXLabs.com. Everybody pronounces it like that though. But if we say it really fast, it sounds like products.
James: Products, oh, I get it. Yeah.
Per: I would have said products.
Melissa: See? Oh, you’re like one of the first people. I thought it was being really clever naming my company that and then I realised how everybody pronounced it and I probably should have tested that first, but I didn’t.
James: Exactly. That’s naming your companies, one of those things that’s kind of difficult to test.
Melissa: Yeah. I’m writing a book right now and I had like a very strong commitment to naming it something and I really wanted it and then I started telling people what it was and I realised that may not be the great name, so now I’m testing like a bunch of AdWords to make sure I have the right name for it.
Per: Ah, interesting.
James: So, The Build Trap is what’s —
Melissa: Yeah.
James: It’s actually the current title or the old title of a new one?
Melissa: That is the title that I’m getting with right now. I might change it to getting out of the Build Trap which seems to be tracking better on AdWords right now. But I was wondering to put Lean Product Management in the title instead because people said Build Trap kind of sounds like scary. So —
Per: Ah, interesting. Okay.
Melissa: Or it sounds a little bit like failure and I was reading Gene Kim and Kevin Behr’s blog post about naming the Phoenix Project and it was a very similar thing to what I’m going through right now, and they suggested testing it in AdWords. And I was like “That’s a great idea.” I should actually —
Per: It is a great idea.
James: That’s a really good idea.
Melissa: Yeah.
Per: And you’ll get lots of tweets now from our listeners about what they think it will be.
Melissa: Excellent. I want to hear because then I’ll know which one to go with. I’m challenging my own assumptions.
Per: And I suggest that everyone visit your Slideshare page as well because all your presentations are really cool, all their cat front pages, which I love.
Melissa: Yeah, they’re all cats. People think I’m a serious cat lady. I was just in Israel and everybody was like “How many cats do you have?” And I actually have a dog who I hope wasn’t barking because I have my headphones on. But, yeah, I have a small dog. It’s actually smaller than a cat, but I don’t have any cats. I just think they’re hilarious when you put them in presentations.
Per: Excellent.
James: Great.
Per: Thank you so much for joining us and taking your time to talk to us, Melissa.
Melissa: Thank you.
James: Thanks, Melissa.
Melissa: Nice to meet you, guys.
Per: Well, that was an excellent chat. Wow.
James: Very nice for Melissa to get out of bed and talk to us.
Per: Yes, on a Monday morning.
James: On a snowy Monday morning.
Per: I just remembered there was one question I wanted to ask her but we’ll have to talk to her again. In her bio, she actually describes that she — there was a brief year in her career when she started a company in Italy —
James: Oh, yeah.
Per: — and learned about the wonderful world of bureaucracy and risotto.
James: Yes, I saw that as well. We can — we’ll talk to her about that on a future show.
Per: Yes.
James: Yeah. I feel like I could have talked to Melissa for hours and I could have — I don’t think I would have stopped learning. She’s got a lot of experience and a lot of good thoughts around how we should and could be working.
Per: Very pragmatic. Very structured. I took a lot of impression from her — the way she talked about how you can ignore the backlog in certain cases as you realise that that’s something I want to do now more and focus more on the hypothesis that actually bring value to the users.
James: As I mentioned at the beginning of the talk with Melissa that we’ve been not just dipping our toes but we’ve been submersing half of our bodies in this topic of where UX is going and who we are. I mean over the years, we’ve been visiting just a lot about the definition of this. But recently we’ve been getting to more of the kind of — the extra strategy as of course, where are we heading? I think it’s very refreshing to hear Melissa’s thoughts around this as well.
Per: Yeah, I think she clarified it a lot actually. I got a lot out of what she said about the differences between product management and UX but also —
James: The overlaps as well.
Per: Sorry?
James: And the overlaps as well.
Per: Yeah, especially the overlaps and the way that we as UXers perhaps should be more proud of what we’re doing and see all the value we bring from a product management perspective as well.
James: But I think we can — I mean this is something for a separate chat and a separate show, but it’d be interesting — well, I would think it’d be interesting to get deeper into the issues around the job title or the job protection aspect of this that we brought up. It’s like why ask some people in some organisations how protective and so willing to sacrifice great collaboration to defend their title? What are the mechanics and mechanisms behind that? And how do you solve it? Because I don’t think just doing Lean UX as we’ve heard now is not the simple answer in all situations. You’ve got to teach an entire way of working to an organisation —
Per: Yes.
James: — effectively. So that was one of my notes I made down just thinking about the protectionism, why and how do we — does that exist? I actually made a few notes. I don’t normally write stuff down when we’re talking to people to be honest, Per. I do my best to try and listen.
Per: That’s what I try to do.
James: It takes enough of my brain power to do that, but with this chat with Melissa, I did actually scribble down a couple of notes in particular her — when I asked her about the way in which she prioritised hypothesis. I wrote a few notes down about that. It was interesting that she didn’t use effort as one of those things.
Per: Yes, that was really interesting as well because that’s absolutely a metric I would probably use for prioritising. Yeah.
James: Well, I mean you’ve got to use it. Of course, you’ve got to use eventually. You got to know how much effort something is going to take, but that’s one of those things that you can learn or you realise when you’ve got to the point of actually implementing then you have an idea about it. But earlier on when you decide in which direction you should go, then how much time isn’t the driving factor.
Per: Yeah.
James: So that was really good and interesting to hear and the strength for customer problem versus value to business was the equation that she currently used.
Per: Yeah. She really works the way that she preaches in the sense that her tool sets are also minimum viable products and they’re simplified so that you can actually get going and iterate over and over again. You don’t use 7 metrics to decide or evaluate your backlog or your hypothesis. You use 2 metrics or 2 values and you go from there so that you actually can get going and talk about something.
James: Yeah. We didn’t talk this directly with her but you could tell by the way Melissa has given her answers that she’s not stuck in her own dogma.
Per: Yes.
James: She was — just that question again about the prioritising hypothesis, she was willing — she was thinking about “Okay, how am I working with this just now?” You could tell that it was — that she’d iterated this a lot and was willing to iterate it and it wasn’t like “this is the answer I’ve come to.” It’s just “this is what I’m working. This is how I’m working now,” which seems to be giving results.
Per: And she doesn’t want to argue about how to write a user story and spend hours on that
James: Yeah.
Per: Like people do.
James: Yeah. Anyway, you can find the show notes for this episode — as we’ve said earlier — on uxpodcast.com. You can follow us everywhere @uxpodcast and you could also sign up for our backstage mailing list.
Per: Which you will want to do because you want to find out who our next people we’ll be talking to are and other stuff that we share.
James: It’s a cozy little place, very intimate, is our backstage mailing list. We’re trying out two new ways to make this easier for you because filling up a form isn’t easy enough. So, you can —
Per: It’s not — that’s why I thought about it because if you’re on your mobile, on the tube, you don’t want to go to the website. You’re listening to podcasts. You just want to go — you’re probably on Twitter listening to it.
James: Well, we didn’t try out this anyway. So, one way you can subscribe to our backstage mailing list is just DM us on Twitter your email address. Another way you can do it is just email us backstage@uxpodcast.com and both of those ways will make sure that you end up on the mailing list. Thank you for listening.
Per: Remember to keep moving.
James: See you on the other side.
[Music]
[End of transcript]
This is a transcript of a conversation between James Royal-Lawson, Per Axbom and Melissa Perri recorded for UX Podcast in February 2016. To hear more episodes visit uxpodcast.com or search for UX Podcast in your favourite podcast client.
