Rich Mironov: Resolving Two Fundamentally Different Product Viewpoints

Enterprise Sales/Solutions teams see the world one customer at a time. Product/Development teams see cumulative market impact and aggregate technical demand. These perspectives are fundamentally in conflict.

The problem is about organizational misalignment rather than individuals failing each other. In this talk, Rich explains why two conflicting perspectives creates irresolvable challenges and will outline a different approach to structuring and incentivising your teams to become a more scalable, repeatable, and valuable product company.

Slides

Transcript

Rich Mironov 

I guess I’m between us and drinks and come home. So I’ll try to keep on time. Thanks very much. Let me set this up just a little bit. I’ve been doing mostly enterprise and b2b product leadership product management since the 80s. Case, anybody thought that was a new thing, not so much. And lately, last decade or two, I do a lot of coaching of heads of product. And some sort of work on designing organisations around how product engineering and design are going to fit together and support the rest of the company. We’ve also done six startups four of which we fall under good character building and life lessons. And whatever else you want to attach the means I had to go back to the investors and apologise and say they’re gonna get nothing other than my goodwill, right? That’s just important to set this up, eventually. And in those kinds of roles, you start to see some patterns. It may not be that you’re smart, but you know, just observant. So we’re going to be talking about really the two sides of a company startup or larger, and some of the communications and decision issues that we have getting those those two sides to talk together. Just a few notes here. You know, everybody else, thank God. So I need to thank Bob for all the inspiration. One of the other things I look for when it’s illegal for me to say, but I’ll say anyway, some of the best product managers, many of the best product managers I’ve hired or worked with our parents. So thanks. Thanks for this morning’s talk. It’s often the very same set of skills and juggling and negotiations. If you ever tried to get your five year old at the at the meal table, to eat the vegetables and the peas before we get to the cookies and cakes and sweets, then everything about this talk will be obvious. All right. Other thing I’ll say is that I’m going to do some intentional exaggeration. You know, I’m gonna go a little over the top and paint both sides, probably in bad light, right, we’re going to exaggerate some we’re going to character you’re going to make caricatures.

So please take this in the in the light that was intended. Good. Alright, let’s go ahead. I don’t know, you can decide which of those two folks I am. Alright, so we’re going to lighten up a little bit by now this one, there’s two kinds of people in the world. Anybody? Commands late in the day, right? So there’s two kinds of people in the world. They’re the people who divide the world into two kinds of people they don’t, I’m usually in one group, but for the next 45 minutes, I’m going to be one of the people who divides the world into two kinds of people. Right, let’s let’s see how you guys are doing. Right now. This one, there’s 10 kinds of people in the world, anybody? Those who understand binary and those who don’t? Okay, that’s for all the engineers in the right. Okay, good. I’m gonna tell you, there’s two kinds of b2b folks in the world, which is really the heart of what we’re going to talk about. And what we’re going to divide the world into is the people in your company who think about the world one account at a time, one opportunity to time one implementation at a time, and the people who think about the aggregate or cumulative effect of all the things we’re doing on the larger customer base, right. And for me, this is almost an essentially fundamental way to look at how software companies operate. Because otherwise we’re going to be spending a lot of time shouting at each other.

Actually, we spend time shouting each other anyway. But But there you go, right. Okay. So and apples and oranges. Right. So so the one group, right, the folks who deal with the world, mostly one or a small number of customers at a time, right? It’s small sampling, and you’re really worried about are we are really worried about closing the deal? Closing the ticket, getting the implementation working, right, current quarter, it’s urgent. It’s one at a time, right? And the other group, of course, cumulative. What’s the total adoption? How many folks are going to use it right? What’s the long term revenue implications? What’s that going to do to satisfaction next year? Right? Can we repeat, can we do it fast right, this year, next year. What I observe and having sat in a lot of these executive staff meetings I observed is that it’s really easy for the folks in one group or the other to start assigning bad intent to talk about the other group as if they’re stupid or lazy, or not very productive or sitting around eating bonbons and playing fortnight or whatever it is. It’s easy to personalise this, but when I observe that I’m seeing the very same pattern at dozens, hundreds of companies. For me, it’s a structural issue. It’s a cultural issue. It’s an organisational issue. For the most part, it’s not about the individual across the table from you, who won’t give you what you want. There’s something bigger going on. So that’s what we’re gonna disassemble here. Right? Take it in two slices. Actually, I have a story to tell. I know, we had chocolate cake at lunch. I don’t know if it was exactly this one. But but here’s the sort of foundational metaphor for the rest of the talk. If you had an entire beautiful chocolate cake frosted and sitting in your kitchen in the morning, anybody have a teenager? Okay, right. So, question and I’d love people to shout at the answers. How is it that in your house with a teenager and you put the chocolate cake out in the morning? How does a teenager eat an entire chocolate cake? One bite at a time? That’s exactly right, right? So your teenager comes in, grabs the fork or whatever, maybe no implement, maybe it’s just facedown, whatever, takes one little bite, right? And leaves and goes on to the next thing.

At the end of the day, what do we know? The whole chocolate cake is gone. So we’re going to keep coming back to this metaphor over and over again, because it’s the difference between focusing on the one bite and the whole cake. Alright, so keep that in mind. I’ll remind you if we get lost. Alright, so cake. Good. So let’s talk about the first group, which deals with the world mostly want to counter the time one situation in time, they’re sequential, they’re separable, we’re going to do a thing, and then move on to the next thing, right? And I’m mostly an enterprise guy. So I’m thinking about enterprise software. First group, of course, is enterprise sales, right? We pay our salespeople to close individual deals, right? Second prize is a steak knife, third prize, you’re fired, right? You close the deal. And you move on. Right? And success is the moment you close the deal, you get it signed, and you don’t have to come back for 12 months, if we’re in a subscription model, or at least eight months to find out how they’re doing right. And success is that moment. Everything else is left, somebody else is gonna clean up right. Second thing that we know about enterprise sales, is that we’re we as enterprise salespeople are actually trying to fit the product to the customer, not the other way around. And I know you’ve heard a lot today and yesterday about how we shouldn’t do that.

