Rich Mironov: Building a thriving product organization (#5)

Rich Mironov (@RichMironov) is known as the “product mensch” in Silicon Valley, and for good reason. Educated at Yale and Stanford, Rich is a 30-year veteran of product management at multiple enterprises and startups that have gone public who now consults as an interim VP of Product helping companies to get their product organizations working at top notch.

Over the last 18 years, he’s worked with over 120 technology companies including Yahoo!, Wealthfront, WhiteHat Security, Wind River, Euclid Analytics, Pushpay and Strategyzer.  He’s an unofficial advisor to many Chief Product Officers and senior execs throughout the world of technology, and lecturer at business schools around the world. 

In short, Rich has deep experience in product leadership and is one of the few people I consider a true expert at not just product management, but the leadership and structure of product organizations. If you are at all involved in building a company or working with a product organization, trust me, you want to go deep into this man’s world! 

We cover a lot in this episode, starting with what product leaders actually do, how Rich diagnoses organizational misalignments and creates early wins to right the ship, creating psychological safety within his teams, some of the unique challenges to doing product management in the world of artificial intelligence and data science, how to defuse tension between different functional orgs in a company, the challenges of imposter syndrome, and much, much more. 

Please enjoy this conversation with Rich Mironov.

SCROLL BELOW FOR LINKS AND SHOW NOTES

EPISODE NOTES

How did Rich end up as a product leader? [0:02:30]
Rich’s first week in “product” [0:05:01]
How to learn a new space or company when you don’t have background in it [0:06:46]
How does Rich figure out what’s really going on, and what to do? [0:08:34]
Common failure modes Rich sees [0:09:32]
What does Rich do in his first 4 weeks as head of product? [0:13:33]
How do you build the trust to make the needed changes? [0:18:37]
Roadmaps: common initial challenge [0:20:29]
How to build initial momentum when “engineering can’t ship anything” [0:22:17]
“Teams that don’t finish anything quit” [0:25:11]
“Caring is probably the #1 most important feature I see in engineering teams that get a lot of really good stuff done” [0:25:21]
What are the conditions that enable a product team to be at their best? [0:25:43]
Lesson: Assume good intent & don’t blame people for the system [0:30:13]
“If we design an organization badly, almost everybody we put into that organization fails” [0:30:27]
“As product people we gotta be curious, we gotta look outside ourselves and figure out what’s broken. We’re analytical, relentless, and we failed them if our product doesn’t work.” [0:32:08]
Digging into psychological safety [0:34:55]
How to provide top cover for your team [0:36:13]
How do you make it OK to hear truth and speak truth? [0:37:58]
How to keep the exec team aware of what’s being built [0:39:19]
The “exclusive or” question to deal with competing roadmap requests [0:40:15]
“Trust starts with delivering the things we said we’d deliver.” [0:42:00]
How do you spread outcomes thinking across an organization? [0:44:06]
Roadmaps & outcomes thinking [0:47:13]
How is PM different in a machine learning context? [0:49:16]
“Just because you have a stack of data doesn’t mean it’s going to tell you anything” [0:52:40]
“Schroedinger’s insight” [0:56:05]
How does a product leader think differently about a product portfolio with ML products? [0:56:59]
Impostor syndrome & internalizing impersonal issues [0:59:22]
How do you help the product team level up their skills? [1:06:55]
“The goal of those discussion isn’t to focus on some artifact. The goal is to skill up mentally.” [1:09:23]
What one change would Rich have product leaders make? [1:11:27]

Transcript

Transcripts may contain typos. With some episodes lasting 2+ hours, it can be difficult to catch minor errors. Enjoy!

Andrew 00:01:45 Rich. Welcome to the show. Thanks so much for being here. Thanks as always, it’s always fun to talk with you and I am beyond excited to have this conversation. Um, so one of the questions that I wanted to just start with really, really quickly is I in my research getting ready for this conversation, I came across at one point you said something like, you know, nobody grows up wanting to be a product manager. You know, it’s always something out, that’s a firefighter, it’s an astronaut. It’s, it’s a whatever. And I was curious, what, what did you actually have your sights set on, uh, when you were growing up and then how did you end up being a product manager?

Rich 00:02:32 Sure. I think if we go way back, I’d say I was really interested in math and physics and, and hard science, uh, which is, you know, something that eight year olds understand, right? You know, you drop an Apple and all this stuff. Um, when I got to university, I studied physics actually have a bachelor’s in it, but there was a really quick sort, uh, at my university between the students who are going to actually be physicists and the ones who were simply studying it, I was in the second category. So it was clear, you know, there’s a select group. If you’re not that brilliant by the time you’re in university, you probably missed out. So took a few programming courses at Silicon Valley, got my first job as a software developer, writing COBOL back in the days when, uh, actually this is pre electricity. And so you actually had to carve your code into stone tablets and then carry them over to the compiler. So upper body strength is really important in those days.

Andrew 00:03:31 Okay.

Rich 00:03:32 Um, anyway, so did that for fuse dropped out, did an MBA, uh, came back into tech and had somebody tap me on the shoulder, say, we’re looking for a product manager for this group. Do you want to do it? Do you want to be it? And I had no clue, no idea what that meant. So of course I said, yes, what was that transition like for you? So we’re going back to the middle eighties here. I was at a company called tandem computers in the mini computer days. Very great, wonderful corporation. And as time and corporate strategy was this pretty small group of people. You know, MBA take a view of the market, kind of things. Five-year nine year vision, but it was very, very disconnected from actually getting anything done. So a lot of blues guy, a lot of Yan, maybe the world would get there in 10 years, but didn’t really got the business. So, uh, tandem was actually tilting up a group to build a conductivity software networking software for Apple computer, which in those days had a factory in Fremont and build a really famous product called Macintosh. And so, so, uh, we were setting up that new group of one of the strategy. Folks asked me if I’d be the product manager for this Apple stack. Again, no idea what that meant, but I got to hang out with really very cool people for a few years and build some interesting communications products.

Andrew 00:04:53 Totally. Do you remember what that transition was like for you? Like what was your first week like on the job? Because most people I talked to their first weekend product is sort of this, somebody kicked me into the deep end off a very high diving board. I’ve been screaming on the way down and now I’m in the water. I’m not sure what’s going on.

Rich 00:05:08 Absolutely. So no help, no suspenders, no training, no onboarding. Here’s your new badge. You sit over here, here’s your team. Uh, and I had no idea what it was I was supposed to do. So not surprisingly the, uh, the engineering folks on my team led really hard. So it was all about specs and customer interviews and things that the developers demanded of me. It took me, I don’t know, couple of three years to figure out what it was I was supposed to do outside of take direction from engineers.

Andrew 00:05:42 I understand that feeling very well, working in an extremely technical organization myself, it’s you can feel buffeted about almost like you’re at the mercy of a lot of different wins that just keep changing and all very opinionated.

Rich 00:05:54 Okay. And what was funny was at least for that, they were telling me to do the right fix. It wasn’t a mistake. So I launched the very first TCP IP stack or tandem computers in, gosh, it would have been like 89. And honestly, I couldn’t tell you why that was important at the time, but it’s turned out that TCP has been really handy to, for tilt up the web and communicate. It’s a big one. And, and, you know, I was busy writing down what the developers told me this might be useful for which turned out to be files for the server or something, but I was jumping in and, and had essentially no. How do you approach that? Like when you, when you jump into a whole new space,

Andrew 00:06:38 You know, really don’t have a background in don’t know much about what’s your, what is your approach for getting your head around it and actually getting from zero to 60?

Rich 00:06:46 I think first you get from zero to five, zero to one, uh, you know, I think I try to bring some humility in every day. Uh, when I drop into a new organization, I assume I don’t really understand their product and I don’t really understand their customers or their need, although it turns out there’s there’s patterns here. So I’m not a hundred percent sure, but I think I’ve consulted with 125 companies since I hung out my shingle in the early ops. And you start to see things that look very familiar. So on the one hand, I try to be really open and uneducated about the details of the product and details of the market. The other hand, I’m bringing forward, a lot of examples that taste or smell the same, you know, two-sided markets are very much the same and enterprise software is of a kind and very low end, a fast turn consumer software that doesn’t have a lot of cost to. It may only be used a few times, you know, it has some similarities among that set of things. So how do we sort, how do we match patterns? You know, and same with product organizations. There’s, there’s some things I see that before the fifth sentences out of anybody’s mouth, I have a good idea what’s going on.

Andrew 00:08:06 Yeah, that’s perfect. So let’s actually use that as a, as a transition point. So a lot of your work, uh, you know, I’ve heard you described yourself as a smoke jumper, VP of product many times. And you know, I think in one of our previous conversations, you know, you described me, you described it to me is, you know, I get the call when I’m kind of the last call. They make some times where they’ve, they’ve really, they know they’ve, they’ve, it’s not going well and they need help. And so they call you and they’re saying help us, you know, right. The ship, so to speak, I’m really interested in how you assess an organization, right? So you, whether that’s from the outside before you get involved, or once you get in there, you know, could you take, take me through, tell me a little bit about how it is you figure out what’s actually going on and then what, you know, how do you figure out what to do about that?

Rich 00:08:52 Sure. And, and to start by identifying that almost all of these are unique in some way or other, um, uh, was it, uh, Tolstoy’s Anna Karenina starts with the idea that happy families are all the same, but unhappy families are each unique in their unhappiness,
Speaker 3 00:09:12 All dysfunctional in their own special way.
Rich 00:09:15 And, and I’m not getting called in to look after the really well organized, well running happy beaming teams, right? So there’s a lot to discover here. And much of it I see is really basic, uh, executive behavior and work and really basic organizational stuff. So I know that if product management reports to sales, there’s a whole set of symptoms. I’m going to expect, like we keep mortgaging the future for the current. And we’re really only working on individual deals and there are no business cases for anything. And the assumption is that if one customer asks for it, we don’t need to check. We should just assume that’s what the market wants. So on its face, I could look at that org chart and never actually get in the building yet and have some suspicions about what’s going on. Right? Likewise, if I count on my fingers and I noticed that there’s 20 or 30 or 40 folks on the engineering and design side for every product manager and the best, the best product managers are going to struggle here.
Rich 00:10:25 And everybody, who’s not absolutely the best strongest tallest, a three minute mile product managers are going to fail because you can’t possibly serve two or three or fourteens ever. And on top of that, we’re expecting you to know what’s happening in the markets and what customers or segments want. So some of these things are completely obvious. Some of them are pretty silent, crazy. So, um, I had a very, very short engagement with a startup here in San Francisco. And I did essentially no vetting. They called me up and said, they really want me to come in as their interim head of product. They need one and I didn’t do my homework, uh, start on a Monday,
Speaker 3 00:11:08 Oh boy, here we go. What happened?
Rich 00:11:11 Sort of first thing, Wednesday morning, I called the couple of founders back in the room and I said, you know, small change of plan. Uh, it’s become obvious to me that the two of you, you, two founders, won’t take a meeting together. And that’s the source of almost everything that’s broken in the company. And I can’t fix that. So the new arrangement is I’m not going to invoice you for Monday or Tuesday and you guys are never going to admit I was in your building.
Speaker 3 00:11:43 I like it. It’s good awareness to pull the ripcord early. That’s right.
Rich 00:11:47 Names changed to protect the innocent and the guilty of course. So that’s at the extreme end and in between, you know, it’s all about, uh, taking an hour each to interview every major stakeholder and everybody on the product team and the sort of designers and developers and salespeople and marketing people and figure out what’s broken. Right. So I don’t know what’s broken and you know, there’s patterns I can apply, but, uh, it’s, it’s just like the retrospective process, right? Okay. We spent a week doing this. We all sat down. What’s one thing we could fix. What’s 20 things we could fix. And if I can glean a couple or three things that are relatively straightforward to repair in my first couple of weeks, then we’ve made positive progress. We’ve shown that progress is, you know, is in the wind. People are relieved to get one thing off their list, and then we can tackle the next one. Um, but rarely obvious to me what, what the starting point is until I get there, no matter how, no matter how much homework I’ve done for sure.

Andrew 00:12:51 Yeah. One thing I’ve heard you talk about elsewhere is that let’s say you’re a new product leader, right? You’re you get promoted into a role. Let’s say you go from a sort of a line individual contributor product manager to suddenly a director of product, or maybe you get a double bump and all of a sudden you’re the head of head of product. Whoops is. And so now you’re now you’re swimming in the deep end and probably don’t have the little floaties. Right.

Rich 00:13:12 So one thing

Andrew 00:13:14 I heard you say to somebody in that situation was don’t make any major changes for your first two weeks. And I’m curious what, um, you know, when, when you, you sort of operate in the extreme end of that type of example, where you, you literally parachute in and it’s like, okay, go, what does, do you have a, what do you do in your first few weeks? And then what do you do for the next, say two to four weeks after that? Could you kind of take us through what if you have a rough approach that’s even if it’s specifically tailored to the situation.

Rich 00:13:41 Yeah. And it varies a lot. And if we back up a little bit, so I would say, I try not to do anything serious in the first week, maybe to somebody who’s, who’s promoted in from the outside who’s hired from the outside. I usually tell them to wait a month or two, because there’s going to be a lot of interesting chronic issues, organizational issues, market issues that are not obvious and to drop in on a week’s notice to start moving things around can be really dangerous. But yeah, that to me, uh, so again, first week is meet with everybody. Listen, take lots of notes and taking notes, by the way, it’s useful for two reasons. One is because I might actually look at them and two, it’s a way to signal respect, and then I’m listening. So I’m going to take notes regardless. Uh, I would say at the end of the first week, the, the thing I do most likely if I have a team already reporting to me in this interim situation, is it figuring out which of those folks are product folks?
Rich 00:14:41 So not unusually half or more of the people in the product team, either don’t want to be there have pretty poor skill and emotional match, or for some reason should be doing something else in the company. And that’s, that’s really one of the very first thing. So I’m already thinking about which of the folks on the team have sort of, you know, good hands, good bones can be mentored up to be product folks, or maybe they already are. And then which of the folks on that same team am I looking to find another home for the company? Maybe they were a better fit for field sales engineer or support, or, you know, put them into marketing. If they’re really marketing people, there’s rarely a sales person on that team. But sometimes because I can’t, I can’t rearrange the department, which I know I’m going to have to do in a few weeks and I can open up a bunch of new racks for real product folks.
Rich 00:15:35 If I haven’t made that quick Quicksort and it’s, it’s not perfect, but I’ve done it a bunch of times. So I feel like I’m pretty good at that. And, you know, I think of it in its own way as humane somebody who’s struggling in a product job and really failing due to their own issues really deserves to be doing something they can be a good match for when I see the entire team failing, which I often do. I can’t write that off to any individual person. Cause the odds that this company has hired six or 10 of the worst product managers in the world is to distinctly, you know, not very high, right. Pretty low. So, you know, first week or two, what’s broken within the product team, what’s broken in the bigger company, I’m listening for lots of, um, a higher bid problems. Like we’re only selling the old products that we’ve been selling for years.
Rich 00:16:27 And none of our new products are selling. Let’s think about sales, quotas and incentives, right? Uh, our customers are the folks coming through the funnel through the marketing funnel seem to want a different product than sales wants to sell them messaging, positioning, uh, you know, wrong use cases, wrong audience. Uh, sometimes we’re in the wrong segments. I’m looking at pricing and packaging issues. Uh, if you’ve got 45 or 122 optional choices for your product, then you and your salesperson and your customer have to make 45 or 122 yes. Or no choices. They’re never going to get that. Right. And it also means an engineering has to plan for two to the 45th different combinations of product. Right. And support’s got to support it, right? So those are things that are sort of obvious on their face. Um, usually takes me two or three or four weeks to figure out what’s going on with the executive team, because that’s more so, and everybody may not be acting out in the same way every day.
Rich 00:17:39 Um, but does the executive team get along with itself? Is there a strategy and the best answers say, yes, we have one strategy. Um, probably not as good to have no strategies, but worse to have 15, uh, are we investing in the actual strategy that we say we are? Um, you know, so it’s a lot of observation. It’s a lot of human observation. Um, I don’t usually get involved at that stage in individual requirements or individual escalations or, you know, the details of the product. Cause I’m, I’m just not that smart about them, but a lot of these organizational patterns, they’re tremendously obvious to me having seen them in dozens of times.

Andrew 00:18:27 Yeah. Yeah. I’ve heard you describe yourself as a real student of human behavior and, and that that’s definitely a requirement for anyone in product, certainly in product leadership. How do you go about building the trust, I suppose, is the word to start to make the changes you believe are necessary? Like, you know, showing up as someone from the outside that seems like that would be a really hard,

Rich 00:18:50 Uh, it is hard in its own way, but as somebody who intends to be a short timer and part of my mission is actually to help run the search and hiring my full time replacement. So I’m coming in the door with a lot of freedom than somebody who’s a longterm full time employee doesn’t have. Cause they’re worried about staying long enough to get stock and staying in good friendship with all their peers. And, you know, if the CEO had a bad childhood and not getting fired this week, right. And as a short timer, I have a lot of freedom to say, what’s true in the politest way. So, you know, you praise in public and you share really difficult feedback in private, but I get to pull the CEO or the VP of whatever into a conference room and say, here’s, what’s really broken right.
Rich 00:19:42 In a polite way, but here’s what I think we need to do to fix it. Are you in or out? And if we come to some major strategic disagreement about this, I’m just as happy to leave. If not, and again, it being one of the last phone call somebody is going to make for these kinds of situations. I’ve got a lot of short term positional authority to push in ways that, um, you know, I have the freedom to do other people don’t have the freedom to do so. So I’m much less worried about that, but, um, you know, you always want to coax folks along. One of the first challenges almost always is that there’s a roadmap and nothing on the roadmap is actually what we’re working on. Um, and there’s, you know, 45 sales escalations for the 45 largest deals. And those are all getting pushed through by the CEO, uh, frequent pattern.
Rich 00:20:41 And so it’s my job to describe that problem in an aggregate way so that everybody why we got nothing done on last month’s roadmap or last quarter, because we did a bunch of other things that weren’t planned. And that’s a way to get ahead of the next few years. Escalations, it’s also a way to change the name narrative often when that’s the case, the folks on the sales and marketing, I have the perception that engineering’s not building anything and product’s not doing anything as evidenced by the, that did most of the stuff on the roadmap was later. And if we can turn that around, uh, for instance, uh, there was a company years and years ago. Um, I dropped in as the head of products six or eight years ago. And so folks in the network security business and they hadn’t shipped any new features. Wow, wow. As a SAS based securities company really tough. And it wasn’t that they weren’t working hard. It was engineering was lacking product support and they would get 75% done on something. And then they’d get you around to the next thing. So they had a show Oh, full of 91% finished features that had never shipped. And everybody in the executive suite, I was absolutely sure that engineering actually could not ship anything.
Rich 00:22:06 Right. Cause clearly they hadn’t. So obviously, obviously, so, and in the first day or two, I had everyone telling me that engineer can’t ship anything useless and we should fire them all and start again. Uh, so I sat down I’m with the head of engineering. Who’s a dear friend of mine now, years and years later, we’ve done other things, other places. And I asked him what on the shelf his team could finish by Friday. It was, it didn’t matter what it was on Friday. We dropped it that got released that had a couple of very minor features in it. And a few bug fixes. And on the next Monday, which is my second Monday, I was able to go into the executive staff meeting and say, we ship new features. We should tune in to small new features today, Friday, whatever it was. Right. And suddenly, I mean, the conversation had to flip from, well, they never shift anything, which is an engineering problem too.
Rich 00:23:03 Well, wait a minute. Why did they ship those two features instead of the six features? Right? Notice now that’s a product problem because product in theory is sequencing and prioritizing the work. And so in very little time, we will, we’re able to shift the discussion from engineering sucks and engineering to useless to how do I get them to shift? I want, which, you know, move that right, right over into the product category. And so now we could argue about whether product was choosing the right thing. And that was a, a huge psychological lift to the engineering team because I was able to come back and say, by the way, big round of applause, here’s the box of donuts I brought in, whatever it was, we’ve shipped something we’ve really turned this thing around. What else do we have on the shelf that’s close to done so that we can now do a more of a product sort. Right. Okay. For next Friday’s release, you know what two things that I want are near completion and we bought five or six weeks worth of getting things done, which is enough time to actually do the negotiating and the sort of shuttle diplomacy on what actually is important. Right? So in six, a week we were able to move from engineering does nothing to, we’re going to have loud arguments about what’s in the priority list. And product has to be there

Andrew 00:24:32 Far, far better place to be because now you’re at least, at least now, now the cat’s out of the bag, right. In, in the sense that, okay, wait a minute. They are clearly capable of actually getting things done. If we let them do it. Um, I believe I’ve heard you describe the, the number one killer of motivation and source of frustration with engineering teams is it’s basically, you know, executive shiny object syndrome, right. Where it’s like, they’re just getting jerked around from thing to thing and they never get to finish and shift.

Rich 00:24:58 Right? Absolutely. And there’s this weird, the theology that says, if we’re agile, then we can change our minds every Tuesday and Friday at 11:00 AM to 4:00 PM, local time, whatever that is, teams that don’t finish anything, quit teams don’t finish it. They lose their motivation teams that don’t finish anything don’t care. And caring is probably the number one most important, uh, feature IC in engineering teams that get a lot of really good stuff done. If they love their users, they care, they internalize the stuff. When there’s an embarrassing bug, somebody works all weekend to fix it. Not because we made them, but because they, they want their users to love them. And they’re embarrassed.

Andrew 00:25:39 Yeah. No, let’s talk about that a little bit because I’ve, I’ve heard, um, you know, one of the things that you you’ve talked a lot about in, in your work is in defining what a product leader is, is that one of the big responsibilities of a product leader is really to build and nurture a product team and create the conditions where not just product, but engineering can, can really work to their best, you know, to their best possible thing. Could you, let’s talk a little bit about what are those conditions, you know, you’ve, you’ve hinted a bit at them, uh, you know, such as connection to their users, a sense of purpose, a sense of meaning, um, as it’s momentum, but talk to me a little bit about that. What are those conditions and then how do you actually go about,

Rich 00:26:16 So I usually start on the engineering side before I get to the product side. Now, important to note, I’m never in charge of an engineering team. So this is really coaching, mentoring and playing nicely with whoever runs engineering, assuming there is somebody, but I first look at the structure of those teams. So, you know, good evidence now for many, many decades that long lived, completely staffed that get to work on one thing for a while and have the skills and resources they need get really good stuff done. And resource pools, suck and project oriented things where we tilt up a group and then we tear them down. We tilt them up another group that we move the people around don’t lead to good results that shouldn’t be controversial, but a lot of places it is so, so first let’s figure it out if engineering’s organized in a way that makes any sense.
Rich 00:27:12 Second thing is to make sure that every one of those teams has a full time assigned, dedicated product manager. And since those teams probably shouldn’t be more than eight to 10 people choose your number. Then I, I already know how many folks need to be on the product team. If I know how big the engineering team is, again, that would seem obvious, but I see all kinds of product managers struggling with 50 folks on the maker side, you know, makers being developers and designers and tech writers and QA engineers and whatever else, right. Who actually do work, who actually build something that we care about. Right. Um, so, you know, is engineering organized in a way to have success is product at least mashed against the engineering teams as a first choice. Um, and is each of the product managers clear that they’re supposed to spend about half their time looking inward with their team, doing all the team level, things like retrospectives and context and incoming, you know, descriptions of problems and such and half their time out with real users and real customers and real prospects and folks who didn’t buy our product, sitting in on the support calls and all the things they have to do.
Rich 00:28:28 Right. And that they’re, they’re bringing that in because of course that’s, what’s going to motivate our team. And then the third thing I’m always looking for is to get out ahead of, again, I’m mostly on the enterprise side. So this is really important sales escalations, to the extent that enterprise sales teams only get paid, if they close deals and they may only have two deals this quarter, and therefore those are the two most important deals in the world and each needs this one or two little special thing that can’t be really hard at that it’s only 10 months of code.
Rich 00:29:03 Can’t be that hard. That’s right. Cause, cause can’t be that hard there’s room in the current sprint I really needed. I got to go to club in Fiji, you know, president’s club and drink with my friends. Right. Uh, and so those are the, like the first three things I’m looking at is engineering organized as product organized and does product have enough clout to push back on shiny objects that come from the sales team or shiny objects that come from the executive team, because those are w without those things, I think everyone fails. So those, we haven’t talked yet about skills. We haven’t talked about seniority or title or how we really divided up some of that work. But gosh, if you don’t have those things, right. Not sure what else matters.

Andrew 00:29:48 Yeah, no, it’s so interesting because one of the, as I was researching and I’m getting ready for this one, like one of the talks of yours that I watched was your recent talk at industry where you kind of outlined a variety of products, you know, sort of team structure

Rich 00:30:02 Or structures so that you like,

Andrew 00:30:05 And some that you are, you know, somewhere in the middle and then Sunday, let’s just say, you’re not a big fan of correct me if I’m getting this wrong, but it seems like the lesson here is first assume good intent. And don’t blame people for the system.

Rich 00:30:17 I think that’s right. And certainly there’s folks in every organization who don’t work hard or who don’t care or who work for some reason, a bad fit. But what I see is that if we designed an organization badly, almost everybody we put into that organization fails or quits or hates their job or whatever the bad outcome is. Um, and, and again, if, if I see one or two folks in a team of eight who are struggling, then we’re thinking about mentoring and coaching or skillsets or a move to some other jobs that they could be better at. But when I see eight of the eight product managers failing, my gut tells me, my experience tells me that first we should look at what the broader problem is, right? Why are eight of them failing and something systemic, something broad, something repeatable. And, and for instance, and this may be giving away a deep secret here.
Rich 00:31:12 But if I ask each of the eight of them, what’s in their way and they tell me, and I write it down, I often have the answer in my hand, right? Whoa, right. Class crazy talk. If we, if we apply our product management skills to product management organizations, clearly if we were doing some online consumer product with a really short online sales funnel, and everybody was dropping out in step three of the step five of the funnel, one of the things we might do is call up some of the folks who’s stepped out or look at their click streams or check the data. Right. And we would notice there’s some weird thing. Like we’re asking for a zip code, it’s a U S product. And it only has four characters spaces, and nobody can type in a five digit zip codes everybody’s abandoned. Right? Um, as product people, we gotta be curious as product.
Rich 00:32:10 We have to look outside ourselves, seltzer, figure out what’s broken as product people. We’re analytical, we’re relentless. We don’t assume that intent on the part of our users and customers. Right. We failed them if our product doesn’t work. Likewise, if I’ve got a whole team of folks and maybe it’s the engineering team, that’s all, maybe it’s often as the sales and marketing organizations that are upset. Well, what’s broken, you know, kind of before we assign blame, before we fire somebody or move them, you know, what’s what is going on. What’s the root issues. And usually that takes some digging because again, sales people will tell me that engineering doesn’t work very hard and that they must be able to get everything done. And I pretty much discount that, but it’s an indicator that there’s something serious, right? Or, um, we’re often in the sales and marketing game of marketing is giving lots of leads to sales that sales can’t close, according to marketing great Gary leads because marketing is bringing them all these folks that don’t qualify for product or in the wrong segment, or don’t have buying intent.
Rich 00:33:23 And the truth is always somewhere in between. So it’s not about taking sides. It’s about figuring out what’s not working. Of course, I’m there really often to defend the product managers. Who’ve had no air cover who had no umbrella. And so I assume good intent, as you said, if we go all the way back to the agile manifesto, right. We believe in people over processes, right. I don’t care if it’s in JIRA. If we wrote a JIRA ticket for the wrong thing, it’s not useful. Right. Um, so you know, we, and every leader should do this in their own setting. Right. Check in with their folks, check in with the folks in the other departments, check in with their customers and partners and suppliers and stakeholders what’s working. What’s not working. Okay. Can we design an internal experiment for a few weeks and try something new? And if it doesn’t work, we will write it off as an experiment and try something else.

Andrew 00:34:22 There we go. So one of the things I think would be that I’m really curious about is, um, we we’ve touched it. We sort of talked around it a little bit, but this concept that I’m also hearing a lot of people talk about as particularly in the product space, like, you know, you and I met at the, the mine, the product conference this summer. And, uh, I remember this was a major theme at the leadership forum that we were at was psychological safety. And that can mean a lot of things, um, that has sort of, I’ve heard a lot of working definitions. Um, I’m curious, how do you define it? And, uh, well, let’s just start there. So when, when you hear that term, what does that mean to you?

Rich 00:34:55 Um, I think in a product context, it’s the ability for the individual product managers and extended folks of course, to raise issues about the product without being punished for it. So, no, product’s perfect. You know, every, every product or service we have is something that every product manager has an infinite list of things they want to do better or fix, or, but, you know, I want the folks, I need the folks on my team to be able to raise their hands and say, for instance, this product’s not earning its keep it’s falling behind the competition. We’re under investing in it. And the customers are really unhappy. Let’s make a strategic choice to let it go or give it the resources it needs. Right. There’s lots of replacements or it’s duplicate with something else. Um, my product managers don’t want to spend the next three years on something that’s failing.
Rich 00:35:52 So I have to be actively listening and encouraging them to say, what’s true. Now if I’m the pivot point here, if I’m the umbrella on the teach shield between the product managers and the executive team, because somebody on my team is going to get beaten up for saying that then, you know, step one is that I own the message. So, you know, a good leader is I think a lot of good leaders was telling you that when things go well, we use the we word as in the engineering team and the product team did a really good job. And let me call out these three folks on the support and design side and two people on my team. Let’s give them all a hand in name them because this went really well. We write. And when there’s a problem, when there’s a disaster, if I don’t know where it lives, I’ll start the sentence with I, as in that doesn’t sound right.
Rich 00:36:51 I will dig in, let me find out what’s going on. I’m not sure who owns that. Notice what we didn’t do was throw somebody on my team under the bus who wasn’t right. And that’s, you know, leadership one Oh one. Yeah. But totally in a company where there’s been a lot of beatings, right? That’s the old joke. The beatings will continue until morale improves. Right. Um, people are afraid to say what’s on their mind. They’re afraid to raise issues. And, and so someone has to step up and say, I’ll take the heat. Now it’s easier if you don’t intend to stay very long again, that’s it, you know, that’s just a secret of half of the work academic recently, but I actually find that as well received when framed correctly. So let’s start small. How do we raise some issues that are really serious issues, problems that are getting in our way without calling out a person individually and saying that they are a personal failure, right? Yeah, totally.

Andrew 00:37:58 What I hear and what you just said is really that to have a high functioning team, a high functioning organization, people need to be able to speak truth and hear truth. And that isn’t always the easiest thing. It, particularly if you’ve got dysfunction at the executive level. So talk to me a little bit about how you, how you do that.

Rich 00:38:18 Yeah. You’re spot on and it’s not always possible. So, you know, there are occasions we went do probably a third of the room exec gigs I’ve done. I would classify as not very successful because I wasn’t able to turn an executive team around that had a lot of really complicated dysfunction out of my scope. Can’t fix that, not the chairman. Um, but you know, what are the things that, uh, that we can do to build trust? Uh, one is, uh, if I can remember that most of the executive team is thrashed and in lots of meetings and busy and on average, doesn’t remember what’s on the roadmap, which I think is mostly true. Um, less true if you’ve got a technical founder, CEO more true with the, if it’s somebody from the sales marketing side, but most of the executive team isn’t spending their time thinking about what’s in this month’s roadmap. And so it’s important to find lots of vehicles to remind both the executive team and the sales and marketing side of the house. What’s in the roadmap probably once a week, because that addresses the question of, are we working on anything? And it preempts, if you believe we weren’t working on anything, then your new idea is something that clearly should jump to the top of the list because we’re not working on anything,

Andrew 00:39:43 Right? Everyone’s I walked through engineering, they’re not typing. So they’re obviously not doing anything. And then they’re wasting time.

Rich 00:39:50 I’m sitting in conference rooms with markers in their hands, right. We don’t pay them to do that. But, um, having a really frequent reminder of what’s in the roadmap has a bunch of side effects. One is that when somebody comes to me or a member of my team and says, you need to do this right away, this is really important. We get to ask the replacement question or the exclusive or questioned that says, well, that’s great. I’m sure this is a really good idea. But what out of the things that the executive team’s already agreed are the most important priorities for the company for the next month. Do you suggest we throw aside and by the way, here’s, here’s, who’s been lobbying for those things. I’m gonna need your help going to their offices and having a discussion about why you want to cancel their thing.
Rich 00:40:39 Right. That’s a bit punitive, but that’s okay. And the other is you get to ask the strategy question of, Ooh, that’s a good idea. The stuff in the roadmap is mostly clustered around, you know, improvements do, multi-tenants ask this quarter work performance and scalability of this quarter, or opening up new markets in Asia this quarter. How does your new idea fit against those things? Or I don’t see it. It’s a chance to remind everybody that we have a strategy, ideally again, fewer than 15, one’s good to a good, um, we have a strategy. We have work in the roadmap. We’re not sitting idle and that lets us have a more useful nuanced, respectful conversation. Then, you know, Chris, Chris, Chris, you guys, I just need you to do this thing, just get it done. Right. And just get it done. And so I think that’s one aspect of trust is to be the, the reminder be the communicator.
Rich 00:41:36 Then in fact, we do have a plan. We do have a set of work underway. We’re working really hard and stuff’s going to slip because I honestly, I think I’ve never worked on a software project that didn’t slip some it’s hacked it’s it may have happened in the history of the world, but that’s a separate discussion, right? We should have some padding in our, our schedules. We shouldn’t over commit. That’s again, hard to do. But, uh, you know, trust starts with delivering the things that we said we were going to deliver. The other thing, the other big builder of trust, I think is to match the roadmap items, to revenue, at least the outward facing roadmap items. Because if we’ve got to grow the business $25 million this quarter, then either products helping or products not help. And, you know, we both know that the executive team mostly listens to things that are denominated in money, not in software deliverables, not in lines of code, not in stores, nobody cares.
Rich 00:42:38 Right. Um, we need to be able to say that this major release, that version 6.5, that has all these new features and capabilities and use cases and whatever is expected to deliver 20 million in revenue. And sales has agreed and we have customers lined up and we have people ready to upgrade or whatever the model is so that we can defend that work on revenue grounds and not just on sort of moral purity and technical excellence. Honestly, they don’t care. Right? So tying the work in the roadmap to money, uh, puts it in terms of the rest of the company cares about or customer units or daily actives or, you know, whatever. The, the major economic thing of the company is stock trades, uh, you know, uh, whatever that North star is, you know, airline flights booked, whatever it is, we’re doing this major investment in a redesign of the onboarding of new travel passenger folks. Because we think if we do that, it’s going to take a bunch of friction out of the system and we’ll have 4% more bookings next quarter. Okay.

Andrew 00:43:51 What you’re saying is what’s your cause what you’re really describing is the, a way of working with the rest of the organization in an outcomes driven way. So often that’s not how organizations are thinking. That’s not how executive teams in particular are thinking within an organization. If you don’t have that, how do you go about sort of fostering that way of thinking so that you can have a conversation like,

Rich 00:44:14 Uh, yeah, it depends if you’re starting from zero or not, and it takes awhile, but, uh, well, a couple of, couple of three techniques I might think of one is to, uh, let’s assume we’re going to finish whatever’s in the roadmap this month and we’re not going to yank the chain of engineering team, but we’re trying to figure out what’s the next month’s roadmap. The next quarter. That’s a really good time because we haven’t signed up for all of it yet to go down the list and ask first the product team or first the executive team, depending on where we’re starting, why do we care? How do we know what success looks like? It says sort of Socratic method. Well, that’s really interesting, but when we finish that, what’s going to be different. So by the way, just Seiden has a really great book out called outcomes versus output.
Rich 00:45:03 And I love it. It’s really skinny, lots of quick, fast read. I recommend to everybody I got along now, but you know, you want to ask that hard question, but the next round of stuff, rather than shaking the box on the current month or the current set of sprints and miraculously, we’ll discover that most of the executive team has no idea why they’re important other than some one deal asked for it, or it seemed like a good idea. Okay. So we’re going to back ourselves into first principles and I would bring forward what I believe to be problems like supports getting an awful lot of tickets. And we have to either hire some more support people or deal with some of the issues. Um, sales is reporting that there are some particular problems with, uh, one set of competitors around a set of features and churn is too high, right?
Rich 00:45:57 So, you know, good guesses. So don’t, we start with churn rather than go around the room and say, who’s got an idea for how to reduce churn and just implement it. We’re going to take a list of ideas that we think might reduce churn. And we’re going to throw some analysis at products, product managers. You might have some, you know, finance folks, whenever you got smart people in the room who are going to figure out their best guesses for, you know, supports reporting, various people, cheering for various reasons. Well, let, let, let’s start with the numbers. Let’s start with the crude situation. Let’s start with baseline. And then we’re going to take our very best guess for which of these ideas is going to reduce churn.

Andrew 00:46:40 So, one thing that I was, I was curious about is I’ve heard other people, um, Marty Cagan in particular talk about, uh, roadmaps, not being a good thing and not to set up a debate here, but I’m curious, do you think roadmaps are actually the way to go or do you see an alternative? Like for example, one thing I’ve heard, I’ve heard Marty talk about, I’ve heard, um, Christina Wiki talk about is sort of basically getting alignment around outcomes and then allowing the teams to figure out how so you agree on the destination, but

Rich 00:47:09 What do you, what do you think about that? I think that’s useful, but it, it leaves a lot on set, right? So I have to disagree. Okay. So if you’re doing output driven stuff, then the roadmap is your Bible and people get punished for not shipping things on time. That’s clearly wrong. And the other hand, um, I, everybody needs a plan. If we’re going to build software, we’ve got to have a plan. And so what I’d say is his roadmap is going to be truest in the short term. It’s less true over time. Next quarter’s roadmap is a sort of 70% guests or whatever two quarters now is at 50% guests. We shouldn’t be, we shouldn’t be unwilling to make changes, but if you’re going to build anything, it takes more than a week. You’d probably need a plan and some resources and to decide which is more important than other instant sequences.
Rich 00:48:03 Right? So if we think of the roadmap as a, as a working plan, uh, and we match it against outcomes, I think getting to outcomes is hard. I think that takes sometimes a quarter sometimes a year, sometimes never. Um, so I’d love to say, you know, here’s the outcomes you’re driving to and delegate to the teams, how they’re going to do those things. But I expect those teams actually to put their own roadmaps together. Now whether we share that what we do and what we commit is, is deeply philosophical. And I’m not sure really matters, but if we don’t have a client for the current quarter, how can marketing figure out what their events and announcement strategies? Right? So it’s necessary to have a plan in order for our various groups of stakeholders to get shit done, but we don’t want to be religious about it. And, and we want to tie it back to totally when we’ve done a good job of finally getting to outcomes instead of output, then we can call that roadmap thing, something else. If you wanted to call it something else, what’s in a name.

Andrew 00:49:16 I know you’ve been doing a lot of work recently around sort of machine learning, data science, artificial intelligence. And I’m curious, how are you finding, tell, tell me a bit about how this is different or the same in the, in those environments. And in one, maybe jumping off point is I’ve done a lot of that work myself over the last year and a half. And I found that a lot of the, a lot of the tools and approaches that probably worked super well in something like a SAS based product that has very clear links between we have a high degree of confidence between, um, what we’re going to do and the outcome we think it will drive. I found that not to be the case in machine learning largely, uh, given at least on an early stage machine learning project. So I’m curious if you could talk a little bit about your experiences, what you’re learning right now, what’s top of mind and, and how you see that shifting some of the concepts that we’re talking about

Rich 00:50:04 You bet, and just for entertainment value. I first worked on AI in 1979. So this is not a new thing. And for most of AI’s history, hasn’t really worked very well. That’s also not visible, but you know, I think if you look at sort of well understood, well architected classic access applications, we have a really good idea of how to build them. There’s good tools. There’s good estimation. If you’ve got a team that’s built a bunch of SAS stuff, they have vague ideas of how easy or hard things are and some sense you can get it all done. If you just work at it, lots of plugins, lots of infrastructure and platforms and frameworks that can get you started moving along. I think a lot of the machine learning and natural language processing and other AI stuff is in an earlier stage. And so some of the things to worry about one is that as a product manager or some random non AI scientist, I have very strong beliefs that data’s going to be predictive. And it turns out my intuitions often wrong, maybe mostly wrong in my head is that same executive dialogue about how hard could it be? I bet this is predictive. We can just download this data set, right? We can train up some, some machine learning and it’s gonna know Catherine dogs are more importantly, hot dog, not hot dog.
Speaker 4 00:51:35 That, that link is definitely going in the show notes. If anyone doesn’t know that you must look put it that way,
Rich 00:51:39 But it turns out that a lot of times the data just doesn’t predict what we want. Does it play out the way we think we discover a new thing or nothing? Right? Uh, years and years ago, I did some work at Yahoo. And one of the things I learned there that, that the young movies folks knew all along was that the folks who rate movies only get movies, one star, four stars, or five stars, because if you’re in the vast majority of people who thought the movie was only, okay, Matt, and you were going to give it a two, a three star, you don’t bother them. And so they get these really weird bi-modal distributions that represent a small number of folks outliers on both ends. And so movie reviews tend to have some problems, right? And if you were going to use movie reviews to predict, um, sort of revenue streams for upcoming movies might or might not work.
Rich 00:52:31 And so sound studio executives say, Hey, we have 50 years worth of data. Whatever the Netflix folks are probably much smarter about this, but, you know, just because you have a stack of data, doesn’t mean it’s going to tell him anything. So, so we have to back off from committing to dates on things or deciding they’re going to work on until the data scientists confirm that there’s value. There there’s indicator there there’s, you know, some kind of positive signal. And the other sort of big thing I see is that a lot of the data scientists, particularly then the ones who are just coming out at some academic program, which is, most of them have had very little business experience, very little software industry experience don’t think about and don’t understand what users do. And so the short form context that I might give my core engineering team, you know, why it’s important to track shipments for some package delivery company may not at all be obvious to my data scientists.
Rich 00:53:34 They’re going to go grab my data set, and they’re going to come back and tell me something really shocking, like a higher incomes of codes have lower default rates on mortgages and lower income zip codes. And you may not know this. That is because nobody thought about the fact that poor people, you know, may be unable to pay their mortgages more often. Right? So, so we as product folks have to spend a tremendous amount of time putting up the guard rails, explaining the situation, walking them through the economics of our company. You know, why is it important to reduce churn? And why is it important to have happier customers? And where does that leave? And which segment is it because yeah. Cause it’s, cause they simply don’t know

Andrew 00:54:22 Exactly. Yeah. Well, and I’ll definitely link to the, your recent article about some of the practices of product management and specifically in data science and machine learning. What I have to say, one of the, one of the key takeaways from that article that really,

Rich 00:54:34 Um, where I just like was nodding my head going. Yeah. Was that done? That means operationalized, not just having an interesting

Andrew 00:54:43 It’s. I mean, that has been, um, something that I have, I have run into numerous times myself, where, you know, someone tells you something’s done and you’re like, great. And then you go and you’re like, so when can we deploy it? And they’re like, Oh wait, hold on. There’s a whole other bucket of work to deploy it and support you like,

Rich 00:55:00 Okay. And if you had just come out of an academic program around data science done within that setting means you’ve built a model and it’s got some good F scores or whatever you’re measuring. And you can show that your model runs on your machine one time against one set of data. If you were going to use that, to predict the future of the stock market, you know, there’s other things that have to happen that you as a newly graduated debt, scientists may not be familiar with.

Andrew 00:55:33 I know that, uh, you know, the F one score or the AP score on your, on your local machine with this tiny dataset worked. And that was great, but we have to do something at an industrial scale.

Rich 00:55:44 That’s right. And, and if, for instance, the, the recommendations or insights don’t ever leave that person’s machine and don’t make it into the applications that we sell to our customers where insights would be really handy in a particular step in the process, then it doesn’t matter. Yeah. Right.

Andrew 00:56:03 I was gonna, I was gonna say, it’s like if a tree falls in the forest and then I thought about it, it’s sort of like Schrodinger’s insight, right. If no one ever saw it, did it really exist?

Rich 00:56:11 That’s it. And it ties right back to the outcomes question, which is we’re doing a bunch of data science. We’re doing a bunch of machine learning, not because we love science projects, although we do, but because we’re going to inject that insight or decision or recommendation into, for instance, you know, we’re an eCommerce vendor. And if we can correctly predict the products are gonna arrive a day earlier, that people will buy more. And so if we can’t put that prediction on the commerce site where our users and buyers see it, then it accomplishes nothing. And all we’ve done is contributed to the, you know, the, the happy home life of a bunch of data scientists,

Andrew 00:56:53 Which is not a bad thing, but it may not be doing anything to forward the outcomes of the, uh, the organization.

Rich 00:56:58 Indeed. How does, how does

Andrew 00:57:00 The fact that you have machine learning based products, change things for someone as a product leader, as opposed to a line product manager, like in terms of you’re working with the executive team and evangelizing for product, is, does it shift?

Rich 00:57:12 I’m not sure it makes that big a difference. Um, I was in Australia last couple of weeks doing a series of, of, uh, conferences, workshops, and a really smart woman named Sally Foote. That’s F O O T E, had a great presentation on putting AI into her, uh, products that had a photo box. And her point was your users don’t care about AI. They don’t want AI. They’re not interested in all of this stuff. If your AI is helping them, if your machine learning is helping them then adds value unless you’re selling tools to AI scientists, and then your Levi Strauss making, you know, tend to blue jeans. Um, but most of the applications of AI machine learning related stuff, I think should be mostly invisible to the users. If they work, what we have to do as product folks is we have to have some escalation method where sometimes these models are wrong.
Rich 00:58:12 Fact, we know that sometimes these models run, they’re never a hundred percent, right? What’s the escalation model. What’s the adjudication, what’s the complaint sequence. So somebody who gets the wrong answer or gets the wrong product, or has a bad result, has a way to come back to the humans at our company, get it resolved so that maybe that’s as much support and customer success issue as anything else, but as a product leader, I’m not sure it fundamentally changes anything about the job, you know, other than again, to make sure that people’s enthusiasm, doesn’t carry them so far ahead of the technology that we’re all dreaming of stuff that doesn’t work in Evansville.

Andrew 00:58:55 Yeah, totally, totally. So I want to shift gears a little bit here and talk a little bit about some of the, sort of the, the, the personal challenges that people face in, in doing these types of roles, whether you’re a product manager, a product leader, you know, these are tough, complex, complex roles. Um, and one of the things that I was hoping we could talk a little bit about, cause I’m sure you have gotten a lot of calls about this over the years, uh, is basically

Rich 00:59:22 What do you, how do you advise product people, um, or just executives in general, around internalizing non-personal issues and things like imposter syndrome, what are you seeing and how do you, what are you hearing? What do you, how do you tell people? Ah, this is a really hard problem and almost every place I go, I, somebody pulls me aside for a very quiet discussion away from everybody else that we could talk about this. Um, so, you know, for those who don’t know imposter syndrome, it’s particularly prevalent in high achieving high school folks who have put strong demands on themselves. And it’s where we secretly internally think that maybe we’re just not good enough. We’re faking it through my boss is going to find out at some point soon that I’m really not good in fire me. It’s this internal voice it’s very difficult to, to deal with.
Rich 01:00:12 Um, so, so what do we do? I mean, and sometimes I play a psychologist at the office, but I’m really not one for clarity, but, um, things I find that are useful when we get groups of product managers together, uh, offsite, or, you know, someplace safe back to your psychological safety point. And we talk about the challenges that we have. There’s this moment when the folks around the room finally notice that everybody else is having the same challenges they’re having, where most of the same challenges. And I think that’s a really liberating moment because I get to S to change my internal monologue from I’m terrible. I should be able to do this stuff. It’s not so hard. If my mom loved me more, you know, whatever she loved my brother better, um, you know, uh, to, well, gosh, if most product managers are having this issue, that it can’t just be about me.
Rich 01:01:10 Let’s let share coping, man. Let’s talk about how we deal with that as an external thing, how do we get out of our stomachs and hearts back into our brains as problems to be solved jobs to be done, right. Um, you know, endlessly, I hear people beating themselves up on this. Uh, I don’t know if you know this, but on occasion, a product manager has written a user story that wasn’t perfect, really, really wow. And you know what, that last week nobody died. And mostly it didn’t make any difference. And folks who are going to spend all weekend perfecting the grammar in their user stories are wasting their time. It’s off of the other way around, which is the, my engineering, team’s all pissed off because I spent too much time documented in too much detail and they had other ways to solve it. So we’re going to throw all that away.
Rich 01:02:03 Right. But until you hear some other folks, voice that, or hear some other folks talk about how the salespeople only seem to love me when they need something improved, that’s not already in the plan and they’d take me out for drinks and dinner and they fly with, with compliments. And then they asked me to get something done for them. You know, if you think that’s about you personally, and you’re not paying attention. Right. And so, so one thing is a lot of sharing where we get really honest in some quiet setting where it’s safe, right? And then I think there’s a real coaching and mentoring opportunity here to have people talk through the concerns they have. Cause I do a lot of this, mostly with product leaders these days, but also down the organizational stack and you know, to have somebody else listen and, and say it out loud and realize it’s not that big an issue.
Rich 01:02:55 And to point out that it’s a, it’s a process problem, or it’s a research problem, or it’s a staffing problem or whatever it is, uh, give somebody the freedom to cut themselves a little bit of Slack. Doesn’t make it go away. But you know, honestly every day I get up and wonder if today’s the day that the world’s going to realize they don’t need my help anymore. The phone’s going to go quiet and the email’s going to go quiet. It hasn’t happened yet. Right. Um, I’m a, I’ve been a solo for 18 years and it turns out, you know, you can be an overnight success if you stick with it for 18 years. But, um, but I think we all have that sense of concern that maybe we’re not good enough.

Andrew 01:03:42 Yeah. It’s something that I, I know I’ve experienced many times. Uh, I remember, especially when I, when I switched early in my career from marketing into engineering, my God, the first two years of my life in engineering were a constant like daily bout in the ring with imposter syndrome. And eventually I remember I went to, I was at a conference somewhere and I heard somebody, I saw this guy get on stage. And I was, I think it was the Ruby on rails conference. And this guy got on stage and gave a whole talk about imposter syndrome. And it was just the most liberating thing ever. I was like, Oh my God, it’s not just me. I’m not the only one who deals with this sense of like, you know, every day that feeling like the other shoe’s about to drop. And it was so liberating. So I love what you were just saying about the fact that you can, when you, when you can see that reflected back to you from other people, you, you realize all of a sudden that, Oh, maybe this is, uh, a pattern or a systemic thing, not

Rich 01:04:32 Absolutely. And engineering teams, you know, developers, very technical folks sort of pride themselves. They each want to be the smartest person in the room and it’s product people. I don’t, I think we don’t want to be the smartest person in your way of one at smartest teams, but, but it’s easy. You know, if you’re a junior developer to feel like you’re not good at anything, because everybody’s talking about how good they are and how easy it was when in fact they worked really hard. And didn’t tell anybody in the same way that if you talk to salespeople, particularly enterprise salespeople, you’ll notice maybe that the reasons we closed all the deals were because they were great salespeople. And the reason we lost the deals is because the product wasn’t very good and the price was too high. So, you know, it’s rare to meet a sales person who has a balanced view, at least expresses a balanced view of their own capabilities. So it would be easy for some new person on the sales organization to believe they’re the only one who feels that way.

Andrew 01:05:30 Yeah, no, it, it really reminds me of one of the, one of the hardest, but most important lessons that’s helped me in the last, I think five years was this kind of what you were just saying about when you’re in engineering, you, you know, it was about four or five years ago. I switched from engineering to product. And that one of the hardest things I had to do was to learn that my job wasn’t to have the right answer and to be the guy who was right all the time, my job was to get us to the right answer by whatever means necessary, like pull people together just to figure it out. But it wasn’t, it was no longer about being smart. It was about getting us to the right answer

Rich 01:06:05 Right now. It’s still okay to be smart. And it’s still okay to have the right answer, but even better if you have the right answer. And then somehow the team gets there by themselves and convinces themselves that it was their best idea.

Andrew 01:06:18 Yeah. If you can, if you can facilitate other people that, again, going back to the idea of inception, which I feel like might have to just be on the critical skills list for someone who really wants to get after it, a product is like, have you watched them?

Rich 01:06:28 I have to. I have, yes,

Andrew 01:06:32 Exactly. Yeah.

Rich 01:06:34 I was dreaming. I was dreaming about watching the movie. Oh, there we go. It definitely worked awesome.

Andrew 01:06:41 One of the things we’re going to kind of start to close up here, but one last thing I wanted to talk about specifically about product and, um, about product leadership and, and sort of mentoring, coaching, um, training people in, in your teams. When you think about coaching or training, teaching people who you work with and, and helping them really level up their skills in a given area, let’s just take product. How do you approach it?

Rich 01:07:07 The way I think about this problem is that there’s a lot of expertise to be found or gained in the product space. And it happens at various places in the product life cycle. So there may only be a couple of times this year that have intensive pricing discussions or packaging or end of life discussions may only happen once every three or five years. Um, so, so there’s a range of things you got to do. There’s lots of user customer research. There’s lots of market learning. There’s lots of the transactional work of being with my team and making sure we’re building the right things and have context. Uh, so, so those things go on all the time. But when I think about the broader range of skills, I’d be looking for the right moments. So the best time to coach or mentor somebody through the basics of pricing is when it’s an important topic, not in their first week on the job.
Rich 01:08:06 Cause you know, you send somebody off for two days worth of workshoppy stuff in the product management one-on-one they get a bunch of concepts. They don’t apply them for the first year. They’re gone, they’re wasted. Totally. So, you know, the best time to talk about end of life processes is when we are considering doing that. So I’ll get somebody on my team, you know, in that discussion when it’s appropriate. But if I think about it from a time point of view, it’s probably my obligation as a product leader or a product head to make sure that all the junior folks on my team each have an hour with me or 45 minutes with me every week to wrestle the issue of the week. So this week it turns out to be sales escalations, and maybe they can’t fix it, but at least we can talk through what that’s about and next week it might be, um, you know, con versus scrum.
Rich 01:09:01 And the week after that, it might be, uh, you know, we’ve got some holes on our development side where we don’t have enough test automation folks, and they want me to come in and do, do manual testing, right. And the week after that, it’s something else. And in the course of a year or however much time you have you’ve touched on many or most of the things and the, and the goal of those discussions, isn’t to focus on some artifact, the goal is to skill up mentally, right? What’s the framework, what’s the model or what are the many frameworks and models. Uh, so that over time they become more independent, more able to make their own choices. And it usually the agreement I’m looking for is, uh, I want to show them how to do it once I want to have them, show me how to do it. Once the third time I’ll do a little inspection and the fourth time you’re on the road. And we might, you know, if we have the time and the runway, we might put together a list of 20 of those things. And if there’s a hot topic this week, we deal with that. And if there’s not, we pick up the next thing off the list. Perfect. Cause, cause there’s too much, there’s too much to learn. There’s too much to do very context dependent. Um, and the way people learn is by doing not by being told. Yep.

Andrew 01:10:19 Yeah. But it reminds me of something I heard you say in one of your other interviews of, of, um, you know, it all, as you said, it’s all context dependent and you can’t just copy and paste from one place to another. So you have to adapt it to your, to your context.

Rich 01:10:33 That’s right. Cool.

Andrew 01:10:34 I want to wrap up here with a couple of quick, rapid fire questions. They’re short questions. Your answers can be however long you like them to be. Um, so one question that I like to ask people is what,

Rich 01:10:44 What is, what’s a small change that you’ve made

Andrew 01:10:46 In recent history that has had an outsize impact, whether that was personally or in your work habits or anything like that?

Rich 01:10:53 I got a, there’s an application called Calendly, which lets somebody book an hour on my calendar. If it’s free, this would seem like a dumb, simple thing. But I have a bunch of folks at coach and rather than exchanging 15 emails, we’ll have about three o’clock on your time. Oh, I’m in my time zone. Um, you know, they could get on the web, they can choose now or they put their name in and they can book an hour. And I think that’s freed up, you know, five hours a week of wasted administrative time that added no value.

Andrew 01:11:26 Second to last question. If you could have the leaders listening to this conversation, make just one change inside their team or their organizational culture that you think would have the biggest impact on that

Rich 01:11:36 Environment. What would that change be? I think I’d emphasize with executive teams, especially and product leaders. That product has a real skillset that we shouldn’t be hiring first for subject expertise. We shouldn’t be hiring first for developer skills. We should be hiring first if we can, for somebody who’s been in the product job at least a little while, because they will know an awful lot of things about how to do product, that would be obviously for your hiring, for sales or development or marketing or anything else. But I see so many folks decide that the product job is easy. So we’re going to hire for subject expertise. Perfect. Um, and then, you know,

Andrew 01:12:17 I know that, uh, you have a fantastic blog, uh, for every, I will link to this in the show notes. It’s Mironov.com, which I believe is M I R O N O v.com. And um, but is there any, anything you’d like to leave the audience with any requests of the,

Rich 01:12:32 I think there’s a lot of great product thinkers out there. Um, uh, Teresa Torres comes to mind. Um, Jared, Jared spool is really smart. Uh, you know, Tristan Kromer is really good. Uh, Daniel Elezalde has done a lot of really good work. There’s tremendous numbers of really smart folks out there. And they’re working hard to put their material out there, working out for free. And I would just encourage everybody to pick five or 10 people that they haven’t been following. And they haven’t been reading and dive in, see which ones are useful. See which ones play to your situation, let other people help you get smart.

Andrew 01:13:14 Rich, it’s been an absolute pleasure. Thanks so much for the time and for sharing all your wisdom with us. I really, really appreciate it. It’s been a lot of fun.

Rich 01:13:21 It’s been a huge pleasure. Thanks.