Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum Podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Paul [00:00:28] Oh hello product people, we’re pleased to be joined today by Rich Mironov. Rich is a 40-year veteran of Silicon Valley software companies. Currently, he coaches product executives, designs product organization, and parachutes into companies as the interim V.P. of product or CPO. In an earlier incarnation, Rich was the product guy at 6 B2B startups, including the V.P. of Product Management and CEO. He is a relentless writer. He is absolutely prolific. He speaks. He teaches. He mentors. And Rich, if I could describe your work to a colleague telling them why they should listen to this pod, I think it would be that there’s really no one better to learn from in the market today about market validation, product-market fit… You know, teams rush in to build something before they’ve spoken to customers or users and what I’ve learned from your work is that engineers need to have a heart, too.

Rich [00:01:19] You bet. I think there’s a lot of really good folks, by the way, doing interesting discovery work and I’m by no means the leading light there. I do spend an awful lot of my time, though, trying to get executive teams to agree that it’s OK to do validation and discovery because one of the major blockers that I see in a lot of places is that the executive team believes that it actually knows all the right answers. You know, that the head of sales talks to a lot of customers, although those are mostly sales calls. And the head of support, you know, has a team that talks to a lot of customers, but those are mostly issues, right. And then around the executive table, the C-suite, everybody’s pretty sure that they’re the one with the magic answer. And so selling the C-suite on the need to really go out and do research and validation sometimes is hard. And I spend a lot of my time on that.

Paul [00:02:04] You mentioned the sales calls right off the bat. That’s something that you’ve called out as a frequent mistake in product teams. Something that people consider market learning, you know, we’re talking to users, but it’s really a sales call and we mistake the two often because what we hear people want us to build and what we know users might need, building some empathy for those on the receiving end of our technology, are often two different things. You know, besides that, what are some other mistakes that product people often make when they’re getting started in their careers?

Rich [00:02:36] Well, there’s, I guess, lots and lots of mistakes to make. I’ve made them all at least a couple of times. One, I think, is that we believe our users when they tell us how to fix the problems instead of digging, digging, digging, digging, and figuring out what problems they actually have. So most users, most people out there, may or may not be thoughtful about the real underlying root issues they have, but they’re always willing to suggest how to fix it, right. “We need another column in the report. We need some more pulldowns. We need to… whatever.” But I find that most users aren’t very smart about how systems are architected. They don’t know the insides. They’re not deeply trained in root cause and so they tend to give us pretty lightweight tactical solutions without clearly explaining the problem. And when we do the thing that our customers ask us to do or tell us to do instead of understanding what’s broken, we’re almost always shipping poor features or half solutions or missing the boat entirely.

Paul [00:03:38] It’s sort of like that apocryphal Henry Ford quote, “If I’d asked my customers what they wanted, they’d say they wanted a faster horse.”

Rich [00:03:44] He never did say that.

Paul [00:03:46] Yeah, it’s attributed.

Rich [00:03:47] So the famous thing he said because he was an engineer was, “you can buy my cars in any color you want as long as it’s black.” Right, and General Motors, which was the head to head competitor for decades and decades, figured out that if you wanted it in different colors and with fins and without fins and whatever it was, they could sell a lot more cars. So within a decade of Ford doing all of his work in terms of assembly lines and getting cheaper cars out there, GM was actually the market leader. They were selling a lot more cars because they’d give it to you in whatever color you wanted. So I think of Henry Ford as a brilliant engineer, but not much of a marketer.

Paul [00:04:24] So tell me a little bit about the market fit piece of this equation. We have a team that’s capable. It’s building products that are functional. But how do we know that we’re building the right thing for the right people? How do you figure out this side of the equation where we’re building that empathy, we’re talking to people? It sounds so deceptively simple, but it’s really where the magic happens.

