How to Prevent Product Waste

Rich Mironov is a well-known consultant and coach to product executives. In 2022 he wrote an article on what he called “product waste”: the money companies lose by making avoidable mistakes about product features and priorities. The article resonated strongly with us, because we see so many avoidable product mistakes that companies make when they rely on gut instinct rather than actual customer feedback and solid discovery processes.

We asked Rich to tell us more about his thinking. As you’ll see in the interview below, the discussion covered a lot of ground, including:

• The volume of product waste caused by bad product decisions. (Rich estimates it’s about 50% of projects.)
• Roadmap amnesia, the process by which executives forget their priorities when presented with shiny new ideas and opportunities.
• The critical need for product people to speak the language of business: They must explain and defend their priorities in terms of revenue and profit. Nothing else reliably moves the other execs.
• The central role of product management in making those business arguments.
• How you can use small measurable wins and business coalitions to reduce the problem.

Rich’s analysis focuses on B2B (business-to-business) companies and product executives, but we hear many of the same issues in our conversations with consumer-facing companies, and with leaders in roles other than product management. As Rich said, the problems are driven by human psychology and politics, and those are universal in almost all companies.

If you want to understand more about the challenges facing everyone in product teams, and the critical need to explain product realities in business-financial terms, read on.

Product people need help selling their ideas

Q. Your article resonated with me because you talked about changing the mindsets of product people — the product process, what potentially is wasteful, when should they validate, and so on.

Actually, the audience for that post is not the product people. 

The audience for almost everything I do is in fact the C-suite folks who work with the product leader. A lot of what I’m doing these days is coaching heads of product — the most senior product person, CPO, VP, whatever it is. And almost all the issues are not about the mechanics of doing product; they’re about the soft skills and politics and coalition building around the executive table to get the right things done even after we know what they are. 

So the article, which is written as if it’s for product folks, is really for CEOs and other folks who don’t understand that half of what they are personally asking for is either a complete waste or wrong. 

A lot of what I’m doing is packaging up stuff to help heads of product understand how to speak with the other people around the executive table. I’m trying to open up conversations.

Most of the posts I’m writing are designed to be easily forwarded from the product person who’s having this very issue to the people who are creating the issue, without offending anyone. That’s what this piece is about. Because I don’t actually find that product folks have trouble figuring out which things are useful and which are not. They have trouble selling them and they have trouble keeping them on the roadmap.

The problem is especially difficult in B2B companies

One other bit of context here: I do almost all B2B (business-to-business) enterprise. This is not a problem that I see in the consumer-facing companies. If you’re selling Fitbits or you’re doing social media or something, you have 27 million people who are each worth five bucks a year, right? And not one of them matters so much that if they phone your CEO and say, “Hey, I don’t like X or I’d pay for Y,” it matters. 

But as you move up into the enterprise space, what you have instead is eight deals worth three million bucks apiece. And every one of those salespeople has your CEO’s ear, and every one of the prospects has been called at least twice by your CEO to ask what they need. And they relentlessly offer up things that wouldn’t pass my sniff test. Requests that are just for that one situation or they’re badly considered or they’re wrong architecture. Or they’re never going to use it, or some RFP committee has some checkbox on page 45.

Roadmap amnesia is rampant

So the underlying theme for a lot of my stuff is roadmap amnesia.

Roadmap amnesia is that we as an executive team spent an hour on Monday talking about what our top three priorities are and why they’re going to lead to money, and why nothing else is going to fit, and why they’re important.

But on Tuesday afternoon, our CEO got a call from “insert big customer name:” JP Morgan Chase, Ford, Deutsche Bank, whoever it is. And somebody said, “if you could just” — and it always includes the word just – “do X.” Roadmap amnesia is where everyone else, except the engineering and product folks in the executive suite, has their brains wiped of everything we’ve committed to and every reason we had and every decision we’ve made because a new prospect or a business opportunity includes the word money. 

Which leads to: “I’m sure there’s room in the roadmap. I’m sure there’s engineers sitting around eating bonbons playing Fortnite with nothing to do. So I’m going to interrupt everybody in engineering and tell them that we need to add X.”

That’s the place where heads of product live almost every day. It’s not a rationality thing; it’s a behavior problem.

