Blaine: Joining me today is Rich Mironov, CEO and product management guru at Mironov Consulting. As a multi-time chief product officer myself, I’ve known Rich for many years and heeded his advice on many occasions. His product bites newsletters are always full of good suggestions and best practices for product leaders and executives looking to take their software product management to the next level. And Rich literally wrote the book on the art of product management. So, thanks for the time, Rich. We’re gonna have some fun.
Rich: I’m looking forward to it.
Blaine: Excellent. So, tell us how you got to where you are today before we talk a little more about Mironov Consulting, how did you get to be such an expert in the art and science of product management?
Rich: I’d love to tell you it was a plan and that I had mapped out all the steps. Of course, it never works out that way. The very short version of this is I was at my third startup I think in 2001. It wasn’t really going at all well and I quit to take a little time off. It turned out that was September 1st of 2001 I took out of the office to take a few weeks off. Anybody who remembers that month knows that the world changed a lot on September 11th.
So, on September 12th, it turned out I was a consultant because I had a mortgage on a house in Silicon Valley and a daughter who wanted to go to college and no income. That’s pretty much the definition of the consultant. [laughter] So I hung out my shingle to figure out what I could do and really have been focusing on software product management up the stack since then. That’s almost 18 years now of mostly solo work.
Blaine: Very interesting. Tell us more about what Mironov Consulting actually does. What kind of engagements do you take and how do you help your clients?
Rich: Sure. I’m almost exclusively focused at the head of product or VP product level. Things I do here: I actually coach a fair number of VPs and heads of products. That’s a couple of hours a month of team psychiatry, I guess, what’s really going on, mostly around organizational and people issues.
Companies bring me in sometimes to do assessments or help them design their software product management organizations: how many people, what the skills are, how do we divide the work, how do we get good value and real results instead of just people in seats.
And then, sometimes, in the in the Bay Area/ San Francisco area, I will actually drop into a company as the temporary or interim head of product. Usually, that’s not a call anybody particularly wants to make because it means they’ve forgotten to have a head of product or that person left under complicated circumstances.
Blaine: In other words, they fired him.
Rich: They fired him or that person quit or whatever. Usually, that’s a mix of actually turning around the product management team and also a lot of executive coaching or counseling or whatever it takes to figure out what’s gone wrong at a systemic level. Not for the faint of heart, but fun for me.
Blaine: Yeah. Very interesting. And product management is, as we both know very well as this domain that is so critical to the success of many businesses, and yet, it hasn’t been that formalized. You don’t go to university to become a product manager. At least, I’ve never heard of that yet.
Rich: No. I actually teach a course in Dublin every year for a little bit where they have a full year course in this, but very rare to find it. What I see a lot is that, particularly at startups, but even at larger companies, there may be nobody on the executive team who’s seen good product management happen or worked with a really great head of product or senior product manager.
So, honestly, they don’t know what good looks like. They’re mostly working off of gut or some two-line job description somewhere about how product managers should or shouldn’t be the CEOs of something because product management’s not as obvious as sales: we either hit the number or not. In engineering, we either shipped or not. It’s a lot harder to put metrics on. Maybe half/60% of the folks doing product work out there I think aren’t that good. So, it’s not unusual to have a whole team of folks who don’t know what they’re supposed to be accomplishing.
Blaine: Now, product management can be applied to lots of different domains, even outside of technology, but I think a lot of what we’re talking about here is software product management or digital product management to some degree. Is that fair to say?
Rich: That is and I’ve mostly taken off of my client list folks who don’t build software directly for money. I know we’ll come back to it later in the conversation, but I think it’s really hard to introduce software as enablers in companies that are either deeply in the hardware business or deeply in the services business where it’s really a cost and they’re not used to doing what they’re doing. It takes a lot of different points of view.
Mostly these days, I work with companies that are trying to monetize their software directly because it’s way easier to connect the dots between we built something people really want to pay for and they’re paying for it.
Blaine: Well, that’s very interesting because a lot of people have been talking about how digital companies, to transform themselves, have to fundamentally become data companies and even software companies. Some have seen Marc Andreson from Andreeson Horowitz recently said, “Software is eating the world.”
Rich: Right. I believe that’s true.
Blaine: Satya Nadella from Microsoft said, “Every business will become a software business.” Talk a little bit more about that. Are you seeing that companies fundamentally need to embrace this?But I think you’re saying they need to think about it as a as core to their business, not as sort of an aside.
Rich: Right. I think it’s really hard. If you’ve been running an airline for the last 20 or 30 years and you think mostly about fuel, gates, on-time arrivals, how much luggage goes into the hold, whether it’s balanced left to right/front to back, the idea that a piece of software could dramatically transform your business is alien.
And, software itself is really squishy. If you were building an elevator, most of your focus is going to be on the mechanics and the weight and the cost of building elevators and getting them installed. The idea that a piece of software might entirely transform the elevator business is one that I think most elevator manufacturers are going to miss, even though we talk about it, it’s in every HBR review, every piece of business writing we have is about going digital.
I see most traditional companies, instead of becoming software companies, are going to fail to become software companies and we won’t remember their names anymore. I’ll give you a good example here.
I did some work seven years ago at a great, great little den startup company called Wealthfront which has automated the problem of investment portfolios. You can put your 401k money in there and their very, very smart algorithm will rebalance your portfolio every night and do all the tax loss harvesting and do all the things that humans find difficult at something like one sixteenth of the cost that Merrill Lynch charges you for bad service. They wear nice suits and nice shoes and they have offices and you can go meet with them, but if you’re in the millennial generation, honestly, those are points against, not points for.
Wealthfront and its cohort of what they call “robo advisors”, we will discover in 15 more years that they completely ate the investment market, but the Merrill Lynches of the world honestly won’t feel the pain for 10 more years because they’re still trying to sell to 40 and 50 and 60 year olds who already have savings for retirement. They’re missing the next wave of everybody who doesn’t want to do it that way and overpay for bad service and product.
So, do I think that that the bank institutions will come around? Some of them will. But, software is eating the world or maybe we will bury them, bang our shoe on the table. This is a slow-moving process until it catches you and it’s over.
Blaine: You seem to be putting out a bit of a message of despair for legacy companies that are trying to become something as a service companies and they don’t buy software or am I missreading?
Rich: Well, I think the point is that it’s hard and most of the digital transformation efforts that I see or that I am involved with don’t work out well because they’re trying to put some software icing onto some other major business instead of rethinking how real users want to interact in the world.
A positive example here just to balance it out: I now have a credit card from Capital One which is, in my view, fine, but they did this really cool bit of software when I’m logged onto their site or I’m shopping on an e-commerce site, it pops up a little widget that lets me create a one-time virtual credit card number for a particular vendor. Now, that channels back somehow so it ends up on my real credit card. But, if I sign up with a vendor that wants to charge me a bunch of things every month and I can’t cancel, I can go back to Capital One and delete that soft virtual credit card number and that vendor can’t bill me anymore.
Now, they’re in the credit card business. They’re in the finance business, but there’s a piece of innovation that actually makes my life better because we’ve all been whack a mole with the vendor who I signed up for a monthly subscription that doesn’t answer their phone, won’t cancel. Right? So that’s value to me. They’ve thought through and talked to enough folks who really use credit cards that they figured out how to help instead of just waving bonus miles in my face.
Blaine: Yeah. So, that’s an example of a company that clearly isn’t trying to become a software company, but has figured out how to use software to enable a small part of their transformation.
Rich: That’s right. And where customer experience or user experience really matters, where crisp software really matters, we’re now into a situation where most folks under 30 either will try your software on your web site or they’ll move on. So, the idea that you have a 60 or 90 or 550 day time to value that requires your customer to move mountains and invest treasury amounts is old. Folks who can’t figure out how to do an online demo of their product will be gone.
Blaine: I think that’s a very valid observation. So, whether it’s a company that’s literally trying to become a software company or they are a company that’s trying to use software as an enabler for their overall transformation, I presume you would agree they need effective product management to make that happen. What has been some of the transformation you’ve seen over the last decade, maybe in terms of the practice of product management?
Rich: I think it’s come a long way the last 10 or 15 years I think in parallel to the whole move to online in the cloud. I’m old enough to remember when we called it time sharing instead of cloud computing because that was the 70s and the 80s.
We now see that the activities of my customers are measurable. We could track everything. We’ve got real stacks of data. We can roll software out hourly or daily so things move really quickly. I’m a huge, huge fan of everything having to do with validation and lean experiments and customer development. Anybody who hasn’t been through Teresa Torres’ writings about how to really do experimentation is missing the boat.
The idea can’t be that we have this two-and-a-half-year migration project thing for ten million dollars. It’s got to be what can we do in the next seven business days that we can test and validate with real users either in paper prototype or online and figure out whether we’re right. So, deep humility tied with really good software product management tied with really great design and engineering.
What else I see in these digital transformations is a lot of intention but an unwillingness to spend to hire the best designers, product managers, developers, and engineers. What you get, by the way, isn’t very good, but you spent your money. Digital makes this just so much more essential to get great, seasoned talent.
The other thing I see too is I see on the con side here, on the warning, is it’s really easy if you’re fast and measurable and experimenting and do all this stuff and don’t really have a strategy to optimize your way out of business. So, I’m thinking the social gaming companies around 2010 who had these sort of hill climbing, follow-the-algorithm, maximize revenue of who’s going to buy my virtual tractor from my virtual farm.
What they did was they engineered themselves out of business because they engineered all the fun out of the games because every week they ratcheted up so you would be encouraged to put one more coin in. And one more friend on your social network and one more offensive thing. They drove themselves out of business.
Likewise, if I think of the YouTube challenge where the YouTube algorithms are naturally pushing people toward more extreme content. You put your kids on there and they’re watching some little games and the algorithms drive to outrage and to politics in a way that we just didn’t anticipate because we don’t have a strategy.
Blaine: Absolutely that’s happening and we see that across media of course and a lot of products these days as they become more intelligent, so to speak.
Rich: That’s right. And so I love that. I think intelligence is great and analytics are great and metrics are great, but if we don’t put our human judgment in and make sure we’re going to the right place, it inevitably takes us in some bizarre direction.
Blaine: Now back to the practice of product management, one thing you didn’t list when you were talking through some of the trends and changes even less specifically was the notion of adopting so-called agile practice versus waterfall. Is that just because it’s just so widespread and commonplace you don’t even think about it anymore or where is that in your mind?
Rich: I worked on some things that we now know to be agile in the 80s and early 90s. It wasn’t that new. At Sybase, we had automated test suites I remember in 1993. It wasn’t new. I’ve been doing the agile thing now for maybe 25 years, 20 years under the agile banner. I think it is really the only choice. Waterfall never worked even when we pretended it did. Every big project fails. Every big project is late maybe in the square of the size of the project.
But, I do see a lot of word choice around agile rather than doing agile. I see folks pick up a scrum book and follow it step-by-step and not understand that it’s just an instance of how you might approach this stuff. The ceremonies have become important and the buzz words and the one-day certifications have become important instead of what agile is really about: giving teams a mission, freeing them to experiment, putting whole teams together with great designers and great engineers and great architects and great dev ops folks, getting out of their way.
The other thing I see crushing this always is I see agile development teams and then I see executive teams that have the three-year waterfall demand model. They’re gonna come down from the mountain top with ten initiatives, each of which would consume our whole company. They then throw 5 or 10 initiatives onto their development teams and expect those folks to both build great product and retool/reengineer everything at the same time. We’ve got a lot of waterfall executive model that just doesn’t help.
Blaine: Well that’s right. Agile needs to be a company-wide practice. It’s not just a product management or product development practice.
Rich: And there’s still just so much focus on, “Did you deliver to me the thing you said you were going to deliver on September 30th because the roadmap says September 30th?” Instead of, “Did it deliver customer value, customer joy, reduce churn, faster time to value?” It’s about the outcomes and everybody still focuses on the dates and the output.
Blaine: Well, you mentioned earlier about companies sub optimizing by not having the best people in their product functions, running product management. But of course, CEOs are the best product managers, aren’t they? Aren’t they the ones who are best suited to really being the head of product management? Why hire a mini CEO to run your product when you have a real CEO who can be the product manager? And obviously, for those that don’t know what I’m riffing on, Rich wrote a very interesting article recently on the notion of CEOs are not the best product manager. So, I’d love to hear you talk on that topic a little bit.
Rich: Sure. And by the way, if I back up a step, nobody on my product team’s ever a second time told me that they’re the CEO of their product. Because the first time I take them for a walk around the block and I explain about humility and that nobody works for them and they have responsibility but no authority and they lead by example and they need to get the emotion and commitment and involvement and collaboration of all of their partners. So, they’re not the CEO of anything. They don’t get to fire anybody. The second time somebody on my team tells me that, I promote them to some other job in the company outside the product management team. So, we don’t put up with that BS in my department.
But, if we come back to CEOs, I think particularly startup CEOs, no startup has a product manager per say until they get to maybe between 12 and 20 employees. You don’t have enough people/enough scope. You don’t have a full-time product manager. Often, the folks don’t know what product management is anyway. And the CEO may have been a subject expert.
Here’s the three points I try to make with CEOs to show them that they need to delegate to their product team the same way they delegate to their finance and sales and engineering and marketing teams. CEOs will tell me first, “Oh, I talk with a lot of customers and prospects all the time. I’m the CEO.” And I agree. And then, we unpack that and we realize that most of the time, when the CEO is talking to a customer or prospect, it’s either because the sales team escalated the need for a sales call or the customer has something burning fire and it’s a dumpster fire and it’s all broken.
What that means, first of all, if I’m the CEO on the phone with a sales prospect, I never am deeply probing for needs. I’m trying to close. I’ve got my script. I know their issues. I’m trying to get them across the line to yes, tell them how great my company is. Sales calls, on average, are lousy places to figure out what customers want. They’re great places to get the customer to agree to your proposition.
Again, I get pushback from every CEO on this and so my follow up question is: when was the last time, Mr or Miss CEO, you were on the phone with a prospect and you listened for 20 minutes without interrupting other than for clarification. And the answer is, “Well, not so recently.” Because when we’re in sales mode, which is what CEOs are mostly asked to do, we’re pitching, we’re thinking of the answers, we’re responding to their issues, we’re telling them why it’s not a problem, we’re cutting them off from telling us what their real issues are so we can get to close. That’s a really, really important job of the CEO, but it’s not product management and it’s not user understanding and it’s not deep dive and it’s not unpack the problems from the symptoms.
What CEOs do when an angry customer gets off the phone having said, “I need you to add this report to your product.” The CEO writes a post-it, an e-mail, a slack, or chair ticket that says “add this report to the product.” Not “Is it the right thing?”, not “Did we have five other ways to answer the need?” Not “Did the customer misunderstand their problem?” CEOs become transmitters of individual requests. What they’re not anymore is broad perceivers of the market. They have deep, deep recency bias.
Blaine: And you’re right. They’re not understanding the overall prioritization of all the other things that are on the backend.
Rich: Now, some of them are brilliant and they may in fact be X product people who know how to do this well. But, on average, what I ask CEOs to do is to provide the same delegation and trust to their product team to figure out what the market really wants as they do to their engineering team to figure out how to build stuff and their sales team to close sales and their H.R. team to set employee policies.
Blaine: Yeah, although I think there is a difference there. Shouldn’t the CEO know what the market really needs? I get that when they’re in sales mode, they’re not doing a good job of that, but isn’t it discouraging if the CEO has never spent 20 minutes listening to what the market shows?
Rich: I think CEOs do know what the market wants in general. I think the direction we get down to product tends to be not general but very specific about individual features and functions. So, every CEO should know that everything is moving to the cloud at some rate depending on your market. But, I would rather the CEO pound on the product and engineering and marketing folks to figure out how we’re going to move to the cloud in the right steps than to write down which products need to be cloud enabled first. So, it’s a scope question.
I think the CEOs are the best judges of whether we have the right strategies and they may or may not have been the strategist, but they’re poor judges of the tradeoff between any particular feature and everything we’ve already crammed into the roadmap and promised.
A short version of a long rant of mine: CEOs and salespeople live in the end universe where yes, we’re gonna get everything on a roadmap that’s been promised AND I need this one little small thing that can’t be that hard it’s probably only 10 lines of code. We do this every week or every couple of days and there’s one more. I love them for it because it’s their job.
But, the engineering and product folks live in the exclusive universe where if we’re going to put that new thing in the plan (which is already over crammed with too many things), we have to take something else out. CEOs hate this discussion because they want there to be bountiful, endless resources. The answer is there’s never, ever, ever as much as we want on the engineering and product side. So, we must make exclusive board decisions even though we all hate it.
Rich: Not everybody can hear it. Not everybody can do it, but we must trust our product folks to come back with hard choices. We may lean in and make the hard choice for them, but telling them to do more and get more done sooner turns out not to be a very useful strategy.
Blaine: How can product folks earn the trust of CEOs or business unit leaders or the business side, though, because it’s easy to say CEOs should give them the trust, but they have to earn that trust?
Rich: They have to earn it and it’s easy to lose that trust. Two or three things I’m always coaching my heads of product to coach their product folks to do. One, is we need to attach real business outcomes to the pieces of work. If we’re going to completely rebuild the customer experience for this insurance product, we better have some prediction about how many more insurance policies we’re going to sell and we better hold ourselves to it. Because when it runs late (and by the way all projects run late), if we haven’t attached real business value of reduced churn or faster customer onboarding or better cross-sell, then our executives should cancel those projects or never approve them. We have to talk in business outcome terms.
And then, when things run late, as they always do, we have to present our executive teams with rational sets of choices. We don’t go cry and say it’s late. What we do is we say, “This is late and it’s more important than another thing. So, I recommend we postpone the other thing to finish this even though it’s late.” Or maybe we say, “It’s late and we’re going to drop some features because enough of the customers can use what’s already built. So, we’re gonna ship on time, but this particular segment or use case is going to be disappointed.” And ideally, it’s the one with less revenue attached.
Going in crying about how something didn’t turn out the way we wanted is not a way to build trust with executives. We have to treat them like adults: “Do you want the surgery or not? Here’s the drawbacks.”
Blaine: Yeah makes sense.
Rich: It’s hard to do because executives want things to go well and sometimes they do and product managers want everybody to understand what we do and nobody cares. It’s not important.
Blaine: Well, I think any business leader listening to this, and of course the vast majority of people listening to this will not be product managers and probably won’t know a lot about product managers.
Rich: Well, that shows they’re smart. [laughter] I tell people that really smart folks do product management for five or six years and then they move into some other role. That’s only important because I’ve been doing product management for 30 years, so reach your own conclusions. [Laughter]
Blaine: There you go. There you go. Well, this has been really great. Usually, toward the end, I give my guests a chance to call BS on some aspect of conventional wisdom. You’ve already called BS on a bunch of things already, I think, through this conversation, but do you have any anything else to lay on us?
Rich: Sure. Just a couple things: one is every CEO I talk to tells me that engineering is not productive enough.
Rich: Almost every time I open that box, I find that they might be wanting to be more productive, but that’s not the issue. Either we’re building lots of the wrong things or we’re cramming twice as much into the plan as we’ll ever finish, so we’re gonna be disappointed. Or, we don’t have a segmentation strategy or our pricing is broken or our internal processes are so bad that we can’t get a part number approved in six months. The easy answer of “engineering just needs to work nights and weekends” is, in my view, almost never useful and almost never right.
The back half of that, by the way, back to the previous discussion, I always hear CEOs tell me that the sales teams know what customers want. And I, instead, especially in enterprise zone, what I see is that the sales teams know what customers tell them they want and then they deeply filter that because no salesperson ever says “I lost the deal for bad salesmanship”. We always hear that the price is too high and we’re missing a few hundred features. I’m always encouraging CEOs to get an outside third party to do win/loss analysis to find out what customers really think because what bubbles up through the sales side of account reviews is deeply filtered and usually slanted. I can tell you what it is before I got there. So those are the those are my two BS items.
Blaine: Yeah and those are good ones. I’ve felt them in the past. Any technology or business predictions for 2019 or the year ahead?
Rich: By the way, I’ve been working on AI since the late 70s.
Blaine: Finally you’re getting to some value here.
Blaine: I think we’re finally going to stop talking about AI because it’s going to work. Which case, it doesn’t need a name. We’ll call it machine learning. We’ll call it whatever, but it’ll just be how we get work done. So, that’s on the positive. I think this is the year when I think we’re going to see a huge continued backlash against Facebook and other social media for enabling all of the things that we didn’t really expect to happen except the folks who expected it to happen around destructive behavior and post-truth society and everybody dressing up their Facebook feeds to impress people instead of being true. I think maybe this is the year we see that for how constructive it isn’t.
Blaine: Yep. I think those are pretty spot-on predictions. We’ll check back in a year. I think you’re gonna be right about those.
So, to wrap it up, any final takeaways or tips for business leaders that are trying to figure out how to more effectively use product management as a way to transform the business?
Rich: I think, particularly around digital transformations, if I put my leader hat on and say, “How do I push for good outcomes and good results through my product management engineering team, but in general?” One of the two for me is every time somebody proposes a really big project, I want to come back and ask what we could do in three weeks or six weeks that’s really small that shows measurable improvement, that proves out a theory and if it’s wrong, we didn’t waste a lot of time and money.
Every time somebody wants an 18-month greenfield restructuring of some application, I think it’s a mistake. And likewise, when I’m sitting with my product and engineering and digital teams, I think we want to first ask the question of “What did we learn last week?” before we ask the question of “When am I going to get a particular deliverable?”
Because if what we learned last week was that deliverable is gonna be of little value, then it lets us ask the correct follow on question which is, “Why are we still working on that thing? Shouldn’t we cancel it for a better choice?” The whole agility thing is about business thinking and business choices in the three to six to eight week phase. If you can’t get something good out of eight weeks, I would go back and shop it smaller.
Blaine: Absolutely. That is right on advice. I see that over and over and over again. Digital transformation is such a big concept that people think way too big.
Rich: We are going to boil the ocean. We’re gonna make every one of our users love us with a perfect user interface. We’re gonna use telepathy and AI to speed this along. Right?
Blaine: Yeah. Yeah.
Rich: Those are ten year projects that are going to fail.
Blaine: Yeah. Right on, Rich. I think that wraps it. So, thanks for much for joining us today on VANTIQ TV.
Rich: My pleasure!
Blaine: Great conversation. I knew it would be based on all of our past conversations. Those interested in hearing more of Rich’s insights should follow him on Twitter @richmironov and also check out his Web site and blog at mironov.com. And of course, search for his book, “The Art of Product Management” on Amazon or wherever you buy your books. You can reach out to me anytime at email@example.com. Thanks Rich.
Rich: Great. It’s my pleasure. Thanks so much.