Rich [00:04:46] Yeah. And I’m going to take the sort of B2B side of life because that’s where I live. I think companies on the consumer side have a million users or 10 million users and so they can send a survey out and have 100 thousand people respond. Now, that doesn’t prove anything, but they have some numbers behind them. On the B2B side, the numbers are much, much smaller. I’m at an ERP company. We might only close nine new customers this quarter, ish. And so the idea that we’re gonna have statistically significant data that really proves anything, I think in all of my years in B2B enterprise, I’m not sure there was ever a place where I would stand up and bet my entire salary and all of my options on anyone, you know, insight. So it’s a little less than prove, but it’s got to be a lot better than “I think I guess how bout maybe,” and if we come back to the sales problem again because they’re overlapping, I think there’s timing here. Which is, long before we put a product out and we give it to the sales team and we ask them to bring money in, the time to figure out what the market wants is a year before then or nine months or fifteen months or whatever our cycle is.

Rich [00:05:56] So I want my team and me to spend, you know, thirty-five hours, that’s thirty-five interviews times an hour each, with thirty-five folks that we suspect might be in our target audience, running through theory, running through, you know, mockups, asking a lot of questions about how they succeed and how they get to be heroes at the job, and, what are they doing instead? And those discussions, I think, should be 85 percent listening and 15 percent talking, because if I’m talking I’m not learning anything. And if I have a product to pitch, I always want to save that for the back half of that hour, because first I want to ask lots of questions about whether they have problems and how they measure results and who buys stuff and what have they tried and… All of that’s about open-ended questions. That’s all about learning and listening and hoping to learn something that shocked me and surprised me. Once we’ve extracted everything out of their heads that I really want to know that’s unaided or unprompted, then I might show them some mockups of two or three different approaches and have them critique them. But all the psychologists know that if I say the words “purple elephant,” right, that drives everything else out of your brain. So whatever you were going to tell me is gone. So if I lead with mockups and sketches, you’re gonna tell me what you think of my mockups and sketches but not whether it’s important.

Sean [00:07:19] You’re leading the witness.

Rich [00:07:20] Leading the witness, that’s right. And so I want to do a couple of dozen or whatever the right number is of these validation interviews way before we code, way before we get committed to architecture, way before we promise the board there’s money because honestly, most ideas don’t play out. At least mine don’t. Two thirds or three-quarters of all the things I thought were really good ideas fell flat, but I’d really like them to fall flat before we spend the next two million dollars building it, right. And then let’s take the other side of the sales cycle. Let’s imagine we’re in some kind of subscription model software. We’re in the SAS world, right, like everybody is. I want to be talking to customers in month 3 and 4 and 5 and 8 and 9, both users and buyers, to find out how we’re doing before the discussion comes around to renewals. Because by the time we get to month 10 and a half, I need to back off and help the sales team close, which means only answering the questions the customers really have that the sales team couldn’t answer. But if we can spot some issues in month 4, well shoot, we’ve got like 8 months to fix it or to make it right. Or if customers have dropped off and stopped using our stuff, we’ve got eight months to figure out why they did that and get them back in the fold and using our product. So I don’t say that I don’t like salespeople. What I say is that the salespeople have a particular point in time, right. Their job is to bring money in and not to get all fussy about the technology and my job during those couple of months of close is to help them bring the money in. But the rest of the year, I better be learning and listening and discovering and validating and all that other good stuff so that when it’s time for them to bring money in, we actually have the right product and we got answers to the questions folks are going to have.

Sean [00:09:02] Yeah, love it. All right, so I have a question for you. So you wrote the book The Art of Product Management.

Rich [00:09:09] I did.

Sean [00:09:09] And I read it years ago. So I’m, by the way, super excited to be interviewing you today so thanks for joining us. That was 12 years ago.

Rich [00:09:16] Yes.

Sean [00:09:18] So in 12 years, what lessons have you learned? I just re-read the book in preparation for this and it’s relatively timeless. I mean, it’s pretty philosophical and pretty spot-on in terms of the problems that we’re still facing today in this industry. So thank you.

Rich [00:09:32] Sure, my pleasure. And by the way, that came out of, so I started blogging in the space in late ’01 or early ’02. And that book is really a collection of the first seven years worth of those that I thought were worth reprinting.

Sean [00:09:44] Right.