So a lot of the coaching for me is: Don’t go into that meeting with a spreadsheet with nine columns and 600 rows, and expect that you’re going to walk everybody in the executive team through your spreadsheet and convince them that they don’t want that $1 million deal.

It’s a people problem, not an analytical problem

Q. So how do you convince them? I mean, if it’s that compelling and the customer is kind of drooling on the CEO’s shoulder to tell them that they want it, how do you control that?

It’s really hard. 

I see it as a people problem first and an analytical problem second. Rather than “Let me lecture you for a couple of hours about how agile works,” the product leader needs to explain why your sales team isn’t going to make quota this quarter and will get fired. 

I often advise the head of product to organize people on the product/engineering side to make a list of things we built in the last iteration or year that didn’t produce business results: We delivered ’em on time, they had quality, they were beautiful — but they didn’t generate money, or they didn’t generate upsell, or they didn’t generate reduced churn. 

I find that when we name one of those, the executive team all tells us that it was the only one. And when we name two of those, they say “yeah,” but make an excuse. But then we name seven of them, and we total up what engineering spent on it…

The point of it is to say roughly half of everything we built last year didn’t do what our executive team was hoping it would do. And when we follow the breadcrumbs back, what we discover is that a majority of those were single-deal, motivated by a deal that didn’t close, or for a deal that didn’t use it. 

Or they were, “I had a really good idea in the shower and I’m CEO.” 

Airline magazine syndrome

I used to jokingly refer to it as “airline magazine syndrome.” Which is, on Tuesday your CEO was on a United flight and they had some puff piece in their inflight magazine about Six Sigma. And he got off the plane and he said, “McKinsey’s quoted as saying ‘Six Sigma’s going to turn our company around, get on it.’”

And then on Thursday, the same executive was on a Delta flight —which has a piece on Agile or customer centricity or machine learning or fill in whatever bulls*** you want here —and they come off the plane on Thursday saying “well, clearly Six Sigma didn’t fix all our problems since Monday, and I just saw that Boston Consulting Group has told us that the future is all about machine learning and AI. When are we going to do them?” 

We’ve all been here, right?

What to do: Document examples of the mistakes the company has made

If I think of it as a behavior problem, not a fact problem, then what we have to do is find the nicest possible way to show a stack of evidence that’s going to embarrass people slightly about things we actually did, by name. You remember the re-platforming project, which we never finished? And you remember attacking financial services with the product that was really designed for healthcare? Remember that? And remember, we spent four million bucks and we closed one customer, which by the way made us $100K? And here’s what we threw out of the roadmap that we all agreed about and told the board was the most important thing for last year, right?

It’s equivalent to helping somebody diet. They’re supposed to write down everything they eat, and then they notice that they’re snacking all day long, right? Until you drag them through the details, they’re never, ever going to see it.

Last thought on that: We pay sales teams — and here I’m thinking enterprise — we pay enterprise sales teams to close deals, right? And then they move themselves onto the next deal. We don’t pay them to remember what we promised. We don’t pay them to stick with it until it’s done. We don’t pay them to avoid making promises that engineering can’t fulfill, right? Their paid job — and they get twice or three times what I get — is to close the deal, celebrate, have some drinks, move on.

And so the winning answer often in these companies is that that sales team got their deal closed because they went to the CEO and said, “this is a really big deal and I need you to override engineering and product.” And then in the minds of the sales team, we’re done. Go hunt the next one — buffalo, whale, whatever it is.

And the question of “are we ever going to be able to deliver the thing we promised?” is honestly of no interest to sales. And so we’ve built a process where all the salespeople know that if it’s a big enough deal and they go to the CEO, they’ll get a “yes.” 

And then when you look at engineering, what you see is that we got none of the things done last year that were on our plan, on our roadmap, promised to the world. What we did was, we ended up looking like a professional services organization, which builds only exactly what the five biggest customers say they want but will never use. It’s a going-out-of-business strategy.

Get recognition that there’s a pattern

So, back to waste. The challenge, I think, is to get recognition from the C-suite that there’s a pattern here. And the pattern is “I forgot what we were doing on Tuesday, I know we promised a bunch of people, but…” And you get tech debt to the ceiling, old versions stacked up in the back room, customers we never moved off of on-premises systems because they complained. And when you go back and do the analytics and you say, well, when we signed up for this special thing, we told ourselves this story that we were going to get 50 customers to use it and 25 were supposed to be new logos. But when we inspect it six months later, the silence is deafening.