But here we are, right? There’s no enterprise customer who finds any product to be an absolute perfect fit. Every one of them has a list really short list, it’s probably no more than 3500 additions. Right? And, and the sales team, of course, we don’t train our sales teams to say no, you can’t have that fu sign the deal anyway, right? Sales is about getting to yes. And so salespeople are trained and rewarded and promoted for trying to figure out how we’re going to answer the need, not just what the product has. So from an enterprise sales point of view, I’m always thinking about how I’m going to meet the need, with whatever product I happen to have, and all the missing pieces, right? And then the third thing, which I know to be false, but I’m gonna say it anyway, is that when a customer when an enterprise customer tells me what they need, I believe it I write it down, I put it a ticket, I put it into Salesforce. And that’s the answer. Right? In spite of everything we know about buying cars, right or renting apartments, right?

So the assumption is, right, we’re going to fit the product to the customer, and they’re going to have some needs. Good. All right. The other group generally lots of names, customer success, implementation, custom consulting, professional services, whatever it is, most either enterprise companies or where they are partners where there’s some group that’s going to finish or complete or add on to what we had in the base product. Right? So what does that group know? Or thinks they know? Right? They’ve never seen an enterprise product that actually met the full needs of the customer. Right? Now, there’s a bit of selection bias here. Because if it did, this group would never run into it. Right? Because they only get called when it doesn’t fit, right. And their goal, their objective, how they how we measure success, is the absolute fastest path between what the customer says they need and maybe put in the contract, and how we can deliver it. Right? It’s not, you know, what are the things that may not appear there? Who knows? Testing, documentation, right, a bunch of things.

But we on the implementation team are trying to get as fast as possible to next to the next thing, because as soon as we’re done with this one, there’s 22 Customers behind us waiting for us, right. And then fingers crossed with great hopes and when did our back because we’re not working on it anymore. We’re hoping maybe we’re even certain but we’re mostly hoping that the software will continue to work after we’re moved on to the next thing or the next company. Right? So this is the sequential account at a time piece by piece. I’m taking one bite of the cake as we go All right, good. We know who this is. Okay. Oh, actually, let’s, let’s take a raise of hands. I wonder who’s on the in this first group. So if you’re in sales implementation, account level marketing, or you’re a CEO who came from that side of the house, raise your hand. Okay, not as many as I expected, right?

Let’s actually do this, okay. So I want you to keep your hand up or raise your hand, if you or anybody on your go to market side has said the following things. And last quarter to engineering needs to be more productive. Product management’s not responsive enough. We wish the folks on the tech side really understood how important this was. Right? I don’t understand what’s so hard. Okay. And, and this is every product person and engineering person who’s you can put your hands down, who’s trying to describe to you in technical terms, why you can’t have what you want, right? And if anybody’s sat through two or three hours of some junior Product Manager explaining scrum to you, you know, that wasn’t very effective. Right? Okay. So let’s look at some things that we on the account and sales side hear from these folks. I’m going to change it over in a minute, right? Sheldon and I are on the product management side. What are the things that we hear from this group that we ignore? That don’t level with us that don’t land? Okay, so arguments we usually ignore, see if any of these look familiar, right? I’m sorry, there’s no whitespace and engineering? Have we heard it? Yes, we have right? The thing you asked for is less important than the things on the roadmap. Anybody? Okay, how about the product wasn’t designed to do that. All right. It probably won’t work and the customer is going to be unhappy. Right? I think there’s one more, we’re gonna run up a lot of technical debt. Okay. Almost all of these almost always fall on deaf ears that we don’t listen to them. We ignore them from the account side from the sales side, because you got to close it doesn’t matter. As an enterprise salesperson, I’m actually not interested in any of these arguments, right? They they don’t address my one by one question. What is my one question? When can I have it? That’s right. And by the way, anybody know the definition of a millisecond? Okay, a millisecond is the time between when the most senior product person on your company tells somebody in the enterprise sales side that they can’t have what they want, and it gets escalated to the CEO. Right. And you’ve all been there, right? So it’s important to note that these are why do our product and engineering folks say these things? Why? Don’t think too hard? Come on? Because they’re true. That’s right. And if we’re on the sales and the account side, we’re not listening, but they’re true, right? They’re spoken as true words, right? So we’re going to take a little side trip for a minute. Oh, I’m sorry. We have to sport that forever. Right? That’s true, by the way, right? Whatever we sell, we have sport. Okay, we’re gonna take a little side trip into ancient Greek mythology, we’re going to do a quick quiz here. So one of the very minor characters in the Trojan War mythology, is one of the daughters of the King of Troy and her name is Cassandra. By No, Cassandra, right. I think the ancient Greeks had brilliant, right. They were psychologists long before they were and Cassandra, like most of these folks in stories, cursed by the gods, and a very specific curse, which is that she is cursed to always see the future.

