Join Murray Robinson and Shane Gibson as they talk with Rich Mironov about the problem with sales led development. It’s easy for B2B enterprise companies to fall into a sales lead development model where the majority of development work is customisation starving the core product of resources for innovation, new features, quality improvements and technical resilience. The end result is frustrated product development and engineering teams, uninspiring products, low profitability, slow growth and difficulty getting investment. Fixing it requires product leaders to help executives understand that the economics of a product and service business are very different and they need to change their behaviour accordingly.

Read along you will

Murray: In this episode, we talked to Rich mironov about the problem with sales led development. It’s easy for B2B enterprise companies to fall into a sales lead development model where the majority of development work is customization starving the core product of resources for innovation, new features, quality improvements and technical resilience. The end result is frustrated product development and engineering teams, uninspiring products, low profitability, slow growth and difficulty getting investment. Fixing it requires product leaders to help executives understand that the economics of a product and service business are very different and they need to change their behavior accordingly. 

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson.

Rich: and I’m Rich Mironov. 

Murray: Hi, Rich. Thanks for coming on to talk to us today. 

Rich: My pleasure. 

Murray: So we want to talk to you about the problem with sales led product development. But why don’t you start us off by letting us know about who you are and what your background and experience is.

Rich: Sure. So I’m a 40 year veteran of mostly enterprise B2B software from Silicon Valley. So that’s six startups, four of which we file under good character building and life lessons cuz that’s just what happened. Been independent for the last 20 plus years. On occasion I parachute into some software company that forgot to have someone running their product team for three to six months and straighten it out and hire my replacement.

I coach heads of product or the most senior product person, mostly at B2B commercial software companies. That’s a mix of technique and psychiatry. I do a little bit of due diligence for a couple of investor firms where they have me look at B2B SaaS companies before they decide to invest. And I do a lot of writing mostly around the subjects of how the most senior product folks at a company deal with the other executive stakeholders. And how we get things done in a world where the other executives actually aren’t very interested in agile or engineering or how any of this stuff gets built. They just want it yesterday at half the cost and twice the quality. And every idea they have in the shower in the morning should be something we’re ready to roll right into production.

Murray: Okay. What are some, big brand names or products that we might have heard of that you’ve worked with? 

Rich: I worked at Hewlett Packard way back in the day. I was writing COBAL in the early eighties when that was a thing. We did tandem computers in the late eighties, early nineties, and the days of the mini computers. I spent a bunch of years at Sybase in the early days of the database wars. Most of the startups I was doing were around communications and networking and security and bits of tech that big enterprises would deploy in the back where nobody would see them.

These days most of my work is with big e-commerce companies, small to medium backend, business to business, SaaS companies, and little bits of stuff. I mostly avoid working with banks and insurance companies and airlines and government agencies that aren’t in the business of making software for money. Because I find that most of those folks have even less interest in building great software than the companies whose business is software itself.

Murray: Okay, good. I wanted to get you on because I saw your article, the Slippery Slope of Sales Led Development, which has a big crack pipe at the top of it.

Rich: And I’ll tell you, important for me to say that’s a stock photo of a crack pipe that was not actually my own crack pipe. I didn’t go to my, shelf for that.

Murray: That’s good. So tell us about the problem with sales lead product development.

Rich: Okay, good. And let me frame it in the context of B2B enterprise software companies who are in the software product business. So if you’re trying to produce a set of B2B software that you’re going to sell to a lot of customers, the way you make money in that business is you sell the same bits over and over again. That’s really important. 

So, if you’re in a multi-tenant setting, you add new customers without creating new code lines, without creating new branches, without hosting it somewhere else, without putting it on-prem. The way you make money in the software business is build once, sell many. Which seems obvious to everybody, and it’s how investors think.

The challenge in enterprise companies is that we hire salespeople and sales executives and sales leaders for a set of very specific skills. They’re persuasive. They’re persistent. They’re willing to position whatever it is that we’ve got to be the solution that the customer should want, and most importantly, they all as good salespeople know that when one of the prospects gives them the wrong answer or says no, they immediately look to who is higher in the organization to escalate the issue and re-litigate or reopen the sales opportunity because it isn’t selling until somebody said no three times.

All of which is great. That’s what I love about enterprise salespeople. I don’t resent the fact that they make twice what I make. But when we are in the moment, when one of those salespeople gets off a phone call with some big prospect, qualified or not. And that prospect wants some little tiny thing that’s not in our product.

They’re gonna apply all of the same skills, they’re persistent. They’re persuasive. The definition of a millisecond here is the time between when a product manager tells them they can’t have this little feature they need, and when they escalate it to the ceo, that’s the clear path here.

We pay our salespeople to do that and we shouldn’t be surprised when they do that. And it almost always turns out that little tiny feature isn’t little and tiny and that the theory that everybody else wants it is mostly untrue. That’s just how it plays out. And so we’re in a situation where all of us product and engineering folks with all of our spreadsheets and all of our backlogs and all of our tools are trying to explain why some salesperson isn’t gonna get commission this quarter and is gonna get fired because we won’t do the thing they say they need. And we’re surprised when it’s really a political and personal issue rather than a technical issue. 

So in an enterprise company where that deal matters and the board of directors actually knows the names of the 10 largest prospective deals this quarter and is pounding the CEO for status on how we’re doing with, a Z Bank or JP Morgan Chase or Broken Hill, or whoever it is, the idea that some product managers gonna throw themselves in the way and say, no, I don’t want to do that for good reason just often doesn’t hold water. It just doesn’t work.

Murray: Yeah. So what happens when you start doing these one off sales led changes to your product?

Rich: Yeah it turns out that one or two of them isn’t so bad, but it’s a behavior problem in my view. So at the very beginning of the quarter, some sales team has some big deal and it needs a little thing, and they escalated to the C E o and we on the engineering and product side get overruled and we grumble about it, but it’s small and we put it in the plan somehow and make some room and we do it. Unfortunately, the next thing that happens is that sales rep who’s gonna get a really big fat commission check, takes all of the other sales reps out for drinks. And Triumphantly explains that the way that he or she got this deal done was by overriding or sidestepping or pushing aside the product and engineering folks and going to the ceo.