Rich [00:09:44] And they’re almost all targeted at individual product managers rather than product leaders and probably somebody who’s new at what they’re doing. There’s a lot of sort of how-to, right, the philosophy under the how-to. I don’t think that’s changed a lot. I do see, again back to the consumer side, we have so much more data than we ever had in those days that we can now actually find out what folks are using and which features are catching on and where folks are getting in trouble in their clickstreams. So whereas I was going mostly on gut instinct and a handful or two of calls, product managers now can really unpack the stuff and really look. And that’s, I think, a huge change. Second thing that’s really different is… I’ll go back to ’02. There were product managers in the ’80s; I was one, and in the 90s; I was one, but there wasn’t a lot of us and we didn’t know each other and we mostly, you know, were handmaidens to the engineering teams and didn’t know much of what we were doing, right. I think today there’s a tremendous social network. You know, your podcast and all the others, there’s a lot of good information. There’s ways to get up to speed, programs, and certificates and classes and stuff, which we never had. And so it’s, I think, a lot less lonely to be a product manager. You know, you can go out for drinks with a bunch of folks and let somebody else buy, maybe. What I always discover and everybody else discovers when we go out for drinks is that everybody’s having the same issue you are. It’s not just you that has trouble convincing your CEO that they’re not the most informed person about the product. We all have this issue.

Sean [00:11:17] One of your opening quotes from the book: I love It and cracked me up. You are a master of the analogy when it comes to product management and you open the book by talking about how it’s akin to parenting. And the quote is; “we’re not really parents until we’ve gotten some poop on our hands and laughed about it.”.

Rich [00:11:32] And laughed about it, right.

Sean [00:11:35] I think you’re right. So now there’s this big ecosystem of product people. You know, I can speak from my experience; when we’re out at the bar talking about it, we’re talking about our products as though they’re our children.

Rich [00:11:44] Yes. Right. And not surprisingly, a lot of the early writing that I did there, so in 2002 when I wrote that my daughter would have been eleven, right. So we’re well past the poop stage but I think this is very much alike. We love our products the way we love our kids, or maybe the other way around, and we protect them and we defend them and, you know, we talk down everybody who says they’re not good. But unlike our kids, we have to be a little more objective with our products. You know, sometimes they’re not good or they’re mispositioned or they’re late. Sometimes we have to sunset and we have to end the life of our products, which we don’t do with our kids. But I think we bring the same long-term view, the same passion, the same protective instinct for our products: “It’s my product, don’t say anything bad about it,” right. “It’s going to go on to win an Oscar, make millions of dollars.” And if you can’t do that, I don’t know if you can be a product manager, if you don’t love your product like you love your kids.

Sean [00:12:42] And that’s the kind of passion that I try to hire for. For sure.

Rich [00:12:44] Yeah. Yeah. And, you know, nobody else is going to stand up for your product the way you do as a product manager. So if you wait for other people to tell you it’s great, nah, you’ve got to get out in front.

Paul [00:12:56] Rich, you have been spinning gold. There’s so many questions that I have about some of the ideas and tricks that you’ve laid out. I think one of the things that I’m most curious about is the need that you’re solving in your career at this point in time. You talk about smoke jumping. First, I’d love for you to share why that analogy with our audience. But secondly, I’d love to know a bit more: why is there a need for what you do so badly in the industry today? We’ve got so many mountains of data. If we can build so many analytics dashboards, if we can have design sprints and usability testing sessions, if we have all this data that we didn’t have 30 years ago, why is there this critical need for smoke jumping?

Rich [00:13:38] Yeah, and I wish there weren’t, but here we go. And the backstory, just to explain it, a good friend of mine who taught me about this was a smokejumper with the Canadian Forest Service. Back in the day he really did that. And that’s a job where they parachute folks behind where the fire is to knock down all the fuel and to dig trenches and stuff and they don’t get to go home until they’ve fought their way back through the fire to the safe side. And the thing I do is a lot safer and easier and more expensive than that, but it seemed like the right thing. The reason it’s important is that I see so many product teams where either there’s no one leading the product team and so they have no representation or voice in the executive suite, or the person leading the product team has actually never been in a product job. So we took the CTO and said, “well, product stuff can’t be hard, we’re gonna give you the chief product officer title,” or, “we moved somebody in from marketing or sales or support who actually doesn’t know what product folks do and don’t know why it’s important and can’t provide the air cover.” And that usually leads to a pretty rapid turnover of everybody who works for them, because to be a product person when your boss doesn’t understand what you do, it’s pretty sucky and there’s a lot of good jobs out there for product managers. So as soon as one leaves, everybody leaves and you’re left with an empty department.

