S2E1 - What Product Leaders Owe Their Teams - Rich Mironov, Author of The Art of Product Management

0:00:05 - Rahul Abhyankar
Hi Rich. Thank you very much for being a guest on this show, Product Leader's Journey. First of all, I'm really excited to have you here and you've been a leading voice on product management for a really long time, really lighting the path forward for many people and, on behalf of the product community and personally too, I really want to thank you for that, truly. 

0:00:30 - Rich Mironov
Oh, it's my pleasure and it's what gets us up every morning to do good work, pay it forward and help the next generation do better than we did. 

0:00:39 - Rahul Abhyankar
I have a question about all the topics that you've written about. Your blog is very popular. How do you decide what to write about? And, I guess, maybe related to that, how has your writing evolved over the years in terms of topics or style of writing or the audience you want to reach? 

0:00:58 - Rich Mironov
I think if we tell it sort of back to front historically, that might be a good way. So I started the blog in late 2001, early 2002. 

I was unemployed, I discovered I was a product management consultant because I had a mortgage in Silicon Valley and a daughter who was going to go to some famous university and no income, which is kind of the definition of consulting. 

And when I first hung out my shingle I went to a bunch of folks to say I'll be your product manager, I'll do product management work for you, I'll be a consultant. And almost every single person was excited to have the conversation but honestly didn't know what product management was. So we're back 20, some odd years here, maybe 30 to 40. And so the early years of the blog I would say the first five years, were mostly around the question of what problems do we solve as product managers? Because it turned out that nobody's going to hire you as a consultant unless they have a problem that is the one that you're talking about, and so it's much more important to frame up the problems that product managers solve than the specific techniques or tools that we're using to solve them. So there's about five or six years of - Gee, if I were trying to end the life of product, how would I do it? 

And if I were trying to price a product for the first time, how would I do it? And if I were, you know, trying to learn from customers, how would I do it? And it was all to set up for the audience that maybe nobody was pricing it and maybe nobody was launching it or talking to customers or end of life-ing old stuff, and so it was less about the technique and much more of the realization that one might need to do those things. Over the last decade or so I've really moved up the stack. So these days what I'm doing mostly is I'm coaching heads of product, I'm doing some courses for heads of product. 

You know, VPs, CPOs, Directors, you might be shocked to find out that almost everybody has all of the same issues and challenges. Not at all. And so for the last, you know, half a decade or more, it really comes out of the work you know and I work a lot on this sort of political and emotional issues that we see in the executive suite much more than the techniques of how we manage backlogs and prioritize stuff. So most of my writing lately comes out of these very fraught, complicated discussions with heads of product where we're trying to get out ahead of the sales or the marketing team or the finance team to do the right thing, and we're trying to find partial solutions and recommendations. 

0:03:29 - Rahul Abhyankar
So what are the things that you find yourself repeating more than you'd like to, perhaps? 

What Go-to-Market Teams Actually Don't Care About

0:03:36 - Rich Mironov
Oh gosh, there's a few that come up almost every day. 

So one is we, as product folks, would really like the entire company to understand what we do in great detail and to love the processes that we follow and to care about prioritization and to understand work in process, and my observation is that almost nobody on the go-to-market side of our companies care about any of that. I have a picture of Dr Sheldon Cooper from the Big Bang Theory, right, and I put that up and I say, when you spend an hour talking about agile, this is what they see and, by the way, their eyes closed at 30 seconds, right. And so the first thing for me is we need to talk with our go-to-market side stakeholders and execs about what they care about, which is money and revenue and attribution, and, you know, helping with deals and market size, right. About the, the what's happening in the kitchen, right, how we're making the sausage. 

We almost always lose everyone on the go-to-market side because it's not what they're interested in, right? So so that's the first one, and the other one is I think you know when we, when we argue with our engineering teams, there's a certain way we structure arguments with engineering, we have proof. We start bottom up, right, it's building the arguments so they see not only that we have the facts, but that we're smart enough to be in the room with them, because they're always smarter than we are right, and it may take 25 minutes to get to the answer. 