We’ve now established a behavior pattern where the executive team is used to saying yes, not no and their hypnotized by the size of the deal. So in the second week of the quarter, some other team does the same thing and we displace another little bit of our regular roadmap for the quarter. And then in the third week, it’s the next sales team. And so when we retrospectively look back on the first 10 weeks of the quarter, what we figure out is that we had all these things we planned to do and 70% of them have incrementally been given away or pushed aside or delayed, whatever it is for these individual, one at a time sales opportunities. 

Shane: And we get beaten up for not delivering what we promised at the beginning of the quarter. They forget the fact that actually they swapped some stuff out and there was a cost and a consequence. It was like, oh, but you didn’t deliver what you said you were gonna deliver. 

Rich: That’s exactly right. So there’s roadmap amnesia. Okay? So roadmap amnesia is the psychological thing that happens when anyone on the go-to-market side of our company hears about a deal that’s worth more than 2 million or whatever your threshold is. It wipes their brain of everything we’ve committed before and everything we said we were gonna do, and everything that we agreed was our strategy. Because 2 million is a lot of money. And so the first thing that happens is folks come into that meeting thinking that engineering’s actually not working on anything we’ve forgotten. And clearly if they’re sitting around, eating bon bons and playing Fortnite this is more important. The other thing that happens immediately after the executive team agrees to do this next thing is the thing I call commitment amnesia.

So from a sales point of view, we’re closed. I’m gonna get paid, we’re done. I’m moving on to the next account. And the fact that there’s 470 years worth of engineering that we just signed up for isn’t my problem, and I’m no longer concerned with it. So the whole sales organization moves from, I got what I wanted on deal one to, okay, now we move to deal two. And the downstream effects of bad design and poor contracts. And we shouldn’t have built that and nobody’s gonna use it and it’s not gonna work. And we have to pull everybody off of what we’re doing are lost. They’re forgotten. They’re wiped clean because the sales team’s paid to move on to the next thing and assume somehow that all the downstream stuff’s gonna get done. So we’re in this place where we’ve created this behavioral loop of repeated larger and larger interrupts and one off things that engineering has to catch and product hates.

Murray: Yeah, I’ve certainly seen this issue where the sales team and the executives commit something to a customer overriding engineering and product completely, and then just disappear. When the engineering and product team have problems delivering it, and they cannot meet the commitment the sales team are nowhere to be found. So all the negotiations and the renegotiations about the contract and the customer expectation management they are not involved in it all.

Shane: Yeah, but having started my career working for B2B enterprise software companies based in the US we had a term for that. It was called Don’t confuse selling with implementing. And we never did. 

We also have feature memories that are like an elephant, and the way it worked for me was, Oh, well we’ve asked for that and it’s getting done for that customer. So now it’s a feature. I haven’t seen it yet, but I know we’re doing it. So for the next customer, I’m not even gonna say, oh, that’s coming. It’s done. Yeah. How hard can it be? You’re just gonna build it for me. So that’s a feature I know we have now. 

Rich: That’s right. That tiny feature that the sales team committed to the customer that we haven’t heard about yet? First of all according to our sales team, it’s really easy. It’s probably no more than 10 lines of code and second it’s teleportation. So at the very beginning of the quarter, the executive team beat on us mercilessly to make sure there’s no slack in our schedule or plan. That we’re up to our ears or our elbows in work that needs to be done. It’s all committed. It’s all promised to the board and the customers. We’ve announced it and then throughout the quarter, what we do as a company is we throw one more steep steaming heap of trouble on top of that and pretend that we aren’t gonna have to take something out. And so when we look at the sales led roadmap, what I see is that at the beginning of every quarter we work really hard as a product and engineering and design team to figure out what needs to get done, and we commit to it. And then somehow it’s sliced off one little piece at a time. At the end of the quarter, we discover we did almost none of the things that we intended to do, and which most of our customers are waiting for, and were promised.

Murray: So let me be a bit of a devil’s advocate for the sales team here. All this product stuff is theoretical. It’s all comes from a bunch of people in the ivory tower making stuff up and looking at competitive feature lists. We here in the sales team know what customers really want cuz we’re talking to them every day. So product team should listen to us because we are out there pounding the pavement. We’ve got real customer demand for real features. And the product team should focus on that because that’s real. You product, people talk all the time about talking to customers and researching customer needs and listening to customers and giving customers what they really want. We’re telling you what it is cuz we are talking to them.

Rich: Sure. And that is exactly the answer I expect to get. So let’s carve up the problem a little bit. If our company is in the business of custom development and that’s the business of ask one customer who has budget and purchase order what they want, have them write it down for us and we build it. That’s actually exactly what we should do. So if we’re in the business of one client at a time you don’t need product folks. You need project and program managers who carefully take down what the specs are and stand over the development team with whips and get it And it turns out that it doesn’t matter whether the end customer who’s paying for this actually gets value out of it. If they ask us to build something dumb that isn’t gonna move their business ahead or they’re never gonna deploy, they still have to pay us for it. So if you’re in the professional services business, the custom development business, then that’s what you should do.

Sales led makes perfect sense, and product folks aren’t gonna be at that company very long cuz they’re not welcome and they’re not needed. But if we go back to the economic problem the way we make money in the software business as product companies is we create a set of bits that we can sell 50 times or a thousand times.

Then it turns out that the sales teams only represent one customer at a time. Second, they almost never ask any of the questions that product folks ask. They’re asking questions about what do you want and how much budget do you have and who signs for it? And they’re mostly not interested in the questions of how big is it or can we reuse it or is it hard to do or will it work. Cuz they’re sales, that’s not their job. And so individual sales teams are going to represent incorrectly that they know what the market wants.

And the distinction here is really important between account at a time or customer at a time, folks and segment or market at a time folks. If I’m in the product side, what I’m trying to answer is what can we build that 500 businesses will pay for or 5,000 businesses will pay for? Cuz that’s where the money is. 