We have to get past optimism and magical thinking. We have to get to this sort of hard-nosed, what’s-really-been-happening-here. Because you know, I’ve never met a CEO who didn’t think engineering was lazy. And over-resourced. And under-enthused. But when you unpack it, what I find over and over again is that we’re putting engineering on things that we shouldn’t. And that’s a political problem. It’s not a spreadsheet problem.

Once the problem is understood, the fix is to validate ideas

Q. Let’s talk about validation. In your article you say companies need to be validating. Talk to me about what exactly you mean by that.

So, we’ve embarrassed the C-suite. They recognize they have a problem: “dudes, you come up with these ideas, we need to validate.” What does that mean the team needs to be doing?

The first thing I see a lot of companies do is they create a form that the sales team is required to complete: “What’s the market value of this feature you’re requesting? How many customers are going to use it? Is it easy or hard?”

And who’s uniquely unqualified to answer those questions? The sales team that only works a few big enterprise customers and doesn’t get paid if they don’t give the right answers.

And usually there’s a threshold: we won’t consider doing anything for this customer unless the number you write down in the box is more than $3 million. Now, quite coincidentally, almost all the people filling out the forms put $3 million or more. And if it isn’t for their deal, it’s for 10 deals they could imagine but have never heard of, right?

So a bad validation step is to go back to the salespeople for confirmation. And ask them to be objective and to do science — neither of which we hire salespeople to do.

The right way to validate ideas

I think validation comes in all sizes. So for instance, if we have a major bug that’s bringing our system down, I think validation is “oh s***, the system is down.” If we get a lot of tickets because people can’t log in or can’t do our two-factor authentication, and we get 50 of those tickets a month, I think validation is asking the support team what the number one and number two and number three most frequent tickets are. I don’t think we have to go out in the marketplace and interview people for a variety of obvious things. But we do need some evidence.

Where I’m most focused on going out and actually doing real digging is where it’s more technical, it’s more complicated, there’s integrations involved, or customer data involved, or behavior changes involved. In those cases, I’m deeply suspicious of every solution that a customer proposes to me — one, because it’s a solution instead of a problem; two, because they don’t know our systems as well as we do; and three, it’s almost always some sliver of a larger issue. And it includes the words “just” and “only.”

So one of the first things to do on the validation side is to try to figure out what the problem really is. Reverse engineer the problem out of the solutions we keep being offered: “We need better data cleansing of the data stream that comes from Salesforce.” Whatever that means.

We could send our engineers off to go build one of those, but it’s going to be the wrong thing. And we need to talk to more than two or three folks who say they’re presenting the same problem. On average, I find that they don’t have the same problem or they certainly don’t have the same solution. So the first round of this is trying to zoom in on what’s not working and what can’t we do. 

Problem, problem, problem, problem.

Once we’ve identified that there’s more than a handful of customers with the same problem, we usually go back to those same folks with two or three or four proposed technical solutions, all of which are at least partly wrong, and we ask them to critique them within an inch of their life, and find the pieces in each of those that might work for them.

And then we take that whole thing back to the team a third time and we try to figure out how we’re going to fix it. The interesting ones are where the customer is having trouble figuring out what’s broken and is proposing solutions in the hopes that they get there. And often we find that in fact it has nothing to do with our system. Or that they’ve written policies which are bad or processes that are bad. Or they’re not training people. There’s a variety of answers that aren’t “build more software.”

Another source of waste is—our customers have a training problem, so we build more software that they don’t have the training to use. Or our customers have a data-cleanliness problem, and so we built all this stuff that has nothing to do with the fact that their data source is where all the bad data comes from and that’s where the cleaning should happen, right? 

You could make an endless series of cases where the problem you say you have is actually a symptom of something. And if we just address the symptom, you’re no happier than you were before.

Create a shared, consistent vocabulary across the company

Q. You’re using the word validate a lot. Because of what our company does, I talk with many researchers. They are really, really itchy about the word because to them if you are trying to validate something, it means that you’re not actually gathering data, you’re just looking for evidence that’ll confirm your argument. I think you’re using the word differently. I think when you say validation, you mean “validate or invalidate depending on the evidence.” Is that correct?