Rich [00:14:56] The other thing I see over and over again, folks don’t call me for this the first time they need me, they call me for this the third time they need me. So they’ve moved somebody into the chief product job who’s failed utterly because they actually have no product chops and don’t know what the job is, right. And then they’ve done it again. And often this is a confusion between engineering leads, CTOs, whose job it is to get a bunch of stuff built, and product, which is actually not about getting more stuff built. It’s about getting the right stuff built. And the more you put engineering folks or technologists into the product job, the more they decide they’re smarter than their users and they build what they want, right, and that doesn’t work.

Rich [00:15:36] The second thing they do is they hire a subject expert. So, you know, I’ve got a company that, you know, we’re building animation tools for brand marketers who are trying to enliven their media streams, and so what we do is we go hire somebody who’s an animator or a corporate brand marketer and we put them in charge of product and they don’t know technology and they don’t know roadmaps. They don’t know pricing. They don’t know upgrades and they don’t know any of this stuff they need to do. And as subject experts, they put their beliefs and training ahead of all the other users, right, because they’re experts. And so over and over again, I see companies that have churned through two or three product leaders because they’re hiring the wrong folks. They’re not hiring for product expertise and product leadership experience, they’re hiring for something else. And those people routinely fail. And then they call me to be the smoke jumper because it’s going to take me a quarter or two to get it all straightened out and help them hire in somebody who’s actually a product leader for the full-time job.

Paul [00:16:35] Yeah.

Rich [00:16:36] I don’t get to go home until I can give the keys to somebody who’s allowed to drive the car.

Paul [00:16:41] That’s a great analogy. And it’s sad, but it is profound. I think, at this moment in time, you talked about how we do have mountains of data now that we didn’t have 12 or 20 years ago. But I think that that’s a critical part of even the new product person’s job, learning that the out-of-the-box Google Analytics dashboard is probably not telling you what you need to make a decision. Monthly active users and conversion rates are often touted as the holy grail of analytics. These are the things that you track for, but what story are they telling you? What’s the message behind the number?

Rich [00:17:14] All those metrics, or KPIs or OKRs or whatever you did, were appropriate for some company. So if I’m Spotify, you know, daily active users and how often they skip over songs and whatever are going to be really important to me. If I’m building cancer therapy machines and proton guns to deal with pancreatic cancer, daily active users isn’t how I measure success, right? You might want to check whether people are still alive twelve months later. So this idea that there’s a universal set of metrics and I’m going to get them out of Google Analytics or pirate metrics or something misses the point that businesses are different and each of them probably needs to figure out what success looks like and how customers are happy or measure them before they go create a bunch of metrics.

Sean [00:18:00] So in the book, you didn’t say it in these terms, but you basically said the worst thing you can do to a product is to put a bonus in place that rewards the shipping of a product. I think there’s a little thing on Twitter that you mentioned a while back because I was obviously stalking you, where you quoted that people need reminding that shipping is not the mark of success.

Rich [00:18:20] Right.

Sean [00:18:20] And savvy product managers propose alternate bonuses that are paid out when we get our first three customer references.

Rich [00:18:27] Sure.

Sean [00:18:28] And that’s speaking my language.

Rich [00:18:29] Yeah. Exactly. Now, we may pay our salespeople on closing a deal. And shockingly, when we do that, they’re really motivated to close deals and not worry about too much else, right.

Sean [00:18:41] Right.

Rich [00:18:41] Because that’s who we hired. That’s how we paid them and trained them and that’s why we send them to club and Fiji or wherever it is. But if we think collecting money from a customer is the mark of success, then we’re measuring ourselves, not them. Again, if we come back to the cancer therapy machine, their measure of success has a lot to do with not how much they spent on that machine, but what are the outcomes for patients? If I have a much software that’s supposed to reduce materials waste in your manufacturing line and speed up your manufacturing cycle, well, we better be measuring how many widgets come off your manufacturing line and whether we saved you hardware or, you know, inputs. And if we’re not measuring that, then we’re not measuring what customers care about and so we’re inviting customers to not buy us or not renew with us because we’re busy counting our change and happily telling the board we made money instead of delivering value.