Outside investors value, repeatable, frictionless, identical sales of software at six to 15 times revenue, and they value services or one-offs or professional stuff at one x. That means is it’s worth 10 times more if we can build something that we can sell to 10 customers, then if we build it for one customer. And it turns out that the sales teams, at least in the enterprise space, rarely have either the insight or the incentive to look at markets because that’s not how we pay them. That’s not how we hire them. So I don’t feel bad about the job they’re doing, but I don’t think we can depend on our enterprise sales team to drive strategy and market share for the company.

Murray: Yeah, there’s certainly a huge difference in profit margin. I’ve worked for, some of those service organizations where they would make a 10% net profit at the end of the day. Whereas Microsoft, if they sell you a $300 copy of Windows, it’s cost them like 50 cents.

Rich: That’s right. In general, we expect if if you can sell the same bits, ideally multi-tenant hosted, where you’re just gonna create some new accounts. The two major expenses, one is the sales commission at say two and a half percent. And the other is whatever bits of technical support you provide along the way. So if you can sell exactly the same bits, you’re in the order of 95 to 97% margin, which is something that services firms can’t ever do, but it requires a tremendous amount of discipline. Around the executive table for a coalition of folks on the financing product and engineering and marketing side to say, no, we’re gonna take that piece of custom work and we’re gonna give it to some development partner of ours, the PWCs of the world, and we’re gonna let them take the money for whatever crazy integrations or stupid new things they want, and we’re gonna keep the money for the license and we’re not gonna create a new code line, and we’re not gonna create a one-off, and we’re not gonna alter the permissions to let them do a new thing and we’re not going to. It’s a tremendous amount of discipline that’s hard to find.

Shane: Yeah, and I think, We’ve seen the cost of acquired numbers being horrendous. Whether it’s sales lead or product lead growth, their acquisition costs are through the roof. Their profitability is down. They’re not profitable. They’re losing money handover fists. But then if there was actually a need to customize what they’re doing on top of that, when they’re already making a loss by doing the builder once sell it many, you can just imagine, or every time they had a new feature, they’re just doubling down on that loss. Their ability to, use lifetime value to come back to anything that looks like profitability must go out from, what, nine to 12 months to five years? 

Rich: Lemme back us up a step. Okay. So the challenge with companies that are selling the same bits many times is they have to get past break even. Okay. So if it costs me a million dollars a year to build and maintain my enterprise software, and I sell it for 50,000 a copy, then the first 20 gets me to break even. If I can’t sell 20, I’m out of business. But notice the 21st of those is almost a hundred percent margin, and the 22nd is almost a hundred percent margin. So if we can build something that the world wants in volume, it’s a license to print money, and so the bets that the investors make are trying to guess which companies are gonna have something that the world wants a lot of. And often they’re wrong. And they lose money on some, but they make money on others. The key thing though is I believe it’s completely incompatible to try to be half of one and half the other. 

Murray: Well, companies do try and do. 

Rich: Sure they do. And I’ve worked with dozens of them over the years. But the way you make decisions at the executive level around the big kids table is completely opposite. So when some big customer proposes that they want something special, if you’re a services company, the first words outta your mouth are, yes. And when can we sign? And if you’re a product company, the first words outta your mouth are, no. Who can we throw that piece of work to so we can save the license. And somebody else is stuck with the custom work. And notice that’s a fundamental set of reactions of some folks around a table. It’s learned behavior and it’s really hard to change.

Shane: Yeah. So while we’re talking about the big person’s table. Isn’t this solved by the chief product officer? Isn’t that the person that sits at the C table, tells the CEO and the sales director or VP of sales no, my business unit’s got do that because it doesn’t align with our strategy. Isn’t that the solution? 

Rich: I think it’s part of the solution. So I’ve been in that chief product officer chair maybe 18 times in my career. And only been fired, maybe a handful. The half-life of a chief product officer at a B2B enterprise software company is about 18 or 19 months. And that’s about how long it takes for everybody to get tired of hearing. No. So for me, this is much more, I would call it coalition. Okay, so as the chief product person, I have to get the c f O on my side. I have to make sure that we’re really clear on how the company makes money, and that the person who’s in charge of bringing us public someday or getting new investments is gonna fight on my side of the battle so that we’re doing the things investors care about. 

I need the VP of engineering or the cto, whoever it is on my side, fighting shoulder to shoulder about why this is gonna wreck all of our plans for upgrading everybody to something next year that we really need and keep us in business.

I need the head of marketing on my side, explaining why two big customers instead of 500 medium sized customers means that marketing might as well pack up and go home. I don’t see the chief product person or the lead product person having enough political clout around the table to by themselves, push back on a sales team that’s gotta make numbers this quarter. And who’s got a direct line to the CEO and whose board members are asking about the individual deals. That’s a losing position in most enterprise and B2B companies. 

It’s perfectly the right place for consumer companies because they’ve got 10 million customers that pay $10 a piece and no one of them is important enough that we really worry about them. But in a company where we’ve got eight big deals this quarter at a million a throw, every single person in the company’s following those eight deals, and it’s really hard to resist by yourself. Again, notice this isn’t a question about strategy or intent or education, this is about the sort of bare knuckles of how do we get decisions made around the executive table that are good for the company over more than one quarter. 

Shane: So in the agile world we often talk about the idea of a triad. It’s typically your chief technical person, your UX person, your product manager. So if you are a VP of product what is the triad at that level, is it product marketing and finance? What are the three Cs that you want to bind to get that power?

Rich: So generally, the tightest partnership, and I described it as shoulder to shoulder, is the head of engineering or development and the head of product, I believe they are peers instead of product reporting to engineering. I don’t see design having a seat at the big table. So design’s either gonna roll up through product or engineering. There aren’t that many seats around the executive. So not everybody has a representative there. But here, remember we’re having as much an economic discussion as we are a technical discussion. So the next key person for me is whoever runs finance because they understand how money is made and kept score, and they have a slightly longer outlook than this quarter. , marketing depends a lot on the company. I look around the organization and in general, sales is the other side. Marketing depends a lot. If it’s marketing as a subsidiary of sales then that’s where they are. 