Yes.

And I’ll pick a bone here: Words mean what they mean.

If your research team thinks that “validation” means something different than your product team, everybody should find a new word.

And I’ll take a side trip for just a minute here. I coach everyone that I work with never to use the acronym MVP (minimum viable product) for any reason in any situation.

Because, to the sales side of the house, MVP says we can get the thing we need to sell two quarters early. The designers think, “oh, it’s a pencil sketch.” The engineers think we’re going to prototype all of the technical bits. It’s lost its meaning.

So in a room full of people, when you say “MVP” and you have 10 people in a room, you got 12 definitions. So I tell people, don’t fight, don’t spend the first half hour defining MVP. If what you mean is a pencil sketch, use the phrase “pencil sketch.” If what you’re talking about is a non-working prototype, use the words “non-working prototype.” If it’s early access for real revenue customers, then use phrases like “early access for revenue customers.”

Because that’s what we mean, right?

So rather than get into the “I’m smarter than you, and I know what validation means,” find words that the team understands in the same way. And the less jargony the better. Maybe they’re interviews. Maybe it’s data gathering, maybe it’s discovery.

But as soon as I’m reading it in those airline magazines, I know that no two people in the world agree on what it means.

“Product led growth.” What the f*** is that, right? As soon as McKinsey puts it in their slides, I know it’s worthless.

So when you say the research folks and the product folks disagree about the word “validation,” that’s my answer.

To do discovery right, include all of the core team

One other slice: In discovery, I’m a big proponent that for each of those rounds of discussion, you want a product person and a designer/UX person and an engineer on the call – in real time.

You want to have them all on the call because the engineer hears different things from the same words. And the designer hears different things from the same words. So, having one of those three people do all the translating generally leaves a good portion of the learning on the floor. Your engineer’s really listening for scalability issues and security issues and data items and which system does it live in? And your designer’s thinking all about which step comes first and “do I put ’em all in one form?” And “when are we naming things that are incorrect?” And your product person’s thinking a lot about why aren’t you using it, and whom do we have to get permission from to sell it to you, and does it make money.

Now, you need a little meeting etiquette here, like only one of those three people gets to talk and it’s never the engineer. The person who talks is either your design/UX person, who is often very good at interviewing. Or your product person, who is often very good at interviewing leads.

And so once the team understands what the problem is, they get together around the whiteboard or the Miro or whatever it is, and the team figures out that we have five or six alternate solutions. And the team argues about which is better. Instead of (noise here of chest thumping) “I’m the product manager. And I have an MBA from some famous university. And I’m right.”

Product managers have to have a little bit of humility and a little bit of empathy to know that half the time they’re wrong. And that it’s more important to get to the right answer or a right answer than for me to be self-important.

A good test of product leadership is, can you leave your ego by the door?

To make a decision stick, translate everything into money

Q. So within the overall product team — engineers, designers, product managers — they’ve now reached an agreement. How do you then get that across to those senior executives so that they’ll stay aligned without next week having the same problem happen again?

Well, I’m used to having it happen every week. <laugh> 

But I think if you can bring forward real information here, it’s probably the head of product who should deliver it. That person has the best relationship or at least connection to the executive team. The head of product says “we all talked on Monday about how Goldman Sachs wants X, right? We’ve spent a few days, and we learned that they didn’t actually want the thing that you guys heard. And even if we build it, it won’t fix their problem and they won’t pay for it.” By the way, we’ll get to money in a sec because here’s what they really need.

I, as the head of product, would probably make seven or eight repetitions of the word “notice”: Notice that the thing they asked for wasn’t exactly what they needed. And then, notice that if we had built just what they told you, that would have been a million bucks worth of waste. Now we can decide to meet that need or not, but here’s the right way to do it. Or here’s two alternatives. But neither of them is the thing the account team asked for, and neither of ’em is the thing the customer asked for.

Notice that we’re trying to form a pattern: This is one more instance of, “if we just go build the thing that the customer’s most senior exec told us they wanted, it’s almost always the wrong thing.” 

And then the closer here is, “we as product heads must translate that into money.”

