Enterprise Sales/Solutions teams see the world one customer at a time. Product teams see cumulative market impact and aggregate technical demand. These are fundamentally in conflict and Rich believes this is not just a vocabulary problem. It’s a fundamental ongoing disagreement about how decisions are made and who makes them.
In this session, Rich explains the challenge, help you understand the rational perspectives of both sides and offer some radical suggestions to help you solve one of the main causes of loss of value in a product company.
Slides
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
Transcript
Rich Mironov
This actually comes out of some, some blog posts and writing I did last year that we’re trying to morph into, you know, a fuller thought so so let’s dive in. Here’s a bunch of people shouting each other at least virtually shouting at each other. That’ll be sort of the theme going forward. A little bit about me in black and white here. So I’ve been doing enterprise product management since the 1980s. In case anybody thought product management was a new thing, not so much. And it wasn’t the first one to arrive, done a lot of product leadership and you know, chief product, whatever CEO, whatever, six startups, most interesting thing, I think, here, I’ve been independent, hung up my shingle in 2001, and done a whole series of what we call the smokejumper job, which is parachuting into some software company that either forgot to have a chief product officer or VP of product or maybe misplaced the last three or four, or they walked out in a huff, whatever it was. So those are really as much organisational and psychological assignments as they are about product, because it usually has to do with dysfunction at the executive level, which I guess I love because it keeps me employed and informed. Do a lot of writing anybody who’s been on my post my site, I’ve been blogging in the space since 2001.
Quick, can anybody tell me why I started blogging in 2001, and not before the crash in 2000? In fact, it was, in fact, the 2001 crash was exactly why but the other reason is that blogs didn’t really exist before 2001. So anybody tells you they were blogging in the 90s?
Audience Member
Check their facts for them?
Rich Mironov
Yes, exactly. So Anna gets the price. They’re good. Alright, so let’s go ahead.
And here’s the setup for the discussion. And I’m thinking about a particularly enterprise software companies, but it could be a lot of different companies, where, what I see is that you’ve got two groups within the company that have in fact, different, essentially, opposing timeframes and point of view, and that this sets up a conversation over and over again, at so many companies where we simply can’t agree on the basics, because we’re measuring the different thing. We’re measuring different things, and we’re rewarding different behaviour.
So here, what I’m talking about is that part of your company, again, particularly if you’re an enterprise software company, lives in the day to day lives in the one at a time. So if you’re in a sales role, or an implementation role or support role, you deal with customers wanted a time, at least in any one moment. And when you’re done with the one, you put the next meeting, you put that one aside and you move on. And that’s essential if you’re in a sales job, and those who are old enough to remember that in sales, first price is a Cadillac. Second prize is that of steak knives. Anybody remember what third prize is? Nobody, either you’re all on mute or didn’t see the movie. But third prize is you’re fired. Right?
So what’s important in sales is you’re actually going to close deals this quarter, where you’re going to be working somewhere else pretty soon. All right, so the measure of success is one at a time. How many deals did you close in the implementation side? One at a time? How many customers did you integrate or bring on board or get their systems running? If you’re on the support side, one at a time? Did we close out that ticket so we could move on? Right? And this makes perfect sense. If you’re in that half the company and it’s how you see the world. Now of course I’ll take the other side now There’s a whole different group that thinks about aggregate impact or cumulative impact. Or how does this all stack up? The math folks would say colouring under the curve, right? How do we see the larger picture and how all the pieces stack up? Primarily that comes from the product engineering and design side of the house. Because on this side, we actually longterm own all of the things that in short term, the sales team sold, right. And in fact, we have a different set of measures. Elise here for anybody not in the product space, is all of the things that systems have to do, they have to have scalability, and security, and use ability. And you know, all the other features of a system such that it operates and continues to deliver value to customers and isn’t offline, right. On the product side, we usually talk about total adoption, how many different customers use the feature we built, not that one big customer that forced us to build it, no one else is using it, we look at company revenue as a whole. Get Noticed that’s different from the individual sales teams that honestly don’t care so much about the company as a whole, they care about their one quota number in their territory. And we worry a lot about time to value for me time to value is the number of minutes or hours or days or weeks between when a customer signs a contract with us. And when the product, the software actually starts to do what they needed it to do and how they saw value. So anybody old enough to remember the old days of SAP where time to value is measured in 10s of millions of dollars and years and cancellations of projects time to value is really long. In the SAS world. Now, most people expect to get on your system, put a credit card in and start some, you know, user identification and be up and running within the hour. So time to value is about how the next customer is going to get onboard and productive and successful. Right. So these are both important. The reason I’m putting the organization’s here is because I see ongoing in my 195 Whatever clients I’ve had since since 2001, that this is a dynamic at many, many companies. And we’re shouting at each other from one side to the other because we’re in fact measuring different things and want different things fundamentally. Okay, so different metrics, different considerations, timeframes important, the definition of time for someone in a sales organisation is 90 minus the number of days in the quarter that have expired, right, if we’re 14 days into the quarter, then my number is 76. Because I have to beat my quota, before the time runs out. product folks in engineering folks tend to be thinking in quarters or years, it takes much longer to get something done of substance. And then we have to maintain it essentially forever. So we’ve set up the system where some folks wants to do all the short term trade offs. And some folks want to do all the long term trade offs. Hence the shouting, everybody good? Anybody have any issues? All right, let’s keep going.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
Alright, so let’s take apart the what I would call sequential, separable, completable. So these are the things that we can get done, check the box, move on. So here’s the very old style now serving picket ticket at the post office or the deli or wherever you are, right, when we’ve made the sandwich for one client, we’re ready to move on to the next and we mentally put it in a box and walk away. Alright, so on the sales side, again, we think of the transactions, the sales transactions as independent, I close this customer or I close that customer, maybe both them on if I’m lucky. Once we’ve done all the paperwork, and I filled out things on Salesforce and know that I’m getting my commission for this, mentally I move on, we’re done until next year, right? If it’s a multi year contract, maybe several, there’s the assumption that what we do in sales is we fit the product to the customer. So there’s almost no enterprise customer who’s an exact fit for every edge of the product. So as a salesperson, what I want to do when I’m rewarded to do what I’m paid to do, is to find ways to force fit the product into the customer problem. And of course, that always generates a bunch of unique requests. Anybody who spent any time in enterprise knows that every big customer has just a few tiny requests. No more than say 60 or 100. And they’re all pretty small. The one I love is this can’t be so hard. I bet you can have it by Friday. We’ll write you a 700,000 Euro check if you can add teleportation to the product by Friday. Right? The competition doesn’t have it. Everybody wants it. Right? Every deal comes with something unique. And when we add those up, when we call around to the curve, we’re gonna get in trouble. And the last thing sales either believes or tells the product side your choice is that when customers say what they want, we actually think They’ve thought it through that they believe it that their analysis is correct. And if we do the thing they say, their systems will work. In fact, sales is, is marked mostly right here. If we do the things they say they’ll sign the contract. But that’s different from the system’s working. Got it. Let’s keep moving. And for folks on the implementation side, again, if you’re an enterprise software, there’s almost always some fit and finish tying your application into some database nobody’s ever heard of, or an application that that customer built in the 70s. And all those folks who retired are dead, right? The standard product usually has a bunch of edges that aren’t finished. And so from an enterprise implementation point of view, we might call that customer success, we might call that onboarding, whatever that group is called. We’re trying to find the fastest path to getting those folks up and running so we can move on. Right?
Again, this is all about finishing it wrapping up and walking away. Of course, that begs the question of who’s going to take care of the stuff we built, when we’ve moved on to the next deal, or the next customer the next situation. But all of the push all the incentive here is to get it done, check the box, wrap it up, send it off, and move on to the next thing. We measure time, we measure effort, and we measure cost spent.
Perfectly straightforward. And I’ll just ask anybody who’s from this side of the house that this is completely obvious to do a hand raise or you know, whatever the signal is on on, zoom here to show that you’re with me. Okay, Brad’s there. All right, Elena’s there, good, Jack? Right. This is how half of our company thinks, right? No surprise Joe’s there marks they’re good. Okay. So there’s a set of arguments that the engineering and product side of the house presents, when I as a salesperson and enterprise salesperson, bring a deal in? That’s worth a lot of money that needs a couple of tiny little special things. And maybe they’re not tiny, but they’re certainly specials, and what are the what are the arguments that we get? Right? We get arguments like this, by the way, here’s, you know, from the sales side, this is what product looks like anybody who hasn’t seen this series? Let me know, I’ll send you the link. Right? So there’s a whole series of of complaints or arguments or pushback that the product engineering side presents to sales that sales pretty much ignores? Because they don’t answer the problem at hand. All right. Give me a thumbs up if you recognise any of these, right? There’s no whitespace there’s no slack and engineering, everyone is committed. There’s, there’s no one sitting around the theory that we had an engineering team eating bonbons in the kitchen, waiting for your special request is simply not true. Right.
From the product side, I say this almost every day, sometimes four times a day. Notice it doesn’t help the sales team, because they can’t close the deal unless we agree to do the thing. Yes, Sharon, I see that. I don’t know if it’s laughing or crying. Alright, what else do we say? We say? That’s great. That’s a wonderful deal. That’s a good idea. But the things we’ve promised to the world, things on the roadmap that we’ve announced that are underway, are all more important than your thing. I don’t know if anybody’s ever tried to convince their five or six year old that they should eat their meal in the correct order, and the vegetables come first, and the dessert or sweets or pie comes at the end, it’s pretty hard to convince somebody of a thing they don’t want to believe. Right. And from a sales point of view, of course, the most important deal in the world is the one that I’m going to close and get paid for. So this argument doesn’t really hold very much for the folks who aren’t happy with the answer. What else do we have? Right? The product wasn’t designed to do that? Well, Fu, right. I’ve figured out a customer who’s going to give us money for this thing. We’re going to make it work. Why can’t you be more open minded? Right? What else probably won’t work, the customer is going to be unhappy later. Well, again, here we’re gonna draw the distinction between if we close the deal this quarter, I get paid commission this quarter. And honestly, the salesperson, I have no idea where I’m working next year anyway. Because if we miss our numbers, I’m fired. Right? This This isn’t a persuasive story. Sorry. And what else did we have? Right? Major technical debt? I don’t know if an enterprise sales person on the planet who really believes in the existence of technical debt, right. It’s an excuse that engineering gives us for not doing good job or having sloppy work or wanting to take their weekends off or be with their kids or something. Right. So the I don’t want to do this as a product or engineering leader, because it incurs technical debt has it just rings false, it gets ignored. And I think there’s one more right. This one’s true. By the way. Anything we build for a customer no matter who in the company builds it, including the integration or onboarding or customer success team, we’re obligated to support for as long as they’re paying us money.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
So this idea that the implementation team is going to get something working in time In an API to some third party product, and then move on, has this hanging problem that it’s eventually going to break also for breaks? Who’s going to support it? We all know that it eventually lands on the engineering side. But again, it’s not a very popular answer, and in general doesn’t win. Right? I’m good quiz question for anybody out there who knows the answer? Can anybody define for me a millisecond? And hint, it’s not the scientific definition. awfully quiet. Okay. A milliseconds the time very quick, yes, thank you, uh, milliseconds of the time between when the head of product or engineering, tell someone on the Salesforce that they can have what they need to close the deal in a quarter. And it’s escalated to the CEO. Right? That’s a millisecond. And anyone on the product and engineering side, who doesn’t recognise that behaviour is simply not paying attention. Because again, we’re paying and rewarding our sales team to be persuasive to be, you know, persistent, to figure out who the stakeholders or shareholders are, who can say yes, and to escalate over anyone on the customer side, who’s in the way to find somebody who can sign the deal. And we’re shocked and surprised, shocked that when when we on the product engineering side block a big sale from an from a salesperson that they immediately know how to escalate, because that’s what we’ve taught them and paid them for the last few decades. Alright, we good? All right, we’re ready to paint the other side of this little argument. Okay, so I have binoculars, it turns out in the product business, but especially on the engineering side, most things take longer than we wanted. In fact, there’s a rule of thumb here, which says, all software projects are 30%, late, even if you include the 30%. Right? Everything is harder than we thought everything takes a little longer than we thought everything’s stacked up there. Again, there’s no white space here. So on the product side, we’re usually looking out this quarter, next quarter, three quarters, seven quarters to figure out how we’re going to incrementally improve our situation, right? It’s the long term view. So Right. On the product side, here’s the things we either know or believe. Your choice, I don’t know. And I had a 2015 talk at Business of Software about how you’ll never have enough engineering, right? It’s a fact in every company, every software company, there are fewer engineers than ideas that we want to give them. Right? Never met an engineering team big enough to do everything. So every time we get a new request a new demand a new sales opportunity, we’re going to have to look at what we’re already working on and decide if we cancel something.
And most importantly, from a product point of view, I care less about an individual account. I’m trying to build product that many, many, many hundreds or 1000s of customers and users will take advantage of so the measure of success isn’t that we got one deal, regardless of its price is that we’re building products that the market as a whole is going to absorb and use and pay us for right. We think a lot more about what I would call sales velocity or revenue velocity, which is can we close the next 30 deals faster? Can we get to yes or no faster, rather than creating a whole bunch of special things for one deal. Good example here is special pricing and packaging. Well, it turns out that special pricing and packaging for a big enterprise customer helps close one of the deals. But it creates all this backwash and time and effort on the part of finance and support and product engineering to create all the things that support that special price. And now we’ve slowed ourselves down again, right again, colouring under the curve, every one off is going to push something out of the plan that we already agreed to nature, the beast, right. And then the last one probably most important on the product side is routinely, I would say well above 80%. When we look at how a customer tells us they want to solve a problem. Actually, they don’t they just tell us the solution. They’re almost always wrong. They’re half right, they’re partly right. But our customers don’t understand our internal systems the way we do. And in general, we have to move from the fix they told us to make back to the problem that they actually have, and then back to the best way to fix that problem.
So as product folks, we’re always deeply sceptical of what our customers tell us. And then we’re doubly sceptical of how the sales teams translate that for us, right. And then on the engineering side, just to split that out. Here’s what we know. Every new feature that we add, increases the codebase increases the complexity makes our app harder to use. Anybody who’s struggled with some new feature in Microsoft Word anytime recently and tried to find their way through all the menus, right? As we add more stuff to the product, it gets worse, not better. And so every time we’re going To do a one off or a special for a big customer, it’s going to have downstream impact. That’s bad, right? No products ever finished. So the, the great lie, just do this one time, and you’ll never have to come back and fix it again, not buying it, right. And then architecture, architecture is a word that again, on the sales and implementation side, we mostly ignore. But products are built to purpose for some particular use. And if you bend them enough, they break and we break in the customers break. So again, we’re setting up a situation where the product and engineering side of the house actually has different goals than the sales side. Right? And just for equal time, and I’ll take right, I’ll take some requests here. And here’s anybody old enough to remember Alec Baldwin, right? The quintessential salesperson. I’d love anybody dropped in the chat window. What are the things that we as product and engineering folks completely ignore? When our sales and implementation teams tell us something that they think is really important? Anybody have a favourite? Customers? Yeah, vastness? Sure. But I would take the s off of customers, and I would make it customer, one customer. What else? awfully quiet out there. All right.
All they need is this new field with a drop down? I love it. Yes, that’s exactly it, Brad. Not only have they told us exactly how to fix the problem. But we in our sales team are sure that the customer got it exactly right. And there won’t be anything else in there. Right? It falls under the same class as one size fits. All. Right. Okay. So here, this is a huge revenue opportunity. Of course, every salesperson starts with this phrase. But on the product side, honestly, I’m looking at the aggregate impact on the company, and how big revenue opportunity is less important than the relative size of the revenue versus the effort you’re going to create for me on my product side, what else? There are lots of other customers who want this. Anybody tell me why? Yes, there we go. We don’t need as complicated as products suggested. Thanks, Anna, and you’re over designing it. I love that when I missed that one. So Anna, find me outside, I have a small price for you when when we go offline, right? Lots of other customers will want this now, in the consumer space, I believe it when my sales and support teams telling me this, but in the enterprise space, where each sales team probably only has four accounts they’re working on. And they’re only working on renewals for two of them. And this is one of those two, it turns out that everyone on the sales and implementation side will tell me this sentence. But the believability is pretty low. And in fact, on the product side, we have to go back out in the market and see if it’s true. Right. So much work for us. What else? Oh, here we go. There we go. I’ll take and his answer here can’t be that hard. It’s only 10 lines of code. Can we put it in next week sprint, I heard we’re agile, whatever other, you know, buzzwords come from the go to market side of the house. Just do it. Right. I don’t care. Right. Not interested? What else do we have here? Right, we can solve it with special pricing. We’ll give them the middle package, but we’ll add two more features and engineering can turn on a bunch of permissions and support. We’ll figure out what what we’ve been given right? Oh, anybody ever had this one? Anybody said these words? Right? If they really weren’t going to use it, I’m not sure how much they’re pushing us for. But inevitably, after we’d said they’re not going to use it right. And then of course, this is the other part of it. We don’t need ongoing support. It’s a one time thing. Drop it in there, run away. It’ll be fine. Right? I can’t tell you how many 1000s of hours my product teams have spent on this. So one more, there’s not. Okay.
So again, what what I’m trying to highlight here is that the two sides, the two opposing sides across the table are actually talking about different things shouting at each other, we’re shouting at each other. And the arguments we’re using, just don’t work on the other side, because they don’t play to the issue that the folks on the other side of the table have. Right product, we’re talking about long term impact. on the sales side, we’re talking about short term revenue. Clearly, we’re just gonna butt heads on this. Okay, let’s keep going. Alright, so there’s one, there’s one more group here that’s not present in the room. And it’s actually I think, for me the deciders, which is the people who care about putting money into the company, the investors, the Board of Directors, because this would sound like just some little schoolyard argument, until we asked who’s going to make a lot of money that’s not an employee of the company. Alright, so let’s do that. And here’s what turns out to be true. And I checked with a private equity firm that I do some due diligence for on the side this week. And it If you’re an investor, and you look at a pure play enterprise SAS company, so somebody with with applications, they resell, you actually value that company, it used to be six to 10. And maybe it’s back to 10, with all the financial crises over the last week or so. But in general, the way investors value a software company, is they multiply total revenue by six to 15x. Right? We’ll take 10 for our number, right? Why do they do that? Why? Why is this the investor response? It’s because first of all, you get to price your software, not at what it costs to build. Because honestly, nobody in the world cares how many engineers and designers and product managers you have, nobody’s interested, it’s about value. So if your product will save the company, your customer, a million pounds a year, they’re willing to pay you 100,000, or 150,000 pounds a year for the right to save a million pounds a year, it’s all about the economics. The second piece here is if we stay within our sort of moral compass here and don’t build anything special, the next copy of software, which by the way, is already been built, because it’s the same bits, we can sell that next bit of software for well over 90% margin, we pair sales team, some commission there, some sales overhead, there’s some support overhead. But basically, it’s all free, because we’re sending the same bits to one more person, one more company, right. And so there’s a lot of pressure on from the investor side, to not do specials not to touching, not spend a lot of time onboarding, not do custom integrations, on and on and on, because all of the money or the investors is in selling the same bits over and over again and touching it as little as possible. Right? Why do we care? Here’s the other half of that. If you look at how investors value services firms, that’s software consulting, and customer development, and advertising agencies, and anybody who’s really selling the time of their people, they tend to value that revenue or less. Usually, they go for some EBIT, da thing where they say, Well, how much money are you returning at the end in its margin, right. And if you’re in the integration or services business, sooner or later, it all comes down to cost because there’s a lot of other firms willing to bid Lower 5% Lower for the hourly rate of what they claim are the same kind of people, right, you have to have a concentrate on projects. And there’s very, very little reuse, as much as we lie to ourselves and tell us we’re going to use that same platform. And exactly the same way next time, it just doesn’t happen. So from an investor point of view, there’s a huge push away from the quarterly, let’s do a special it’s a big deal, we can interrupt this the roadmap, run up some tech debt next year, with one exception. And the exception is, if you’re a private equity firm, and you intend to flip this firm within the next two years, you’re willing to run up tremendous technical debt, as long as you can sell the company off before that technical debt comes home. So again, the the investor push on the CEO is really important here. And it’s useful from an internal politics and process point of view, to realise where the pushes are coming from. Anybody shocked that I’m from the States and talking about money.
There we go. Okay, let’s keep going. So last piece here, and this is a pie chart I use all the time all the time, all the time with my clients, is we can’t put 100% of our engineering effort into new features that people want this week or this quarter. A good balanced plan, where we’re going to build things and also maintain them and have them continue to work looks vaguely like this, right on the left, roughly half of all the engineering work is going to go into things that customers see and request and maybe even want if on a good day, we’re doing it right. So that’s any new feature, any new workflow, improvements, integrations, you know, downloads, better logins, two factor three factors, 16, factor authentication, whatever it is, right. All the things on the left in purple, are what our sales and implementation and advisory board folks who are begging and screaming at us to do on the right in red is all the things you have to do to actually stay in the software business. And so if we stumble on scalability, if we forget about security, if we didn’t think GDPR was anything but four letters, right? If we don’t have DevOps, if we’re not doing automated testing, we ended up putting ourselves out of business. So it’s really important that something on the order of 40%, or maybe more of all of the engineering cycles go to things that the go to market team doesn’t really care about so much now except when it fails. At the bottom, a little slice for discovery. That’s the bit of advertisement for product management because turns out to be Guess wasting this pie is building something that very few or no customers are going to use. So discovery validation getting out in the market are we actually building a thing that’s going to move the needle, bring in revenue, make lots of customers happy. And then as a concession, because we’re in the enterprise space, the blue slice at the top, there’s always two or three deals during the quarter that we cave on, on the product side, because the CEO needs them. And we’ve got to close revenue. But when that slice gets above about 10%, I start to see the whole system degrade. Right? So knowing that we got different animals here is actually a really good tool to figure out what we’re prioritising as to other things. We’ll come back to that, I think in the q&a and the breakout. Okay, taking a big deep breath here. Oh, there we go. I’m sorry, Anna, you win a double triple prize on this with the phrase, I just need some demo where, right? Hint. If you’re doing enterprise software, and you’re creating your your demo software in figma, or something other than a screen capture of your actual software, you’re already in a world of hurt and bad things are gonna happen. Right? The three crowns are around the little Potter gonna stir and put a curse on you and your Macbeth. Okay, so, moving ahead. Where are we? Alright, so here’s some takeaways.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
And then we’re going to just open this up for conversation on the hopes that I haven’t triggered too much PTSD with anybody who’s on either side of this right. And oh, hint here for anybody who missed it. That picture on the right, at least here in the US, we call that a takeaway container. There you have it. Okay. So fundamental challenge. I don’t think this is about personalities. I don’t think that replacing your head of sales or head of product, your head of engineering solves this problem, because I don’t think it’s about people who don’t like you. Right? It’s about misaligned goals and misaligned timeframes that will continue to haunt the company, no matter who’s sitting in that chair. So I try my best to pull myself out of the personality who hit home first, I think you’re wearing ugly clothes, whatever kind of insults come out of here that are picking on people, right? Second one is, right? We all know this, the long term doesn’t bite you until it does. I’m sure there’s some, you know, variation here on climate change. Right? What was what was the movie? Don’t look up. Anybody seen this? This little silly parable about the asteroid that’s coming? Right? The long term doesn’t arrive, it doesn’t arrive until it does. Gosh, what’s what’s the William Gibson approach, quote, The future is here. It’s just not evenly distributed. Okay, so that’s a third thing. The cost of specials is really, really high. If you’re a startup, you do every kind of unnatural thing you have to do to close those first five or eight customers. But you’re going to have to unwind it when I when I visit with or consult with a an enterprise company. And they’ve got 24 customers, and 22 code lines. I pretty much know the game’s over, right? There are services for more, they’re out of business, your choice. Okay. So therefore, so here’s the the important takeaway. I see this as a C level as an executive level problem. And it’s a scorekeeping problem, because we can’t let sales win all the time. And we can’t let product and engineering win all the time. But most importantly, for me, I can’t have sales be both the scorekeeper and a player on this turns out there’s there’s a medical syndrome you guys may not have heard about. It’s called roadmap amnesia. Right? And in roadmap amnesia, we all agree at the beginning of the quarter exactly what the priorities are for what the company is going to build on a Tuesday. And by Thursday, when a big sales opportunity comes in whatever team is on that has either forgotten what’s on the roadmap or doesn’t care, right? Likewise, there’s a syndrome here. And Mark, I think, hinted to it while we were on the break. But there’s an amnesia problem with how many specials we’ve done, because it turns out that each sales team wants just one or two specials. But if you have 12, sales teams do the math. It turns out that each of them got one special or two, and you now have 25 of them. And they’ve crowded out every single thing on your roadmap, including all the maintenance. So there has to be some scorekeeper. Maybe it lives in product, maybe it lives in finance, right? Who identifies that we’ve used the two specials for the quarter and we’re done. We’re over the cupboard is bare moving on? No more choices come back next quarter. When we give that back to sales, bad things happen. And then I think finally we got one more here. Another out in this problem, you If you’re really a product company, is you find a bunch of service companies you want to pair with you want to partner with, and you give some other company, all the services work, or you and a partner, to close a deal with a big customer, and you don’t even take the money, you just pass the money along or direct it to some service company that is in the business of building special wonderful things, and maintaining them over time at a price from the end customer. If you can split these two into different businesses, suddenly, some of the incentive lineup, right, last thing and I skipped that sub bullet on on item number four. For me, it’s my favourite. I love salespeople. I hardly even resent the fact that they make two or three times as much money as I do. And I deeply respect the fact that I have a lot more advanced degrees, and it’s not of help on the sales side. Right. But what’s important is to know that good salespeople do something actually. What we’ll we’ll take one more from the field, anybody know the very, very first thing that every good salesperson does at the very beginning of every quarter. Anybody been a salesperson? Come on, carried a bag had a quota. Okay, the very first thing that every good seasoned experienced salesperson does the beginning of the quarter, is they deeply inspect their compensation plan. And they figured out how they’re going to hit quota with the least amount of deals and effort. Right? Turns out all the economists have been telling us for years that people don’t do what we want them to do. They do what we pay them to do, particularly on the on the go to market side. So if our comp plan rewards salespeople for bringing in special contracts on things we don’t do. And it’s easier than selling the standard product, that’s exactly what they’re going to do. And it’s our fault. Because we set up a comp plan that encourages them to do the thing that undermines and breaks the roadmap every week, right? So for instance, a thought here is perhaps our company should change his comp plan. So you get 110% quota relief on selling exactly what’s in the product. And we don’t pay you if you sell anything else. You’d be surprised how fast some behaviours change. But if we’re not dealing with the comp plan, then we should expect the sales team to continue to do what they what they’re paid to do, which is be the customers advocate on an individual account level, regardless of whether it makes any sense for the company as a whole. Okay, I’m going to take a breath here, a little commercial announcement, I think here’s how to find me. Last one, and anybody who doesn’t know the answer, you may notice that my last name and my domain name are the same. And you might know that there’s something like 28 million people in the former Soviet states with my last name. Anybody know how it is that I have my own name as my domain?
Luck. Yeah. So luck a really good answer. And I’d go with that. But I got in quick. That’s it. I bought my domain in 1993. And no, not much of the eastern half of Europe and Asia was on the minute there. So anyway, 21 years worth of blog posts, they’re help yourself. Some of them are funny, and some of them are not. They’re all designed around the problem of the executive issues of product and organisations. Okay, so I’m done with the chat. It’s 40 minutes past your 20 minutes of habit, if we open this up for whatever wild q&a anybody’s got.
Mark Littlewood
Great. Thank you Rich. And at this point, I’d suggest if you want to take yourself off mute, that’s absolutely fine. Unless you’ve got fighting cat and dog, or how do they how do they behave themselves Rich when you’re actually speaking, because it’s the first time that I’ve seen you at Zoom for more than 30 minutes.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
Rich Mironov
I see. Well, it’s it’s early here and I had the dogs out for a walk at 5am. So they’re sleeping at my feet politely. And the heads and the headset means none of the noise that you guys are making is coming through to disturb them. So right now we’re fine. The puppy does tend to chase the kitten a bit. And she’s not excited about that. So I’m the referee on this.
Mark Littlewood
Right, so maybe give the first question to Anna, who has been doing a very, very good impression of being teacher’s pet here. Go ahead.
Audience Member
Oh, I didn’t know if I’ve got a question. Okay, well, you’ve got some answers, no longer teacher’s pet, right. But yeah, very, very timely for lots of conversations here about how You know, sort of on the commercial side of our business and how sort of suddenly all focus is like, well, focus is on this particular thing and all perspective gets gets lost. So I can see why now I can see this MCs.
Rich Mironov
How do you make it work? Got it? Well, and I think that’s the real challenge. I do a lot of coaching of heads of product. That’s mostly what I spend my time doing. And routinely, someone who’s new to the head of product, or the product or Chief Product job, has this very odd, quaint impression that the way you convince folks in the rest of the company have your point of view, starts with a spreadsheet that has six columns in 145, or 500 rows. And then if I walk the whole company, through all of the logic, and the weightings and the business cases, everyone will agree with me because I am smarter than them. Right? More advanced degrees, I might even have an MBA or equivalent, right? Turns out..
Audience Member
That’s very logical.
Rich Mironov
..and also logical. That’s right. There we are. Right. But it turns out, that’s not a very persuasive point of view, at least for the folks who are being paid to not think that that’s a persuasive point of view. Right. So this is much more of a people issue. And a I think it’s a management systems issue. So back to the trade offs here. The coaching, I usually provide starts with every new thing isn’t a an exclusive or relationship to some old thing we’re going to have to take out and you have to name it specifically. So when the sales team or the VP of sales, or the CEO comes to me and says, we just got off the phone with HSBC, whoever it is, right? And they’re going to give us fill in large amount 900,000 pounds, if we just fill in something impossible, right? The right answer can’t just be no drop dead, right, we have to present the business choice. And the business choice, for instance, is to say, Well, that seems pretty big. Remember, there’s no whitespace or, or gaps or capacity on the engineering side. Here’s what I propose, we cancel in its place. And the thing we’re going to cancel is we’re on version 7.2 of our product. And we’re working on version eight. And every one of our 1000 customers is waiting for version eight, because it has all these benefits. But if this deal is more important, we will put on hold the number one thing we’ve announced to the world that millions and millions of currency units are depending on, we’re happy to postpone that a couple of quarters. And here’s how much it’s going to cost the company. Notice, notice that’s not a discussion about tech debt. Write it. One more thought here again, out of my coaching, sometimes we talk about reverse dog whistles. I know this story, okay. So a dog whistle for those of us who know dogs, right? The dogs can hear it, the people can’t because the frequency or reverse dog whistle is when you say something that no one pays any attention to or hears. Right. And my advice to folks on the product side is any sentence that comes out of your mouth, that’s for the rest of the executive team that’s not denominated in money won’t be heard. Now, we may be talking about short term versus long term money, that’s fine. But these discussions are about money. And so if if we want to be included in the table and not sent to the, to the small kids table to eat with the other little small kids, we have to be talking about money as much as we’re talking about tech. So that’s a training issue. That’s a conversation issue. And how do we explain in money terms? What those 16 outages this quarter cost us and all the hundreds of customers who turned away because we promised ourselves once again that just this quarter, we wouldn’t invest in any infrastructure tech debt, but we’ll catch up next quarter. That’s a lie, by the way. Okay, long answer. Anybody else have have one to throw at me?
Mark Littlewood
As soon as got one to throw in?
Rich Mironov
No, no, go ahead.
Audience Member
Thank you, Mark. Hey, Rich. This is I wrote in there. It’s like so familiar.
Rich Mironov
Sorry, it is I wish.
Audience Member
So I offer a service that’s I tried squawky birds, no dogs or cats, sorry. And our business is a small one. And we offer software testing as a service. And so startups bring us in to work on quality etc. And I’m starting to see over the last two years is I think more especially to because of this conference and focusing on the business end of things for me personally, but now I’m seeing their businesses and exactly what you’ve described and I can’t test or put in place anything quality, if I don’t understand all of these things that you’re talking about that are extremely broken in these companies, I don’t know what to do. Is there anything I can do?
Rich Mironov
I think so. And, and, you know, let’s think about the testing in a slightly longer a longer context, right. So, you know, most software companies either forgot to do testing or promised they would do it next quarter. next quarter real in the same way that we promised ourselves, we’re going to go to the gym and exercise next week, but not this week. Right. So I think you might think of this both as a bridge and as a training opportunity. So you can help your clients get from here to a little further down the road, both build some tests for them, run some tests for them, show it house, show them how it works, you might be thinking about embedding some folks in there to help them get over the hump to a place where there’s enough testing that they can now be self sufficient. Yeah,
Audience Member
so we do have that good, good. I mean, that’s what we kind of started with, is just regression testing and embedded testing and slowly, and it works when they’re small, getting in with companies that are 50 to 150, that already are like, a mess.
Rich Mironov
And they will continue to be a mess until they solve this problem. Right. So, so the idea that the quality issues will go away if we just wait, I think is is insincere. Right. So, you know, you know, how do you help sell to them? The getting sufficiently close, and but training them how to do it if they’re willing? Right, yeah.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
Audience Member
That’s what I’m trying to do. That’s right.
Rich Mironov
If they’re not willing to invest in ongoing testing internally, and they’re not willing to hire you forever, then I predict some bad times ahead of them.
Audience Member
Yeah, I’ve seen that.
Rich Mironov
Rough seas.
Audience Member
Excellent. Yeah. Yeah, I could go on.
Rich Mironov
That’s right. So you know, I have this stack of analogies for what we’re talking about. The one I use with CEOs a lot is, and it’s a bit sexist. So I apologise in advance. But how, how is it that that a teenage boy eats an entire chocolate cake that’s on your kitchen? Table? I know this one, because I would do it. Okay. The answer is, each time he walks in the kitchen, he grabs a fork, and he takes just one little bite of the cake. Right. And by the end of the day, the cake is gone. But we have no idea how this happened, right? The quality issue is sort of the reverse side of this, which is until we get to 30 or 40% coverage, it doesn’t really help us much. But but we have to do it to stay in business.
Audience Member
Right? Gotta come to me.
Rich Mironov
Yeah, sorry, if it’s too familiar, good. Anybody else have a war story or thought?
Audience Member
I’ve got one Rich, forgotten what you’re talking about just now priorities. I like the one in one out process. But it doesn’t really work emotional blackmail. I like the approach that we could stop this this thing that you’re going to miss. So how, how else do we manage when I put in just now everything seems to be a priority one? Right? They say that’s the top priority. Well, what about this one that you’ve asked me to do? Yes, that is as well. What about this? Yes, that is, so there doesn’t seem to be any quarter to negotiate out of it, then you just take on more deliver probably less quality? Because you’re doing too much.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
Rich Mironov
Right? Well, let’s first let’s acknowledge what the end result of that is. So any company that’s got 11, number one priorities actually isn’t finishing any of them? Were maybe one of them. And we’re not sure which one. So, so the the intellectual dodge that says we have 14 High, the number one priority things is, it’s just not true. Right doesn’t work. And, you know, get I’m gonna think about the psychology rather than the fact base here. But if we look around the executive table, and there’s no one other than engineering and product who recognises that we have to have no more than one or two number one priorities. Honestly, it’s time for the head of product to dust off her CV and go work somewhere else, because it simply doesn’t solve, right. And so, and the number one reason the heads of product get fired in my limited data set over the last four decades, is that the rest of the executive team gets tired of hearing no, that that we’re all we’re all eager for a little pixie dust or a magic wand or some magical thinking that will somehow make it true that engineering can get four times as much done as they’ve ever done before and we can have 11 number one priorities right. So so this is tough talk. And, you know, it’s it’s folding one’s arms and sitting quietly. And, and waiting for it all to burn down every once in a while, right? Because the logical sentence, we have eight number one priorities just doesn’t work for me. Yeah,
Audience Member
the other thing we get is that it is his number one priority. But don’t worry, here’s some money, go get some more people. And they think that instantly because they’ve got wave in the one set you, you can write off that, but you’ve got to get them on board them you’ve got to get?
Rich Mironov
Well, I think I think that’s mostly true. And you know, if we, again, anybody old enough to remember that Fred Brooks in 1974, wrote a book called The myth, the mythical man month, it tells us that adding more people late in a project makes it later there, there are some things you guys didn’t notice. Okay, I’ll get to the reference. But there are some pieces of work that can in fact, be outsourced. Right. And if you’re, if you’re clever early on, in, in planning those out from product engineering sense, you can actually free up a bunch of energy here. So for instance, if your application has a generic well supported API for input and output of data, then and only then you can take that money or the customer can take that money and give it to the PwC isn’t Infosys isn’t anybody else’s in the world to write to your API and pull data in and out? But you can’t do that after the fact? Right? So So part of the product discipline is to look at the look at the whole sort of product suite and say, Where do we want to find opportunities for money and outsourcing and partnerships and taking a bunch of load off our backs? And where is it critically strategic to the internal workings of what we’re doing? Right. And so, so a product and engineering team that hasn’t thought about this will in fact, be stuck? Because there’s nowhere we can spend money? Right? But if we’ve thoughtfully laid this out, there might be two or three opportunities that create a lot of revenue. Because what was that word architecture that we had before it turns out to be important, right? The other thing, and I didn’t put it in our quote list, but yes, this idea that if I give you money on a Tuesday, you can have people hard on a Wednesday morning, they can be productive, is completely false, right? By Thursday. But it’s counterintuitive, right? It’s very counterintuitive. So whining about it doesn’t help so much. You know, we have we have talked about grownups. Right, that simply doesn’t work. But trying to take the morally superior tone here is off putting. Okay, so we got time for one or two more. Go ahead, Mark.
Audience Member
Well, I had a question about that. It’s really, I really empathise with people in big organisations that are doing product, particularly when those organisations suddenly decide their product companies, and they weren’t before and the CEO announces, and you’re giggling, and I know a few people on this session are kind of wincing, but let’s not, you know, name people. How do you, you can’t be product driven, if your senior leadership team doesn’t know what that means. They’ve heard it as a thing. And they’ve been told about it. Now, those organisations change, how do you start effecting that change? And how do you start making that happen? So that’s maybe on a slightly more mature.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.
Rich Mironov
I think that’s right. And, and just acknowledging what what Mark said, I think this is a really, really, really hard transition. Mostly because every single bit of executive behaviour in a services company in an agency company in a an outsourcing company is exactly opposite to the executive behaviour of a product company. Right? So when, when some sales team calls up and says, We just gotten off the phone with big company X, they’re gonna give us a lot of money. If you’re a services company, the very first word out of your mouth is Yes. And you don’t need any more words, right? We might have some words like we have to hire some more people because we’re out of bandwidth, right? But a service company is actually in the business of doing one off one at a time special stuff for money, whether the end customer gets value or not. And they measure themselves on margin per deal. That’s what a service company is. A product company has none of those characteristics. What I find is until we’ve rotated out two or three of the most senior members of the executive team, for folks who’ve come from the product side, not from the services side, very difficult. In Enterprise in consumer I don’t see this problem. So if you’re selling 500,000 units of something at nine pounds apiece, There’s actually no one customer who’s big enough that their opinion matters. And so you’re really talking about aggregate impact. And if we add a feature, or we change a thing, can we get 50,000 more buyers, that’s about surveys, that’s about large numbers, that’s about aggregate impact. So in the consumer space, everybody’s used to thinking of product lead, because product lead and marketing lead are really the same thing. And you hardly need a sales force, right? A lot of consumer, you know, b2c folks either don’t have a sales force, or they have a business development team, it hardly matters, right? Because you’re selling in large numbers of small dollars. If your company has 11 deals this quarter, each of which represents 1/11 of your revenue. And if we lose any of those 11 deals, people get fired, suddenly, the names, those deals really matter. And the escalations, those really, really matter, and the product and engineering folks have lost most of their seat at the table. Right? So what I find is, honestly, the very first thing I do in this situation, is I look up the CEO on LinkedIn. And I try to make some determination whether they came from the sales side of life or the engineering side of life, and I decide if I’m interested in technique engagement.
Audience Member
Okay, but what about the people that have committed during Well, I’m already..
Rich Mironov
I don’t know much about UK law. Okay, we’re around the world. But in the US, long ago, we outlawed indentured servitude. And what that means is that if you’re at a company that is organised in a way such that your function can’t succeed, and you are going to fail at your job, you have other options. Was that too strong a recommendation?
Audience Member
No, I think that’s where you, that’s where you end up.
Rich Mironov
That is where you ended up this if if your job as the head of product, or the head of engineering, is to build a platform and product that 1000s of customers are going to love and use and has great experience and doesn’t ever fail and determines great and delivers great value. But the deciding half of the organisation undercut you every few days to do a special for a big customer, that’s not going to serve the rest of the customer base. That’s that’s not a really good story. And so one side of the other is going to have to back down. And my observation of enterprise software companies that are run by salespeople is I know which side?
Audience Member
Well, let’s be let’s be a little bit more charitable, let’s say that the CEO wants this to happen. Yes, it just, they just know.
Rich Mironov
Right? So so for that, what I look for, and I’ll put my small agile hat on for a minute, what we have to do is we have to have some wins within the first 190 or 120 days that show not tell, but show that a product light approach delivers more money. So we find a couple of quick wins, where we can make some improvements that improve our top of funnel or get people sign up more, or reduce the number of tech support calls or any of the other things that have been sitting in the back waiting. And we bring forward a couple of those, and we denominate them in money. And we show that if we fix a really big bug, we reduce our support calls by 1000 A quarter. And we multiply that by the $100. Now we pay our support team and the 20 Customers who now don’t churn away because they’re not all pissed off at us, right. And we we find a way to do some product, lead work, whatever we call it, because the name doesn’t matter, right. And we show that there’s money in it. And that we convince people that this is a plan we can follow for long enough to show some larger results. Even if the money is small. We have to denominate in a way that the organisation appreciates. instead of whining about how many tickets we have, and whining about downtime, we have to we have to show somebody that we can fix a couple of things if we’re left alone long enough to do them that are valuable to the larger customer base in the company. Right? That’s the grown up conversation. Now may or may not be possible do depends on where you’re starting. Sometimes we got you know, two centuries of tech debt because the original code was written on, you know, bare skins with stone knives and hand carried over the over to the compiler. But you know, the whining and complaining I find not to be useful when the executive team is excited. We have to show them. One of the thing that we can show them is we can pull out an insider to from all the customer interviews that we do, which is shocking and surprising to the rest of the company even though we’ve told them too many times. Right. There’s a thing that we know. That’s why we’re not getting renewals and churn is so high and money is falling off the edge. It’s reason x and if you’d let us fix reason x, we think we could reduce the churn rate by 5%. Multiply through what’s it worth?
Rich Mironov
Smokejumper
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
BoS Europe 2025 🇬🇧
🗓️ 31 March – 1 April 2025
📍 Cambridge, UK
9 DAYS LEFT for Early Bird Tickets.
Spend time with other smart people in a supportive community of SaaS & software entrepreneurs who want to build great products and companies.
BoS USA 2025 🇺🇸
🗓️ To be announced soon
📍 Raleigh, NC
Learn how great software companies are built at an extraordinary conference run since 2007 to help you build long term, profitable, sustainable businesses.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.