Shane: But we’re starting to see companies in theory be data driven. Were you seeing the CDO?

Rich: I don’t see those titles at that level in commercial software companies. Now, clearly we think about those things, but we mostly talk about getting the work done, and we often forget to attach at the very top in bold type how much money the thing is worth. Or maybe we don’t even have a plan or we don’t have an outcome. 

Let me create an example here for you. I’m doing a bunch of work with a big European e-commerce firm, that I can’t name, but they have a really good development plus product plus design team that’s working on improving how they present and show and sort the various products that appear when you put in a product search and it turns out there’s a lot of science here. There’s a lot of tech here. And if we can do a better job of sorting the order in which things appear at the top of this e-commerce page, people waste a lot of less time. They buy more stuff and they abandon fewer things in their shopping carts. Now, none of that included the most important thing to the executive team, which was a currency symbol. okay. It’s products responsibility. When we come to the table and we say, look we’re gonna have teams spend 15 weeks or whatever it is, on improving the search and sort algorithm and how stuff’s gonna appear at the top and people are gonna click on more stuff and be happier. We have yet to get anyone interested around the table until we say, and if we can get them to click more things and abandon fewer things in their shopping cart, according to our estimates, we’re gonna bring in something between 90 and 150 million euros next year. Okay? Now we have their attention. Suddenly we have their attention cuz we’re speaking in executive language, and that activity of translating what we’re doing to what it’s worth. It turns out to be a key skill here. And it also lets us answer a bunch of these interrupts where somebody comes in and says, I have a deal that’s worth $80,000. And I get to say instead looking at the top four things on the roadmap, which we’ve agreed are worth 18 million, 15 million, 12 million and 10 million, I’m pretty sure 10 million is bigger than 800,000. So go pound sand, that’s how executives talk.

Shane: The problem is that product say, we have all these things we wanna work on. They’re strategic, but there’s no dollar value. Salesperson works in and goes, got a customer, a million dollars builds us one thing and we can’t compete with them because we’re promising something else. But if we could actually quantify the value of what we’re gonna build in product and that value is higher than the one sales deal, then the, the C level should listen to us if they’ve got any brains. 

Rich: That’s exactly it. And so for me, good product people led by the head of product, are doing this translation all day long between the things we know we should do and the economic reason behind it, or what it’s worth in new revenue or savings. If we don’t attach money to it, nobody hears us. What, I coach my heads of product on is any sentence that comes out of your mouth in the executive room that’s not denominated in currency isn’t heard by the rest of the team. It doesn’t matter, so we as the product folks at the table have to bridge this communications gap and this perception gap and say last week we all spent 15 hours talking about how the next upgrade to our major product is gonna cause 80% of our customers to pay us extra and upgrade. And that’s worth something between, pick your numbers, 10 million and 50 million, big error bars. So I’m unexcited about canceling that or delaying that for something small. That’s the language of business that I think engineers aren’t trained to speak in and designers aren’t trained to speak in. So as the product person on that triad or in the executive team, I’ve gotta be the person who says it in the language that’s understood and is heard. 

If I can back up one step though, I might. Cuz about half of what we do, you can’t do that with. So about half of all the engineering and product work we do is to keep in business. It’s scalability, it’s security, it’s backend, it’s data cleanliness, it’s migrations. That’s not about money yet. It’s about staying in business and the sales folks pick something off the roadmap that’s from the wrong column and tell us that we can cancel all the infrastructure work just this quarter in order to close a deal and we have to throw our bodies on the tracks and stop that.

Murray: Yeah. So what I’ve seen is that the sales team come in with this big juicy licensing deal. If only you can make, all these changes to the product. And the CEOs salivating over the potential revenue and so is the cfo and the, head of engineering has been chosen because they’re compliant. Theoretically, everybody wants the customer to pay for the changes so sales low balls everything. And the compliant engineering people, want to come up with a budget estimate that keeps everybody happy. So when sales says oh, can’t cost more than a million, that’s all the client will pay. So everybody says, all right, we’ll put in a million. But what happens then frequently is that it ends up costing 10 times as much. And then the engineering team are in this horrible position where they don’t have anywhere near enough people to do that work or anywhere near enough time. Cause they’ve been given a budget of 1 million to do 10 million worth of changes. And then that leads to all sorts of mess with the product.

Rich: Yeah. I don’t think you have product at that point. And the argument that says, it’s a 2 million deal and so we can spend 500,000 of that doing custom engineering. If we look at the economics, that’s already a failure. Even if we could have delivered it for the budget that was spent, it’s a loss because what we expect from product and engineering is to get six x or 10 x or a 15 x value in revenue terms out of our work. And so if we’re doing a one for one if we’re selling our work at cost we’re either a services firm or we should pack up and go home. But coming back to your question, I think of it as a hopeless problem for engineering because we’re already committed to more than we can do and it’s not gonna get done.

Murray: Yeah. Yeah. I think the effects are very negative here. Engineering people are very stressed. The quality is poor. People are resigning. Companies will then say, oh, we’ve gotta get in some vendor in India to help us out because they’ve got lots of bodies and then they do a lousy job and the whole thing just turns into this 

Rich: Sure. 

And I think buried in there is a poor assumption that’s easy to make, which is that writing code is like building fences. Okay. We need it to be a hundred meters long and we’re gonna have a post every two meters. And so we need 50 posts and a bunch of things, and it takes somebody 10 minutes to dig a hole. It turns out that building software is actually a creative enterprise. It’s an intellectual enterprise and we’re inventing new things as we go along. So the idea that we’re really gonna estimate something really well and then deliver it on price is a manufacturing analogy that I think doesn’t work in the software industry.

Interestingly, usually the comparison we get is the car companies know exactly how many cars are gonna roll off the assembly line. . But what’s different about the automobile industry is they spent seven years designing that car offline. By the time we get to the factory, this is a manufacturing process where we’re stamping out identical cars, and what we miss is that in the software industry design and manufacturing happen at the same moment. We’re not done till we’re done. We don’t know how long it’s gonna take. All efforts at sizing are best guess, and we’re almost always optimistic. And so the, this analogy that it’s just like building a house or a floor or a fence doesn’t hold 