And always tell everyone what the future is going to be, and have no one believed her. Right? So she’s famous, among other things for saying, Don’t wheel that wooden horse into the city. It’s full of Greek soldiers. And what did she get back today? Come on, you’re a pessimist, right? You’re not trying hard enough? Right? Almost every product manager on the planet has a couple of times a day where they get to play Cassandra and they say, that’s not going to work. That’s going to be too big. We’re going to have to take things out of the roadmap, right? And what is the general reaction from the rest of the executive suite? How hard could it be? Right? Exactly. It’s not just do the thing. We need it. Right? So this is really important from a psychological point of view, because it’s, it’s as best as I can tell the number one reason why Chief Product officers resigned from companies before they get fired, okay? They are tired of telling the future and have nobody listening. Okay, let’s keep going. Alright, so let’s take the other side of the game, right? The folks who think about the cumulative impact if you know, if you’re into graphing, its colouring under the curve. It’s what’s going to happen to the larger instance All based it’s the Long live view. Right? Okay, so product product management, and I’m going to differentiate that from engineering just for the fun of it right? As a product person, I’m actually not that interested in any particular deal. My question is how many of the many, many customers or logos or accounts we’re going to have are going to use that thing? Right? I want to build for the segment, I want to build for the masses, I want to build for lots of stuff. And I worry not so much about the individual revenue from one deal. I worry about revenue velocity, which means could we close 25 More customers or 2500 More customers without doing any more work? If we put the right things in the product? Right? Two things I know that nobody wants to hear, right? The roadmap is full. Anybody worked at a company where there’s whitespace in the roadmap? Okay, I’ve never encountered it. But you know, like the Yeti, I believe it does exist somewhere. Right? Okay, so So I know that if we’re going to put something new in, we’re gonna have to take something else out. And we work pretty hard to figure out what the very few things are that we’re going to put in. So this is a very painful process. And then the other thing, and again, kudos to everybody who made the point yesterday, and today, my base assumption might my coming in assumption is that when customers tell us what they need, first of all, they tell us what to do instead of what their problem is. Second of all, they don’t understand our systems. Third of all, it’s being transcribed by folks who are trying to put the minimum number of words on the post it note, right? Almost everything that comes in through the third hand, fifth Hand 11th Hand channel. I’m deeply sceptical of right, the idea that we’re going to do the thing because somebody said it not so much. Right? Okay. And the other group, of course, I’m going to call engineering and design, right? These are the folks who actually do work. Suppose the product managers, right? What what do we know from the engineering side of the house, we know that every time we put something new in the codebase, it gets more complicated. Every time we add a new feature, the UI is a little harder, right? It reduces ease of use bloat, right? Product expansion, we know that nothing’s ever finished. So anybody who’s running a project based funding model, where we’re gonna do version one, and then move everybody on to something else, gosh, there’s a train wreck that they don’t want to hear about from me, right. And then products, certainly anybody who’s an architect to your products tend to be architected for some specific set of purposes that they’re well suited for. And when we decide that our banking software could also apply to healthcare, or vice versa, we usually learn a few things over and over and over again, that we really didn’t want to learn again, right? So fit to purpose is really important from a design and architecture and product point of view. Notice it was of no interest to the other group. Right? Okay, so let’s play the back half of this game, right? So somebody from the sales side of the house, actually, let’s back up from it. There’s some key attributes key key key skills that every good enterprise salesperson has, right? They’re persistent, right? It’s not selling until you’ve been told no, three or four times, right. They’re persuasive. They’re able to make a really good argument and wrap whatever we have into a good story to get somebody to buy it. Right. And they have this really, particularly specific skill, which is when a prospect at the enterprise says no, they cleverly figured out who further up in the org chart might be able to say yes, we call it escalation, right. By the way, I have I have no resentment at all, and no issue with the fact that all the salespeople make twice what I make, I’m sure that’s perfect, good. And they wear nicer clothes. Okay, so what are the things that if I’m on the inner if I’m on the engineering and product side, if I’m on the larger picture, the cumulative impact side? What is it that the sales folks tell me that I completely ignore? And I don’t care about and don’t land in my head? Right?

Good, good, perfect, we have to close the customer now, even though the product won’t meet their requirements, because competitor x is going to close it otherwise and sign them for a seven year deal. Right? Excellent. Right? How do I feel about that as a product guy? Not so excited. Alright, so things we hear. This is a huge revenue opportunity, right? Why do I ignore this? Because they say that every time. That’s right, not only do they say it every time. But if I’m in a company of any size, every single salesperson comes to me at least a couple of times a quarter and describes a different deal. That must be the largest one that the company is ever going to have this year. Right?

So I’m trying to think Prairie Home Companion was a radio show in the US for a long time. And they there was this thing called the Lake Wobegon effect. Right? And right now, the Lake Wobegon effect is that all of the children are above average, right? Turns out every deal that the company has is the largest deal for the quarter, right? And I’m sorry vicious just a little bit. Okay, what else do we hear on this side that we tend to ignore? Right? Anybody been here? Okay. There’s a correct answer to this. So when somebody on the sales team comes to me and says, It can’t be that hard, it’s only 10 lines of code. What’s the correct response? What do we do? You turn the keyboard around. And you invite this person to write the 10 lines of code or shut up, right? Not a persuasive argument, at least for me, right? There are lots of customer, other customers who want this now, in fact, as a product person, I desperately want this to be true. But what’s my concern? It’s not why is it not? Well, yeah, they’re bullshitting. But there’s another reason to, they know how to, they’re actually very good at persuasion and how to manipulate me. But also remember, we’re in the enterprise space, we’re not in the consumer space. And each enterprise sales team really only covers maybe two and a half accounts, right. And so they are not sampling the world. They’re sampling their two customers, one of which wants this, right. And they’ve just slightly embellished to tell us that everybody in the world wants it. Right. So so on the face of it when the sales team comes to me and says everybody wants this doesn’t always land for me. What else do we have? Right? Don’t worry, they won’t use the feature. Okay, then how about if we just not build it? Right? What else? Oh, this, this is the equivalent, right? Anybody get the call on midnight on the weekend on the engineering side about a piece of something that wasn’t supposed to be supported? And nobody’s left to right. Okay, good. By the way, oh, I’m not there yet. So again, notice that these are all a set of arguments that make perfect sense on the sales side and don’t land on the product side, because they’re all individual. That’s right. And as the lead product person or somebody in engineering, I keep trying to get back to segments and large numbers of customers and frictionless selling of 1000 more units. And these are just not what I care about. Right? Okay, good.

