Rich Mironov

Rahul Abhyankar [00:05] 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. You've been a leading voice on product management for a really long time, lighting the path forward for many people. On behalf of the product community and personally too, I really want to thank you for that, truly.

Rich Mironov [00:30] 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.

Rahul Abhyankar [00:39] 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 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?

Rich Mironov [00:58] I think if we tell it sort of back to front historically, that might be a good way. 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.

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. 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. 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? If I were trying to price a product for the first time, how would I do it? If I were 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 and old stuff. 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. These days what I'm doing mostly is I'm coaching heads of product, I'm doing some courses for heads of product, VPs, CPOs, directors. You might be shocked to find out that almost everybody has all of the same issues and challenges. For the last half a decade or more, it really comes out of the work, and I work a lot on the 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.

Rahul Abhyankar [03:29] What are the things that you find yourself repeating more than you'd like to, perhaps?

Rich Mironov [03:36] Oh gosh, there's a few that come up almost every day. 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. My observation is that almost nobody on the go-to-market side of our companies cares about any of that.

I have a picture of Dr. Sheldon Cooper from the Big Bang Theory, 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. 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 helping with deals and market size, not about what's happening in the kitchen, 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.

That's the first one. The other one is, when we argue with our engineering teams, there's a certain way we structure arguments with engineering. We have proof. We start bottom up. 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. And it may take 25 minutes to get to the answer.

When we're working on the go-to-market side, 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. 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. Because if we all agree around the table that you got the right 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.

Again, that's about understanding your audience and what they care about. We talk about money or accounts or markets, or upsell or scalability, because that's what the go-to-market side of our companies actually cares about. Sometimes we have to go to the discussion and talk about tech debt or architecture, but honestly, a lot of it's wasted.

Rahul Abhyankar [06:21] You talk about the politics about that, and you've written about how prioritization is a political problem.

Rich Mironov [06:29] There's a couple pieces. One is, there's always a request to prioritize everything in the backlog, all 940 things. In fact, to size them all, 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. We're not going to size.

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. What a complete waste of time. 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. We're never going to get past whatever, number 30 or 35. So let's not pretend.

Then 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, how big is it and how strategic is it and what does sales and marketing want to say? 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 seven items, of which we're going to choose three, and have just a knockdown, drag out fist fight for five hours. 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. We could have a 17-column spreadsheet with weightings. There's somebody in finance who believes we can prioritize to eight decimal places. Makes no sense. 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%. 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.

Rahul Abhyankar [09:03] Rich, you've been doing product management for three decades.

Rich Mironov [09:08] 35 years.

Rahul Abhyankar [09:09] 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?

Rich Mironov [09:40] Let me segment the problem a little bit, because I think there's two poles here, there's two sets of answers. If we're in a B2C company, we're trying to sell streaming music services to 40 million people at six pounds or euros or yens or dollars a month, there's no one music subscriber who is so important to the company that the CEO has their phone number. 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. 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. 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.

In the high-end enterprise, what I find is that the sales teams discover 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. 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. So the lumpier and the larger the deals are, the harder it is, I think, to be in the product role.

Unfortunately, I'm stupid enough to have kept myself at the enterprise end of this. I see tremendous boardroom power and leadership in the B2C space and small business, SMB. If you're doing small end accounting, if you're Xero 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.

Rahul Abhyankar [12:38] And you don't see that changing?

Rich Mironov [12:41] 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 $5 million deals. 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, when JPMorgan 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.

Rahul Abhyankar [13:42] 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.

Rich Mironov [13:53] Yes. I don't have any magic there. 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. 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. 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 product 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. 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.

Rahul Abhyankar [15:07] I used to joke about this with one of my head of sales counterparts in my previous life, 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?

Rich Mironov [15:29] That's right. You've heard me tell the sort of joke survey thing here. 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. And the two reasons we lost deals this quarter are because the price was too high and we were missing a few dozen features.

That's universally true when you ask the sales team. 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.

Rahul Abhyankar You've written about merchandising product management as something, an aspect of a product leader's responsibility, that doesn't get much attention. Talk about that.

Rich Mironov Sure. I'm using merchandising in the internal sense here. How do we make visible the good things that have happened? If I'm putting on my CPO or product leader hat, 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. 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.

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. 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 the people doing the work.

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, and that we're not sitting around eating bonbons and playing Fortnite. We're actually working really hard on a bunch of things that keep adding value to the company. Notice I keep trying to attach money or outcome or customer sat to pieces of work.

Rahul Abhyankar [18:59] And that's a language that the go-to-market side of the house understands very well.

Rich Mironov [19:07] They absolutely understand. It's in their language. 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.

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

Rich Mironov [20:05] That's hard, and it's obviously specific. Just to frame up the analogy, 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.

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 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. On day one, I heard that from most of the executive team and I chatted with the engineering team. What I learned—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.

What do we do? What's the quick win? 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. They finished two little features and one bug fix. The next Monday they shipped a patch. I got to go into the executive meeting and say, hey, engineering shipped a patch on Friday. It got very quiet because everybody had this belief that engineering never shipped anything. Then it was, oh well, what did they ship? And I talked about the two little features and the one fix.

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? In one moment, we were able to undercut the theory that said engineering doesn't do anything by doing something 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?