Rich [00:19:35] Back to bonuses; I was… It’s OK; I can tell this story. So I was at Sybase in the early ’90s and learned a lot, did a lot of really cool things. When Sybase shipped the thing they called System 10, which was I think 1995, which was an upgrade from System 4 because Oracle had just shipped System 7 and so 10 was going to be three better than four, three better than seven, six better than four. Right. And all the executives had a bonus tied to shipping system 10 on time and we shipped it on time and everybody got their bonus. There was a small problem, which was that System 10 wasn’t backward compatible with System 4, and that meant that every single Sybase customer was going to have to rewrite their application from scratch in order to upgrade. And so I took hundreds of calls from customers who asked me when that had to happen so they could buy Oracle instead, because if they were going to rewrite their application, we had opened up every account for competitors, right? But we paid a bonus for shipping on time. So we went out of our way to create the wrong incentives for the wrong behaviors in the wrong activity and you don’t hear much about Sybase anymore. People do what you pay them to do, not what you want them to do.

Paul [00:20:43] It’s profound.

Rich [00:20:44] Well, it’s not mine, but I’ll take it.

Paul [00:20:46] Yeah.

Sean [00:20:47] You can hire their hands, but you can’t hire their hearts.

Rich [00:20:50] That’s right. And back to the development side, we need to make our development teams, our engineering teams, love the product as much as we do because if they love the product and the users as much as we do, they work nights and weekends because they want to fix stuff. If we have them just coming in because it’s time to write a sequel statement or do a dev-ops thing and we don’t have their hearts, then they get recruited away next quarter to something they care about.

Paul [00:21:15] So I’m curious, going back to earlier in our conversation when you were talking about discovery, and discovery is a topic that’s near and dear to my heart. I tend to work on initiatives that are more focused on corporate accounts, that are large scale, that are parts of ecosystems, and it’s hard to build discovery into long lifecycle, mature products. And discovery is often sidelined as the thing we do just to validate what we’re already thinking. What is a strategy that we can use as product people to convince leadership that discovery is not only necessary but valuable, that it’s going to improve the quality of our products, that it’s not a soft skill, it’s not a thing that we do to capture sentimentality. It’s a thing that is actually a critical value add piece to the process.

Rich [00:22:04] So I’m with you, but I put it in the other order. I’m not sure we can convince our executive team in advance that we’re going to learn all these cool things and have better products. Now, I know it’s true because I’ve seen it over and over again, but trying to explain to folks in advance that they should spend money and time on this is really hard. So let’s turn it around and say, “we’re gonna do some discovery, some validation,” whatever you’re gonna call it. “We’re gonna hide it for the next quarter in all the other things we’re gonna do.” By the way, that’s one of the reasons you need a product leader who can push back on the rest of the C-suite, but, “we’re gonna do some of this and maybe we’re not even going to talk about it and then we’re gonna bring forward what we learned and identify some features that we’re gonna put in the roadmap that nobody wants and some things that we didn’t think of that now have space because we took out something that nobody wants,” right, “and we’re gonna bring back verbatims and recordings and quotes from our real users, not the buyers, but the users, about the five or six things we could do in the next year that are gonna make them love us more.” I would rather bring the evidence forward and not have to call it something. I don’t care about the philosophy. I don’t care, you know, “yeah, so McKinsey’s been telling us for 30 years to do this and they’ve been charging ten million dollars a day to give that talk to the executives,” but it never happens. So I think we have to understand that most of our executive audience has other jobs and they’re not really that interested in what product managers do. They’re interested in selling more and having more stuff ship. And so we have to figure out how to get ourselves in front of that train, get the work done.

Paul [00:23:42] So a little guerilla discovery tactics here.

Rich [00:23:43] It’s guerilla discovery. And then the other thing I sometimes do, and it depends how willing I am to embarrass the executive team. But one on one, right, you know, as we said, if you praise kids, you praise them in public and you give them strong feedback in private. But I go back and I have the product and engineering team dig up the last six or eight things we did that really landed flat, that were useless and worthless and not ideal, and I write down the names of those projects and who proposed them. And by the way, who proposed them?

Paul [00:24:13] Executives.