And when we're working on the go-to-market side, in fact, there's an exec, a CEO I've worked with out of Chicago, who says the first slide of every deck is the bottom line up front slide. Okay, it tells me the answer of what you want and what you're looking for. And if you don't have it on the very first slide, you're kicked out of the meeting. Right, because if we all agree around the table that you got the right answer, we actually don't want to see the presentation, right? And if you have the wrong answer. 

We actually don't want to see the presentation and if you have the wrong answer, we're going to dig pretty deep until we convince you you're wrong. And again, that's about understanding your audience and what they care about. And we talk about money or accounts or markets, or upsell or scalability, because that's what the go-to-market side, or upsell or scalability, because that's what the go-to-market side of our companies actually cares about, and everything else. Sometimes we have to go to the discussion and talk about tech, debt or architecture, but honestly, a lot of it's wasted. 

Prioritization is a Political Problem

0:06:21 - Rahul Abhyankar
And you talk about the politics, about that, and you've written about how prioritization is a political problem. 

0:06:29 - Rich Mironov
Yeah, I think there's a couple pieces. One is you know, there's always a request to prioritize everything in the backlog right, all 940 things In fact, to size them all right with this idea somehow that we're going to move some of those small things up. That's almost completely a waste of time, so I usually fall back on. Let's imagine we can fit 12 items into next quarter. 

I don't know, so let's prioritize two or three times that size. Let's prioritize 30 things and everything else 31 through 10,000, we're not working on. Everything else 31 through 10,000, we're not working on. We're not going to size right. And then that brings forward a short enough list that actually we can talk through the list. 

One of the things I see a lot on prioritization and backlogs is we want to walk some audience through all 500 tickets, right, what a complete waste of time, right. Tickets right, what a complete waste of time, right. So we need to do something really quick and dirty to get to the 2x or 3x capacity, because every one of those is going to need hard arguments and sizing and market analysis. Right, we're never going to get past whatever number 30 or 35. So let's not pretend. And then we, we on the product side, can give that list to a small number of go-to-market side stakeholders and ask them to prioritize it. We won't actually necessarily do it in that order, but we'll use that there's how big is it and how strategic is it and what does sales and marketing want to say? But but the human mind can't conceive of a list of 40 things. So if we understand the emotional challenge and the mental challenge here. 

I would rather bring you know seven items, of which we're going to choose three and have just a knockdown, drag out fist, fight for five hours, and four of them are going to be left on the floor, and three of them are going to be what we do and we're going to agree. Everything past some reasonable short number, I think, is a waste of energy, you know so. So we could have a 17 column spreadsheet with weightings down to. There's somebody in finance who believes we can prioritize to eight decimal places. Makes no sense, right? We're guessing at revenue. We're guessing at engineering time. We're guessing at design time. We're guessing at delivery. We're guessing at the market plus or minus 60%, right? So you know, we're going to make some choices. Some of them are going to be wrong, but let's not waste our time on anything that's worth one-tenth what the top handful of things are. 

Why the Product Role in Enterprise B2B is Challenging

0:09:03 - Rahul Abhyankar
Rich, you've been doing product management for three decades 35 years 35 years, we still find ourselves in this interesting situation where we have to continuously justify the importance, the value of this role, the function. Are we ever going to get to a point where we don't need to justify the importance of product management? Do? You feel we are there now because we see the chief product officer role has a seat at the table. Is that what we were looking for as the tipping point? 

0:09:40 - Rich Mironov
Let me segment the problem a little bit, because I think there's two poles here, there's two sets of answers. Right, um, if we're in a B2C company, so you know, we're trying to sell, you know, streaming music services to 40 million people at six pounds or euros or yens or dollars a month. Right, yeah, um, there's no one music subscriber who is so important to the company that the CEO has their phone number. And so, in a mass market I think of product and engineering and marketing as all aligned we could run an experiment where we raise prices 15% for 1% of our audience and see if we make more money or not, see what the elasticity is and if we lose 20,000 of those subscribers. Life is like that, right? We could change our offers, we can change our content, we can run a bunch of experiments, and there's no one of those that we get punished for. 