Then I got to go down to engineering and say, you guys were the heroes today because we shipped a patch, and we're going to do one next week too. The engineering team, which had been feeling very stepped upon, badly treated, they got to be heroes. I think we brought pizza. It didn't matter. 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.

Rahul Abhyankar [23:00] Do you look at the org chart, and does that tell you anything?

Rich Mironov [23:04] Usually I look at the org chart. I don't even need to talk to anybody. 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 versus core engineering, often I can read the symptomology right off the org chart. I think of org charts as really powerful.

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. 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. It puzzles me, it really puzzles me.

Just imagine hiring a head of software engineering who'd never built software. Or a head of sales who'd never been in sales. Or a head of marketing who'd never run marketing. But somehow, anyway. 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. If the CTO actually has good product chops, that's okay. If the chief marketing officer has good product chops, that's okay. But to have a whole group of folks who don't really understand what we do, I think sets us up for some bad outcomes.

Rahul Abhyankar [25:18] When you work with companies on an interim basis, do you assess the maturity of the product organization?

Rich Mironov [25:27] 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.

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. 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? 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.

One of the things I always have done here—I parachuted into this company on a Monday, 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. One of the questions I ask them always is, well, how many customers have you talked to in the last week or three that weren't sales calls, where you were trying to learn from the customer? Do discovery, do validation. 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.

Maybe there's an organizational barrier, they're not allowed, and then it's my job to fix that. 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.

Rahul Abhyankar [27:31] 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.

Rich Mironov [27:42] Yes, and negotiating power too. 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. 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? 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.

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

Rich Mironov [28:31] I get to ask my folks what's in their way. It's like going into the retrospective. 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.

Rahul Abhyankar [28:54] 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?

Rich Mironov [29:08] I think we owe our teams a lot of things. The first one that comes to mind for me is, we have to be honest with them. 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, 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. 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. Maybe that's fixing it myself, and maybe that's negotiating with engineering. Whatever it is, we're doing a hard thing and I owe them.

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, 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. My job is to make that happen instead of be important.

Rahul Abhyankar [31:02] When you look at 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?

Rich Mironov [31:23] There's a question I would ask before that, which is, is this really what you want? 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. The job is different. It's not that one is better necessarily, but they're different. 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 try to hire their boss.

So you have to want it, and then we're into what I might think of as finishing school here. 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, 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.

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? As you're coming up from individual contributor to director to VP, your work mix changes, and it's a lot more about indirectly getting things done through other people, even more so than the PM job itself.

As you move up that stack, when you're sitting with the board, as a CPO should, 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. Particularly if you're an ex-engineer, 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. It's a different language.

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 standups. 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.

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.

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, as distinct from somebody who's being paid to close one deal with a special attached. 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. How do we push back or how do we shave off the manual work, the one-off work, the special work, so that we can focus on scalable, repeatable, out-of-box standard stuff, and then we can sell another 10,000 of them without sweating.

Rahul Abhyankar [35:12] Also related to that is product leaders need to be really super diligent about avoiding waste.

Rich Mironov [35:19] 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 thrashing and shifting teams from project A to project B to project C and none of them finish, it's complete waste.

How do we say this? The scarcest commodity in the universe is engineering time, and you never get it back once you've spent it. 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.

Rahul Abhyankar [36:03] You wrote The Art of Product Management. How long ago was that?

Rich Mironov [36:08] 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.

Rahul Abhyankar [36:23] So what's new in the second edition?

Rich Mironov [36:25] 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. 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 how to think about your job, get along, a lot of emotional pieces about loving your customers and products. I think it's an ideal intro for somebody who's new to product or thinking about it.

Rahul Abhyankar [37:06] Any stories or anecdotes that you've included in the second edition?

Rich Mironov [37:11] 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. 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. All of the discussions about testing and validation and incremental stuff and UI experiments is somehow lost on folks who make commission.

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. It's really hard, even in a product seat, in a sales seat, to decide that there's revenue in it. It's really just about plain speaking. 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. I did a bunch of extensions on some pieces there about end-of-lifing. I have some good recipes for how to do that, again from the same period, but weren't in the book. 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.

Rahul Abhyankar [38:45] 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.

Rich Mironov [39:01] That's always the plan. 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. 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. That's one of the spines for the next theory. The other is the idea that we talk about money instead of internal agile, because that audience needs to hear about money. I'm mapping out the next book, and hopefully it takes a lot less than 15 years to get there.

Rahul Abhyankar [39:49] Can't wait for it. Do you want to quickly summarize the four laws of software economics?

Rich Mironov [39:56] Just the first two are the important ones. The first law of software economics is, your engineering team's not big enough. We've all been here. Everybody believes we're 5 or 10% short. No, every engineering team has 20x or 50x the demands. We're never going to get through the list. So get over it. Prioritize.

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. 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.

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

Rich Mironov [40:45] 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. 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 you can see a rotary phone. This is my history shelf. I was a Mac user in 1984 when they first launched the Mac, and I'm passionate about it. For anybody old enough to remember, there it is.

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

Rich Mironov [41:34] It's my pleasure, and thanks for hosting. Offline we'll get together and gossip about everything soon.

Rahul Abhyankar [41:41] Sounds good. Thank you, Rich.