I have a little joke. It’s a story I tell to my CPO coaches: There’s a “reverse dog whistle effect.” A dog whistle is a whistle dogs can hear, but you can’t hear it. The reverse dog whistle effect is anything that a product person says to the C-suite that’s not denominated in money cannot be heard. 

Nobody [in the C-suite] wants to hear about tech debt. Nobody cares about the roadmap. Nobody cares how hard engineering’s working or how many designers you have.

Nobody cares.

What you have to say is, “We can build that. We’re guessing it’s going to cost us two or three million bucks. That will push out the upgrade, which we all agreed around this table was worth $20 million. And our back-of-the-envelope guess is that we’ll get $50,000 for that $2 million spend.”

Now you have someone’s attention.

Because it turns out that when we as technologists talk about tech, nobody cares. You know, the Charlie Brown teacher noise: “waah, waah, waah.”

We talk about tech debt and they hear “lazy and incompetent and why didn’t they do it right the first time?” We talk about dependencies and they say, “well, couldn’t you just have done a pert chart early on and figured it all out?” We talk about how two engineers are the only two in the company who can do X and they think that they’re prima donnas and lazy and “Why can’t we cross-train everybody?”

So my strongest recommendation always, always is we have to talk about these things with currency symbols. Or nobody cares. We have to come back and say, “this is what we learned and this is why it’s going to cost us a lot of money to do the wrong thing.”

Product management should do the translation into business terms

Q. This is fascinating. I often see it when we work with designers who want the company to do something because it’s intuitively obvious to them that this’ll be a great experience for customers.

That’s right: “It’s the right thing to do. It’s beautiful. We want to reduce obstacles.” None of those have dollar signs. 

By the way, I don’t expect my designers to learn the language of finance. I expect my head of product to get the right answers from people and either help them or do the translation for them. It’s the product folks who have to figure out how to take what designers want to do and find a way to make it make financial sense.

I mean, asking designers to be finance folks is mostly a waste of time. Likewise, engineers. So the product manager has to be bilingual here. They have to speak basic finance, and they have to speak tech if they wanna get anything done.

To establish your credibility, start with small measurable wins

Q. As you’re talking, it reminds me of some reading I’ve been doing recently on the history of A/B testing. Stay with me for a second and I’ll explain why I think there’s a parallel, and you can tell me if I’m getting it right or not. If you read stuff written by the people who pioneered A/B testing 20 years ago, they said they had to take the companies through a process of showing them how bad their guesses were. They didn’t use this phrasing, but once they had humiliated everyone and convinced them that about three quarters of the time their guesses were actually wrong, then they were open to a different process which said, “Hey, we’re going to run a scientific test to figure out which of these is best, and then we’ll do the one that actually works in the test.” It feels to me like you’re describing something analogous, that you have to humble people with their bad decisions before they’ll listen.

Somewhat, yeah.

I think there’s an alternative strategy too, which I’ve worked on with some of my clients, which is you find the smallest possible improvement that you can prove made money. So rather than the big win, what you’re looking for is to be able to say, “we changed the headline on this email that invites folks to our webinar about whatever we sell. And this headline got 4% more signups than that headline.” Because everybody downstream actually is desperate for more people to show up.

Small examples where you can prove that the science works. Because the big examples take too long. They’re too long, they’re too expensive. And you have to build trust. Before anybody will let you spend a lot of money on something, you have to build trust by showing them the small ones.

Again, in the e-commerce space, just because my head is there: “we rearranged the algorithm deciding which product is listed at the top of the search. Based on profit margin or partners or whatever. And we did this for one little category for two weeks and revenue is up 4%.” Now everybody else wants you to apply that same thing to their category, because they didn’t care about the tech. They don’t care about A/B testing. They prefer not to be humiliated, but if you show ’em a way to make more money, then you’ve got their attention.

There’s folks who do lead scoring. The reason sales is willing to let us do lead scoring is because if we do it right, they make more commission. Do they care how we did it? No. Will they go off script and sell all kinds of other things that seem attractive? You bet. And there’s always this fist fight between marketing and sales about lead scoring. Because marketing says, “these are the leads that score the most.” And then sales says, “yeah, but they didn’t close — not because I was a bad salesperson, but because your lead scoring sucks.”

So I think this has that same feeling to it.