Now flip to the high end of the enterprise space. 

This quarter we're going to close 20 deals, and three of them represent half of all the new revenue for the company. 

And, by the way, not only does the sales VP know the name of those 20 deals, especially the three, the CEO is helping on all three and the board is calling once a week at least to ask how those three deals are going. 

The idea that a product person is going to walk into the room and say, well, they want something unreasonable, they're looking for five-factor authentication and we only have four-factor authentication and so we're going to pass up the $2.5 million a year deal that means we don't have to fire everybody this quarter that's a very different emotional and political situation. And so in the high-end enterprise, what I find is that the sales teams discovered new requirements all the way through, many of which aren't requirements, but salespeople are paid to get to yes as quickly as possible. That's what we reward them for. And the idea that they're going to say to some customer that's a stupid idea, or you're never going to have that, or that's not going to work, not so good. And so the lumpier and the larger the deals are, the harder it is, I think, to be in the product role. 

0:12:05 - Rich Mironov
Now, unfortunately, I'm stupid enough to have kept myself at the enterprise end of this. So, whatever I see tremendous boardroom power and leadership in the B2C space and small business, right? Smb, you're doing small end accounting right. If you're zero and you're getting $12 a month from 5 million small businesses, you can run an experiment. I'm not sure in the enterprise space that the executive team yet wants what product management is offering and selling. 

0:12:38 - Rahul Abhyankar
And you don't see that changing. 

0:12:41 - Rich Mironov
I see it changing a little bit at a time. There's a moment when it might change, when the board comes to the executive team and says we need to scale the company up much more quickly. It takes us 18 months to close these and we need to close 50 deals at 50,000. 

Now we really need what product's selling, which is scalability and standardization and good onboarding and great UX and standard SKUs and well-understood discounts. But until there's a stick, I often find that the go-to-market side will agree to whatever it is that I propose today, but when the call comes in… Right. When. JP Morgan Chase says we'd love to buy that product, we'll buy it at full price. If you throw these other three products in for free and make this other commitment, it's hard to back up from that. 

0:13:42 - Rahul Abhyankar
And what you're saying is it goes back to your earlier point about the mid market versus the large enterprise and the lumpiness of the deals, and so on. 

0:13:53 - Rich Mironov
Yes, yes, so I don't have any magic there. I do think of this and it came up on a coaching call this morning for me, again, it's a politics question, but I think of this as a coalition issue, right? So when sales invents a new SKU and a new price and a new pricing metric and a new package, everybody in finance has to scramble to put it in the system and everybody in support has to scramble to figure out how we're going to know what they got, and everybody in engineering has to scramble to put a new build together. And everyone in the company outside of sales feels the pain. So how do we as product leaders have the pre-conversation with all the other execs around the table? So when sales says, oh, all we need to do to close this deal is invent a new SKU, a new pricing metric and make some commitments, it's not just products saying they're not happy, it's the rest of the company sharing the pain of the last 15 times we did this and how it's not okay. 

And it's not that I dislike salespeople. I deeply respect them and I can't do what they do, but without some guardrails they go there right away because it's the easiest way to close a deal. 

0:15:07 - Rahul Abhyankar
Yeah, I used to joke about this with one of my head of sales counterparts in my previous life is that he and his team are the only people who are getting great job satisfaction because they're closing deals, signing and bringing in those customers. But then the rest of the company's job satisfaction goes way down because everybody's now struggling to see. How do you support that? 

0:15:29 - Rich Mironov
That's right. That's right. And you've heard me tell the sort of joke survey thing here. But you know, if you go survey a sales team, an enterprise sales team, the number one reason we closed deals this quarter is because they're great salespeople. They're all above average right. And the two reasons we lost deals this quarter are because the price was too high and we were missing a few dozen features. 

A few dozen features and that's universally true when you ask the sales team and they're really good at self-promotion because they're salespeople and they have a voice and they're the most important folks in the company. But yes, there's a cost. 

