Bruce McCarthy – UX and Product Roadmaps
Podcast: Play in new window | Download (Duration: 34:00 — 18.1MB)
Subscribe: iTunes | Android | RSS
Product Managers are responsible for the success of a product. As we’ve seen, UX is not misaligned with business goals, in fact it helps achieve those goals. If UX has become a necessity in terms of a driver of business, product managers need to adapt to it. Those who have a respect and understanding for the value of UX, and incorporate it into their product strategies, can better serve their users and customers, as well as the business.
In business, competition is the core of what drives innovation and consumer loyalty. But this doesn’t mean catching up to your competitors in some feature-checklist war. What sets your product apart from others and what about it delights your users? Engaging in user research can tell you how your customers use your product but more importantly why they use it that way.
That question of “why” can be very important. If the users of your product are requesting what seems to be a simple fix, such as moving a button, there could be a greater underlying reason. So rather than just accepting the request and acting on it, using research to uncover that “why” can lead to a new use case that you weren’t actively supporting. This in turn can lead to greater opportunities for the business as a whole.
Bruce will be presenting one of 8 daylong workshops at UI20, November 2-4 in Boston. For more information about his, and the other workshops, visit uiconf.com.
Recorded: June, 2015
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Jared Spool: Hello, everyone. Welcome to another episode of SpoolCast. I am very excited today that we have Bruce McCarthy, who is a product manager extraordinaire. He’s been doing a tremendous amount of work over the last few years, teaching product managers how to do product management.
I’ve run into him a few years ago at some workshops that happened here in the Boston area called Product Camp, which is this fantastic day-long set of sessions. He gave a great talk on roadmaps. I realized there’s a lot of intersection between roadmaps, user experience, and what we’re doing.
We talked a bit and today we’re going to talk to him about these roadmap and UX things. Bruce, welcome!
Bruce McCarthy: Thank you very much. Good to be here.
Jared: Product managers, they are this force in a project. There are good project managers, and like everything else, there are not-so-good project managers, just like there are good designers, and there are definitely not-good designers.
One of the things that I’ve learned over the years is that when you have a great product manager on your team, things get done and they get done well. All of the plates seem to keep spinning.
Bruce: That’s a good way of describing the product manager’s job, as the team’s plate spinner.
Jared: I don’t know if you’re old enough. You’re probably old enough. A lot of people I talk to are not old enough to remember “The Ed Sullivan Show.” There was always that dude who had the plates on sticks, where he would spin them.
He would have like 20 of them and his entire act was, to some Siberian dance music, keeping all the plates spinning. I never understood what the point of it was, but apparently this is a career path for people.
Bruce: Apparently! It’s a good analogy for product managers. Some people call the product manager the CEO of the product. I don’t think that’s exactly quite right. I think of them more as, to use the business position analogy, a COO.
Because they are still operating within the strategy set by the executive team usually, but under that mandate, they are empowered to tap any resources necessary for the success of the product. Their job is to direct all the activities cross-functionally and make sure that they’re all pulling in the same direction.
Jared: That’s how I see it. They tend to run interference with things that want to take the project off track. They tend to be trying to predict issues that are going to come up while they’re still early and easy to deal with. I remember when I was doing software development back in the ’80s, I worked with a couple of really awesome product managers.
They were sharp people, but at the time I did not sense, like most people in the world, that they saw design and user experience the same way I did. You’ve been around long enough. Has the perspective on how the importance of a good user experience shifted in the product-management world?
Bruce: Dramatically, I think, over time. I’ve always been a big believer in it, myself. Initially not so much as a business driver, but just because I was interested in the topic. It’s become a necessity for product managers over time, especially, with the shift to SaaS.
If you think about it, the product manager’s responsible for the success of the product, for the business outcomes of everything that they do. The perspective of the product manager has changed with the business necessities.
If you’re in a SaaS business, then that business is not just about winning RFPs as it might be in a big-enterprise on-premises software installation, or selling units as it might be in packaged software, which is all about the promise on the box, if you will, of all the great features that you’re going to get. Instead, the real key to winning in SaaS is retention and renewals.
Jared: SaaS being Software as a Service?
Bruce: Software as a Service, where you’re paying for the software as a subscription over time. That means you can stop paying for that service as a subscription at any time. Which means that, if I want to be successful as a purveyor of Software-as-a-Service tools, then I need to be able to make you happy as an ongoing user.
I need to have you engaged and using my product every day or at least every month on a regular basis, so that, come time for the annual renewal, it’s a no-brainer for you. “Of course I will sign up again.” Even if it’s a B2C product that’s more month-to-month, then every month when the bill comes, you’re happy to pay it.
You’re happy to put in your corporate credit card or set up a PO and just set it and forget it. That means if I’ve got to keep you happy and engaged as a user, as a product manager I’m much more focused on making sure that that’s likely to happen, that you can do what you need to do in the product.
That you can accomplish your goals and that you don’t dread logging in to the product every time. If I go back to when I was a young product manager in the ’90s, it was much more about features. It was much more about, “Do we have the checklist of features that you want, compared to the competition, so that you will buy at first?”
But actually, now that I think about it, my perspective about usability being important may have been informed by my first real official product-manager job. I worked for a little company called iMarket back in the ’90s.
Jared: I remember them.
Bruce: Yeah. You could buy data on CD-ROMs. It was marketing data, so we sold to marketers. It was a subscription product. It wasn’t delivered over the Internet, not initially. Later on we did that. But it was a quarterly CD that we sent you. It was an annual subscription. Also, the more you used it, the more data you bought from the platform, the more money we made.
Jared: That was a Lotus spin-off, right?
Bruce: It was.
Jared: I knew those guys. I remember I worked with them when they were at Lotus. They had a great product.
Bruce: They really did. It lasted quite a long time. It lasted into the new millennium. The company was eventually bought by Dun & Bradstreet.
Jared: Yeah, D&B. I remember that.
Bruce: We had a subscription product and we tracked our renewal metrics. We tracked how often people actually used the product once we had a phone-home feature built into it, because we knew that the renewal rate was a big lever for the success of our business. We had a renewal rate around 80 percent and we were always working to try to optimize that.
Jared: I remember. I worked with a lot of teams back in the day. The not-so-great product managers, they seemed to focus on customer surveys, getting customers to rank what features were best, and then just constantly catching up with competitors.
Bruce: I’ve got to tell you, those are two hot buttons for me. They are really common mistakes, rookie mistakes in my mind. They bug me, when people rely on those things, because both of them are really abdicating your responsibility to think strategically about what’s going to make your business successful and what’s going to make your customers successful, which hopefully is what drives the first one.
If all you’re doing is getting into a feature-checklist war with your competition, that’s just a recipe for becoming a commodity. You and all your competition will have the same list of features, and the only thing left to compete on will be price. That’s a terrible place to be operating.
I would much rather be the product or the company that really gets a particular segment of buyers and users. Really understands them in depth and can, as a result, serve them better than anybody else. We did that, I think, pretty effectively at iMarket. There were a bunch of imitators — CD-ROMs where you could buy marketing data — that came out afterward.
They all ended up either going out of business or for a while they sold for $79 once a year, instead of our price, which was hovering around a thousand dollars for a year. The difference was that we really did understand the marketer. We really did understand their needs. We really got into their heads. We had a usability lab right there in the building with a one-way mirror.
We’d invite people in and watch them use the product and take notes. As the product guy I sat through all of those tests and took notes. We debated about what to test next, based on what we’d seen. It was a real driver for us.
The competition thing, I always think, is a bad idea. If people want to look at my blog, productpowers.com, I have an entry that’s been very popular called, “Don’t be better than the competition!” That’s about this particular issue.
Jared: That sounds like a great entry. We’ll get a link to that posted out.
Bruce: The other one you mentioned was voting.
Jared: Voting, yes. Oh my gosh, the voting thing.
Bruce: There’s tools out there that are enabling in the bad sense of the word, like UserVoice and Salesforce and others, that allow you to set up a voting system, so that your customers can propose ideas and vote on them. I have a blog entry on this, too.
Dell came out with something called IdeaStorm back when they were having some financial difficulties and having difficulty growing. The whole idea was there would be a forum where customers could send them ideas for products or features, and other customers could vote on them.
Very quickly, a bunch of Linux zealots took over the forum and, because they were really passionate about it, went in and voted every day and managed to put Linux on Dell boxes up to the top of the list. But that wasn’t going to drive Dell’s business. That wasn’t innovation. That was just the hobbyhorse of a small but dedicated group of people.
Jared: Yeah, and so many times people ask for things that they’re not going to use. Or they’re asking for a solution that isn’t the best solution for them and others.
Bruce: That’s exactly right. Usually, I find when a feature request comes in or a design-change request comes in from customers or from a salesperson or a customer-support person who got it from a customer, it’s that person’s best guess as to a solution to a problem, but a problem that they haven’t articulated. They’re not telling you why they want it. So you collect this list.
Product managers usually have hundreds of things on this sort of list, somewhere in Excel, of feature requests or feature ideas that they try their best to prioritize. But they haven’t usually gone and dug underneath the request to understand the real underlying need, to understand the problem that the customer wants solved.
What I recommend the product people do, actually, and this is something that UX people can help with, is to figure out the underlying need by going back to the original requester — the customer, the user — and saying, “I got your list of 57 things that you want to change in the product. Can you tell me why you want these things? Let’s start with number one.”
“You’ve asked for this button to move from here to here. Why do you want that?” “Well, the button is on the opposite side of the screen from the other controls that I use while I’m doing a particular task.” “Oh, wait. You’re doing what task?” “I got this thing I need to do every day.” “Oh, you’re the first person who’s ever told me that you have to do that thing.”
“I didn’t know people did that thing with my product. Tell me more about that.” Pretty soon, you understand that there’s a whole new use case, or a set of use cases, among your customers that you didn’t know about, that your product does not serve well.
If that turns out to be common, that a bunch of people are using or could use your product in that way and derive some value, you can come up with a whole new approach to solving that use case that might involve moving that button where the customer asked for it, but more likely involves completely rethinking that workflow.
If you successfully do that, you might expand your market. You might get a whole bunch of new customers. Even if it’s not new customers, you might have more engagement and a bunch of much happier users who are more likely to renew.
And a bunch of the little onesie-twosie-type of requests like, “Move this button, or change this color!” will all evaporate from your list of 150 things to do, because you solved that one underlying need that you didn’t know existed.
Jared: People who are off doing user research in the UX space, they’re running into this all the time, where one of the mantras of good user research is you don’t actually listen to the customer, but you watch what they’re doing and you ask lots of questions. There’s a technique that’s popular amongst UX people called the “Five Whys”, which has its good sides and bad sides.
I like the “Five Whys” because it basically says, “Don’t just stop at the first answer. Keep going!” What I don’t like about the “Five Whys” is that it implies that there’s only one “why” to everything. If you follow it down, “Why do you want this feature?” “Because I need to produce this report.” “Why do you produce this report?” “Because I have to get information to my manager.”
“Why does your manager need that information?” “Well…” You start to drive down this stuff. It implies that at the end of the fifth “why”, you’ve got all the information, when in fact there may be more than one reason for the report. There may be more than one reason that their manager needs the information.
Bruce: I love the “Five Whys” construct. I talk about it frequently when I do talks and when I train product people. But you’re right, it’s just a tool in the toolkit. Overall, I talk a lot about the need to do qualitative research with your users and your buyers, to go and watch what they do and ask why they’re doing it, to understand the larger context.
You can even do a little bit of that over the phone, although it’s not nearly as high-fidelity as if you’re there in person with them. It all starts with a general understanding of, who is this person that maybe represents a persona in my world? What is it that they are trying to accomplish in their job or in their life that’s relevant to my product?
Where is it that they currently have frustrations? All the feature-request conversations, including the five follow-up “whys”, need to live in the context of that understanding of who is this person and what’s important to them and where are they struggling.
Jared: Right. We’re definitely on the same page with that. I think the “Five Whys” thing is a great thing just to get people to realize that you can’t stop at the first answer.
Where I go with it is, there’s a technique known as a fish-bone diagram, which I’m sure you’re familiar with, which basically allows for the idea that there’s more than one thing at each step and lets you draw them out and fill them out to completion, and then you get to prioritize. It just gives you a bigger picture. We digress.
What I’d really like talking about here is the idea that there’s a lot of commonality between how a product manager is trying to figure out what’s the right priority and direction for this thing that…
I guess one of my senses is that one of the differences that separates a really awesome product manager from a not-so-awesome product manager is that a really awesome product manager is always thinking in multiple releases. In fact, this is one of the things I remember about working with iMarket back in the day, when they were at Lotus.
I think after that, they would have on the wall what was in this release, what was in the next release, what was in the next release. If I remember correctly, you guys shipped four times a year. Two of the releases were bug fixes. Two of the releases were new feature elements.
All those things were planned out. If somebody wanted to add something to the upcoming release, “Oh, we need to put this in the…” You had to ask the question, “What’s not going to be there?”
Bruce: All right. It’s a matter of physics.
Jared: Right. The people who are not very good product managers, I think they just say, “Yes, sir. We’ll do that. We’ll get it in there somehow.” Everything seems to be focused on the next release and this notion. But this idea that there’s a long lifetime to a product is something that, I think, is just becoming understood to many people who work outside of product management.
Bruce: I think that’s true. Again, it may have something to do with the increasing prevalence of subscription models. We appreciate that there is a kind of at least nominal or an opportunity for a purchase decision more frequently, not just once but over the lifetime of a relationship with a customer.
They’re going to be making the decision to keep going or not keep going with you many, many times. You’ve got to continue to satisfy. In fact, because the competition is catching up and because there are always new alternatives, you’ve got to find ways over time to continue to raise the bar on satisfaction with your existing customers.
Going back to what you were saying about thinking about releases over time, I think really good product managers have always thought that way. They’ve always realized, “We’re going to have to increase our value over time. We’re going to continue to work on this thing and make it better and more compelling.”
“Even if we do have a one-time sale, we’ve got to be able to get to a broader and broader market over time.” I remember early in my product manager days, when we all operated more or less on waterfall and release schedules…Could be very long. They could be years. The prevalent question about any given feature was, “Does it have to be in the release?”
The release, capital T, was your sole focus, the next release. That’s a difficult world to live in as a product person, because what you want to be making is decisions about increasing value to the customer and thereby to the company, over time. Exactly on what intervals you release that value is somewhat important, but not the most important thing.
The most important thing is that you do the most highly leveraged things first. The things that are the biggest bang for the buck. Things that add the most value for the least investment in time and resources, and that you set up an ongoing train of adding those things. That release schedule that you described, that we had back at iMarket, I remember it vividly. We had it up on the wall.
I was responsible for it for a good while. It was a road map. The prototypical definition of a road map is, we’re looking four to six releases out and we’re saying, at a high level, these are the things that we’re trying to tackle in each of those releases. You hit it at the very highest level, feature release followed by bug fix, followed by feature release, followed by bug fix, very high level.
We also would bring it down one level from there. Instead of talking in depth about a bulleted list of 57 features or a bunch of tickets in JIRA that we were going to try to get to, we would talk about it in broad themes. We would talk about it in terms of problems we were trying to solve for customers.
Jared: I’ve heard you talk about these themes before. Remind me again, a theme is different than features.
Bruce: Yeah. A feature is like, “We’re going to shorten up the number of steps in the checkout process on an e-commerce website.” You go to Amazon, and you got five or six steps in the checkout process when you’re buying something. You got to put in your credit card. You got to give it the shipping address. You got to verify this, that, and the other thing, and eventually you get to check out.
A feature would be like reducing the number of steps by, say, combining the shipping and financial credit card address on the same screen instead of as two steps. Then you have to ask yourself, if somebody has suggested this idea, whether it’s design or engineering, a product or a customer, why are we doing that?
Jared: Yeah, why are we doing that?
Bruce: What problem are we trying to solve? It turns out that we have drop off during the check-out process. At each stage, there’s a percentage decrease in the number of people who make it to the next stage. We figure that if we combine some stages, we lose fewer people along the way. Now we’re trying to solve the problem. We’re trying to solve a problem of abandoned carts.
We might actually decide that there are, potentially, many things we could do that would help us resolve this problem with abandoned carts. Maybe there are too many steps. We could test that as a way to reduce the fall-off. Maybe there’s a problem with one particular step where people can’t remember their credit-card number or something.
Or maybe some part of one of the screens is just incomprehensible to the user. They don’t know what’s being asked for. They keep putting in the wrong information, and we keep throwing errors. Maybe it’s that people are just easily distracted, and they lose interest halfway through. They mean to come back, but they never do.
So maybe we need to send them email reminders. “Hey, did you still want those ski boots, because they’re sitting in the cart, ready for you to checkout?” There’s probably a dozen different ideas about how we could improve the experience of the checkout in order to lose fewer people along the way.
If I’m putting something on a road map that says that we’re going that address that problem six months from now, I’ve got six months to figure out what the best solution is, and it might not be reducing the number of steps.
Instead of saying, “Six months from now on the road map we’re going to reduce the number of steps in the checkout process,” I’m going to describe a theme, a benefit-oriented, problem-solving theme. The problem I’m trying to solve is to increase the checkout rate or decrease the cart abandonment rate.
That’s a benefit to me, the company, not to the user, but hopefully the user actually wanted the ski boots. It’s a benefit to them and directly, too. That’s what I’m going to put on the road map. I’m going to say, “We’re going to reduce cart abandonment.” I’ve got 12 ideas that we’re going to explore along the way, and test our way what one or two or three of those are the best ideas.
Jared: So these themes really allow you to hone in on a problem, not the solution?
Bruce: Right.
Jared: It seems to me that that is where — if you have on your team people who know how to do user research, people who have good design skills — that’s where they would thrive.
Bruce: Absolutely. This is where I work very closely with UX people. I actually use UX people to help me fill out my road map. I’ve got an existing product or a prototype for a product. I’m starting somewhere. I’m thinking about the next 12 months’ to 18 months’ worth of things that I want to put on the road map.
I have some ideas about that, but it’s difficult for me to be certain of the priority of those things. It’s also difficult for me to be sure about which solution is actually the right solution to a particular problem.
I’ll put out problem-solving type of themes, like the ones we talked about, in a preliminary way, based on the feedback that we’re getting from the prototype or from the current version of the product, the problems that are coming up from user research, or even from requests after I’ve asked my five levels of “why”.
I’ll put that out there. Then I want to work with a UX person to validate that these problems are in the right priority order. They’re all real problems. The worst problems are being addressed first. For any given problem, we’ll work through prototypes, clickable mock-ups or whatever, of potential solutions to that problem. We’ll try them out on users and see what really works the best.
If we’re working ahead like that, then my road map gets smarter and smarter and better and better, and more likely to actually solve the right problems in the right order as we go.
Jared: It feels like that’s where you get to do some of the stuff that we’re talking about these days around testing assumptions, and putting out hypotheses, and creating this notion of what people call a minimal viable product, but it’s really just, “What’s the least we have to do in order to see if, in fact, we understand the problem?”
Bruce: I’m a big believer in this minimum viable product, this MVP concept, but many people misunderstand it. It’s a sort of…
Jared: They think of it as, “What’s the least we can get away with shipping?”
Bruce: The crappiest-version one that we can possibly put out. In fact, it is, “What is the smallest amount of work” — you said it well — “that we can do in order to validate a hypothesis, to verify that our assumptions about our business plan…We’re going to provide a product, a certain product with a certain feature set to a certain market. They’re going to be willing to pay for it.”
“We’re going to be able to acquire them in a profitable way.” You got to figure out whether those assumptions are all right before you actually go and build the entire product, and start to market and then find out that some of those assumptions were wrong.
Jared: Right.
Bruce: UX people are, I have found, highly, highly leveraged in those early days of testing your assumptions. I’ve done this over and over again, actually. We did it at NetProspex, and we are doing it right now with a startup that I founded called Reqqs, reqqs.com. It’s a product for product managers that helps them with prioritizing and road mapping.
What we did early on with that product was to first do a bunch of research with product managers to understand their problems, and when they ask for features to ask them why they wanted them. Get those problems boiled down to the essential few, which, with product managers, it turned out, the worst problems are prioritizing and road mapping.
Both the decision-making part and the communications and getting-everybody-bought-in parts of that process. Then the whole question was, “Do we have a solution to those problems? Do we have something that will actually provide value in those problems over and above the alternatives,” which right now, for most product managers are Excel and PowerPoint.
So we did mock-up after mock-up. I walked users through those mock-ups. We set them up in a clickable fashion. So you could go from one page to the next as though it were a real product with real data.
Kept optimizing it based on the feedback that we were getting and to the point where we had something that was in HTML and clickable and apparently responsive, even though there was no database behind it, that people said, “Yeah, this is great. If I could put my real data in, this is exactly what I would want.” Then we went from there into producing the real code.
We used a whole bunch of the front-end code. Not all of it, but a lot of it. Similarly, at NetProspex, I was building a tool for salespeople that was basically a search tool for contact information. It was for telephone salespeople, for what they call BDRs, who just make lots and lots of outbound phone calls all day long and make appointments for salespeople.
This was a quick lookup-tool, essentially, for getting the right contact information for somebody you wanted to reach. We had a whole team of these BDRs. We had 25 of them at NetProspex in-house. So I said, “Perfect. I will produce a clickable mock-up and I will put it in front of them and see what they think.” I learned a huge amount by doing that.
Then after we got beyond the clickable mock-up stage and into early prototypes, but the UI was still very minimal, I would put it in front of them have them actually use it in their job and see where it did or didn’t work for them. I quickly learned to keep the UI simple.
It actually helped me reduce the feature count that we needed in order to get into our first release. Because I discovered that some of the advanced features that I thought people would think were really cool, that the salespeople couldn’t figure out how to use them. So we just got them, and we had a better product for it.
Jared: It seems like these are such obvious things, yet many teams feel like they have to discover it on their own, and reinvent what’s already known.
Bruce: I have some hope that the world is getting a little bit more educated about the necessity to involve design early and often, and about the value of crafting an entire user experience and buyer experience all the way from…
I think about it as a journey that starts all the way from the marketing and publicity stuff — where people do speaking at events or they write blogs or they have advertising to try to create some awareness…
All the way through the buying process, all the way through the first-use process, all the way through the repeat-use process and the renewal, and eventually hopefully referral to other potential customers. That whole process and the experience of your buyer and your user through that entire process, has to be optimized if you want to have a profitable business today.
Jared: I think that that entire sort of thinking of the experience is definitely the way that organizations are going, and that everybody needs to be ready for this. I’m really excited about your workshop at UI20. I think it’s going to be a lot of fun.
I think it’s going to be a great way for folks from the design community to understand how to influence the road map, and influence the strategy of the product, and to bring their super powers as UX people into the process and be able to build better experiences and be contributing to the team in even a bigger way than they already are.
Bruce: I’m excited about it, too. I think there’s a lot of overlap there between those roles. Only good can come from closer collaboration between the two of them. I know people who have jumped the fence between those two roles, and found a renewal of enthusiasm for coming to work and new challenges.
I would encourage anybody on the UX side to think about whether product management is for them. It’s a crazy job, can be stressful, but it’s hugely rewarding. You really get to see the fruit of your labors when a product ships.
Jared: Yeah, I have many friends who started out as designers and user researchers and other folks on the UX side, and have found their ways into product management and working on the product team. We go to lunch and they’re just as nice as they’ve always been.
Bruce: [laughs]
Jared: Nothing about them seems to be that different [laughs] .
Bruce: So you’re saying it’s not going over to the dark side.
Jared: No, that’s a complete myth! Whoever is spreading that rumor, it’s a complete myth. Bruce, thanks today for taking the time here.
Bruce: My pleasure. Thanks for having me.
Jared: To all of you listening, if you want to see Bruce in action and to hear how your work can influence product strategy and how the product-management world can make your life a lot easier, you want to attend his workshop at UI20, which will be November 2nd through 4th in Boston, Massachusetts.
It’s a full-day workshop where you’ll talk about all the things we’ve talked about today and more. You want to check that out. Thanks to Bruce, thanks to everybody who was listening. Thank you very much for encouraging our behavior. We’ll talk to you again, soon. Take care!