The Rich Mironov Hypothesis: Great Product Leadership is Both Subtle and Slow to Pay Off

Rich Mironov is a veteran product management and product executive coach with years of experience helping product leadership and tech company executives ask the right questions. Today on the Product Science Podcast, we look at the patterns he’s seen in organizations that do product right, where most businesses get tripped up, and what you can do to hire the right people.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, and more. Love what you hear? Leave us a review, it means a lot.


Questions We Explore in This Episode

What makes for a good product manager, and why are good developers, tech support folks, and salespeople not necessarily a good fit? How did Rich go from an undergrad degree in physics to development and eventually product management? How did he end up running his own strategic consulting business?

What patterns does Rich see across different sets of business leaders and startup leaders? What are the dangers of CEOs getting involved in product and engineering teams? What sizes of organizations are the most vulnerable to these kinds of product management mistakes? What hiring mistakes are made when startups are looking for a product manager?

What makes the difference when product is done well, and do most CEOs know the difference? What is the difference between a throughput problem and a strategy, validation, and priority problem, and how can a product manager learn how to head off these issues at the pass? How do you tell the executive team the vital information they don’t want to hear?

How is medical and veterinary software a good example of bad software and systems design and what can we learn from them? What is the number one problem Rich can spot in an organization at a distance? How can scrum and agile create these issues? What does Rich recommend to startups in order to address these issues?

Why are constant, real conversations with real customers outside of the sales cycle vital to effective product management? What are the dangers of assigning product managers to more than one team? What should you do if you notice these patterns in your organization? What is the real problem when you hear that you need to write more complete user stories, and what should you do? What difference does experience make when it comes to asking the right questions, and how do you find those people?

Quotes From the Episode

“I see a tremendous amount of companies that leaned into some other department, grabbed the name tag that said product manager, and sent them into battle to fail and quit the company dozens of times.” - Rich Mironov Click To Tweet “When the CEO is overriding most of the other decisions because of very scarce data from a narrow slice of specialized escalations, it's really hard for the company to succeed and make good product.” - Rich Mironov Click To Tweet “The really good product work is both subtle and slow to pay off. Almost everybody starts with the assumption that our problem isn't a product problem, our problem is an engineering problem.” - Rich Mironov Click To Tweet “It's not a throughput problem, it's a strategy and validation and priority problem, where most of what we're building is useless or worthless, or getting in the way or not helping.” - Rich Mironov Click To Tweet “Slice products horizontally and have a real end-to-end product manager, responsible for adoption, use, and successful outcomes on one end, and working with one or at most two development teams at the other end.” - Rich Mironov Click To Tweet “Almost all product leaders have the same issues around organizations and leadership and authority and proving the value of doing real work. So don't stay awake all night wondering why you're not good enough.” - Rich Mironov Click To Tweet “The head of product has to go to bat at the executive team level to get the right incentives and the right metrics and the right goal set. Nobody else in the company is in charge of moving us from output to outcome.” - Rich Mironov Click To Tweet