Merchandising Product Work

0:16:08 - Rahul Abhyankar
So you've written about merchandising, product management as something, an aspect of a product leader's responsibility that doesn't get much attention, you know. Talk about.

0:16:20 - Rich Mironov
Sure, yeah, and I'm using merchandising in the internal sense here but how do we make visible the good things that have happened? Right, and so you know if I'm putting on my CPO or product leader, hat on, I would like to send a message to the company every single week. It's got one or two things that went really well, that landed that improved customer satisfaction, that brought in a bunch of deals that reduced our support overhead, right? 

I want to name some people or some teams because, again, remember, the go-to-market side doesn't actually understand the details of what's happening inside the development machine. 

So when somebody on my design team figures out that by moving the postal code or the zip code ahead of city and state so that we can auto-fill in city and state, we're getting 3.5% more folks signing up for our consumer service because they're making fewer mistakes and they have fewer things to type in, I want to send the email to the whole company or say it in the all hands meeting and I want to name the design team specifically, maybe even the people, and say we just made this tiny little change and it's going to be worth 15 million bucks next year, and let's have those people stand up and be applauded or let's put their names on the thing, or let's find a way to recognize the good work. 

When somebody on the engineering team makes a bunch of changes to the backend system so that we can support 40% more users on the same AWS instance and we have much better scalability, I want to go out to the company and say here's the team that did a bunch of scalability work, which means we're going to save $3.5 million in AWS fees next year and be able to meet all our sales goals because we were afraid of maxing out our systems. 

Let's applaud. Let's applaud the people doing the work, and the first time it's awkward and the second time it's awkward, but if you do this every week for a few years, there's this subliminal message to the rest of the company that we do real work, that it really matters, that it puts money into the company's hands, that the astronomical salaries we pay ourselves are worth it, right, and that we're not sitting around eating bonbons and playing Fortnite right? We're actually working really hard on a bunch of things that keep adding value to the company, right? Notice I keep trying to attach money or outcome or customer sat to pieces of work. 

0:18:59 - Rahul Abhyankar
And that's a language that the go-to-market side of the house understands very well. It's in their language. 

0:19:07 - Rich Mironov
We're speaking in their language, so we respect them. We show our respect for them by speaking in their language. Now, it's often really hard to attribute any particular movement to any particular small feature. So sometimes we bundle them up and sometimes we estimate, but we know when we're making an impact. But the rest of the company doesn't hear about it unless we as leaders engineering leaders, design leaders, product leaders merchandise the good work that our teams do every single week. So it answers the question of well, what do you guys do? You're spending all this money over there and we never see anything. 

Diagnosing What's Not Working in Product Land

0:19:47 - Rahul Abhyankar
So Rich, you've described yourself as a paratrooper, parachuting into companies when you have these conversations with CEOs who want to bring you in. So when you land on the ground and you folded your parachute, what's the first few things that you look for? 

0:20:05 - Rich Mironov
That's hard and you know it's obviously specific. And again, just to frame up the analogy, so if you were in the Canadian Forest Service, you were fighting fires and they were huge they parachute a bunch of folks behind the fire to knock down the fuel and to cut lines and keep the fire from spreading. 

They don't get to go home tired and smelly and smoky until they fought their way back through the fire. So I've done, I think, 15 of these interim CPO jobs. Usually the first thing is I'm trying to figure out what's broken. Everybody told me before I got there what's not working, and it's almost always a symptom instead of a root issue. What's really broken? Second thing is I'm looking for really easy quick wins, because I may only be there three or four months and there's not time to negotiate, there's not time to like change all the systems. What can we do quick? A good example here, and I think you and I may have talked about it before I parachuted into a company where the general belief among the executive team was that engineering never shipped anything at all, and and and. 