But I don’t see in the enterprise space that you ever get as scientific as you get in the consumer space. And therefore there’s just a lot more squishy behavioral emotive stuff going on here. All the more reason why you need to be able to speak the language of the execs, express it in their terms.

Build alliances with other functions by relating to their priorities

One other thing here before we let it go, just because it’s in my head.

Often I can get the chief financial officer to be my co-conspirator / champion / collaborator around whether we’re building it for one customer or many. And we speak the language of finance here. Because investors value repeatable SaaS license revenue at six to 15X revenue, and they value custom work at 1X or less.

So I go to the CFO and I say, “I know we want an IPO next year or the year after. If you let this piece of special one-off work go through and we spend $100,000 and we get $100,000 for it, that looks like break even. I think you just cheated our shareholders out of $600,000 or a million bucks in valuation. And if we make this a pattern, you don’t get to retire, right?”

We need people who are on our side of the discussion who understand why building a set of bits that we can license 5,000 times without having to touch again is worth a lot more than 5,000 special projects.

So again, what we’re doing is we’re taking the evidence, but we’re translating it. We’re forming it into what the executive team cares about. 

Likewise with marketing. We can go to marketing and say, “we think we have some behavioral cues about who’s gonna renew.” Or who’s gonna sign up, or who’s gonna get through the trial. We can help you get more qualified leads to sales if you’re willing to let us show you what we know. Which is how they get their bonus.

All of the precursor tech talk is lost in that conversation. We have to say the most important thing in the trial process is getting them to do two transactions or reading a manual or going through the 10-minute onboarding. And “we need your help lobbying for that because we’re gonna need four more trainers to get everybody through the onboarding,” right? And “you’ll make more money and be happier because we’ll have more people. Your close rate and your conversion rate on the trials go up and that’s how you get your bonus.”

It’s all about framing it in the issues that those teams care about. And their worldview.

What’s their metric? What’s their OKR? How do they get bonused? How do they get fired?

Accept the behavior and work with it

Q. I want to talk about my preconceptions coming into this conversation, and how you’ve kind of nudged my brain in some ways. I would’ve expected that the behavior you describe, of the execs treating the product organization as kind of order takers, is something I’d see in legacy companies that have been around for a while, kind of pre tech industry, pre Agile, that sort of stuff. But you’re framing this as something that’s happening also in the more tech-oriented, more recently formed startups and places like that. Talk to me about that.

I have eight or 10 heads of product on my coaching roster at any given week. This is the number one issue we talk about every week at most of those companies. Remember, this is B2B enterprise SaaS. I think the B2C companies are much more scientific, but in B2B this is the number one issue. 

The number one issue is that the CEO, in spite of all of the discussion we’ve had for the last three years, got a call from the sales team that told him that if we could just add teleportation in by Friday…<laugh>

And it’s a behavioral thing. It’s the difference between thinking about the world one account at a time, and thinking about the world in segments. If you come out of the sales side of enterprise products, you are paid and have decades of experience thinking about the world one account at a time.

And as soon as it’s closed, it’s out of your brain. It’s gone. I got paid, let’s move on.

And all of the downstream impact of I created a new package, I changed the pricing model, I promised a thing is someone else’s issue that you don’t care about.

Q. You’re saying it’s not about the generation of the company. It’s just that in these roles, certain things are going to happen in people’s heads.

That’s right. And you just have to accept it and work with it. 

And how many times in the quarter does some member of the board of directors call the CEO and ask how sales is going? Almost every day. 

Do they call and ask how tech debt’s doing? Not so much. Do they call and ask how happy the engineers are because they got to work on something and finish it? Not so much.

So I think this is inherent in the organizational model if the CEO doesn’t come out of the engineering/product side of life. And mostly they don’t.

Prioritization is a political problem

Q. You wrote the Product Waste article in May 2022. What sort of reaction did you get? Are people resonating to it? Are you seeing signs of progress?

Uh, yes. 

And then no.

I know a piece lands when a lot of people reply or reach out. If I’ve hit a nerve people send me little unhappy notes that say, “you gave me PTSD.” Or “do you have listening devices in our conference room?”

The second one is, I get a fair number of people who say, “thanks for doing that. I forwarded it to my E-Suite with no comment, so that you can take the heat instead of me.” And then the third one is, “I’m with you, but I need you to talk me through what we do about it. I need help figuring out how to sell this to my C-suite.” And that generates some amount of engagement or consulting or advice.