One other couple other key facts. I don’t know if you know this, but every development organisation I’ve ever seen has a roadmap or a plan that looks like this. We’ve already taken out all the things we can take out, right? And the request is, well, there’s got to be something else in there that we could slip out, that’s not so important. So you can put my thing in? Well, I know that every engineer is an optimist, right? As a as a product manager, I tend to be a pessimist, but Right, the hope and dream that there’s a bunch of whitespace in the roadmap, or there’s an entire engineering team sitting around eating bonbons playing fortnight and waiting for some work to arrive from the sky fund sales. Not so realistic. Okay, let’s keep going. There’s a third view. So I lied, I was gonna divide the world into three pieces. We’re gonna do the third view here. I spent a fair amount of time with some investor groups doing due diligence on SaaS applications, right? And, and here’s the fact that drives me, which is, if I were an investor, either we’re going to IPO we’re going to put some money in for the next round. The investors tell me and I believe them, that when they look at the pure frictionless one more licence didn’t have to touch it. SaaS, revenue, right? The recurring revenue, it’s worth six to 15 times, right? So if we’re bringing in a million pounds a year of licence licence licence licence, next round might be between six and 15 million, right? It’s all about build one sell many. It’s all about fewest number of touches. It’s all about as little professional services as we can as little customization as we can as few as specials as we can. How do we get a lot more done? Because all the money in the software business is in selling the same bits? One more time? 20 more times? 1000? More times, right. So when investors look at a pure play software company, they’re looking at the ARR. And they’re saying, okay, that’s what six to 15? What’s the other half of this? Right? Any professional services work? You use? Customization? New connectors, data cleansing, right thing, right? The investors had best value that at 1x. Right? So if I bring in a million pounds worth of professional services, okay, less, what’s your what’s your number? Point five, okay, somewhere, I’ll take point seven, just for the fun of it. Right? So the next billion pounds worth of professional services or custom work or implementation, or whatever we want to call it is worth less than a million. Right? So there’s a tremendous incentive at the company level, to push ourselves to need less integrations and less specials and less whatevers and less touches and less fittings and less options.

But notice at the departmental level, that’s not true. Okay, if we have a team that does integrations and professional services, my guess is that they’re Being bonused on how much money they bring in, and every every pound they bring in is actually worth minus money to the company. Right? So so this is the third group that I weigh in the back. Alright, ready to keep going? Alright, so let’s do a few examples. These will be silly pictures, but maybe I’ll tell you some good stories, right? And we’re gonna tell both sides of the story. So put yourself in the situation of of an enterprise sales team and the customer needs shockingly only one new thing, right? It’s not in the product. And your company has some process flow, right, some form to fill out. That’s the new feature request form. Right? I’m I had the sales team, I fill out the form or actually, more importantly, I have somebody junior to me fill out the form, right? What’s my expectation about what happens with that form? Right, the reason I’m filling out the form is because I expect when I hit the send button, right, three to one, I’m gonna get back a date and a commitment. Right? If I weren’t going to get a date and the commitment back, why would I bother filling out the form? Right? Number one complaint about these kinds of systems or processes from everybody on the go to market side is? No one ever responds. Right? And when they do, what did they say? No? Okay. I’m not sure which is worse. Okay. So so this is the one accountant time, how do I see my thing? And it’s, by the way, this is the most important enhancement that the company has ever requested? Because Because it’s my deal. And by the way, I don’t get paid. If we don’t close it right, now I get to work somewhere else, right? So what does the other side of this picture look like?

Okay, I’ve done a bunch of audits where I take the product management team at the company, and we count the number of requests per whatever unit time here, right? And it turns out that your typical product manager gets between 20 and 50 requests a week. Okay, go ask, right, maybe it’s lower, maybe it’s only 19, right. And they come by email, and they come by slack. And they come by posting notes on your monitor. And they come by having a meeting. And, you know, all these other things. And there’s this other system, which by the way, the sales and marketing side would like to have a service level agreement, so that we have to respond within eight business hours, or whatever it is, right? When you add up all of their quests, it turns out that the sum total of the request is usually between 20 and 40, times the entire engineering staff of the company, right? Not 20% 20x to 40x, which means no matter what we’re going to do, even if we did nothing other than addressing requests, we’d have to turn down at least 95% of them. Right? Because our engineering team can’t possibly deal with this load. Right?

So the first thing we know is, it’s completely physically impossible for me on the product side, or somebody in the engineering side, to give a yes. To even a small fraction of these. By the way, there’s also remember our roadmap, there isn’t actually room for too many more things. The other thing we know, coming back to, to the point earlier that Bob has led us through so well for so many years, is almost every one of the requests is incomplete, incorrect, missing all the interesting things doesn’t have the technical stuff we need, assumes lots of facts not in, you know, entered in evidence, and has as the number for the size of the deal, perhaps the 10 year licence that we might just see out of this customer if we close it and all goes well, and we do land and expand, right. So the tickets themselves are, in some sense, nearly useless, because we’re going to if we really think it’s a good idea, we’re going to have to go back to those interviews, we’re going to have to go back to the real customers, do the interrogation, do the discovery. And that’s going to take some number of weeks. Right? Again, remember, we’re 20x or 40x opacity, so we can’t possibly do that for all of them. But for the ones we’re going to want to do that match up all the patterns, right? This is a couple of months worth of work. Right? So the or however long it takes. So the idea that the sales team is going to get a yes on a new request in eight working hours.