On day one I heard that from most of the executive team and I chatted with the engineering team. And what I learned? Right, what's going on? They had 15 or 20 features that were each 90% done. Nothing was getting done and the interrupt rate was so high that they couldn't finish anything. So what do we do? What's the quick win? So I sat down with the VP of engineering and I said, well, pick two things that you could finish this week, and I don't care what they are. And they finished two little features and one bug fix. And the next Monday they shipped a patch. And I got to go into the executive meeting and say, hey, engineering shipped a patch. On Friday. I got very quiet because everybody had this belief that engineering never shipped anything. And then it was oh well, what did they ship? And I talked about the two little features and the one fix. 

And so we immediately moved on to the right discussion, which was the product discussion of well, how did you decide what we're going to ship and what are we going to ship next? Right, so so in in one moment, we were able to undercut the theory that said engineering doesn't do anything by doing something right, trivial to get to the real meat of the issue, which is are we in agreement about what's important and what's the priorities and what we're going to work on? And then I got to go down to engineering and say you guys were the heroes today because we shipped a patch right and we're going to do one next week too. 

Right, and the engineering team, which had been feeling very stepped upon, badly treated. You know they got to be heroes. I think we brought pizza and it didn't matter right. It wasn't about the facts on the ground, it was about the emotion around and the theory around the executive team. One has to really take that apart and figure out what's not working. 

Organizational Dysfunctions that Prevent Product Success

0:23:00 - Rahul Abhyankar
Do you look at the org chart and does that tell you anything? 

0:23:04 - Rich Mironov
Yeah, usually I look at the org chart. I don't even need to talk to anybody, right you know, when you see, for instance, that the engineering team is broken into project groups that get reshuffled after each shipment. 

I know what's broken when you look at the org chart and figure out that everybody in product has been recruited from some other department and has never done the product job, when there's more people in the implementation and customization side than versus core engineering, right, often I can read the symptomology right off the org chart. Right. So I think of org charts as really powerful. So I think there's been a real resurgence of product management. Getting a product leader who reports to the CEO. I think that's very, very positive, especially if that's somebody who's put a career into product management. I'll go off on the side here for a minute. I end up getting pulled in a lot where they've hired a chief product officer, which is great, but that person's never, ever, done any product management Interesting. Doesn't know what it is that we do, doesn't know how we add value, can't deliver the political coverage and the tools that we need. Um, and it puzzles me it really puzzles me. 

Um, just imagine hiring a head of software engineering who'd never built software yeah. Or a head of sales who'd never been in sales yeah. Or a head of marketing who'd never run marketing but somehow anyway. So so I see that again, first on the B2C side and then coming up on the B2B side. That's really very positive If we're not going to hire somebody who's explicitly separate as the chief product person. My theory usually is I look at, I interview and look across all of the rest of the executive team and try to find somebody who understands product and has run product before. So if the CTO actually has good product chops, that's okay, and if the chief marketing officer has good product chops, that's okay. But to have a whole group work for folks who don't really understand what we do, I think sets us up for some bad outcomes. 

Assessing Product Competency

0:25:18 - Rahul Abhyankar
So when you work with companies on an interim basis, do you assess the maturity of the product organization? 

0:25:27 - Rich Mironov
I think that's a really challenging thing because I don't actually believe there's any direct metrics for any individual product manager, given the situation of where the product is and where the engineering team is and where the company is. 

It's really hard to measure in a metric sense, but I think it's easy to see. So I have on my site, somewhere decades ago, there's an old assessment tool which is really about the relationships with the other departments and how clear the strategy is. Right, yeah, so are we working well with engineering? Are we working well with design and marketing? Do we have a clear audience and segmentation? Have we figured out how this product is going to make money? Right, yeah, if you haven't done those, you're not doing product management. It's harder to measure outcomes because almost none of it's in our control, right? 

But you know one of the things I always have done here, you know. So I I parachuted into this company on a Monday, right, and, not surprisingly, I have a team of people working for me and every one of them is going to get an hour with me in the next day or two, right. And one of the questions I ask them always is well, how many customers have you talked to in the last week? Or three? Um, that weren't sales calls, where you were trying to learn from the customer, right? Do discovery? Do validation? 