Murray: Yeah. Yeah, I agree. The other thing I see in these situations is that if you have engineering leaders who’ve come out of corporate It, like some sort of insurance company or a bank or something that, where they’ve been building stuff just for captive users inside, those people seem to really struggle with this. They dont get the product idea at all. Is that your experience too? 

Rich: That’s exactly my experience. I don’t know if you’ve ever found any banking software that you loved and you thought was terrific. I haven’t. Banks and airlines and government agencies actually don’t care about quality. They don’t care about really serving the user. And most of the decisions are made over on the business side by people who don’t understand the tech, and so if you are the CIO of a bank the way you get your bonus is you deliver the things the business told you to deliver on time. Maybe even on quality.

Generally bank systems folks aren’t in a position to push back on the business unit and say, you gave us the wrong problem, or You gave us the wrong solution, or, I have another way to do it, or, this is gonna be worthless. The score keeping method in a bank IT is, did the IT organization do the things we demanded that they do. And so the bonus is about saying yes and staying on time, and it’s all about cost and time and the word value almost never appears.

Murray: Yeah, 

Rich: So when somebody moves from that to a situation where we want them to be different what they bring with them is an experience of agreeing to or being told what the answer is.

Murray: Yeah. And also a cost reduction focus too, cuz in those organizations it’s all cost center. 

Rich: Exactly right. If the thing you’re measured on is cost, then it makes perfect sense to find less expensive developers in places where they’re less expensive. Cuz you’re not really worried about quality and you’re not really worried about team cohesion and you’re not really worried about great solutions and or psychological safety or actually building the best thing or value.

Murray: Yeah.

Shane: Yeah, I think the term is you’re looking for mercenaries, not missionaries, 

Rich: That’s right. And when you hire mercenaries, you get just what you deserve, which is people who build the thing you tell them to build, whether it’s any use or not.

Murray: And they’re trying to get the cheapest possible mercenaries in the world cause all developers are the same, 

Rich: That’s right. 

Murray: Why, pay $200 an hour for a developer when you can pay $10 an hour for a developer? 

Rich: That’s right. And then we weaponize story points and we say we want the team that’s gonna deliver the most story points per unit time. Not understanding that’s a completely silly thing to do. Or we implement some SAFE methodology that’s all about predictability and nothing about value and customers because what we want is predictability and cost management.

Murray: You mentioned something before about building things that people don’t use. I saw some research from Pendo who are a SaaS platform provider that something like 70 to 80% of the product features sitting on their platform that companies have built are rarely or never used. It seems to me that just a massive waste of effort by everybody.

Rich: It is exactly that. We have to ask the right question upfront before we start coding, before we start designing, before we start an architecture. What’s the success criterion for that new product or feature. So if we really think that 60, 80% of our user base is gonna take advantage of that feature let’s use Pendo or any of those other products to instrument it, and we’re gonna measure usage. Not delivery date, cuz that’s less important. But over the next year, we’re gonna watch the installed base of our customers either use this feature or not.

We’re gonna critique ourselves. We’re gonna look hard, we’re gonna look at the discovery and validation in interviews we’re doing directly with the real end users. And we’re gonna try to improve the way we make decisions before we try to improve the way we make software. Because if we ship a feature that nobody uses or very few people use, it costs us the same amount as that same feature which everybody used.

So, I’m careful about separating a thing I call product waste from engineering waste. Product waste is, we delivered something on time that’s beautiful, that’s easy to use, right on spec, and the world yawn, and it got very little pickup. That’s product waste. And if we could reduce the product waste by a third, then our engineering team gets a third more useful work done without new people, without new tools, without cost cutting, I often see that a good half or more of everything that gets shipped at a company doesn’t move the needle, doesn’t get used, doesn’t matter. And that’s a product failure, not an engineering failure.

Murray: Let’s connect this back to the sales team. I’ve seen arguments where we have to rebuild our product platform. And so we’re talking about what features we are gonna have on the next version. And somebody says, we have to have this because it’s essential to ibm. IBM use it all the time. They’re always using this feature. So we have to have this expensive feature in there. And I’m going straight to the CEO if it’s not in there. And everybody would normally just agree. But it’s quite possible that feature has never actually been used by ibm. And the real issue is that even the customers who are buying your product at IBM don’t even know what they’re using it for.

Rich: Not at all surprising. And so the idea that we instrument our products we track usage, we track activity, we track adoption, is really important. And the product folks need to be doing that long before IBM comes up for its contract renewal, we have to be prepared to say, last year when you dragged out this list of features for us to close this deal, here’s four things you forced us to do And we’ve run the numbers between last year and this year, and three of the four had zero usage. And you can’t do it in real time if you haven’t done your homework. 

If I go way, way back in history, I was at Sybase in the early nineties, in the early days of the database war. So that was Oracle and Ingress, and Informix and DB two. Microsoft hadn’t yet licensed the thing that you now know as SQL Server from Sybase, where it was called the Sybase SQL Server. I was in charge of all the platform stuff and we had a bunch of products and they ran on 43 operating systems. And I was the only person in the company who could name all 43.

I started an end of support cycle, sorted them from most used to least used. And it turned out at the bottom, there were four or five of those that had never been sold. And so we had engineers and test people and designers who were busy running a nightly build and test on platforms that no one had ever paid for or was ever going to pay for, cuz they were already obsolete. So I was able to end of life three or four, branches of the product without having to send a customer letter out because there was no one out there. And we worked our way up. We ultimately end of lifed about 18 of those 43 operating systems. So we freed up 18 teams that were maintaining stuff that nobody bought and nobody used.

Murray: So I’ve got a scenario for you. Chairman of the board, of a, B2B product company comes to see you. Their customers are big conservative enterprises. So think about I don’t know, something like 

Rich: Machine learning. 