Again, it’s physically impossible can’t happen. Right? So we’ve set up a situation where the one side views the other side as unresponsive, not working very hard, not seeing the urgency that deals really important. Why can’t you just you always includes the word adjuster only, right? We’ve set up a conversation that really has some some real problems to it. All right. We’ll get to some partial solutions. And let’s take our second instance. All right, anybody involved in a migration from on prem to cloud? See me after class. I was working with a client In Australia, actually, and they’re five years along, in their migration, no problem. And I asked, I asked a couple of leading questions. One was CIO of the new deals that you’re signing this quarter, what portion of the mark in the cloud versus on prem? And he said, Oh, we’re 60% Cloud for the current quarter. Right. next quarter, we hope to get 70%. Right. Okay. So my understanding of how enterprise customers buy in their, their expectations is that if we licence you something today, gosh, you should probably expect it’s going to work for the next three or four years, right. So if we’ve signed even one new on prem customer, this quarter, then the earliest we can be off the cloud is three years from now, right. And if we’re only 60, or 70%, along the way to what we’re selling, next quarter is going to be 72%. And the quarter, if that’s going to be 77%, we’re three or four years away from actually cutting off the new stuff. And then we’re three years after that to get the last one. So the idea that we’re going to free up all of our engineers to work on the new cool stuff, and maybe even finished the cloud product, right? Because we might need it. Right? The the individual deals are driving the impact of never finishing. Right. The other the other question I usually ask is so Okay, how many? How many old versions of the on prem software do you have? And what’s the end of support date for the oldest of the oldest of the oldest versions? Right? So we’re on version 19. But there’s still some folks running version 12.2. Right, which was built in the 90s, whatever it is, what’s the end of support date? Silence. What do you mean? Okay, well, it turns out that it’s really, really hard to get folks who have on prem software, and you have to do an awful lot of arm twisting, right? And so on the product side, and I’ve done many dozens of these. There’s a campaign, right, we’re going to announce, so we’re in 2023, okay, we’re going to announce to the whole customer base that version 12.2 falls out of support. Two and a half years from now, okay, so we’re gonna put it at the end of 2025, right. And every month, we’re gonna send an email and a notice and a paper and a pony express and a telex and whatever else to every single customer who’s got version 12.2, reminding them that the absolute end date with no exceptions, is December 31, of 2025. And we have a free upgrade. And we have always help and here’s the right, blah, blah, blah, and you have to get off. So the question that I posed to the client here, and that’s my general question is, imagine the following scenario. We’re in November of 2025. And your fifth largest customer who’s running version 12.2, calls your CEO and says, I need another year.

Okay, now, it’s a behavioural test. Right? It? It turns out, if your CEO says, yes, that’s okay. Right, we will never get to the end of this process, right? Because there will always be one, right. Murphy’s Law says, there’ll be one customer on version 12.2. Who won’t go and one customer on third pain 13 A, right, who won’t go. And so the cumulative effect, right, the colour under the curve, the largest story is that our product set looks like this. Okay, anybody been in this store? Right? Everything we’ve ever shipped is still somehow under support, or even if it’s not, we’ll take a call. We’ve got right, every kind of old crazy thing here. I think he got some, you know, old clocks, and whatever you got, we got all kinds of very cool things, globes with countries that haven’t existed for a few 100 years, right? Product sprawl, right? So if you’re thinking about the cumulative impact of moving from old to new, you’ve got to have an executive team that’s going to stand firm in the face of a customer, one customer, two customers who wants to extend the deadline, otherwise, you never get there. Right. So again, notice the difference between they’re really big customer, we don’t want to lose the revenue, right? And we’re trying to move to the cloud. Right? Which one are we on? I think I have one more here. Actually, this will be more entertaining. We were talking about cake. We’re going to shift to pies for a minute here. Okay. There’s something really special. There’s something magical about pie charts versus all other charts. Somebody told me what’s special and wonderful about pie charts. They’re colourful, yeah.

The slices. Yeah. So the the really important thing for executive audiences about pie charts, is if you want to make one slice of the pie bigger, you have to make another slice of the pie smaller. Okay. Pie charts inherently present us with or choices where all the other kinds of charts are and choices. Yeah, yeah, do everything and we need this to more programmes. So I’m going to walk us through a sort of Typically healthy r&d or engineering budget for an enterprise software firm, and then we’re going to dissect it a little bit, we’re going to cut the slices. So let me just tell you the pieces, the purple on that side, that’s all the things that customers ask for by name, or sales teams ask for it by name or partners. So these are the visible things that have to get prioritised against each other, because it’s what folks asked for, or even better, it’s what they need, right? New features, new workflows, blah, blah, blah, blah, blah, right? Anything is going to drive money, any upsells, right? If that slice were 100%, we’d be out of business in two quarters. Okay. The next big slice, the red slice, is all the things we have to do to stay in the software business. Right? If you have customers calling you up and saying that you need more scalability in your application, gosh, you’re a year or two late, right? If customers are calling you up telling you that you got some security issues. Oh, man, I think you were anyway, not good, right? So all of the things that happen in there are the things that are behind the curtain. Right? They’re the things that have to get done, if we’re going to stay in business, but nobody on the go to market side really appreciates them. And they would really like us to prioritise all those lower just for this one quarter, right. Okay, good. There’s two last things, we’ve talked a lot about discovery or validation, or interviews or finding out what’s true. It’s a small slice, it’s usually between five and 8%. Right. But we’ve got to do it, or the next round of things we build, they’re probably going to be wrong.