Yeah, um, and and you know the ones who say none and aren't embarrassed and don't have a reason why they can't do it we joke they get an immediate promotion to some other department in the company. Because if you're a product manager and you're not directly talking first person to people who use your stuff and pay for your stuff, then I don't understand how you can know what to ask your teams to do and what problems to solve. So maybe there's an organizational barrier, they're not allowed, and then it's my job to fix that. But you know, I mean you and I have been around for a really long time. I don't think it's so hard to figure out who the product folks are just by talking to them for 15 minutes. 

What Product Leaders Owe Their Teams

0:27:31 - Rahul Abhyankar
Yeah, and you know the aspect of product managers being allowed to have those one-on-one conversations with customers. That comes back to credibility with the sales team. 

0:27:42 - Rich Mironov
Yes, and negotiating power too, right. So if the product managers tell me that they've been trying to do calls with customers for discovery and they're being blocked, well then I can't blame them for that. That becomes my problem to help solve. So how do I negotiate, for instance, with the head of sales that we're going to do a one-for-one for every sales call we do. We're also going to do a discovery call and your folks are welcome to listen in but not speak. And if we're delivering real value to the sales team on sales calls, then that's going to free that up. But I don't see individual product managers having the organizational juice to go to the VP of sales and try to negotiate that. 

0:28:26 - Rahul Abhyankar
That's great advice for people leaders in product. 

0:28:31 - Rich Mironov
I get to ask my folks what's in their way. It's like going into the retrospective, right. Yeah, what are? The two or three issues and I'm going to grab the couple that are most obvious, most easy to solve and are biggest in the way. If I can remove some obstacles for my product team, they'll be happier, more productive, more likely to stay, they're going to see me as their champion and the rest of the company is going to see more value. 

0:28:54 - Rahul Abhyankar
Yeah. So I mean that's great to be able to remove those roadblocks, but stepping back overall as people, leaders in product, what do we owe our teams? 

0:29:08 - Rich Mironov
I think we owe our teams a lot of things here, right Gosh. The first one that comes to mind for me is we owe. We have to be honest with them Right Now. Sometimes there's things happening in the company that you can't share. When somebody comes to me on my team and says I'm having trouble, doing this canceled. 

I owe my folks the straight scoop and the justification. If somebody really good is going to leave my company and I can't fix whatever it is that's causing them to leave or it's time for them. I owe them my best support when they're gone in their next job search, because they worked for me really hard and I respect them. And if they need a reference or an introduction. What do I owe them? I owe them well-structured engineering and design teams, because if engineering is all broken and organized in a bad way, product can't succeed right. 

And maybe that's fixing it myself, and maybe that's negotiating with engineering and maybe that I don't know. Whatever it is right, but we're doing a hard thing and I owe them right. We've talked about the funnel versus the umbrella. There are a lot of folks who are leaders, who are poop funnels, and when poop falls on their head, you know what it all gets funneled down to people who work for them. I think of leader jobs as the poop umbrella, and my job is to keep as much of the poop off their heads as I possibly can so they can come to work or be remote, but they can work and do good work and feel good and make a contribution and get promoted and be respected. 

0:30:58 - Rahul Abhyankar
Yeah. 

0:30:59 - Rich Mironov
And my job is to make that happen instead of be important. 

Moving Up to VP Product

0:31:02 - Rahul Abhyankar
So when you look at the mid-career product leaders the director, senior director, sure, the mid-career product leaders, the director, senior director what advice would you give them in terms of understanding what's expected of them as a VP to be able to make that career transition, and where do you see people challenged to make that transition? 

0:31:23 - Rich Mironov
Yeah, there's a question I would ask before that, which is is this really what you want? So there's a question I would ask before that, which is is this really what you want? So as you move from individual contributor to director to VP, you do a lot less product management and do a lot more communicating and merchandising and stakeholder management and politics, and the job is different. And it's not that one is better, necessarily right, but they're different. And there's a lot of folks who step into the director job and then they decide it doesn't make them happy and they demote themselves back down to senior PM or distinguished PM or whatever you've got and and try to hire their boss. So so you have to want it and then, and then we're into what I might think of as finishing school here. 