Rich [00:24:14] Yes, you’re exactly right. So I’m going to sit down one-on-one with the executive and say, “well, you may not remember this because you have a strong recency bias and a success bias, but last year we spent, you know, 67 engineering weeks building this new set of report dashboards. And by the way, we have no users. And that came out of these three accounts where we listened at the customer advisory board to the most senior people from those accounts who never use our products, but like to golf with us and drink, who said ‘we need more dashboards.’ We wasted four million bucks on that last year and nobody’s using it, right. How do you feel? Do you feel stupid?” And then I go to the next one where we talk about how we diverted all of our energy away from encrypting data at rest and emotion and later in the year we got hacked, right. So my job is to, you know, hold up the dirty linens here a little bit and say, “we are not as good at predicting the future as we think we are, exhibits 1 through 11, by the way, we could do the same thing and spend five million more bucks on a feature nobody wants or we could spend one hundred thousand dollars finding out if it’s a good idea.”

Paul [00:25:23] Yeah. So I’m not sure the ethics of guerilla discovery, but I do like the saying, I’m not sure who to attribute it to, but the concept that you’re going to pay for discovery, whether it’s by design or by default.

Rich [00:25:32] Right.

Paul [00:25:33] It’s going to get paid for one way or the other.

Sean [00:25:34] You always pay for it.

Rich [00:25:35] And it really helps to have some cringe-worthy example from inside the company where we spilled a lot of engineering and a lot of marketing and a lot of sales and nothing happened. Because we’ve all forgotten about those, particularly on the go-to-market side where, you know, everybody is sort of, by default, they’re optimists and they’re looking forward and they want to take credit for all the good things that happened. That’s who we hired and put in those jobs. Failure always somehow lands on engineering and product, mostly engineering, and I want to get the product folks to own more of it than engineering and to get out ahead.

Sean [00:26:11] All right. Well, along those lines, you know, product owners are often non-hierarchical leaders of matrix teams, right?

Rich [00:26:19] Yeah.

Sean [00:26:20] And as a non-direct boss, so to speak, we need to really understand, I think I got this from your book in some context too, but understanding how people think, what motivates people, how to inspire actions, are like sone of the core skills of a product leader in any context.

Rich [00:26:37] Any context, that’s right. I’m always sending folks off to do the Myers-Briggs course or whatever the equivalent is to understand that salespeople are different from finance people who are different from engineers, on average, which shouldn’t be surprising. We may be delivering the same message and the same content, but the way we deliver that is different for every department in the company and every customer group. Really, really important: I see very junior product folks in their first job mostly working on the hard skills and the workflows and the user stories and the roadmaps. But as you get up, as you get senior, as you move into leadership, it’s all soft skills, it’s all communications, it’s all understanding your audience and how they’re rewarding what’s important to them.

Sean [00:27:21] And another quote that I took from your book is that product people don’t stay in the boxes that we assign them to, right?

Rich [00:27:28] Never.

Sean [00:27:29] They recognize the need to move around and to do whatever’s gonna get done to make this product successful.

Rich [00:27:35] That’s right. Because as product people, we own outcomes, not outputs.

Sean [00:27:39] Right.

Rich [00:27:39] So engineering, in some sense, is output driven. It shouldn’t be, but it’s often output driven. Did we ship the thing on time? But if we ship something on time that nobody buys, we as product folks have still failed. And so it’s not enough to stay in our lane and fill out our forms and do tickets and write user stories. If the thing we ship isn’t a success and doesn’t deliver customer value and make money for the company, well then, you know, dust off your CV, you’re working somewhere else next year.

Sean [00:28:07] Well along that same line, in a couple of different places, I’ve seen you mention this context of the emotional range that a product owner or product leader goes through in a given day and I want to hear thoughts about that and about, you know, resilience in that context.

Rich [00:28:22] Yeah, I think, you know, some groups in the company are going to be more receptive to an emotional pitch and some more to an intellectual or a fact-driven pitch. If I think about the way engineering teams argue, right, so the secret agenda every time you’ve got an argument within your technical team is that everybody’s trying to prove they’re the smartest person in the room. They never say that, right. Maybe they do.

Sean [00:28:46] They sometimes do.