And because we’re in an enterprise company, I know that we’re going to have a couple of specials, we’re going to have a couple of just for these one customers, we’re going to have the I just got off the phone with JPMorgan Chase. And they told us if we could just add teleportation to the product by Friday, right? We’re gonna do a few of those, right? When I see that slice get above eight or 10%, this company becomes a services company becomes a professional services contract. outsourcing firm, because that consumes everything else, right. So we’re gonna paint this picture, right. So this is the story at the beginning of the quarter. Right? And yes, there’s one deal I can’t remember. Yeah, so Credit Suisse called up, that’s not going to work. Okay. UBS called up and they have a really big contract. If we do this one little thing, it can’t be so hard. It’s only 10 lines of code. And we’re going to agree to do it, because it’s going to bring a lot of revenue in. And that’s our plan. Right? That’s the beginning of the quarter. Now, we know all of us know, that engineers are optimists. And we’re going to do some technical discovery along the way. So what really happens at the end of this deal, right? Is that blue slice is actually probably twice as big as we planned. Right? What what disappeared? Everything about the future? Okay? We’re not dead yet, because we’re going to catch up next quarter, right? But But notice that even on this very first deal, we’re getting into deep water, right? What’s the next thing that happens after we close this deal? And the sales team on this deal finds out they’re getting huge commissions, right? They’re gonna trade their smaller houses for bigger houses, and they’re older cars for newer cars, and they’re older spouses for younger spouses, whatever it is, right? What’s the next thing that happens after this deal closes? Yeah, even even more important, they take all the other sales teams out for drinks, so they can lord it over them and buy drinks. And when all the other sales teams ask how it was possible to close this deal, because it needed something special, they say, I went to the CEO and the CEO said, yes. Okay.

All of you in the room who are CEOs, I hope you’re listening. Okay. So there’s a behavioural pattern we’ve now established, which is, how do we close big deals in this company? We go to the product folks. And they don’t say anything. Or they say no, we’re gonna engineering around product, even though they told us not to. And we don’t understand anything they say. So then we go to the CEO. So the behaviour pattern is that we’ve now established for the company that the way we get big deals closed is we escalate over the CEO, remember, that’s a key sales skill, right? So sometime in the middle of the quarter, it starts to look like this, right? A couple more. And a couple more, right? We’re eating the cake, one tiny crumb at a time. Right. And it’s not obvious to anybody, because we’re not keeping score that we’ve given away the 5%, seven times, right. And at the end of the quarter, right, at the end of the quarter, it looks something like this, right? Where we land is oh my gosh, there’s a lot of blue. And because I’ve done a bunch of the audits, we go back. So I have the product team go back and say, Well, what were the things we put on the roadmap at the beginning of the quarter that we intended to do? And then let’s look back at the end of that quarter, what did we actually build, right and we only score the things that we intended to build it and then we built into Turns out a good third or half of all the things we promised the world, and we announced, and we told the board of directors, right? We actually didn’t build because we gave away the feature stack one little tiny forkful at a time, and no one was keeping score, right? And by the way, if that red slice doesn’t terrify you, then I think you’re not paying attention, right? Because that’s where all the systems fall down. Right? Unless you’re in the special case where you actually fired all the people who knew how to run that system. And then it stopped working. Right? We won’t go there. Right? So but what’s important here is, right, this is the difference between seeing the pattern one account at a time one week at a time, and integrating under the whole seeing the collective problem, right? What’s the cumulative impact of doing this over and over again, it’s a behavioural problem. It’s an executive problem, much more than it’s a technical problem. We’re good. Alright, let’s keep going. I don’t know what we got next. Alright, so I’m going to talk a little bit about another shaggy dog story. First time I did this, I was at a startup in 2003, the VP of sales and I actually had a great relationship. We’re still friends, we would go out to lunch, once a week, settle a lot of issues. I had product marketing, business development, I’m trying to anyway, but he and I would go out at least once a week off site and hash out any issues, we had a great relationship, we established the following thing. I gave Stuart because his name was Stuart, I got a I got an empty shell casing. By the way, these are silver bullets. So in case anybody remembers, right, so I got him an empty shell casing, right. And I gave it to Stuart. And I had to put it in his desk and said, Stuart, that token, that item is worth one engineer weak, every quarter for anything you want. Right? You tell me it’s the most important thing. You give me the token, I will assign somebody to do that thing, whether I think it’s smart or not. Right. So someone’s going to help me. Why did I have a physical token associated with this? Give it once. Right. So the traditional thing is that the head of sales, asked for this one time special in the quarter, early in week, two of the quarter. Right? So we set this up so that when Stuart reached into his drawer on week three, it wasn’t there. And week four, it wasn’t there. Right? What we’ve done here is we’ve actually helped share the hard decision making because the VP of sales, the Chief Revenue officers job is to make the most money for the company is on all the pipeline calls knows which deals are real and which ones are going to close, and is the most incented person in the company to figure out which of the deals needs that one week of engineering, right? So we’ve shared the problem. Right? There was one tremendous benefit to me and my product team as well. Anybody? So Exactly. Right.