You have to. You have to talk finance with the finance folks. You have to talk sales with the sales folks. You have to talk customer with the customer folks. You have to stay on message. There's an old piece of mine I called Shoulder to Shoulder, which is in as the head of product I can argue with and shout at the head of engineering and design as much as we need to, with the doors closed. 

But when we're in the big committee meeting and the big executive meeting, engineering and product and design are going to give exactly the same answer to every question. 

They're not going to separate us or pick us apart or find any daylight between us, because otherwise we're lost, right? So how do we, you know, how do we build consensus? How do we do what's mostly the right thing it's never perfect how do we delegate all the real product work to the folks who work for us, who are so smart and hardworking, right? So you know, as you're coming up from individual contributor director to VP, your work mix changes and it's a lot more about indirectly getting things done through other people yeah, even more so than the, than the PM job itself. And then, you know, as you move up that stack, you know, when you're sitting with the board, as a CPO should, you know, you have to be very thoughtful about how boards behave and what they want to hear and how to position things to get what we need and not to shoot your career in the foot. And if that's, particularly if you're an ex-engineer, right, as many of us are. 

The way engineers talk and argue among themselves is brilliant, but it's not the way the rest of the world talks and it's not a different language, different language, and so you know. Often we talk about how product managers have to be trilingual, the way, the rest of the world talks and it's not a different language, different language, and so you know, often we talk about how product managers have to be trilingual. 

We have to speak enough engineering and design and maker that our teams understand us, respect us and don't lock us out of the stand-ups. Right, we have to speak enough end customer, whatever we're selling, that we can really deeply understand what problems they have instead of what problems they're describing, and enough basic finance that we can explain it all to our executive team in money. So in the course of a day, as you go from meeting to meeting to meeting, you want to stop for 15 seconds and remember which meeting is it. Is it the customer meeting? Is it the engineering meeting? Is it the finance meeting? Is it the sales meeting? Because you're going to say the same thing in completely different terminology and style. 

So we, as product folks, want to think about the longer term. We want to think about the market as a whole, we want to think about the whole product cycle. Again, as distinct from somebody who's being paid to close one deal with a special attached, yeah, um, we're responsible for the health and safety and growth of our products, like our children, and we want our products to grow up to be big and small and sell thousands of copies. And so how do we push back or how do we shave off the, the manual work, the one-off work, the special work, so that we can focus on scalable, repeatable, outbox standard stuff, and then we can sell another 10,000 of them without sweating. 

Identifying & Preventing Product Waste

0:35:12 - Rahul Abhyankar
Yeah, and also I guess related to that is product leaders need to be really super diligent about avoiding waste. 

0:35:19 - Rich Mironov
Yes, yes, when we're doing something for just one customer, it's probably waste. When we're doing something and we haven't done our homework or discovery, it's probably waste when we're doing something and we haven't done our homework or our discovery. It's probably waste. 

When we're thrashing and shifting teams from project A to project B to project C and none of them finish. It's complete waste. So how do we say this right? The scarcest commodity in the universe is engineering time, and you never get it back once you've spent it. So, as the head of product, I'm desperate to apply engineering to the things that matter and to let them finish and to have my team do that, so that we actually get the good outcomes that we need instead of 57 pieces of half done work in process. 

The Art of Product Management

0:36:03 - Rahul Abhyankar
You wrote the Art of Product Management. How long ago was that? 

0:36:08 - Rich Mironov
That came out in 2008, so that's 15 years. And much of the things in there came from the years 2002, 3, 4, so that's 20 years. Anybody who tells you product management's a new thing? Well, not so much. 

0:36:23 - Rahul Abhyankar
So what's new in the second edition? 

0:36:25 - Rich Mironov
Yeah, I tried to keep to the original format, which was a series of posts from the 2000s. I've got a lot of newer material but honestly, there's another couple of books in the works. So if somebody doesn't already have the first edition, I think this would be great, particularly folks new to product management or trying to get some legs under them. There's no framework, there's no sort of structural advice. It's mostly you know how to think about your job, get along a lot of emotional pieces about loving your customers and products. So I think it's an ideal intro for somebody who's new to product or thinking about it. 