That’s how I know a good one landed.

There’s a related post I wrote about how prioritization’s a political problem as much as an algorithm problem (link).

The request process is a trap

There are a couple of other ones that are on the same theme. One was titled A Working Request Process Should End in Yes. If anyone in the field organization goes through the trouble of filling out all the forms to get something or ask for an enhancement, they expect me to approve It.

Now, when you do the numbers, that’s impossible. It’s very similar to “I’m a founder of a company and I want venture capital money and I’m gonna have a meeting with a VC and I expect them to say ‘yes.’” The VCs are doing 250 meetings a year, and they’re funding six companies.

There’s this fundamental breakage between folks who think about their one account all day long, and it’s the most important account in the world to them, and the resources available to make changes. It’s the Lake Wobegon effect: “all the children are above average.” Everyone who fills out a request for a feature expects a YES.

But when you aggregate that, we know that 95% or more have to get a NO or be ignored.

And by the way, when you tell them NO, what’s the next thing that happens? If they’re important enough, they appeal to the boss. If they’re not important enough, they ask you to spend an hour explaining your logic.

So you’re trapped either way.

And so the quick and dirty automated NO doesn’t actually close the argument. Every product manager I know, and every product leader I know expects to get escalations when they say NO.

We joke that the definition of a millisecond is the time between when you say NO to an enterprise sales rep and when that person escalates it to the CEO.

So the point here is that everywhere — it’s my sampling bias, but everywhere I go, I see this Issue.

Progress is slow, but changing sales compensation can help

Q. You said you got good responses to the article in terms of the messages you got back. But you also said “yes and then no.”

You also asked “are we making progress?” This is a really hard problem. And I don’t have pixie dust or a magic recipe to get the folks in the executive suite to think like product folks instead of like salespeople.

I don’t have it.

And so this comes down to the individual situation and the data and who you can build coalitions with.

There’s one other approach that I see work but is rarely implemented. This one I love: Our company has a problem because the salespeople keep selling things we don’t have, or integrations and custom work that we don’t wanna do. 

Why do they do that?

They do that because their compensation plan pays them the same rate on what we actually build and what a customer might ask for that we don’t have. So the shortest path to a solution here is to change the comp plan. So they only get paid for the things that are done and that we have.

It’s very, very rare that we can get anybody in the executive suite to actually agree to make that change. Because in their hearts, they don’t believe it.

But instantly, if you change the plan so we don’t pay people for custom work, within moments our sales team stops selling it.

That’s a good way to raise the real issue, which is: You’re telling product and engineering that you believe us when we say don’t sell specials and don’t do custom work, but you won’t act on it.

Well then, s***, it’s time for me to dust off my CV. 

Right?

A recession may make the problem worse

Q. I would think that given that we’re in a recession — or entering a recession, or everybody thinks we’re in a recession — companies would be a lot more open to this message of wasted effort and let’s do this the right way. Are you finding that, or is that not happening?

I’m not. I hoped I would find that, but I’m not seeing that.

I’m seeing companies cut whole job functions. What I don’t see as much of, and what I would like [to see], is the sort of surgical choice that says we invested, you know, $20 billion in virtual reality — not to pick anything too finely here — and we’re willing to walk away from it. So we’re gonna keep the bones and the meat on the skeleton and we’re gonna surgically take one whole thing away.

Instead I see a lot of the sort of peanut-buttering reductions: every team’s gonna give us two people back. And that doesn’t accomplish anything.

And again, I think it’s about the personalities in the C-suite. If it’s really sales driven, we’re gonna be more focused on current quarter revenue than ever before. Does it actually make them more likely to promise anything because they’re so desperate to hit their number?

Well, you know, if we’re all gonna get fired next quarter anyway…

So I think companies go to their default behavior here, whatever it is. And with a lot of enterprise companies, we have the absolute urgent need to close more deals this quarter. And we’ll figure out next quarter how to pay for it.

Now there are some companies that are really well run and and aren’t like that, but it’s hard.

I would love to tell you that this is gonna make a change, but…

The opinions expressed in this publication are those of the authors. They do not necessarily reflect the opinions or views of UserTesting or its affiliates.