Holly Hester-Reilly: Hi, and welcome to The Product Science Podcast, where we’re helping startup founders and product leaders build high growth products, teams, and companies, through real conversations with people who have tried it and aren’t afraid to share lessons learned from their failures along the way. I’m your host, Holly Hester-Reilly, Founder and CEO of H2R Product Science.
Holly: Well, Rich, I’m so excited to have you talk with me today for The Product Science Podcast. For any of our listeners who don’t yet know who you are, can you share a little bit about your background and what you do?
Rich Mironov: Sure, I’d love to, and thanks for letting me join in. I’m a 35 year veteran of software in Silicon Valley here, the last 30 of that in product management. You could say I’m a slow learner, because other folks went onto more successful, interesting things. For the last, I don’t know, decade and a half, I’ve been out on my own as a solo, and the mix is I sometimes lean in as interim head of product, VP of product, chief product, whatever, for San Francisco area companies that forgot to have that person.
Rich: Come in and set it up and then help them hire the person they need. I coach a lot of VPs of product, or chief product folks around the world, remotely. Then, I lean in sometimes on project work. A lot of that tends to be organizational design. How do we structure a product management team and have them working well with engineering and with marketing and such, so that we’re getting the work done? Who are we hiring? How are we onboarding and training them?
Rich: I see a tremendous amount of companies around the world that leaned into some other department, grabbed the name tag that said “product manager”, tapped somebody on the shoulder and sent them into battle to fail and quit the company — dozens of times. They’re simply not understanding for instance, a developer who’s a really good developer isn’t naturally necessarily a good product manager, and a tech support person isn’t naturally a product manager, and for God’s sakes, salespeople are generally poor product managers. So, how do we build an organization that works? That’s what I spend my days worrying about.
Holly: Yeah. I find organizational design so fascinating, so I’m definitely going to ask you more about that, but before we do, I do like to have people tell us a little bit about how they got into product in the first place, and what that looks like. Because some of our listeners are still growing their careers and in those mid stages, so I’m curious to hear about how everyone got there and what their growth looks like.
Rich: Sure, and preface that to say I got into product management before electricity was discovered and we had to write all of our code on stone tablets with stone knives and feed them by hand into the compilers. Things have gotten better, but almost everybody I know has one of these, “Here’s how I stumbled into product management stories.” Very briefly-
Holly: Yes, tell us yours.
Rich: I have an undergraduate degree in physics, way, way back in the day. Hewlett-Packard hired me right out of college to write COBOL in the early ’80s. I didn’t know COBOL but I’d taken some computer science courses, it wasn’t that hard. After a few years, I got bored, I dropped out, I went to Stanford and did an MBA. Actually, the most useful thing out of that was that I met my wife — who was a classmate of mine at Stanford — so I went to graduate school to meet a woman who could support me in the style.
Rich: Graduated, went back into tech: went to Tandem Computers, which was a great company in the late ’80s and corporate strategy, that sort of stuff. They moved me into product management.  I didn’t know what it was, nobody helped, very few books or resources. “Here’s a marketing requirements document, fill it in and people will build things.” I think almost everybody who came up in product in the ’80s or ’90s had to invent their own stuff.
Rich: I sympathize with everybody there, and there’s a lot more, including your podcast and all of your writings, people are really grappling now with what product should be, and a lot of good argument, and that’s great, ’cause there’s resources. But go back a decade or two and there was really nothing. I started blogging (http:www/ about stuff for product management in 2002. ‘Cause by the way, that’s when blogs arrived.
Holly: Hey, I was on LiveJournal before that.
Rich: Okay. But there was so little about what it means to wear that ‘product management’ name tag, and a lot of struggling.
Holly: Yeah. Absolutely. Well, I was technically doing, we didn’t call it blogging, I called it journaling on the internet.
Rich: Of course.
Holly: I was technically doing that before 2002, I did not in 2002, know what product management was. I totally hear what you’re saying. It must have been interesting, beginning to write about it publicly at that time. Yeah, so how did you end up running your own, what, decade and a half now of your own consulting, training, et cetera business?
Rich: I’d love to tell you it was a strategic decision. I’d be lying. I was at my third startup that I joined in January of 2001, and it was pretty miserable and it wasn’t working. It was driving me pretty nuts and it wasn’t happening. Being very clever, on September 1st of 2001, I quit, intending to take two weeks off, because there were lots of jobs.
Rich: I was actually, I was a VP of product at that company, and of course, September 11th rolled around and the world change, and bigger things changed, but in Silicon Valley, all the VCs stopped funding things and you knew how many startups were closing ’cause they rolled their Aeron chairs out to the sidewalks for somebody to pick up before they locked their doors and went home.
Rich: I had a mortgage on a house in Silicon Valley, and a daughter who was eventually going to want to go to college. No income. Turns out that means you’re a consultant.
Holly: It does. Well, some people do that for a little while, until they’re not a consultant anymore, but something about it must have worked for you, right?
Rich: Yeah. I’m tremendously lucky, I can’t tell you how appreciative I am of my situation here, but I have lots going on. I worked with, I don’t know, 120 clients over the last decade and a half. Being on my own means the staff meetings are short. If I’ve taken my meds in the morning, we don’t argue that much, and I get to see this very horizontal sample slice of what a lot of companies are doing.
Rich: It’s not about being more perceptive or smarter, it’s having a sampling model where I’ve worked with 75 tech CEOs, and been one myself a couple of times. I get to see things that are hard to notice if you’re at the same company for nine years, ’cause you think that either your company’s special, which they’re not, or your company is how all of them are, which is also not how it is.
Rich: Most of my work has devolved into recognizing patterns that software organizations and tech companies have over and over again, which they can’t see because they’re stuck in their own stuff.
Holly: And that leads us back to some of these organizational design principles, but maybe tell us a specific one.
Rich: Sure.
Holly: What is a pattern that you see over and over, people don’t see when they’re in it?
Rich: Top of my mind for me, because I haven’t pushed it yet, I have a post that’ll go up probably late in January ( about why CEOs shouldn’t want themselves to be the primary person who understands and measures what customers want. Almost every CEO I meet with who came up through the startup and was the only person or whatever, has this belief that he/she talks to more customers, has more in depth conversations, samples the customer base appropriately, and that they really, really know what customers want.
Rich: My experience is just the opposite. As a CEO, for instance, you’re really busy, you’re time sliced, you’re trying to run everybody’s organization, if you’re not careful, and the kinds of escalations you get — because you don’t talk to customers on your own, you don’t pick out your customer list and phone folks — what CEOs get, they get two kinds of escalations. One is on the sales side, particularly enterprise companies, sales teams will escalate to the CEO for the feature requests that product won’t build, engineering can’t build, doesn’t make any sense, but some customer wants.
Rich: Then they put the CEO on the phone with this preparation saying, “Okay, talk to this customer, close the deal, you’re the chief sales officer, promise them the thing they want.” And I describe this as crack cocaine, because it immediately derails all the product planning and all the things we intended to do. But CEOs I think don’t see that they are put in that position exclusively.
Rich: Or, the other thing they get is they get escalations from big customers who are unhappy about things that often don’t matter. So, they feel the need, the urge to lean in with the product and engineering teams to say, “Hey, it can’t be this hard. Just do the thing this customer wants because I’m the CEO.” I see it as a major erosion of strategy, of the ability of product and engineering teams to make decisions, of planning, and it throws out all of the things we pretend to tell ourselves about validation and business cases and customer need and backlogs and scrum being at all useful.
Rich: When the CEO is overriding most of the other decisions because of very scarce data from a narrow slice of specialized escalations, it’s really hard for the company to succeed and make good product. That’s one where every CEO tells me, “No, I don’t do that. I know other folks do that.”
Holly: Oh yeah. I mean, nobody ever does the wrong thing themselves, right?
Rich: That’s right. But you might not see that as a pattern if you hadn’t watched a few dozen CEOs lead their companies in a great circle, with the best of intentions. It’s not that they’re bad, it’s a really hard job, and if you don’t recognize the syndrome, then you’re captive to it.
Holly: I’m curious, let me dig a little deeper on that one, is there a particular range of company stages or sizes that you tend to see that at? I mean, obviously when the startup is actually three people, that’s not the same story, right?
Rich: Right.
Holly: ‘Cause they don’t have the sales leader, the [inaudible 00:11:22]. When does that behavior start to become a bad symptom?
Rich: Really good question. I lean in a lot with relatively early stage companies. I see that when a company gets to between 12 and 18 employees, and/or they’ve got more than nine named customers, or six named customers, that the complexity and the scope, that’s when it escapes the CEO. Even though the CEO’s probably been the person to do a lot of this early work and has done their best to get through it.
Rich: It’s also the place where I usually recommend that we actually hire a product manager. If you’ve got a development team of nine, we know the CEO can’t be giving good direction with everything else, we know that the VP of engineering or CTO probably wasn’t a product person, and if the company’s going to survive and grow, we need somebody who’s really product, really validation, really thinking through strategy and pricing and packaging, and priorities, and so somewhere in there — 12, 15, 18 people? — you’d better have somebody who’s a full time product person, and ideally who’s been a product person before.
Rich: Because it’s a really, really hard job and in the same way you wouldn’t hire a VP of sales who’s never sold anything; you wouldn’t hire a CFO who doesn’t know about tax laws and payrolls, and paying bills; and you wouldn’t hire a VP of marketing who is fresh to social media, or outreach and segmentation and market strategy; hiring a product manager because we have somebody on hand who really wants the job and we don’t know what else to do with that person, or was in a two-day course at one of the many, many places that offer two-day courses and give you a CSPO degree.
Rich: They’re not product managers. They’re wannabes, and if you put that person in a product job at your 18 person startup, I think you’re risking your last two years worth of work.
Holly: Yeah. You must see that, in order to tell us about the things you shouldn’t be doing, you must have seen people do it, right?
Rich: Well, I have an attorney client privilege problem, where I will tell you I’ve seen this many, many dozens of times, but I will decline to name the guilty or the innocent.
Holly: I guess one thing I’m curious about, I only started doing the horizontal sampling in the past couple of years, so some of these things have been very surprising to me. I’m curious if you’ve noticed any patterns in the experiences that the offending parties have had before they make such a … Maybe I shouldn’t call it make a poor decision so much as neglect to make a good one, but I’m curious if they had ever been part of good product to companies before, are they all people who are just totally new to product development and that’s why they don’t know they would need a product manager?
Rich: I’m careful not to assign blame here. If we go all the way back to the very earliest, good agile principles, before it all got derailed into hard coded ‘best practices’ which aren’t best, one of the most important agile things is you trust the people over the systems. You believe everybody is doing their best, bringing their best point of view. I’m about identifying biases and organizational problems, and process issues, and lack of skills or training, but let’s assume everybody really wants their companies to succeed.
Rich: And that telling them they’re bad or misinformed or stupid or don’t know what they’re doing is worse than unhelpful.
Holly: Yeah.
Rich: Having said that, if I go back seven years and say, “Well, where did these folks come from?” Or 12 years, or 20 years, not a lot of companies have been doing product very well for very long. Most of them still aren’t doing it very well, so most of them, the vast majority are going through the motions of focusing on output instead of outcome, and product managers as, what does Steve Johnson call them? Janitors.
Holly: Mm-hmm (affirmative).
Rich: Product janitors. “Here’s the Post-it note, write down what I want you to have the team build and carry it over and write a story.” Classic, narrow product owner, never gets to meet a customer, has no authority.
Holly: Mm-hmm (affirmative).
Rich: I see most CEOs as not having been in a company where product was done well, so they don’t have a mental model. Also, noting that the really good product work is both subtle and slow to pay off. Almost everybody starts with the assumption that our problem isn’t a product problem, our problem is an engineering problem. If we could just make our development team 40% faster, more efficient… we’d get everything done.
Holly: Yeah.
Rich: We could get through all of our backlogs and ship everything our customers want. That’s a huge misunderstanding. Because we know that products with more features mostly suck, and we know that most of what engineering builds isn’t useful. So, recasting that problem and saying it’s not a throughput problem, it’s a strategy and validation and priority problem, where most of what we’re building is useless or worthless, or getting in the way or not helping.
Rich: But you don’t get to see that until you’ve gotten punched in the nose a bunch of times and shipped a bunch of things that nobody wants, and then had somebody brave enough in the company to say, “We’re shipping things people don’t want.” Honestly, if the executive team are the ones coming up with the ideas, nobody’s excited to go back to the executive team and say, “Those last three things you asked for were kind of dumb.”
Rich: Which is why you want somebody from the outside who in my case, has some gray in his beard, to say not, “You guys are dumb and you’re overdriving, and you’re not getting your ideas, and you’re biased, and it’s all about recency and shiny objects.” You want somebody who says, “This is a general pattern and you don’t have to feel bad about being in a general pattern, but you have to stand up and fly right and try to get out of it. Because we all love you and understand that you’re doing the best that you can do, but here’s a pattern you may not have been seeing.” Notice those are syntactically the same, but in a people sense-
Holly: It’ll be received very differently.
Rich: Often that means taking some of the executive team out one at a time for drinks, or in a quiet meeting room somewhere, and finding the way to tell them what they really don’t want to hear. They would love to know that this is a throughput problem, or if we hired a few more smart engineers, or if the product folks would just listen better to us, or we didn’t delay so much to think and validate and talk to customers so much because we know what they want.
Rich: That’s a really hard message. It’s a really hard message, and particularly if you’re a subject expert, if you … I’ll pull a few examples carefully here. The market’s full of two or three thousand software applications that are designed to run veterinary offices. All but two of them have only one sale ever made in the world, and it’s to the veterinarian who wrote it, who does Visual Basic on the side for fun, and he bought it himself, because he didn’t like any of the commercial ones.
Rich: This is a really hard pattern, and so we have to appreciate where folks are coming from. Subject matter experts know that they are the person who did the best M&A work for M&A, or they did the best teaching applications, or the best hospital and software management, or the best whatever, and they take their own single instance.
Rich: Some really wonderful, smart folks in the healthcare software world I work with in the Boston area taught me that “when you’ve seen one hospital software system, you’ve seen one hospital software system.”
Holly: It’s that bad?
Rich: Every one of them [hospital] is broken and old, and archeologically stacked up with bad choices and weird stuff, and, “We built it ourselves” and none of them work. All of the CTOs of hospital software companies that came out of running hospital software systems believe that they understand based on their one point of experience, how all hospitals run.
Rich: I only say this because I’ve worked with six other hospital software firms, every one of which told me they were building the thing that all hospitals want, and then every installation took nine months of professional services to fit into whatever weird thing it was.
Holly: I believe that so quickly. I actually was just at the hospital last week.
Rich: Uh-oh.
Holly: ‘Cause this is so sad, I stubbed my toe so badly that it broke.
Rich: Oh dear.
Holly: So while I was there, I was actually watching what the ER stuff used for their tools and the guy asked me what I do, so I was telling him about software and so it was interesting. ‘Cause then he started to show me, “Oh, this is how this part works and I like this, and I don’t like that.” I was just like, “It’s amazing, the systems are so complex.”
Rich: And archaic and [crosstalk 00:21:41]-
Holly: Well, they look like they were designed 20 years ago.
Rich: Just about a year ago I changed doctors and it’s taken my new doctor’s practice a full year to get my medical records from my old doctor’s practice.
Holly: Yeah, it’s amazing.
Rich: With a prompt from me every four weeks to each side.
Holly: Wow.
Rich: I don’t know how you deliver good medical care if you don’t have somebody’s medical history.
Holly: Yeah. Well, that also explains why every time you go to a different doctor, they ask you for your whole history.
Rich: That’s right, and I’m supposed to remember every drug I’ve ever taken, and every inoculation I’ve had in my whole life? I guess I should just bring it with me, but it’s a symptom I think of really bad software and systems design, with choices made by folks who aren’t the people who have to make it work. So, doctors choose hospital systems. Systems people don’t choose hospital systems.
Rich: Doctors aren’t experts at this, yet we all know that doctors think they’re God, or they used to, so they can’t make mistakes, so they’ll pick something. Every hospital system has just a raft of this stuff. Sorry for the rant.
Holly: No, that’s okay. Dive down specific holes sometimes. Let’s actually go back to the organizational design. I’m super curious to hear, what are some things that you coach either CEOs or product leaders to combat some patterns, or to combat some anti-patterns. What do you tell them to put in place?
Rich: A few things off the top, and I can usually solve this by inspection without ever having shown up, but it’s bad form because I should really show up and ask some questions, and leave a big invoice so they take my advice. One thing that is completely obvious from a distance is everybody who’s separated product managers — in big quotes, “the business” — from product owners who report up through engineering teams and are not in product organizations.
Rich: This for me is the fundamental failure of everybody who picks up a scrum book and thinks it’s right. What I observe is that the folks in the business, whatever that is, are generally very poorly aware of what it takes to build anything. They don’t believe that priority lists are really priority lists, and mostly they don’t believe in validation. They believe in issuing demands or requirements or feature lists.
Holly: Yes.
Rich: Again, many of which are worthless or counterintuitive, or counterproductive, and that they think of the, ’cause it’s always an IT organization if they call it that. They think of IT as a service organization that’s supposed to build what they want. That leads to bad systems, then we have product owners who are disempowered, who are not allowed to say ‘no,’ who have gotten no product training in the outbound stuff about customers and needs and stories, and value and selling channels, and how to make stuff useful.
Rich: They’ve been forced into business analyst roles where they write stories, they write user stories, and then they approve user stories.  I see that as a huge anti-pattern. My strongest recommendation is I want to slice products horizontally. I want to have a real end to end product manager who’s responsible both for adoption and use and successful outcomes on one end, and working with one or at most two development teams at the other end, two if they’re very senior and experienced.
Rich: That person’s charged both with setting the priorities and agendas and writing the stories and deciding what’s going to get built, and being the direct source for talking with users and customers and buyers. I don’t want to hear about a research team that gives me a report, I don’t want to hear about only getting stuff filtered out of comments in Salesforce. When I parachute into a company, it’s almost always a software company, and I ask the folks who were product badges how many customers they’ve talked to last week that were not sales calls, ’cause those don’t count, and they say, “None.”
Rich: Well, in the next three weeks we’re going to fix this and they’re going to be talking to two or three customers a week, or there’s some structural issue like sales won’t let us do it, and I have to fix it. Or, the folks not willing to do that are going to get a promotion to a different job in the company. Because I believe you cannot do product management at all if you aren’t directly personally on the phone or the hangout, or whatever it is, with at least a couple of customers a week, outside the sales cycle.
Rich: That’s one, and it’s really easy to say, it’s really hard to retune that organization. There’s people issues, there’s skill issues, there’s staffing issues, and there’s a lot of, “No, we don’t need it.” It’s my job to go in and fix it. The other thing I see is I see a product person, regardless of what the rest of that title is, who’s assigned to care and feeding three or four development teams.
Holly: Yeah, that shocks me too. That’s one that I …
Rich: And I know without meeting any of the people in that company, that that person’s failing, and that everybody believes that they’re not doing a good job and they should be fired, because if you’re thoughtfully doing product work, I don’t think you can thoughtfully do product work for more than about one team.
Rich: Again, if you’re senior and you’ve been doing it for a while, I think I could stretch you to two teams, depending on a lot of internal variables. But take somebody who’s relatively junior or hasn’t done this a lot, and assign them to feed stories to three teams, well I know what they’re doing all day long. They’re sitting in front of a screen, they’re writing stories based on what somebody else told them is important, and they’re hoping not to get caught out with the fact that they’re skimping on every story in order to get ’em all checked in by Friday.
Rich: I mean, that’s setting everyone up in the organization for failure and it means somebody on the development team side is probably stepping forward, and either pretending to be a subject expert, or making all of the decisions about what’s important. That’s not what we hired them for, and they may fail at that, ’cause it’s not their expertise. Anyway, those are two things that I look at: a staffing ratio of no more than 1 to 12, and that includes tech writers, and that includes designers, and that includes DevOps and tech automation engineers, test automation engineers.  If you’ve got more than 12 people you’re feeding, you’re not doing your product job.
Holly: Yeah, absolutely.
Rich: And again, nobody wants to hear that they’re five product managers short in a department of nine. And of course, then they can’t hire them ’cause I told them they should hire folks with some experience or seniority, and we know very few of those folks exist. But if that’s the real issue, then it doesn’t matter if you change your story template, or you put new spreadsheets in place, or you go from JIRA to something else.
Rich: Those are all fake answers: that we send everybody for two days of scrum training somewhere, and then you put ’em back in the same situation.
Holly: Yeah, those are Band-Aids. What do you recommend? Let’s say somebody’s listening and they’re noticing that these things exist in their organization. Do you have any advice for them? Especially if they can’t just hire you. Like, what do they do?
Rich: What do they do? Of course, the real advice comes with an invoice, but I think it should be obvious. First, if the person running your product team hasn’t ever been a product person, or maybe hasn’t been a head of product, but has been an individual contributor, that’s a really tough job and the failure rate is high.
Rich: I recommend, if it’s empty, you really want to try to recruit somebody who’s managed product managers before. That would seem obvious, except everybody ignores that. They all go for subject expertise or engineering talent. Again, I lean in sometimes, that’s usually a six months search, so sometimes I lean in.  I help do that job while they’re looking, which is always brutal, but apparently I like it.
Rich: I always recommend getting somebody who’s a coach or a mentor for those, has a product, who can coach them, again, not on writing stories or sitting in meetings, but on how executives think. ‘Cause they’re sitting at the big table with the big kids who make a lot more money and drive sales and drive marketing and drive other things. They have to think of themselves as executives, not as junior product folks who get told what to do.
Rich: Then, down from that, again, if you’re hiring, I’m always looking for a team that’s got a mix of experienced or senior or veteran product folks and newbies. The newbies bring a lot of enthusiasm, they bring new insights, they bring willingness to learn, but if you just have a department full of newbies, they’re all going to drown.
Rich: Whether they quit or you fire them or the company fails, it’s not a good outcome. They need in-house coaches and mentors who can sit next to them and show them how to do the things at the time they need to. Again, going to class would be fine for a couple of days, but in general, you’re learning things that are very generic and are out of order. I don’t need to know how to do business case today. I need to know how to do a lightweight, thumbnail business case, when it’s important, which turns out to be in March.
Rich: So, I need somebody who can lean in and say, “Oh yeah, yeah. You don’t need to do all that much, it’s just three lines of revenue projection.” Or, well for this thing, which is really company dangerous, you’re going to get asked a lot of questions and you have to build a model that has pricing and market segments.
Rich: Another example here. Everybody I talk to in every engineering organization tells me the product managers need to write more complete user stories. But that’s wrong. When you sit down with an individual team, and their individual product manager, the better question is, “Well, of these last 25 stories, which ones did we put too much detail in? ‘Cause you know all this stuff.” And we could have gotten away with three lines or one line. Reformat the database to be more performant because you guys are the database experts. Then, which stories were too short because it lacked all the context? So that we can put our energy where it needs to go, instead of filling out templates.  (
Holly: Yeah.
Rich: A junior product manager’s never going to know to ask those questions, and a senior person sitting next to them is all the coaching difference of, “Here’s how to navigate our organization. Here’s what works. Here’s some war stories.” Hiring for experience, hiring for in the job, actual been there, been punched in the face a few times is really important, and then training up the interview team and the HR or the recruiting folks to actually look for resumes and backgrounds that match what we said we wanted.
Rich: Routinely recruiters who don’t do a lot of product management hiring always get confused between project managers, program managers, and product managers. They always lean toward industry experience and subject expertise, ignoring product experience, and they never know what questions to ask to see whether somebody’s real or fake.
Rich: I’m always trying to train those hiring teams for how to interview, so we can spot product talent instead of whatever other shiny things came through.
Holly: Yeah. That’s actually an interesting point as well. I know, I personally have started to meet several more people in the recruiting and placement industry who are focused specifically on product.
Rich: Oh good.
Holly: Yeah. It’s good to see. I’ve had a couple people say, “I’ve noticed there’s a lot more need for this. I think I’m going to double down” and it’s like, “All right, good” but I’m curious what are some tips or things that you tell those hiring teams to look for instead of the easy to keyword match items?
Rich: I think everybody on the team generally brings their own bias, so engineers really want to hire engineers, because we all know that engineers are smarter than everybody else and they solve the only hard problems. Avoid coding tests unless you’re shipping a product which is about coding. If you’re shipping a developer thing, then you probably want to hire folks with developer experience, but not hospital software.
Holly: Mm-hmm (affirmative).
Rich: I’m always pushing them to ask case study questions. “Tell me about a couple of product decisions you made that didn’t work out well and what you learned.” ‘Cause by the way, newbies and wannabes actually have never shipped anything, so they don’t have those stories.
Rich: I’m always asking, “Tell me about a product that’s not our product, and not the one you built that you really like and why… and a product that you really don’t like and why.” What we’re listening for is good product thinking, segmentation, ease of use. It doesn’t meet the needs of certain groups, the pricing model’s wrong, et cetera.  Not designish, the button was in the wrong place.
Rich: I’m always asking for something that shows empathy with the other organizational groups. At an enterprise company, it’s really hard to work with and navigate with sales teams. Tell me how you have negotiated or worked things out with sales, and the answer can’t be, “I do everything sales wants.” The answer can’t be, flip the bird and, “I never talk to sales.” The right answer’s in between, what are the specific things you’ve done with your team to make sure your team has lots of context and is included in the validation process so that they really understand the problem and don’t have to take your word for it?
Rich: That excludes everybody who doesn’t do that, excludes everybody who’s never built anything, who comes from an organization where product gets told and then engineering gets told by product. If you can’t empathize with and understand the reward systems for every organization in the company, you don’t know why they behave the way they behave.
Rich: Marketing just wants the three or four bullet points of no more than nine words each that explain the product, and you keep wanting to do a demo of how the internals and the machine learning is better than somebody else’s. And honestly, they couldn’t care.
Holly: Yep.
Rich: And support really wants to know that you’re going to fix the top three bugs at the top of their list — and explaining to them that they never get what they want because you have a different prioritization scheme isn’t useful. Empathy, validation, “Tell me how you learned. On your last job you picked up a product that wasn’t something you were an expert in. Tell me how you learned all about how your real users are and what they need in the first month or two.” Because by the way if they don’t do that, they’re not product managers.
Holly: Yeah. Those are awesome. I know we have just a few minutes before you turn into a pumpkin, so the last thing I always like to ask people is do you have any specific pieces of advice for a new product leader? Somebody who’s early into their management of product managers position?
Rich: Yeah. First to send my sympathies along, because it’s a really hard job. And ’cause I get groups of product leads together every once in a while, what we discovered is that we’re all having the same issues. So probably the first learning is we, each of us, ’cause we’re driven, driven successful folks, believe that all the shortcomings are our personal internal shortcomings.
Rich: If I were better, taller, smarter, richer, younger, whatever it is, I wouldn’t be having this problem. The answer is almost all product leaders have all the same issues around organizations and leadership and authority and proving the value of doing real work. So, try not to eat yourself alive and stay awake all night wondering why you’re not good enough.
Rich: Reach out to a bunch of other product leaders and have lunch or breakfast with them and find out it’s not something new. And then, I really recommend that they stop doing first line product management. They all want to keep managing the product that they used to manage before they got promoted, and that’s not a recipe for success. They have to focus on people and issues and processes.
Rich: I think of the head of product as product managing the executive team. How do we get the company to want to do the right things so that my product managers can then get the right things done? It’s an enabler. It’s a remover of blockers. How do we get all the functional groups to actually want to cooperate, to actually care about data and validation, to make time to learn what we’re building and why, to surface good inputs and responses? That’s really hard, ’cause every other functional group is heads down trying to meet their quota or their number or their NPS, or their, on the engineering side, they’re getting great at how many stories we checked off.
Rich: I think the head of product has to go to bat at the executive team level to get the right incentives and the right metrics and the right goal set. ‘Cause nobody else in the company really is in charge of moving us from output to outcome. Everybody is doing their work ’cause they’re in a functional job, the finance folks are supposed to count money, and the sales folks are supposed to bring in deals no matter how bad they are.
Holly: Yep.
Rich: And if we don’t fix the comp system, if we don’t fix the quota system for sales, they’re all going to do the wrong thing ’cause that’s why we pay them.
Holly: Exactly.
Rich: I worry much more about the comp plan than I do about misbehaving sales reps, ’cause I know the very first thing they do every quarter is they look at their comp plan, they figure out how they’re going to make their number. If we’re rewarding them for bringing in specials and one-offs and customers who need a lot of custom work, that’s what they’re going to do. They’ve got to put food on the table and a new Tesla in the driveway.
Holly: That’s right. Yeah, no I love that. I definitely have also had some conversations with early people managers of product managers, and I think that’s the mindset shift to the executive team management and all of that.
Rich: Sure. And it’s new and it’s hard, and we all want to do the thing that we’re good at, that got us promoted, and that’s not going to work. One last thought before I lose you, ’cause I’ve been really loving it, if you haven’t told folks about Melissa Perri’s new book, about “The Build Trap” — I just finished it, five stars, everybody should go get it.
Holly: Oh, awesome. Yeah, I’m going to be talking to her, she’ll be on a later episode. I think she and I are doing an interview in a week or two.
Rich: Perfect. Yeah, and there’s a lot of really good work getting done and we should all be reaching out to name the people who are doing it.
Holly: I love that. Thank you, Rich. We’ll definitely include that in the show notes as well, and yeah, awesome. Well, thank you so much for your time. It’s been fantastic.
Rich: It’s my pleasure. I’m thrilled with what you’re doing, I’m so pleased to see your practice growing, and for you to be finding folks who really want your expertise, which is great.
Holly: Thank you.
Rich: Applause from here.
Holly: Oh, thanks so much. As you know, I’m super thankful for all of your support.
Rich: Let’s go get ’em.
Holly: Let’s do it. All right, have a good day. Bye. Well, I hope you enjoyed that conversation with Rich Mironov. If you’d like to find him online, you can find him online, @RichMironov. R-i-c-h-M-i-r-o-n-o-v. Or, visit his website, Thanks for listening.
Holly: The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and product leaders how to use the Product Science methods to discover the strongest product opportunities and lay the foundations for high growth products, teams, and businesses. Learn more at
Holly: Enjoying this episode? Don’t forget to subscribe so you don’t miss next week’s episode. I also encourage you to visit us at to sign up for more information and resources from me and our guests. If you love the show, by rating a review would be greatly appreciated. Thank you.