0:37:06 - Rahul Abhyankar
Any stories or anecdotes that you've included in the second edition since. 

Stop Saying MVP!

0:37:11 - Rich Mironov
Yeah, there were a few. There's one piece that should have been written then and was actually written later that I decided to sort of predate about not using the acronym MVP. So this comes up all the time and the major point of the piece is everyone on your go-to-market side when they hear MVP, they focus on the P and they assume no matter what you tell them. However many times you tell them that it's a full product ready to sell, to take revenue for, and it works really well. So all of the discussions about testing and validation and incremental stuff and UI experiments is somehow lost on folks who make commission. So that piece is about how no one who works for me ever uses that acronym a second time, and it lists 10 or 15 very carefully chosen phrases that mean just what they mean, like non-revenue technical validation and flipbook, which it's really hard, even in a product seat, in a sales seat, to decide that there's revenue in it and it's really just about plain speaking. 

So how do we get out of the acronyms, how do we get out of the silliness of keywords to what our audience can really understand? That was one, and I did a bunch of extensions on some pieces there about end of lifing. So I have some good recipes for how to do that, again from the same period, but weren't in the book. So you know there's some new bits there and a new introduction, but anybody who's been using the older one, the first version, I think that's still valid. 

0:38:45 - Rahul Abhyankar
Yeah, I've gotten my copy of it and started reading, so looking forward to going through it. What I do hope is to see more of your dry humor, not less. 

0:39:01 - Rich Mironov
That's always the plan and the next big piece of writing really rolls up. For the last eight or nine years, I've been focusing on the questions of how do we make good decisions when the rest of the executive team isn't interested in the product process. So you know we had talked about some of my longstanding pieces. There's one from 2015 about the four laws of software economics. That's really held up nicely. So that's one of the spines for the next theory, and the other is the idea that we talk about money instead of internal agile, because that audience needs to hear about money. So I'm mapping out the next book and hopefully it takes a lot less than 15 years to get there. 

The Laws of Software Economics

0:39:49 - Rahul Abhyankar
Great, well, you know, can't wait for it. Thanks. Do you want to quickly summarize the four laws of software economics? 

0:39:56 - Rich Mironov
Well, just the first two are the important ones, right? So the first law of software economics is your engineering team's not big enough, right? We've all been here. Everybody believes we're five or 10% short. No, every engineering team has 20X or 50X the demands we're never going to get through the list. Right, so get over it. Right, so prioritize. And then the second one, back to economics, is all of the money in the software business is in the second copy of the bits that you sold, exactly the same way as the first copy, and every time you touch it you're going back to spending more money. So how do we sell exactly the same bits in exactly the same configuration thousands of times? Because that's how we print money in the software industry. 

0:40:40 - Rahul Abhyankar
Rich, I see that vintage Macintosh back on the shelf behind you. What's the story about that? 

0:40:45 - Rich Mironov
That's not the very first Mac which we have somewhere. That's the very first Mac that had a hard drive a 1988, a 10 megabyte hard drive which is big enough for an operating system, and it's next to the Rolodex and the manual typewriter and the hand cranked adding machine and the fountain pen and the camera that takes film and all the way in the corner the camera that takes film and all the way in the corner you can see a rotary phone. 

So this is my history shelf. But I was a Mac user in 1984 when they first launched the Mac, and I'm passionate about it. So for anybody old enough to remember, there it is. 

0:41:29 - Rahul Abhyankar
Great Rich, thank you so much for taking the time and look forward to reading all the new things that you continuously post, and thank you so much for doing so much for the community. 

0:41:34 - Rich Mironov
It's my pleasure and thanks for hosting and offline we'll get together and gossip about everything soon. 

0:41:41 - Rahul Abhyankar
Sounds good Great. 

0:41:42 - Rich Mironov
Thank you. 

Transcribed by https://podium.page