In this episode of the Augusto Digital Insights podcast, Brian Anderson interviews Rich Mironov, a 35-year Silicon Valley veteran—of mostly B2B enterprise software.
He published a book called The Art of Product Management, Lessons from a Silicon Valley Innovator and has 19 years’ worth of blog posts on his website about trends in product management.
Brian and Rich sat down to explore more about Rich’s career, and the insights he’s gained. Today, Rich primarily does two things: serves as the interim head of product or coach product executives on how to do their job better. He considers it a matter of pride that he never gives advice he wouldn’t take himself.
Rich describes the product mindset as a mix between the customer-facing and engineering-facing parts of the job. He notes that he expects both his product managers and himself to spend half their time with real users, discovering what’s important, needed, and going to move the needle. The other half is inward facing, communicating with development and engineering teams to collectively figure out how to fix the problem.
He goes on to explain the importance in having multiple people from different perspectives at the table when beginning a project—at minimum, a product person, a designer, and a developer—so they can notice unique issues, fallacies, and solutions.
Rich continues to highlight the importance of meeting with real users, providing an example of a company that makes cancer therapy machines. Each year, the organization brings in cancer survivors to share their stories and, according to Rich, “You’ve never seen a bunch of software specialists and physicists work harder for the next three months than when they’re coming to work to save lives.”
We thank Rich for his time on the Augusto Podcast and wish him the best of luck in all his future roles!
Brian: This is the Augusto Digital Insights Podcast. And I’m your host, Brian Anderson.
Here, we talk to industry leaders about how they’re using digital technology to transform their businesses. There’s a lot to cover here. So let’s get started.
Hi, everyone, welcome to the Augusto Digital Product Insights podcast, episode number two.
Our guest today is Rich Mironov. Now, I met Rich last year in Cleveland, Ohio at the Industry Conference. Rich was one of my favorite people to talk to at that conference. I quickly recognized how deep Rich is in product management.
Rich also has a book that is called the Art of Product Management, Lessons From a Silicon Valley Innovator. Lots of experiences, from well-funded startups in Silicon Valley to enterprises nationally, and I think globally.
Hi, Rich. Welcome to the show.
Rich: Thanks for letting me join in.
Brian: Please, introduce yourself and maybe just tell us a little bit about your journey into product.
Rich: Okay, so I’m a 35 year veteran out here in Silicon Valley of mostly B2B enterprise software. I was a developer way, way, way back in the day, but dropped out to move over onto the product management side of the house. Actually in those days, we used to say that developers had to have really good upper body strength because first you had to carve your code into the stone tablets. This was before electricity, and then you had to carry them over to the compiler.
So, I go way, way back to the punch card days to the paper tape days, but I’ve been doing the product management side of enterprise products, now for a long time, moved up into a bunch of VP and product and CPO jobs. And a couple of CEO stops along the way. These days, the two things I do, one is I drop into companies sometimes as the interim head of product. So that’s when there isn’t somebody in that job where it’s empty and we really need to clean up a lot of organizational and product mess.
The other is I coach heads of product and product execs on how to do their job better. So, I’m never willing to give somebody advice that I wouldn’t take myself. So it’s a matter of pride that I’m willing to drop into a company and try and straighten out the product function.
Brian: That’s great. That’s great. Let me ask you a question. Rich, when you hear somebody say the word product mindset, what do you think?
Rich: I think for me, it’s a balance between really two different things: inbound and outbound, or a customer-facing and an engineering-facing part of the job.
I expect my product managers and myself to spend about half of our time with real customers and users and discovery in the field to find out what’s really, really important and needed, and it’s going to move the needle. And about half our time inward-facing with our development or engineering teams, communicating first, the problem, not the solution, and then collectively figuring out how we’re going to fix that. So it’s really important to put those two things together.
A lot of folks who come up on the Scrum side of life and don’t see really well-functioning organizations think that the product folks just sit with engineering and write stories. But for me, it’s clear, that’s a failure because if you’re not spending a tremendous amount of your time, face to face with the folks who are going to use this stuff, then you’re probably building the wrong thing. And so if we separate the engineering mindset from the product mindset carefully, right, engineering is always being pushed to do more faster with higher quality.
On the product side, the most important things are, are we prioritizing the number one thing first and pushing everything else out of the way so we can finish it. And are we really sure that when we’re done, it’s going to make a real impact in the world—real value, real users, real revenue.
So, the product folks have to really internalize. We have to live life, walk in the paces of the end folks who are going to use our stuff, or most of what we’re going to do is wasted.
Brian: Yeah, that’s really interesting. Well, how do you think hypotheses play into that thinking?
Rich: I think it’s really important, hypothesis is really important, but we have to add humility right next to that.
Traditionally, if we’re subject experts, we believe we’re right, and we know what’s true in the world. And I observed that I’m never more than half right on any of these.
Now I’ve been doing it a really long time. Most folks who come at this as subject experts, aren’t great at systems thinking or software thinking and put their own point of view ahead of all the real users. And so that ages off really fast, or they’re thinking about maybe only experts like themselves.
So a hypothesis is good, but then you have to do the thing the hypothesis implies, which is you have to go out and test your theory with dozens and dozens of folks who are in your target audience. By the way, it’s not showing them your thing and asking if they like it, because most people are polite enough to say, yes.
It’s spending the first half of that hour, probing a lot on why they have the problem, what they’ve done, how they measure success, what good looks like having them walk you through their current stuff. It’s not about proving to yourself you’re right, because that’s easy to do. It’s about trying to prove you’re wrong.
How do we knock down that hypothesis? How do we find out which half of it is incorrect? So that when we finally get around to doing the expensive engineering work, we’re much more likely to be building things that the world loves and cares about.
Brian: How much, from your perspective does engineering play into that early, like you mentioned the early part of it. When we do the expensive engineering work, when does engineering in your mind come into play versus a product and the experimentation?
Rich Yeah, This is in phases, right? And it’s peeling the onion. So let’s go all the way to the beginning.
I, as a product person, have to have some theories, some hypothesis that the world needs something right? We’re best served if, in that early discovery set of interviews and exploration, there’s probably three of us along.
There’s a product person who may be thinking a lot about economics and market sizing and how we’re going to extract money from folks. But there’s also probably a designer, a UX workflow graphic thinker who’s going to be looking much more carefully at what they do today and what they call things and how does it work or not work so that when we do design later, it’ll be useful.
And then I also want somebody who’s an architect or a senior developer along because they’re going to be listening for another set of things around data structures and repeatability and scale and performance.
So when we bring the three of us out there with six ears, right, three sets of ears, we actually hear very different things. And then we get back and we huddle.
So rather than the sort of classic MBA-driven, I’m the product manager, I beat my chest and tell people, I’m the smartest person in the room. Right? I went to famous universities, whatever. And then I do all that myself and come back with what I believe to be the answer, right? That’s less good. It’s expensive. You make a lot of mistakes, but it also leaves the rest of the team by the side of the road. Right?
So if there’s two or three of us who were collectively listening, who are trying to understand what’s going on and spot our own fallacies or lack of terminology or whatever it is, we’re going to come back with a really clear sense of what’s broken.
If we have a bunch of folks in some healthcare application who have two unintegrated applications and they’re printing out or copying data from one onto a piece of paper and then walking over to the other desk and re-keying it, right. Well clearly that’s a problem, but we could solve that in a lot of ways.
And the answer may not be obvious until we dig deep into the systems and the issues and the HIPAA compliance, all this other stuff, right. I don’t want to be the one who has to channel all the perfect answers. I want somebody from each of our disciplines along.
And then we come back and then we sit with the whole team and we argue and we whiteboard and we spitball and we put post-it notes up, whatever we do, right? Because now we’ve got all the smart kids in the room and the smartest answer may not come from any of the three of us who were out in the field.
Right. That’s why we brought everybody together. And so we get better alignment. We get better design, we get better answers.
Now we go to phase two, which is we bring that hypothetical solution back to a bunch of folks and we show it to them. Now we learn a whole bunch of other things like that’s not allowed here, or we don’t have those devices, or I don’t know the answers to the questions that you’re trying to have me put into the boxes, or social security numbers are nine digits, not six digits. When we moved from ICD-9 to ICD-10, we have all these new codes and you’re using the wrong ones in the wrong order.
So, first we’re going to go out and try to figure out what’s broken and maybe what’s needed, what the problem is. Second, we’re going to go out and revalidate our solution. And then we’re going to start spending the real money on building.
Brian: How, do you do some of that early validation of a solution? Once you guys have come up with a solution, what are the tools that you used to get people to understand what you’re saying?
Rich: I’m looking for the simplest things you could have, a basic sketch, right? A piece of paper, a whiteboard. You might go as far as mocking up some web UI thing. But, again, I think there’s a lot of waste there.
If we can sketch things out on pieces of paper and give the folks at the other end of the table, markers or pens, ideally one of those is a red marker. And have them slash through it and say “Okay, you’ve got your six step workflow here, but step three doesn’t make any sense. It’s in the wrong order. Right? You can’t do that. That’s not how we do business here.
And again, what we’re trying to do is we’re trying to spend the least amount of money and the least amount of time to get the most feedback and going into the engineering cycle and building it all and having a beta product is expensive and wasteful, when it turns out, we didn’t really understand it.
Brian: Right? Yeah, totally agree. It’s low fidelity.
Rich: It’s low fidelity, that’s right. Now, if it’s something really fancy if you’re doing some work for a bank, that’s very brand conscious, well, maybe you do the low fidelity stuff. And then you do a high fidelity mock-up just for the bank folks who need to know that the logo is in the right place at the right color. Nobody else cares. So you might do some high fidelity stuff also, but almost all the value is in the low fidelity. It’s in the sketch. It’s in the realization.
I have this dent in my forehead from 35 years of slapping myself on the forehead and being surprised at things I should have known, because every time I go out in the field with a hypothesis that I believe is really good, and I’ve done a couple of hundred of these, I’m humbled to learn some things about some new market that everybody in that market knew, and I just didn’t know. Right? How do we say $300,000? It’s getting out ahead with low fidelity mock-ups or prototypes or whatever you want to call them.
Brian: Yeah. Yep. Yep. I see that. That’s what I think too. Let me ask you a little bit about that relationship between product management and product engineering. What makes it really good? When is it really good?
Rich: I think there’s a lot of collaboration and teamwork here, but if I go back to first principles, you may know this, not everybody knows this, but all developers and all engineering folks are smarter than all product managers. And we know this because we asked them and they tell us, right?
And so the idea that I, as a product manager, I’m going to wheel myself into the room and give a lecture about how smart I am and how I know this stuff is the wrong way to keep their hearts and minds. I may occasionally be smart, but I’ll never admit it when they’re in the room. I may spot some things that I think are technically wrong or incorrect, but I’m always humble and ask it as a question or lead around slowly, because I don’t want to be the person telling the developers that they’re wrong.
Right. And a lot of this I think is about helping share empathy for the end user. So, I’ll give you an example with some folks out in Los Angeles, I worked, years ago, the biggest firm that does payrolls for studios and television production and such, and that’s a weird corner market, but it turns out if you’re an extra or a grip where you do a lot of work with different shows, you get one paycheck at the end of the month from these folks, but it may be a roll up from six studios. And we were trying to figure out who are the people who really use this stuff and why do they love us? And turns out there’s some junior set accountant or location shoot accountant, who records when people show up and when they go and their hours.
And those are the people who really care because every week or two, somebody will come up and say I’m just an extra, but thanks for getting the paycheck to me this week, because I could put food on the table for my kids, work two fewer shifts at Starbucks, right? And the developers really thought that what they were doing was writing SQL statements and putting layouts and stuff together. But when we piped in interviews or recordings with the people who use their product every day and gave them names.
Now everybody starts to care about the people at the other end of what they’re doing. They have a voice in their head. They have a vision or a picture in their head. And so they come to work, not just to write code, they come to work because they know that somebody down the line is going to be helping the extras and the grips on the set put food on the table for their kids.
And they work harder and they work smarter and they put fewer bugs in and they fix them when they’re broken. Not because we’re paying them to write code, but because we’re putting a mission in right? We’re showing them why it matters to somebody at the other end, who’s going to love their stuff. Right?
And so I see, great teams are the ones where we’ve all started channeling the real users. And we argue about what’s good for them. And whether we’re doing what they need.
Brian: Yeah. Mike Belsito said something similar. He said, it’s like the whole team is focused on the why, understanding the why.
Rich: Yeah. Right. And the product manager needs to be humble enough to get out of the way on the what for most of the time. But it’s all about the why. It’s all about the mission.
I had a chance some years ago to visit the folks at Varian Associates in Palo Alto who make these $10 million cancer therapy machines, the proton beams. And they fly some folks in every year to their employee meetings who get up on stage one at a time and say, “Hey, I’m from Stockholm, Sweden. And I had pancreatic cancer. And I went to a hospital in Stockholm that used your machine. And I’m on stage today because you people in this audience saved my life.”
You’ve never seen a bunch of software and physicists work harder for the next three months than when they’re coming to work to save lives. That’s a great team. And that’s great product management because everything that comes out of it is better.
Brian: Yeah. Yeah, I love that. Okay. Well, let’s talk about when it’s bad.
Rich: Okay. Oh, gosh. There’s so many ways it’s bad. I’ll just reel off a few.
One is that the senior execs of the company believe they know exactly what customers want. They’re mostly wrong. They’re mostly reacting to incoming sales demands that are poorly understood. So, somebody, five steps away wrote a thing on a post-it note that said they need better reports. And the CEO walks into the engineering team with the post-it note that says, “This is the most important thing and I need by Friday.”
It makes no sense. Nobody understands it. And that’s a Tuesday. And then on Thursday, the same CEO comes in with a new post-it note, got off a different phone call and says, “Oh this is the most important thing we have to do. We have to work on the backend synchronization.”
And the team is frustrated because they never finish anything. They’re frustrated because there’s no context. They’re frustrated because mostly the things they build are wrong because they’re not well understood or problems or respects.
And the executive team is frustrated because engineering never finishes anything—without looking in the mirror to say, “We are the number one reason why engineering never gets to the end of the week.”
Brian: Yeah, and then that morale starts to degrade over time, too and there’s all this stuff happening—conversations between the engineers that are not healthy.
Rich: And depends where you are, but here in San Francisco where there’s something like 50,000 open jobs for software developers, and you can walk across the street and get a raise, right? People don’t just come to work because you pay them. They come to work because it matters. And in the organizations that have really bad leadership or can’t prioritize, or every two days they shake the box or there’s a lot of blame, the development teams just pick up and leave. They don’t need this. And then we end up with a cycle of backfills and tech debt and all this other stuff.
Brian: Yeah. Yeah. That’s super interesting. Anything else that makes it really bad?
Rich: I think there’s a lot of folks who believe they know how to build technology, how to build products. Most of them don’t. And so there’s this, I love it when I hear the words just, and only as in, “Can’t we just slip this thing into the current sprint because I bet it’s not so big and I really need it. And I think it’s important and I bet it’s only 10 lines of code.”
Right? And when you’ve got a bunch of non-technical, maybe sales folks or BD folks, or whoever, who come in and say, “Oh yeah, this can’t be that hard, because my prospect told me it wasn’t hard, and here’s the post-it note. And by the way, I’ve already promised it and put it in the contract. So I need it by five o’clock today.” And it’s something simple, let’s say teleportation, right. How hard could it be?
That it’s only 10 lines of code. I need it by Friday. Everybody wants it. And so when I see the driver sip of all the decisions and roadmaps coming from the non-technical, sales side of the house, I know we’ve got a stack of very frustrated people and the designers and the developers and the product managers all have one foot out the door. Life’s too short.
Brian: What about sourcing? Augusto is a product engineering company, and there are companies that hire us to be their product engineering teams. What do you see when people are sourcing these engineering teams that are aligned with product managers? What makes it good?
Rich: Yeah. Your most immediate client on the other side, the product manager it’s really good. If that person deeply understands what it means to build software and is willing to make hard trade-offs and priority calls.
I see folks, for instance, there’s product managers from kinds of walks of life. If you came out of the hard goods manufacturing you’re making Yale bicycle locks, right? Or you’re doing food preparation, you’re making frozen foods in your factory.
Most of those folks have a very, very poor idea of what it means to build tech. And they’re all on a sort of per unit revenue margin model, right. We need to reduce the cost of the food we’re building, because then we make higher margins, and they bring a lot of really weird points of view toward product management for software, because that doesn’t work.
So, the good ones are the ones who trust the team, stay in close contact.
They should be doing a lot of the product owner work that falls in there, which is looking at this week’s work and checking and making sure it’s still what we wanted.
But back to my original point, they also need to make sure that the thing that we’re building is the right stuff. So, when we go outside for engineering, the engineering team has to assume that the thing we’re building is going to be useful and valuable.
They’re not going to do their own discovery, but if we build something that’s not valuable, it’s a hundred percent waste. Even our client paid us for it. And we met our goal because we delivered it on time. If it doesn’t deliver real end user joy or cost savings, then your product manager asked for the wrong thing.
So, that tight bond between, I’m going to share a lot of context, I’m going to pipe in interviews. I’m going to make sure that the thing I’m asking for is actually what I need and want, where I see a lot of falling down on the sourcing side, because we do just what they ask us to do, then the world doesn’t care.
And we take a lot of feedback about how the thing we built isn’t that useful. Okay. Where did that go wrong? So, how do we get a really close, personal daily relationship with the product person on the client side rather than, “Well, here’s the 20 page spec and I need it by September.”
Brian: Yeah. Totally agree. Yeah, understanding that why, if I’m translating what you’re saying, understand that why, having that relationship, you want your engineering team to be someone that you trust, right?
Rich: That’s right. Yeah. Another good indicator that it’s going well is when the engineering team comes back, as they always do, and say, “Well, that thing you asked for is harder and it’s going to be longer and more expensive.” First on my side, I have to trust them, right? It’s not just running up the bills.
And then we collectively have to decide what to do. Are we going to do a simpler thing? Are we going to push the date back? Are we going to rearrange our priorities?
Brian: Do we need to spend more?
Rich: …Spend more. Can we find another way to do this? Can we do two phases? And the first phase is good for them for half our users, right. There’s choices to be made.
Instead of “you guys signed a contract and you set that on 10:35 AM on September 14th, you’re going to give me everything in that stack and it’s going to be perfect, right?” Never happens.
Brian: Never happens.
Rich: Never happens.
Brian: And when you are in those situations, it’s never a win-win, it’s…
Rich: Right. Right.
Brian: It’s either a lose lose, or one side is winning the other side, losing.
Rich: That’s right. And so the folks who think that building software is like putting up a fence, right? Oh, you’re going to dig some holes and you’re going to put posts in and everybody can estimate how much materials and how long it’s going to take, and how many people, why is building software harder than building a fence?
It turns out that it’s much more like writing a hit song for the radio. We put all the notes on the page and we gave you three choruses, but it’s a really dumb song and nobody wants to sing it.
Brian: It’s so true.
Rich: It’s so true. But if you have this very mechanical view, okay, it’s going to be $109,000, and it’s going to take exactly this many days in the weeks and everything in my spec is perfect. Then as a client, you’re always disappointed because software just simply doesn’t work that way.
Brian: Right. Yes. Yeah. I agree with you.
That’s great wisdom and hard always to talk to clients about this, that aren’t as open to that thinking. They’ll come with a budget in mind, we’ll ask them what the budget is.
And then they’ll go, “Oh, I don’t want to tell you that”, then you give them a budget. They’re like, “Well, okay, well, that’s all we want to spend. That’s at the top end of our budget. How are we going to do that?”
And it’s like, you’re talking about the wrong thing.
Rich: Right. And it’s top of mind.
But I’m thinking about the app that just got fielded in Iowa to roll up delegates from the primary. And I’m guessing the folks who built it didn’t know what they were doing, and collectively, it was just a horror show.
I find software to be subtle and complicated.
A lot of clients don’t understand technical debt. They don’t understand that software ages and stops working and it’s in an ecosystem. They don’t understand why their data isn’t clean. And so if your, if your primary contact on the client side, doesn’t appreciate what you do and doesn’t understand why it’s hard, then you’re in this cycle of trying to teach them while doing the work. And that’s just really hard.
Brian: Yeah. That’s super interesting. Rich, what are you doing these days? And how can people leverage your services and your wisdom?
Rich: Sure. Easiest thing. And if you could include the link in the stuff, that’ll be easier, because my name’s hard to spell, but I have 19 years worth of blog posts on my website and something like a hundred talks and podcasts and such, and they’re all free. And they’re all about how to think about the world in a product way. So people should just grab that.
Of course, if they want to buy a copy of my book, that’s fine. The book goes all the way back to 2008, one of the very first books on stuff for product management.
But I try to clear my head about once a month, put out a thousand words or 2000 words on something that’s really coming up in my client engagements. That’s a pattern so that everybody else can see the pattern.
Something that makes me really happy every once in a while is I’ll get a note from a product manager who finally notices that the problem they’re having isn’t just their. It’s not because they could be taller, and younger and better looking and run a three minute mile, they wouldn’t have this problem.
It’s that all product managers struggle with priorities and all product managers struggle with budgets and all product managers struggle with engineering, figuring out something’s going to be later. And all product managers struggle with getting customers to migrate to the new thing.
And once you see that it’s a pattern, that’s not about you personally, then you get to get your ego out of the way and say, “Well, how do other people deal with this?” Right? Not, “I’m at fault. I wish I were better and stronger and smarter.” It’s not it. So I think folks sometimes wander through a lot of my writings and they recognize their own situation. And it’s a load off their back because it doesn’t have to be about you. It’s about organizations and the situation and getting stuff done.
Brian: That’s great. That’s great. We’ll definitely include the link.
Rich: And then the other thing I do sometimes, and it’s really only in the San Francisco Bay area, but if somebody has a company that forgot to have a head of product.
Brian: That happens?
Rich: All the time, it keeps me busy. So people call me up to come in for three months or five months, get it all working, get it straightened out, and then help them hire the full-time head of product that they should have hired, but didn’t.
Brian: Cool. Great. Well, thanks very much Rich for being on the show and I appreciate all of your insights and wisdom, and looking forward to seeing you in the future.
Rich: Good. It’s my pleasure. And you guys are doing really good work, so keep it up.
Brian: Hey, thanks for listening to the Augusto Digital Insights Podcast. Augusto is a custom software design and development company.
If we can help you on your next project or you just want to say hello, contact me today by calling (616) 427-1914 or visit www.augustodigital.com.
Remember, you can always find this podcast on iTunes, Spotify, Google, and YouTube.
Want to learn more or work on an idea together? We start our engagements with an intro call.
Schedule one today to see how our product centric approach can revolutionize your process.