Murray: Yeah Machine learning or something like that. Potential investors are saying there’s not enough sales revenue coming in. The engineering costs are really high. There seems to be a different version of the product for every company. The product roadmap never gets met. Customers are screaming all the time that the commitments are never delivered. And we dont know what the path to profitability is. Can you go in there and help us out as an interim CPO and make things work? What would you do?

Rich: It’s not necessarily a typical scenario that I accept as an engagement, but it’s a typical request. So there are a hundred possible explanations, none of which I know are correct until I’ve done some digging. But one of the first places I would start is I would sit with the product and engineering team and I would go back two quarters or some amount of time, and we would do an inspection of what we put on the roadmap at the beginning of the quarter and what we finished at the end of the quarter.

And we’re likely to have a match between deals that arrived in the middle of the quarter and what got done and things we committed that were pushed outta the way by those and didn’t get done. So let’s imagine I’m gonna put a list together that says here are the 15 biggest interrupts we got from deals. And this, by the way, this is all about coloring under the curve. This is all about integrating the data instead of looking at one deal. because remember on the sales side, we think of the world one deal at a time. But on the engineering side, we think about the world as the integrated total accumulated commitments and stuff we’re working on.

So we’re gonna find the first 15 instances of, yeah, I need this one thing. Yeah. This is the only interrupt. Yeah. If we do this, we’ll make our number. And I try to assemble both the rough guess at what we spent engineering months or whatever our unit is here. And the actual revenue that was driven by that. Not the hope. Not the promise, not what the sales team told us at the beginning. But did we close the deal? How much was it worth? And how many other customers did that drive a deal for? So rather than, Saying Somebody’s wrong here yet, we wanna do the work.

And sometimes what we discover is that there’s a lot of amnesia here. I have to walk through 12 of those things before I can get the executive team to agree that there’s a pattern. I have to basically embarrass them in front of each other, and then we’re gonna total up and say of those 15 specials, we closed eight of those deals cuz seven of them, for whatever reason, didn’t close. And of the eight we closed. We brought in 2 million worth of 20 million worth of revenue on the expense side. Noticed that, first of all, we spent 40 million building that. And second of all, we sacrificed these major pieces of feature function, which we had all agreed with. The thing that were gonna open up a 500 million market for us. What we’re doing is we’re taking it from technical issues to money issues, and then we have the argument that says, is this the way we wanna run our company?

Because the pattern next quarter will be just like this quarter, which is we’re gonna have a roadmap and a plan and an architecture, and then we’re not gonna do much of it, we’re back to the sales led roadmap. And if that’s what the company wants, then that’s what we’ve got. Not very profitable, not very fun, but that’s okay.

If in fact, we noticed that the major new feature function that was gonna drive our whole marketing and sales campaign and bring 700 new customers in didn’t get finished because we worked on something for these two individual customers. I have to somehow make that. I have to show, not tell that, that our behavior is that we make promises to ourselves about the market, and then we sacrifice those for individual accounts or individual deals, and then we forget about it. This is holding folks heads underwater and seeing what happens. Some companies are actually very happy with that, and, they thank me for my input and they don’t let the door hit me on the way out. And some of them see this as an issue and they can make changes, and some of them see as an issue and they can’t make changes.

There’s a really cool technique here that I always offer up and nobody ever takes, which is, let’s imagine we make a tiny, tiny change to the sales compensation. You guys may or may not know this, but salespeople do what we pay them to do, not what we want them to do. No matter how many times product comes over and gives them lectures and tells ’em what our strategy is and shows them PowerPoints and forecast and whatever, salespeople will never pay any attention to any of that if they can make their quota an easier way.

By the way, the easiest way to make quota in a enterprise space is to sell services, sell one-offs, because lots of people need ’em and everybody has a budget, so if we make this tiny change to the comp plan as follows, you get 115% quote relief for selling exactly what our product does. You get 0% the first time you sell anything else, and the second time you’re fired. Now the reason for me to bring that to the table isn’t because I actually expect the team to agree. It’s because it makes it so obvious what choices we have. And it turns out, if we make that change within about 48 hours, we don’t have this problem anymore. Now we lose some salespeople and we lose some sales.

But if the executive team as a whole is really behind the idea that we should sell same bits, scale up into the right, make tons of money, get outta the professional services business story, then they should be willing to consider this. If they’re really not, if they’re all from it, if they’re all from sales and professional services organizations, they laugh at me or they cry, or they send me out the door and we’ve at least established what the choices are. Because if the company’s willing to take anything, then it’s a services company. And if they’re only willing to sell the things we built or the things we’ve announced and have in the next quarter, then it’s a product company and they’re gonna make a lot more money and the CEO’s gonna get to retire earlier on the I P O or the acquisition.

And generally, that’s a motivator for the CEO and the cfo. Not so much for salespeople because they get paid every quarter, whether we have a successful company or not, but it’s as stark and financial as how are we rewarding people for doing the right and wrong thing?

Murray: Yeah, maybe you could do a similar thing with a profit based sales compensation package. 

Rich: Sure. You might say you get paid for the standard part of the product and you don’t get paid for the extra work until it gets finished. Now you’ve got a bunch of sales people leaning over to engineering saying, when are you gonna finish this thing I promised

Murray: Yeah. 

Shane: Or you say to them, your base plus your bonus is for off the shelf. Every time there’s a customization, a percent of that customization cost comes off your bonus. You’re incenting them to not customize. 

Rich: Yeah. Notice it’s not about me banging my shoe on the table and talking about strategy and convincing people I’m a nice person and being charming and sending gifts to the sales team and buying them drinks. None of those matter. For everybody else in the company, they matter. For everybody else in the company, it’s about relationships and building good stuff and holding hands and loving what we’re doing and loving our customers. The enterprise sales teams are very clearly hired and promoted and rewarded. For bringing in money and if we don’t understand that, then we we waste a lot of time.

One of the other coaching items for me endlessly is, if you’ve come up on the engineering side, you think that the way to convince somebody of something is to either show them your 500 row 16 column spreadsheet and walk them through it or give them a two hour dissertation on Agile. 