So so each time a some other member of the sales team, other than the VP came to me and said, I need I want I need I want, right? I got to say, well, that’s a fascinating idea. I think that’s a great idea. I love it. If you can get your boss to agree that that is the most important thing this quarter. I’ll do it. Don’t let the door hit you on the way out, right. So really important, because what we’ve now established is we’ve established a little bit of scorekeeping so that we don’t give away the rest of the pie, right? And it’s dumb. And it’s psychological. And it’s how executive teams need to work together. Because remember, I’m never going to get the sales teams agreement that we’re doing enough, right? We have to have some mechanism, and it addresses a very narrow but but very serious illness that I see in organisations, which I call commitment, amnesia, okay. And here’s how it works, right? Someone on the sales team gets a phone call. And the phone call goes something like this, Hey, Deutsche Bank, or choose your organisation Ford Motor Company, will give us a contract for 800,000 pounds if and fill it in. Right.

The next thing that happens is, every single person in the sales organisation has their memory wiped of every discussion we’ve had at the beginning of the quarter of what’s on the roadmap and why it’s important, and why we’re fooling why there’s no reason because this is a really important deal and as motivating, right. So some kind of executive scorekeeping that’s very simple and very obvious, and hard to miss is one of the ways we can reduce the amount of commitment amnesia and roadmap amnesia. Remember, once the sales team signs the deal, they believe they’re done. Right In fact, they are done. But they left a whole heap of things for the rest of us to finish right So this is again, one of the techniques I’ve used to take the emotion out of it, right? It’s not that we dislike each other, it’s that we’re actually working across purposes, right. And, again, for all of you who are CEOs or founders, I think you want to really listen for this kind of conflict, because it’s easy to do the individual transactions one at a time, and discover at the end of the quarter or the year that you’re in our all blue pie chart, because you haven’t seen the cumulative effect of the all the Cassandra’s, in the company telling you that there’s a really bad thing that’s going to happen. Right? That doesn’t make sense right now. We’re good. Okay, so let’s do a little bit of summary here. Because anybody knows that’s an American takeaway container. So these are our takeaways, right? I think of this as an absolutely fundamental organisational and people challenge for the company. Almost every place I’ve been on the enterprise side, I see it now. Not so much in consumer, right. Why? Because if you’re in a consumer tech space, you’re trying to sell nine $9 a month to 10 million people, right.

And there’s no one of those people who is so important and has so much money, that they have your CEOs phone number and phone up, right. But in the enterprise space, you’re much more likely to have nine deals at a million bucks apiece. And by the way, again, we talked about boards, we heard about boards, your board of directors knows the names of all nine of those deals, and they’re usually pretty patient, I think they only call you as a CEO, say once a week each, to find out how every one of those nine deals are doing and what they can do to help close. So there’s tremendous pressure on the enterprise side. To do it anyway. Right? So fundamental organisational financial challenge that I see in so many of the enterprise and high end b2b software. It’s driven by the model. Okay, let’s keep going. So the first thing I would say the first takeaway is, let’s try to respect each other and, and assume good intent and listen, as a product person, I spent a lot of time listening, but not everybody else does, right? When somebody on your go to market side tells me that the engineering team is inefficient or lazy or sitting around or doesn’t understand. I get very angry, right? Because I see these folks bringing their hearts and souls in every single day. And my designers, my engineers, my DevOps folks, they’re putting everything they have in, right, but it’s not so obvious, right?

Turns out that sitting and thinking and working on the whiteboard is much more important than typing the code. But if you just walk through the engineering space, hard to know if people working, right, okay, so assume good intent, as the CEO, how do you listen on both sides? How do you see the overall picture? Right, what else we have? The long term doesn’t bite you until it does, right? There’s probably some global warming story here. I won’t bother telling right. But yeah, we’re only 16 steps away from falling off the cliff. Now we’re 14 steps, right? If our company is going to survive, and we’re going to thrive, we have to understand that the long term matters, and that some of the folks in the company defend the long term against the short term. Good. What else do we have? Costas specials, right. Every enterprise company does a bunch of really unnatural things to close their first two, or three or four, five customers, right? We do. Right? We’ve got to get a couple of customers on the board, we got to find out if it works, we’re going to do all kinds of crazy things. We’re going to parachute engineers into do installations, we’re going to do an integration with a database that nobody’s worked on since the 70s. And all the people who developed it are retired or dead, right? We’re going to do all kinds of really regrettable things, but we’re going to do them, right? Because we’re a startup we’ve got to survive. I see the cost of specials go way up at customer number six or eight or 10. If you’re still doing anything special for customers. For customer number 40.

Okay, well, I’m unhappy, right. I hope you’re unhappy, too. Right. What else do we have? We the several people talked about comp plans. Right? So my observation and I think everybody agrees, salespeople do what we pay them to do, not what we want them to do. Right? So if you happen to open up your comp plan, and he noticed that salespeople get paid the same rate, the same dollar for dollar on custom professional services work and selling the licence of the thing we’ve already built it we don’t have to spend any more money on they’re going to do the thing that gets them to quota fastest and it’s way easier to sell custom work than any package. Right? So many times I prefer to propose the final this very, very tiny, tiny change to the comp system. Right? I think we should comp our sales team 110% on standard licences, and minus 100% on everything else. And it turns out, that’s really hard to get through the executive team. But if we do adopt that it solves this problem almost immediately because salespeople won’t sell things that cost them money, right? But if we’re rewarding our sales team for selling the things we don’t have, and we’re not Oracle, everything else that happens is completely predictable. So so how do we think about as product and engineering folks, as the folks who are looking at the overall picture? How do we think about the comp plan is one of our most important weapons, right, and we can’t change it ourselves. But we can certainly lobby with the financial organisation, right? Last one. And I’ll give you a little little brief on this. So we’re still in the place where the big enterprise customer wanted a bunch of things that aren’t in our product. Right? We didn’t make that go away. But we don’t want to do it. And I think there’s a there’s a false dichotomy, a fourth false choice here, we either say, Well, we have to build all the things they want, or lose the deal. And the alternative here, I think, is a really good one. If we’re a product company, let’s find a couple of services companies to be our friends. Let’s teach them our API’s. Let’s give them a free copy of our software. Let’s train them all up. And when our enterprise customer comes to us thinking we’re accustomed development shop, and wants to give us 15 interesting projects that have nothing to do what we do. Rather than saying, fu Here’s the door, right? We don’t want your money. We’d rather say, here’s a set of trusted partners who understand our systems and you the customer can pay them, the system shop, whatever you agree, and they’ll end up supporting it because you paid them to build it, right.