Rich [00:28:47] Yeah, they sometimes do. But the style of engagement with the technical folks is, first we lead with data. Let me show you what came out of the interviews. Let me show you what the segmentation was. Here’s what’s happening. And then we lead them to a conclusion or a problem statement or a next step. Because, first of all, my assumption is that everybody else in the room is smarter than I am because they’re engineers. I was smart, but I’m no longer a developer. But everybody certainly thinks they’re smarter than I am and they all want to go through the steps because they’re expecting me to bring good data forward, but maybe not be so smart, right. So I have to sell them on the idea that we’re getting to the right answer from the data we brought forward. Whereas when I sit with sales and marketing folks, honestly, they couldn’t care. “When is it shipping and why is it good? And give me the three bullet points,” right. “What’s its price?” You know, “are we in beta yet? Can we sell it? Who’s the competitor?” And so I see the sales and marketing folks want just the facts, ma’am. They don’t want to dig through the evidence unless they disagree with me, because if I came to the wrong conclusion, it must be because I talked to the wrong people or gathered their own data and they’ll go there. But for the most part, they’re looking for something short. You know, what’s the capsule? Give me the three eight-word bullets. And if I bring the engineering style of argument forward, I’ve lost everybody in the room. And then on the sort of finance and project or program side, it’s very much more rule-driven or process-driven. So go try to tell finance folks that it’s going to be six more months payback on your product and they’ll show you the corporate goal that says all things have to be a 12-month payback, right. Go tell them that you can only estimate demand to within a factor of 40 percent, which is pretty good, and they’ll explain that, “we don’t spend any money unless we can do the ROI on the equipment we bought to six decimal places.” That’s who they ar, that’s why we hired them; they’re doing their job. Talking about vision doesn’t help. Talking about tech debt doesn’t help. You know, we’re gonna have to find some way to get the numbers in place so I can get my stuff funded, whatever promises I have to make, right. As we go through the organization, we find people with different points of view, different sampling, different reward systems. You know, the support folks are paid to close out tickets and to get people working. They’re not paid to ask strategic questions about competitors. So when we talk to the support or the customer success team, I should always expect a long list of current bugs and current issues that are going to help current folks but will never open up a new market.

Sean [00:31:23] Short term versus long term thinking, right.

Rich [00:31:24] Yeah, it’s short term/long term; it’s money versus technology. Everybody in the company has their own place where they sit and as the product person who nobody works for, I have to meet my audience where they are instead of expecting them to love product management so much that they want to do it my way.

Paul [00:31:42] Yeah, I love that. Your audience isn’t always the user, your audience is the finance professional and the executive. As the product person in the room, you’re playing every instrument in the orchestra.

Rich [00:31:53] That’s right. I’m pitching the industry analysts on why my stuff’s better. I’m pitching channel partners on why it’s gonna save them time or make the money, right. I have to understand who I’m speaking with and what they care about. And then I have to force-fit my product and its benefits somehow into the thing they want.

Paul [00:32:11] I love that. So we’ve just got a couple of questions left. One that I think we’ve been dancing around the entire time, but I’m not sure if we’ve actually used the word to describe it. And one of these days, we should probably put a blog post together of all the answers; we try to ask this question every time. The concept that we’re talking about, I think, is innovation, whether it’s through the product, through technology, through relationships, whatever. What would you say is your definition of innovation?

Rich [00:32:36] I’m going to be careful here because everybody brings their own, right? I think innovation happens at every level of scale. So I see innovation at the feature level where my product manager and engineering and support and design team is figuring out what’s going to make the current product more useful and more valuable to our current users. If we go up a level, I see the director or group product manager and all the appropriate people trying to think about new segments or new audiences or new whole uses for the thing we built. Because what we’re trying to open up is a, you know, a greenfield or take on a new challenge. And that’s innovative if we do it right, understand what the market wants, bring something out that’s not been there before and kill a bunch of stuff in the market, right. If we go up a level, usually in the executive suite, what they really mean is, I want to be in a whole new business. I want to acquire a whole new product set. What’s going to put $50 million more on the top line? Those are high risk, even though they never want them to be, and they usually spend less energy validating a $50 million acquisition than a one million dollar feature, which gets me really hot and bothered. But, you know, at the executive level, what they are hearing is customers making the innovation excuse, I think. “We didn’t renew your product because somebody else had some new feature,” and they’re not telling us that we had poor quality. They’re not telling us that we’ve been embarrassed in the press for something. They’re not telling us that we’ve been outsold or underpriced. It’s more polite for customers to say, “well, there’s this new thing out there,” right. So I think executives get confused between, “we have to do something really new, a whole new product,” maybe, maybe not, and every sort of fractal or, you know, iterative level of innovating somewhere along the chain. And I expect every single person who works for me to have some innovation, within their scope.