And it turns out they don’t care. Blah, blah, blah, blah. As soon as you start to talk about any of those things, they’re busy reading their email or they left the meeting, if we as product leaders aren’t addressing the core issues in the language that our audience needs, then we’re engineers. 

Shane: So that’s interesting because product people are taught to talk to the customer, listen to the customer, understand the need of the customer, the jobs to be done. Why aren’t they using those skills internally? 

Rich: They should be. They should be. My direction for my product managers is if we’re setting up a meeting with a real customer to learn things and ask an interview, we should always invite a designer and a developer into that meeting real time. Now, put the developer on mute because generally, We don’t really want them asking questions directly. Maybe the designer may be a better interview than I am, but there’s this real time, really important emotional connection that we as a team form with the real people who use our stuff. And filtering it through product managers is inefficient, filtering it through sales and then marketing, and then support, and then our crm, and then product and then engineering. Pretty bad. But there’s this the two really good outcomes of this one is, each one of those three that try it actually listens for different things. My designer thinks about workflows and problems and how do we get from here to there and what happens first. Are my engineers thinking about data items and scalability and what happens in the back. And I’m thinking about money and problems to be solved. We hear different things, so we actually get more outta the call. The other more important thing is I know that my engineering team and my design team don’t come to work just because we pay them. They come to work because they love our end users. They care about what they’re doing, and they want their work to be used and appreciated. And so if I can bring in rotation the various folks in my engineering team in to hear a real user say either I love that feature, that was great, I didn’t know I could do that. You made my day. Or every time I use the three factor authentication it screws up and I can’t do my job and I’m afraid to get fired.

It lights a fire in the bellies of my engineering team because they know who the users are and they care. And by the way, that evening, my engineer’s gonna go off and fix that three factor authentication problem, whether it’s in their space or not, because they’re embarrassed and they want to help the users and the customers. I get twice as much out of my engineering and design team by putting ’em on the front lines and having them hear directly real humans say, this worked that didn’t work. Here’s an idea. Of course, almost all the suggestions from users aren’t very good. That’s okay, we don’t expect to do those things, but we have to hear it from the mouths of the people who matter. And I find that when my team understands and loves and appreciates and channels my real users, not only do we get better work done, we’re happier turnover on the team or turn on the team is down. People have a sense of mission and they know why they’re coming into work every day. They’re not coming in to write sequel statements. They’re coming in to help some accounting clerk pay the people in their company so those folks can put food on the table for their kids. It’s so important that we not hide our developers and designers in a closet and protect them from the world.

I wanna protect them from sales, but I don’t wanna protect them from the world. I want them to experience and hear what’s really happening, because I’m not the smartest kid on that team. Just ask any developer, they’ll tell you they’re smarter than their product managers. I need the smartest kids on the team helping figure out what the problems and solutions are instead of me writing ’em down on a ticket and telling them, I have an MBA and I’m smart.

Murray: Yeah. Hey, just one question there. What makes a good cpo?

Rich: Ah, this is a hard question. Things that come to mind first, most importantly, I think you don’t want a CPO who hasn’t spent a lot of time in grade as a product manager. In the same way you wouldn’t hire a head of software or a CTO o who hasn’t written a lot of code. And this would seem obvious, but everywhere I go, people wanna hire subject experts who’ve never done product because they think their travel industry is complicated, or their e r p industry is complicated. They wanna hire industry experts who couldn’t spell product if you gave them all the consonants in the right order. And that’s a fundamental failure. 

But assuming you have somebody who’s been, time and grade in product things they need to leave their ego at the door every day when they. They need to have a really good grasp of how strategy turns into tactics and back. They have to be great communicators and collaborators. My job as the head of product or as any product manager is I want my product to grow up to be big and strong in the next 18 releases, I wanna be standing in the back of the concert hall listening and applauding when my product’s on stage playing violin and impressing everybody. It’s never about the product manager, it’s about the team. It’s about the product, it’s about the happy users and customers. And so we have to be able to be, somewhat unemotional.

We have to really look at our own motivations and our own experience for what’s going to happen next. We’re always looking around the corner. If we ship this, what happens if we end a life that what happens? If we merge some products? What happens? How will this affect our users and our paying customers and our teams? Because those are the people we bring our love in every day. So at the product manager, that’s my team at the Chief Product Officer, I have to love the company and the company’s future and the good of the company before. I love any of the departments or the people.

Murray: Yep. And how important is, agile and lean startup line, ux, that sort of stuff? 

Rich: I think it’s really important, but I think it’s important looking in. Nobody on the go-to-market side cares.

They don’t care if we’re agile or not, or Scrum or XP or Kanban or whatever. Nobody cares on that side. But I would frame it another way, which is it’s my job as a product person to lobby for and get whatever my team tells me they need. They need tools, they need ticketing. They wanna do it this way. They wanna do it that way. How do we check in code. I’m a big bigot for automated testing. I think there’s no alternative than that, but the team wants to do conbon. I’m in. They wanna do team, pair programming I’m in. They wanna be remote. I’m in. My job is to ask the team in the retrospectives in other places what’s gonna make them happier and productive and better. My opinion’s less important here, means to an end. And I’m a huge agile small a. But what that means for me is that my team gets to choose its tools, its methods, its approach.

No two teams are gonna end up in the same place. Nobody ends up doing just what’s in this GRUM book or the Kanban book. It’s really not my place to tell ’em how to do their work. I don’t care what ticketing system we use. I don’t care how we score points or do estimates. I need to make my team love their work and deliver great stuff.

Murray: Yeah, I think maybe we should go to summaries. Shane, what do you think? 

Shane: Yep, let’s go for it. So you started off with this really interesting idea of build once, sell many. If that’s what you do, you’re a product company. If you’re not, you’re a services company. Be very clear which of those two you are. 

If you’re making an investment in your product and you’re not getting a six x or a 10 x out of it, then you’re a services company. So it doesn’t matter whether you have services to make your product work, whether you have partners do services, whether you have, support or implementation or a hit team that go in there and set it up for them. They are services.