So it’s important that we meet the customer’s need. It’s not important that we build all the things that meets the customer need, right? So this is the out from we’re just shouting each other. Right? We’re good. Okay, I think we got not much more. I don’t know why I put that up. But there it is, right? There’s where to find me. Yes, I bought my domain name before anybody in the former Soviet states got on the network, which is how I got away with that. Right. That’s me, let’s come back to here. I think I’m done.

Mark Littlewood 

Fantastic, thank you. Gonna take like maybe one, possibly two questions, but we’re going to be

Rich Mironov 

I’ve got nine minutes left. While they they’ll put something on quest? anybody? Anybody been there? Go, Ivan. Sorry?

Audience Member 

Should you own your service company? Say again? So you’re building a product, you own the product company? Should you also own this service company?

Rich Mironov 

When I look at service companies and product companies, I find nothing in common different organisational structure, different staffing, different financial model. So I would say if you can have two companies, and not much sharing of execs, maybe they share the office space, I think that’s fine. But But I think it’s really, really, really hard to run a product company with any sizable services in it. So so how do we? How do we divorce them enough that they can run on their own and we can run on arm as

Audience Member 

Oracle and Oracle consulting basically, the whole separate things.

Rich Mironov 

Sure, but if but if you look at if you look at the financials, you’ll see that Oracle consulting is very, very small relative to Oracle licences. And they really only want to take on interesting and risky projects. And they give almost all the systems work to the PwC and Infosys is of the world. They don’t want it right. So there’s a team there, but you got to have a little bit of a leash on them. Because you don’t want it to grow. You want it to shrink.

Audience Member 

My question would be What do you do? Like you told about the scenario, right? To sales executives go to the CEO to get approval? What if, or the story with the VP of sales? Right with the coin? Right? What if the CEO as potentially the most powerful person is the person who keeps pushing for these one time special? Who are the most

Rich Mironov 

Yeah, so So I spend not this week but I spend most weeks I spend seven or eight or 10 hours coaching heads of product at software companies. And this is the most frequently asked question and unfortunately the answer for me is if the CEO won’t back the product and engineering team part of the time, then I believe that the product management job is completely failed, right that no no head of product, no VP product, no to product at all. Sir can succeed in a company where the CEO consistently overrides the product and engineering decisions, because the job is gone. Right? You may still have an engineering team, although often, you know, you’ll see what happens there too. But the the number one reason why Chief Product officers quit companies, by far is because they’re trying to get the influence around the sea level table, the the executive table, and they don’t have it, and they don’t have the backing of the CEO. So all of you who are CEOs or founders, if you’re wondering why your last two heads of product quit, and this looks familiar, think about it. Right? The product team has no authority. It only has responsibility. And if we’re not listening to the product team, then we might as well not have one.

Rich Mironov 

You can just shout out or we can wait for the mic. Sorry, if I get emotional over this. It’s important to me.

Audience Member 

Yeah, so you mentioned that investors are valuing repeatable arr. And then a little bit later, you said that it’s, which is board members, phoning you up asking, you know, really focused on this quarter? So are investors is it just the investors don’t know what they want? Asking for a friend?

Rich Mironov 

So investors is a big class of people, right? And many of the investors I know and work with are really current quarter focused, right? If we substitute the words private equity, right, so my experience with PE firms, at least the large ones is their timeline to buy and then resell the company is sufficiently short, that we’re not actually going to be able to do any serious product work between now and engineering work. So it’s all about maximising short term, you know, sales revenue, and hoping to find a buyer for the company who doesn’t ask the right questions and get it off your hands before it breaks, right. But I think there’s a lot of leased out in Silicon Valley where I was, there are a lot of VCs who do understand this, and have the five to seven year view instead of the 18 Minute view. Right? Not all investors are the same. I think we heard today you really are yesterday, you really want to have investors that are aligned with you. But I don’t see a lot of folks who come out of the finance programmes of MBA schools that really want to spend any time on this problem, right. So so finding investors who understand what it means to build software and maintain software would be a really handy thing. Right? How you do that? Will not my problem. Good.

Mark Littlewood 

We got one more final, going once, going twice, going twice, three times.

Rich Mironov

Smokejumper, Mironov.com

Rich is a seasoned executive and serial entrepreneur – he has been the ‘product guy’ (as CEO/VP Product) at six startups. With deep technical roots in B2B infrastructure, SaaS and consumer online, Rich combines ‘what-we-can-build’ with ‘what-markets-want’.

He has been relentlessly blogging, speaking, teaching and mentoring on software strategy, product management for two decades. Today he coaches executives, product management teams and agile organizations. He has spoken at BoS Conference before, always to rave reviews, on topics such as the Four Laws of Software Economics, Solving Your Real Roadmapping Questions and, The Art of Software Pricing Demystified.

Rich has three big things he cares a lot about:

• Organizing the product organization.
• Cross-functional leadership.
• Building what users actually need.

He wrote The Art of Product Management and is a voice for the scrappy entrepreneur in all of us.

Next Events