Sean [00:34:33] I love it. What I’m hearing you say is that the micro-innovations are really important and they add up.

Rich [00:34:38] That’s right. And they don’t show up on the budget and often they don’t really show up as visibly. By the way, back to loving our products and promoting them, I really want, and I want everybody on my product team, to be selling, to be crowing about the micro-innovations and the small innovations we’ve made this quarter that made folks happy or reduced churn, closed two new accounts, whatever it is. Because if we don’t say it, nobody knows it happened, right. If a great feature falls in the forest… If we’re not saying our kid’s gonna be really great and he’s gonna go to Juilliard and, you know, play with the symphony, nobody’s going to know. And so it’s on us not just to love our products, but to beat our chests a bit, which may be uncharacteristic for us, and make sure our team gets credit for the fact that we’re innovating in the small, not just in the big.

Sean [00:35:27] Continuous innovation.

Rich [00:35:28] Yeah. One other thing just before I lose it because it’s a good thought. I always ask my product managers once every three or four weeks to give me the name of somebody not on our team, but on one of their other teams, who did a really good job or helped or did some special this week and then I send a thank you note to that person’s boss. Because there’s nothing more motivating to help product and ship good things and help customers than when your boss gets a note from somebody else who’s important saying that you did a good job. Notice that’s free. It costs nobody anything, but man, do people work hard when you thank them.

Paul [00:36:02] And they save handwritten notes.

Rich [00:36:03] And they save handwritten notes and it’s all about soft skills. And the next time you want somebody or somebody on your team wants somebody to do something. And they remember that they get thanked for it and they get to be a hero, there you go.

Paul [00:36:15] I’ve said it before and I’ll say it again, you’re spinning gold, Rich.

Rich [00:36:18] Thanks so much.

Paul [00:36:19] This is like a tactic a minute here.

Rich [00:36:20] You know, there’s nothing like working at something for 30 or 40 years to make yourself [inaudible].

Sean [00:36:25] No doubt.

Paul [00:36:26] That’s great.

Sean [00:36:27] One last question for you that we ask every guest. It’s, what are you reading today? Like what thought leadership are you recommending, obviously besides your own books?

Rich [00:36:35] Yeah, I don’t recommend my own. I do a lot of reading of murder thrillers just because it’s a nice break, but things that come to mind; Ron Lichty and his coauthor just came out with a new edition of Managing the Unmanageable, which is how to run engineering teams. Hank Chesbrough, who teaches at the Haas School at Berkeley, just came out with a new book on open innovation. I’ve been recommending a lot Josh Siden’s book Outcomes Over Output and Melissa Perri’s book about the Build Trap.

Sean [00:37:04] Oh yeah.

Rich [00:37:05] Both are really, really good. Josh’s is especially a fast read. I see so many folks who set goals for the company without thought, and then, you know what, the wrong goals lead them in the wrong direction. And then John Cutler, who I don’t think he has a book out, but he writes brilliant posts almost most every week. He’s really smart. Teresa Torres is somebody I think is just flat-out brilliant, off the charts. She’s way smarter about validation and discovery than I am. There’s so many good thinkers where if I go back, again to 2008 or 2002, not many. It was easy to stand it out when there weren’t many.

Sean [00:37:39] You’re giving yourself too little credit, my friend. Thank you for entertaining us. This has been a great podcast.

Rich [00:37:45] It’s my pleasure and I’m so thrilled that you guys are out there doing the hard work on this.

Sean [00:37:50] Thank you, sir.

Paul [00:37:52] We’re standing on the shoulders of giants.

Sean [00:37:55] No doubt.

Rich [00:37:56] That was Isaac Newton, I think, wasn’t it?

Paul [00:37:58] It might have been. Alright, Rich, it’s been a pleasure. Thanks so much for joining us today.

Rich [00:38:02] Thanks.

Paul [00:38:06] That’s it for today. In line with your goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.