I’m going to invest some money in my engineering team and if it’s not given me a six or 10 multiplier, then I should think about what kind of company I am. That’s the crux of it. It doesn’t matter what they say, how they make money is how they’re gonna behave. If they make money from consulting services, they’re gonna sell you a product that requires consulting services. If they’re building a company, they’re gonna sell, then they’re gonna give you a product that does what you want for a lower cost than it costs because they’re gonna make the money at the end of the sales cycle, and the sell the company. 

Go back to the end goal. What’s the score keeping method of our sales teams, of our product teams of our company? Think about that. 

And then the next part was think about the context of our sales people. They’re trained to be persistent, persuasive, and every time they get a no, escalate it to somebody that can remove the no from them. So they’re trained to do that. If they’re successful, they’re bloody good at it. So what happens when we say no as product people? They’re persuasive, they’re persistent, and they go around us to get a yes.

I like the idea of the triad being product engineering and finance, that those three people having the same goal for the company and then playing the game together, which is a political game to make it successful. So you know, that shows where the value in the company is focused on. 

I love the idea of roadmap amnesia. What’s the technique we could use? Hell bring up the roadmap from last quarter just show 80% of what we built this quarter wasn’t planned. And then we couple that with no slack in our backlog. So we leave no breathing space. Even though we know that 50% of all the work we do in every quarter is late arriving work. Just look at that and go, okay, we’ve only booked 50%, lets not plan for the other 50 cuz there’s no point in it. Not great behaviors, but better than over-planning. And then underdelivering.

I love the idea about Halflife. So halflife of a chief product officer or VP of product is 18 months because everybody gets sick of no after 18 months.

And then we went on to product waste, which is one that I thought about a bit. Always struggled to get round to doing. So that idea of if nobody’s clicking that button, Then it has no value, so if we don’t monitor it how do we know? And it comes back to that overall theme and there’s, quite a big theme in the data world starting off this year around show me the money. And for me, that’s, I think the answer to the product teams that are getting wagged by the sales team, write down the value, show the execs the money, argue about dollar value. Don’t argue about features and products. For me, that’s what I got about out of it. Thank you.

Murray: Okay. I was thinking what are the root causes in this sales lead organization and what you can do about it? I think a lot of it has got to do with the people that are there, the people you’ve recruited into these positions. 

If you’ve got a CEO and a head of product and, a head of engineering who all come out of service companies , they’re not gonna behave like product people. They’re not gonna build products, they’re just going to sell services and build services. So you might have the wrong people in those roles. And because those senior executives create the culture of the organization, they set the compensation for everybody, they set the bonus structure. And when they’re under pressure, which they will be in that situation, cuz they won’t meet their goals by behaving that way, they will fall back on their past experience. And so the head of engineering, who’s from a corporate IT role is gonna fall back on just saying yes to the boss and trying to deliver stuff and cut costs. The CEO is gonna focus on selling more deals and so you’re gonna end up with this company that’s really a services company pretending to be a product company. 

And the investors in the company are gonna believe the story that we’re a product company, for a while. but they’re going to see that they’re not getting the margins of a product company. They’re only getting the margins of a service company. So they’re gonna stop investing. Or they’re gonna want to invest at a much lower level. Cause maybe you are able to make your revenue targets, but you are never gonna make your profit margins using this approach.

Rich: And you’re always gonna be late and a dollar short. That method only works if you understand what business you’re in,

Murray: Yeah, so if you’re in a service business, you’re gonna get investor evaluation one or two times revenue. If you’re in a software business, could be 10, 20, 800 times if you’re Tesla. So it’s a big issue really. It’s a board responsibility and a CEO responsibility.

Rich: I feel for the folks who are at the doer level in the organization, the product folks and the engineering folks, and the design folks in general, they’re not able to make the kind of change at the corporate level that would dramatically shift this. They’re not in the room where it happens. 

Murray: Yeah. They’re on a hiding to nothing. What gets rewarded in an organization like that is compliance. Do what the salespeople want. Say yes. You can’t deliver it. Just keep saying yes. And people who stick their head up and say, there’s a fundamental problem here. We can’t do this. You said this has to be done in six months. It’s impossible. They have a short life cycle. 

Rich: That’s right. I can’t tell you how many replatforming projects I’ve seen or worked on where it’s a six month project that’s so far taken six years and they’ve been through four complete teams. But the assumption is that the current team just isn’t working hard enough or isn’t good enough. And so we should replace team number four with team number five, because we’re gonna get some other answer.

Shane: Or we replace the technology. 

Rich: Let’s acquire some other company that says they have everything we already need. Yeah.

Murray: Yeah. And we certainly don’t wanna replace any of our leadership team because they certainly couldn’t be responsible for it. 

All right. That has been fun and interesting. Let’s tell people where they can see more of your writing or where they can find you rich.

Rich: Sure. I cleverly managed to acquire my domain name, which is the same as my last name in 1992 before anybody on the ex Soviet Union got there. I have 22 years worth of blogs and talks and videos and tools and stuff. It’s mironov.com, that’s m I R O N o v.com, and it’s all free and everybody can take it.

The last eight or 10 years of that is mostly about the challenge of product in the larger organization and leadership. The first 15 years or so, we’re much more about doing the product manager job.

Murray: Yeah. Great. And I think people can find you on LinkedIn as well, 

Rich: They can find me on LinkedIn, they can find me on any of the social media. I’ve cleverly taken my name as my email address. I’m hiding in plain sight

Murray: All right. And people could contact you ,to get help. An interim c p o for the product company pretending to be a service company. 

Rich: or even the product company that is a product company.

Murray: All right. And you also do c p recruitment too, don’t you? 

Rich: I help a lot of my clients find the right CPO when they haven’t before. So interview candidates and right job descriptions and such as a sideline.

Murray: Okay. That’s great. All right. Thanks, rich. Thanks for coming on. We appreciate it. 

NN – Outro: That was a no nonsense. Agile podcast from Murray Robinson and Shane Gibson. If you’d like help to build great teams that create high value digital products and services, contact Murray evolve.co. That’s evolve. With a zero. Thanks for listening.