Are sales or customers more forgiving of your roadmap? | Rich Mironov
In episode 7 of Talking Roadmaps, Phil Hornby interviews Rich Mironov, a seasoned Silicon Valley product management expert. They discuss the intricacies of balancing sales and customer expectations in product roadmaps, the importance of cross-functional collaboration, and how to build effective product management teams. Rich also shares insights from his extensive career, including his experience as an interim Head of Product and his focus on organizational issues.
Rich is a 35-year veteran of Silicon Valley product management, including six startups. When he's not coaching product leaders or helping design software product organizations, he is a smokejumper product executive – parachuting into software companies to run product teams on an interim basis. Rich founded Product Camp, has been blogging about software product management since 2002 and his "Art of Product Management" was one of the first books on the subject.
“Customers are more forgiving about roadmaps than sales teams”
Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
The next episode will return to talking to thought leaders. We have Tim Herbig, Product Coach and Consultant, coming in Episode 8 so watch out for the next episode!
-
Really pleased to have Rich Mironov here with us today, the CPO Smoke jumper. As always, I would like you to subscribe, hit that bell icon, all those mandatory things on a YouTube channel, and hopefully we're going to have a great conversation here today. Rich, maybe you can introduce yourself.
Sure. I'm a nearly 40 year veteran of enterprise software product management. So for anybody who thought this was a new thing, not so much six startups along the way, a couple of companies you would've heard of. And for the last, oh, I don't know, 20 years I've been independent. So that's me coaching heads of product, occasionally dropping into companies as the interim head of product. That's the smoke jumper job you referred to. I do focus a lot these days on organisational issues. How do we put product management teams together, helping my clients hire in the right head of product or VP or CPO. And I think a lot about cross-functional collaboration and cooperation, particularly at enterprise software companies where, for instance, the sales team is really paid every day to subvert and break the roadmap on behalf of individual customers.
So true, so true. So it's sometimes called the rhino in that sense, the really high next opportunity.
That's right. And the other phrase we use a lot is roadmap amnesia. And roadmap amnesia is what happens between when you present the roadmap as it's been agreed. And your lead salespeople get off the phone with any customer who wants anything, all memory is flushed, and they come into the next meeting thinking that engineering's not actually working on anything and that whatever they want to do is pretty easy. So we just slip it into next week's sprint.
Oh, I love it. I've never heard that phrase before. I'm amazed I haven't, but it's a great one. I am going to be stealing that one, I'm sure.
There you go.
So I guess let's start with some really fundamentals of roadmaps, because obviously that's our kind of central subject.
Sure.
What's the purpose and who are the audience of roadmap in your world?
That's a good question. A hard question, and I actually think there's not a single specific audience for roadmaps. There's lots of audiences and because of that, and those audiences actually want completely different things out of these discussions. So I think the idea that there's one roadmap that everybody's going to like, I guess that's the one roadmap to rule them all just doesn't work for me, doesn't make any sense. So we as product folks have to be thinking about the different half dozen audiences and what each of them is trying to accomplish or get out of our conversation, and we may in fact have five or six different representations of the same plan that make sense for our different audiences.
I think that tallies up exactly what I said, and when my cohost interviewed me, I said one version with multiple views. I think I'm working on five views nominally these days, but sounds like you might have a few more.
Well, and when we say views, that's okay, but honestly, for all of the roadmapping tools out there, which give permissions to folks outside product and engineering to look at roadmaps, I almost never find anyone in the company who ever uses those links to ever look at my representation of the roadmap. So when we talk about views, I think we're really talking about delivering different versions or different slices or different subsets in some setting. The idea that we're going to have a roadmap living in some piece of software and the rest of the company is going to be self-service. I've just never seen that work. So true. I've never seen that be true.
Yeah, yeah. I think I have this aspiration that maybe one day it will happen, but I think the reality check is it probably will. Well,
I'm sure someday it'll happen. I haven't been in the game that long, so maybe the 40 years I've spent trying to do this isn't enough and somebody will get there soon.
Maybe. I mean, maybe you could just break down some of those different audiences and kind of what they're looking for
And let's back up for a minute to what I think a roadmap is for sure. Okay. So for me it's a representation of the current agreed upon plan the minute we as an organisation, change our plan while the roadmap's out of date. And I don't think the roadmap itself is actually an objective. Nobody congratulates me for having a roadmap. So I think we have to get a little less emotional about it. And then for instance, there's some version of this that we work directly with our engineers or developers and designers on, which has lots of detail and dependencies and keywords and all this stuff, and goes very deep and has everything we're working on. If I think about a version of the roadmap for marketing, and here my context is mostly again enterprise software companies. So marketing is going to be out there trying to get folks into our webinars and excited about what we're doing, what they really want is the headline, the name of the release or the product and a couple of benefits.
Do they care what it does? No, they don't. Right. And vague enough delivery times that we can organise outreach or lead gen or training or whatever it is for the things we're doing, but they're mostly empty containers. So marketing wants to know what to say about the next feature or release or capability, but they're never going to use it. So it's headlines, right? Yeah. The sales organisation, usually there's two sorts here. So there's the half of the sales organisation that actually sees on the roadmap the things that they think their customers need. And so all their questions are about delivery dates. How soon can I collect money for this revenue? And whatever answer we give them, why can't it be a month earlier, if not
Three,
If not three, if not today. So again, what the product does is much less important than when I can charge money for it. The other thing I see, especially in enterprise space is I know that every single sales rep in my company has a list of features which are not on the roadmap, which some big customer or other has at some point threatened to not sign a deal for if we don't do so. The immediate reaction from the other half of the sales team is what about items one through 690 that I personally need to hit my quota this quarter because I'm the most important person at the company and my time is worth more than yours?
Where did those things go? Because I filled out all the forms to demand new features, yet they didn't show up on the roadmap. Clearly your roadmap is broken, and when I say no, it's not. Usually the next question is, so what's your boss's phone number or email again, because I need to go over your head and escalate to get this done. So true, so true, so true. The finance team really just wants to know what it's going to cost to build things and when it's going to arrive. And they have this odd idea that we can be exact to say six or 12 decimal places.
Who else am I missing support or customer success or any of the implementation teams. They actually want to know how this stuff is going to work. So rather than just the roadmap, what they want is six hours of hands-on training so that they know what to do when this stuff arrives. And the reason to think about this on a departmental basis is no two of those groups actually want the same set of information from me, so I might be able to jam it into one diagram, but I probably need versions of this that match my audiences. And I forgot one. Of course, as a product person, we have customers. I was going to
Ask you about that one. If it didn't come up, it felt like we weren't going to get there.
We weren't going to get there. And honestly, I see most customers as being much more thoughtful and forgiving than my sales team is. And mostly I think what my customers want from the roadmap presentation is they want to know that they're not going to be embarrassed by having bought a product which is dead on arrival, or they have to swap out and lose all their political capital to go through another review cycle for replacement products. They just want to know that we're going to do good work and we have something for them,
And hopefully not too much pain on that implementation as well. And for that first few months of using it, it's not hassle to get going.
And as product folks, we should be laser focused on that, which is if I can figure out how to make our product 25% faster to deploy or integrate or use, we better do that because our competitors are going to do that as well. And customers don't pay us money to sit in the implementation queue for six months.
I mean, I remember training a company a few years ago where they talked about a five week deployment process, and I said, oh, cut that slow. In my head, I'm thinking one click deployment. They said, no, you don't understand. Our nearest competitors takes a year. It's like, oh my God, you've got a strategic differentiator then.
That's right. And if you're doing a relatively lightweight consumer software, if you're building a dating app, then people need to be able to run that thing in three clicks or less. But if you're putting up some big data analytics thing that has a dashboard in the back, then it's probably going to take more than 10 minutes.
Yeah, I mean think it was an enterprise grid content management platform, for
Example, right? So five weeks sounds great. In fact, my guess is that three of those weeks we're waiting for the customer's IT group to get you a password so you could make an update through their firewall
Probably. So we know who it's for, we know what it's for, who owns it and who maintains it.
I'm a strong believer that the product management team owns it and maintains it. We don't really have complete authority over it, so everyone in the company has some point of view and maybe a higher pay grade than mine. So we're constantly fending off opportunities to change the roadmap and new ideas and interrupts and such, but I don't really want my engineering team to own it because there's a lot of subtlety in how we describe it to the world and they'll get in trouble, but the closer to the folks who are building it as possible.
Yep,
Totally agree. So I give it to product management in deeply dysfunctional organisations. Almost anybody might own it with deeply dysfunctional results
And well, they'll get to a destination whether it's the right destination.
That's right, that's right. Which is useful I think because a lot of folks aren't clear on how product managers add value to the world. And in my, again, strongly held view, we don't make engineering work harder or faster. Okay, that's just wrong. First of all, we can't do it. Second of all, they won't let us, right? So the idea that product management's job is to stand over the developers with whips in our hands is wrong in every direction. What we are responsible for is getting more value out of the work they do. So when we look at the roadmap, when we look at the choices we're making, our priorities, our value, the way product management adds value is we're smart enough to do good discovery and validation and throw away the half of the stuff that was proposed that won't accomplish anything or add any value to anyone. And if we can throw away the half, that's useless, we actually get twice as much out of engineering that's valuable without having them work weekends and nights.
Sure. Yeah. I mean, one of the things I often talk about is how about a day's worth of product management effort equates to probably in the order magnitude of 30 days worth of engineering or r and d effort, at least that sort of leverage. And so if we're not directing them at the right problems, they're wasting a lot of time on the wrong things.
Indeed, my own number suggest that if you have a development team without a product manager, they're probably wasting about a third to a half of their time, not because they're not doing good work, but because it doesn't matter.
And I guess mine is if they're going to get some of that right, but they're going to spend a lot of time on things that are maybe in the right direction.
Absolutely. Right? Sure.
So obviously there's going to be a load of other artefacts around the roadmap, things like vision, strategy, objectives, dare I say OKRs,
You
Dare. How do things, all things interrelate into a roadmap.
So I actually think of it the other way. I think the roadmap comes later. If we're doing a big piece of work and we don't have some of those other assets, who is it for precisely and what are the outcomes we're trying to generate? Is this a new piece of tech to reduce churn in our current customer base or increase our user satisfaction by getting rid of some ugly stuff or opening up a new market or reducing tech debt? If we're not clear on why we're doing something that's upfront, that's the definition of waste. So if we think of the roadmap as probably having some swim lanes or some kind of thematic structure, then we're actually going to have different audiences for the different swim lanes and different content in each of those. So we might have a tech debt, architecture and quality swim lane. And then the hint there is that most of the things in there should probably match our theme. And then one hopes, and so I don't care what we call them, tickets, stories, epics, PRDs, choose your favourite two to 10 letter acronym should probably be the thing that's upfront that describes goals and outcomes and why we should bother. And then if you've done a good job of that, then the roadmap might only be the name of the item and a link to the rest of the dogs.
I mean, something has to be the master here or the primary source of data. So I'm used to roadmaps being highly variable. We do a lot of edits on roadmaps, so I think I want as little as possible on there if the folks looking at it can then vector off to find the more data.
In fact, funny if you're getting into what I was going to ask you next key elements of what's on there. So you've talked about it being quite minimal, but almost linking out to other assets that have more detail. What might that structure look like though if we were looking at even that minimal visual?
For me, I'm thinking of two or three or four swim lanes or themes across the top. You've got vague timelines. There's nothing that's precise about this, but for instance, we might have current quarter next quarter and then some much bigger slices for the first half of next year or maybe forever. So the idea that there's precision here is wrong. And then in the near term stuff, I usually like to represent them in a way that shows off uncertainty. So in the current quarter, all the boxes have heavy borders and dark type and shading, and it's really obvious that we're serious about it. But as you move out into the later time periods, for instance, I'd like to use dashed lines or cloud shapes, those clearly communicate that. Honestly, we don't know. We have a name, we have a hope, we have a vague date, but you may not know this, but all software projects run 40% late, even if you include the 40%.
I forget which rule it is, but work take time allowed. That's right.
That's right.
Yeah. But everything always moves to the right in terms of delivery.
That's right. Now, I did work on a project in I'm thinking 1995. I worked on a project at Side Ibase in the early days of the database wars that came in on time, on budget, on spec, and customers loved it. And I'm citing the year here because I'm not sure I've had that since. The likelihood that everything's going to line up the wind at your back, the perfect specs, no technical issues is pretty small, even though everyone looking at your roadmap wants to take their millimetre ruler out and count the number of days that are in that box. It's just silly.
Yeah, I mean you might hit the dip, but you'll usually have ticking something out. Then of course. Is it still on time? Semantically?
I try not to get religious about this. The idea that by putting this on a chart on a box guarantees that it's going to happen, not so much go ask any developer. We're always 90% done until the very end and then we're 50% done.
Yeah, it's always just two hours to do that. To add that one picture,
How hard could it be?
Yeah, if I caught an old sales director of mine, it's only ones and twos, which is I ironic said,
It brings to mind one other sort of odd conundrum that I see a lot at the executive level, which is in sort alternate minutes, the executives of the company have two completely contrary points of view about roadmaps. So in the odd numbered minutes, they believe this is a hard and fast commitment where we've done all the science and all the sizing and it's going to arrive exactly when the box shows it's going to arrive. And in the alternate minutes, they each have something they want and they look at the roadmap and decide that there must be room in there for one more thing because important. And so we flip between the, is it a commitment or are we agile conversation? Because if I want one more thing on the roadmap, I want us to be agile. That means I can jam one more thing in with no new resources and nothing moves magically. But when some customer wants it, I claim it's an ironclad commitment. And those two ideas fundamentally can't exist in the same head except for every executive I've ever worked with.
Indeed, I'm loving this visualisation. So I will make sure it's visible to people in the final edits because that kind of more certainty that most solidness of things falls. And then going out to the right, the Vega timelines, the swim lanes as well, giving that thematic stuff. It's a really nice visual.
Good. And another way to think about that that's less visual is at least again, in the enterprise space, I usually want to be about 90% certain about the things in the current quarter something might move or slip or maybe even get done earlier, but pretty solid next quarter, 75%, right? The out quarters, 2, 3, 4 quarters. Well, when we're down to half, there's really very little certainty there. So as you move further out, the world's chaos just comes back into join you.
Well, I mean, we have things like wars and viruses and things like that. I think we're all learning. Uncertainty is a reality and the world's starting to get its head around that at the moment,
But why can't you tell me what time in the morning on September 16th, it will ship, right? Yeah,
Indeed. Cool. Mean, so this is clearly, this visual is I guess in a PowerPoint sort of format. Yes. Do you have any preferred tools in terms of visualising, communicating a roadmap?
I don't. And there's a lot of really good tools out there. My sense though, again, back to the earlier comment about the Go-to-market side, in my experience almost never uses those tools or accesses them. I think as long as it syncs back to what my engineering team uses, they're never going to use this either. So if it spits out Jira and whatever the next 16 versions are, then we can synchronise what engineering's looking at with what product's looking at. But when it's time to really present to the world, I'm used to dumping these out as you pick your format, but PD, F or screenshot, even though I know that every member of my audience wants access to the live document where it says they do, it's out of date by the time we see it. The other thing that lets me do, by the way, whenever I'm dumping this out to a presentation, I always like to put the little splash or a violator that goes across a violator, by the way, is a diagonal piece of phrasing. And it might say today's date subject to change immediately internal only.
So you're putting it across it almost like a watermark instead of
The B. It's
Easy to crop off.
That's right. And then if I'm going to give this presentation material to my sales team, I always give it to 'em in PDF form and not in PowerPoint form because otherwise they can just open up a PowerPoint and remove that warning, which the definition of a millisecond, by the way, is the time between when you give your sales team the PowerPoint and when they take off the warning and then mail it to all of your customers.
Indeed. I mean, I have even heard stories of someone putting that violator in there, but using profanity because they were so annoyed how many times it had still been shown.
There you go.
Yeah. So now thinking about this in terms of roadmaps, what about best practise? Are there any kind of key, best practise elements that you'd like to share?
Honestly, that's a hard phrase for me. There's so little consistency across companies and products. I'm suspicious of the phrase best practise.
Okay. Maybe good practise. Good
Practise. We'll take good practise, good practise. For me, my product managers never lie to customers. Now, we may avoid questions and we may fail to come to the meeting and we may use flower language, but for me, product managers have an obligation to not lie. And so if I'm showing anything to a real customer, it's either on the roadmap because we're working on it or we know we're going to, or it's not on the roadmap. I avoid the hypothetical potential out six years, maybe we'll get to it kind of things. They always come back and come back and bite us. So there's one. And the other I think is it's a habit of engineering and product teams to have code names for stuff. Whatever your favourite Marvel character, there's always an infrastructure project, which is code named Lego because we can somehow convince ourselves it's going to be easy to attach to things and it never is. Putting code names into roadmaps I think is a fundamental problem. They don't mean anything, and it invites everybody who's watching it to imagine what it might mean.
Funny enough, you went straight to my next question, which what's the mistake you see coming on roadmaps in there? Well, yeah, it's interesting though. Just to pick up your point about you have to be working. I'm just thinking, casting my mind back to the style you showed me in those getting out to the cloud styles, where are we already working on those things? Is that what you're suggesting there? Well,
I think what I'm suggesting here is that we're pretty sure we're going to do those things. They're obviously marked as speculative and we're thinking about how to do them.
We probably have some architects somewhere. If it's machine learning, it's going to take years to sort out anyway. So those are things that we better understand instead of what's my distinction here? Sometimes the marketing team invents a thing that they want us to have in the product, and we have no idea what it even means, but that they're really insistent that we put a bubble on the roadmap that says fully user deployable. And if I don't know what it means, it better not be on the roadmap. If we don't have some way to answer the next couple of rounds of questions about what's inside of it, we're just inviting trouble.
Yeah. Yeah. I mean, because for example, I can see AI slash ML success modelled in there, and I guess what on your example, and I guess part of that is saying, well, we've got an idea of how we're going to use AI on machine learning. It's not just AI enabled.
That's right. That's right.
It's the marketing bs.
That's right. And I know it's a marketing only roadmap if it includes all of the following, Bitcoin cloud-based artificial intelligence, and oh, I don't know, something, blockchain, augmented reality, augmented. So when I see all those things, I'm pretty sure that nobody on the engineering side approved it.
Yeah, so true. So true. So we've got some good practises, we've got some bad practise. What about anti-patterns,
Anti-patterns, any patterns? Let's see. So one that a deep anti-pattern is we change the roadmap every week where you choose the frequency. If we're doing that, it's probably because we're not a product organisation at all that we are. Maybe we're a professional services organisation that has hopes of being a product organisation, but every time a customer or a client comes in the door, we say yes to the thing they want us to build. And it's really just a schedule, sorry, schedule. So if it's a project management tool to track dependencies across things, or it's a delivery map for what we promised our customers, first of all, I don't think product management should be involved. Second of all, I'm not sure you need product management at that company. So if what we really do is we, our very clever sales team finds clients who need something built, writes down the spec on the back of a post-it note and hands it to the engineering team says, do this. I don't understand it, but I need it by Friday. Then product management's honestly not a thing, and roadmaps become delivery schedules.
Essentially they become a project plan or release plan,
And those are fine if you're in the project or release business. But in software, in the SaaS business, in the software product business, hitting the date is not when you make money. You make money when people love your product and sign up for it and pay you. And so the idea that at 11 in the morning on a particular day, we will have changed our business model because we shipped something I think is naive,
Especially in the B2B well with sales cycles that are often measured in the years.
That's right. That's so the idea that we can match any feature, the enterprise space directly to revenue is pretty suspect.
So whose advice on road mapping do you listen to?
Really good. There's lots of folks. Bruce McCarthy is usually the first one to leap to mind. He and his co-authors have really good books on this, and he's an expert, Christina KY who put out the KR books. Now, they're not nominally about roadmaps, but they really are because if we're doing OKRs or goals, well, the roadmap follows our strategy. Yet I see a lot of folks who they spend a full year arguing about whether they should adopt OKRs, and then they spend about four minutes picking the OKRs and they're entirely wrong, and that's a disaster. And then they blame the tools. Other folks really smart about roadmap, again, not strictly on topic, but Theresa Torres, who's really the leading light in discovery and validation and her opportunity. Trees are really good feed into the roadmap problem. So if you're doing good discovery, if you really thought hard about problems and solutions and involve your team in that, then the roadmap really becomes an outcome, an artefact of clear thinking.
Yeah. Well, Bruce, funnily enough, is lined up to be on the show in the not too distant future. And both those are the two ladies are definitely on my target list, let's put it that
Way. Absolutely. And there's a lot of really good folks thinking about this, but for me, roadmapping is part of a process. It's not an end goal in itself, and it doesn't deliver value by itself. So we have to put it in the context of building and shipping and collecting money for products.
So true. And so you've mentioned some people we listen to, any particular resources you go to, any sources of insight beyond, say those people's blogs or books?
Not so much, and I have to admit, I work mostly at the CTO or VP product or CPO level. So I haven't built my own roadmap in, well, probably a decade. And the folks I coach, the folks I work with directly are mostly delegating the roadmap problem. So we spend a lot more of our time, our coaching time, trying to figure out how to sell the roadmap to the rest of the internal stakeholders much more than what's on the roadmap itself. And so that's a lot more time spent with Myers-Briggs than it is with AHA or prod plan or Pendo or whatever your favourite tool is here, right? Sure. Yeah.
One my sort of philosophies is that we as product people, we spend too much time focusing on how we do or what we do as the job, the technical skills done, not enough on how we do it in terms of understanding the stakeholder management, the influencing skills that really get stuff done,
Right. And when I drop into a company as this smoke jumper interim head of product, one of the very first things I do is I have to size up my current product team and I get a little time with each of them and they think it's just a meet and greet. And the smart ones know it's a job interview, but one of the very first questions I ask is, how many customers or users or partners did you talk to outside the company in the last two weeks? That was not a sales call? And the best folks give me a number greater than zero.
The okay, ones may tell me none, but they have a reason why the organization's getting in their way and they're embarrassed about it. The folks in product jobs who aren't talking to directly to real end users on a regular basis and aren't embarrassed about it, they actually get an instant promotion because I'm going to promote them to some other job in the company that doesn't work for product. Because if you're not talking to customers directly, you are not a product manager. Right. So true. And that's important because for me, the best product folks are each spending about half their time facing their engineering and design and maker team and half their time facing customers in the market, each of them not dividing it into two jobs. And so I'm bringing back customers and knowledge and insights to my team, and we're working the roadmap together. And then I have to trot that back out and convince the rest of the company that we actually have customer data that suggests these are the right roadmap items. So for me, I've done much less of the tooling and creation over the last decade or two, and I depend on people who are smarter than me who do that job to bring something up. That makes sense.
Cool. Makes sense. So coming towards the end, rich been really good conversation. I'm going to ask you the hardball question
Now.
If you had to distil your philosophy on roadmapping down to one or two sentences, what is it?
Okay. Roadmaps are communication tools. They're not strategies. And we have to have as many versions of those or variations on those as the different audiences who need to absorb them. I think it falls to us to have presentations and materials and content that work with our audiences instead of blaming our different audiences for not being alike or understanding.
Love it. Love it. So I'm going to do my Steve blank I think it is now, and ask you, what should I have asked you that I didn't ask you about road mapping?
I think you should have asked why it's so hard and why there isn't a universal standard for it.
So what's your thoughts on that question then, rich?
I think it's a real reflection of larger company ethos and processes and culture and how different groups get things done. And so I don't think there's, if we go back to Plato, whatever, there's no canonical perfect roadmap for all settings, for all companies, for all situations. That was why I sort of pulled back on best practises. I think you have to find something that works and that doesn't consume lots and lots of time and gets the job done. And the job to be done here is to keep other folks in the company in some out of the company vaguely aware of what's happening next.
Yeah, and funny enough saying what you said, there was a tweet from John Cutler about three months ago that said, we have to understand the jobs to be done of a roadmap. And actually those different audiences have a different jobs to be done for
It. That's right. And just to say it, I think John Cutler is wildly brilliant, terrifically smart. He's got access to all kinds of data. I follow him all the time. I think he's terrific.
Cool. So I think we'll kind of conclude there, rich. Really, really awesome. I guess one last thing I'd like to just give you an opportunity to do is just kind of if you'd like to pitch out there, what you do to people in case there's anyone listening who'd like to get in touch.
Sure. So first thing I'd say is I've been blogging in the product space for 21 years. Hint, that's where when blogs arrived. So I've been doing a monthly column. Now you can do the math for how many of those are, but please, oh, please take everything off my website. That's useful. It's all there. It's all free shovel through it. So that's my pay it forward piece. And then the work I do, primarily what I do is I coach heads of product. So if you're a CPO VP director and you have a product management team working under you and your company wants to sponsor this, then you're a candidate for me to be a coach for. I'm not young enough for energetic enough anymore to actually be a head of product. So second choice is to coach.
Sure. And if I remember right that you're focused on the enterprise B2B software space.
Certainly software. I'm more enterprise B2B. I have a couple of folks I coach on the consumer side, but I come out of the big expensive software side of the world.
Sure. Cool. Thanks Rich. And we'll put a link down to your blogging stuff below here. Funnily enough, I was rereading one of your blog posts about giving up on the MVP as a phrase only the other day.
I'm so sorry.
To be honest, I've given up on it myself as well. I tend to talk about a rat riskiest assumption test, but that doesn't cover every scenario at your first point now,
And just worth jumping on it for a moment, because there's a pattern here I see, which is that on the product and engineering side, we have some key phrase or acronym or word that we think we know exactly what it means and we use it in some careful, thoughtful way. And we all agree as soon as we give the go-to-market side of the house, sales and marketing access to that phrase or acronym, they will turn it into the thing they want and it won't be useful anymore. So agile comes to mind. Nobody on the side cares about that word or what it means. They just think it's a way to beat us and make us work faster. MVP, oh, it's got a, it's a product so we can sell it. When can I get revenue? I think of that as selling philosophy. If we're using words or phrases or acronyms that aren't in plain language, then we should expect everybody else to have a different or wrong definition for it, and we're wasting our time. So yeah, everybody I coach to drop the MVP acronym because no two people in your company agree on what it means.
Yeah, yeah, totally agree. In fact, I spent too much time teaching people what it's supposed to mean and it still doesn't change. So I've given up.
That's right. I just move on and I say things like, oh, this is a non-revenue paper prototype. Okay, can we sell it for money? No, because the first two words are non-revenue.
Yeah, so three.
Got it.
So thank you for your time today, rich. Really interesting conversation. Just a reminder, everyone out there to like subscribe, hit that bell icon and equally join us in the comments down below. Or heck, reach out if you'd like to take part and you'd like to sit where Rich is and give your thoughts on road mapping. We'd love to hear from you. Thanks again, rich,
Brilliant,
And see you all again soon.
