What is up with car door handles these days?
theguardian.com
theguardian.com
The rest of the writing is just generic railing at the general state of things with a side of Musk whinging.
Not an invalid take, I guess, but I was interested in the door handles.
There is kind of a meme/general advice to be risky, to try things out, fail and iterate on failure. Everything mentioned in the article sounds like that.
I mean, why have houses? They are pretty hard and expensive to build…what was wrong with caves?
Yes, we could say that something’s are „done“/„finished“ and don’t need improvement - or we try and see.
In enterprise software sales, a lot of time and energy get wasted arguing about features the customer will never use. Post deployment, those same people will scream bloody murder about how unstable the products are and how the vendors just can’t do anything right.
Similarly, I think if car makers set out to incrementally improve their product a few percent a year, nobody would buy it. It would be boring. Outdated.
People - like the author of this article - claim they want stability. But, I’m here to tell you that what they buy is change.
You work in enterprise software sales and you think people buy change? That is bizarre and shocking. Enterprise software sales is nearly 100% conversations with people who refuse to make massive improvements in their own QoL (and bottom line) because they loathe change so much.
In fact, I've built multiple E2E businesses that succeeded in difficult industries because we promised no change (to people's work processes) while still improving their software behind the scenes.
What an absolutely bizarre conclusion. You seem to be a victim of confirmation bias, where you aren't considering the 99% of corporations who aren't even taking your pitch, let alone buying your product.
But back to the article...
Most people hate change, but the ones who do like it don't like changes where things become worse. Car door handles were perfect and have become significantly worse.
I worked (past tense,) and, yes, they buy change, regardless of how strange you find that to be.
I cannot count the number of times I listened to a customer complain about a lack of feature velocity (real or perceived) in one meeting, then complain about outages caused by new features in the next.
> Car door handles were perfect and have become significantly worse.
Yeah. It’s almost like the car makers know something about what drives buying behavior amongst their customer base.
Maybe it depends on what part of the enterprise software market you're in. I've been working on enterprise software for decades and I've never once heard a customer complain about a general lack of feature velocity. They have complained about the time it takes to implement some specific feature that they really want, but that's a different thing. In my experience, what enterprises want is stability and as little change as possible while keeping the software useful.
The only way I can reconcile our two different experiences is that we're addressing different sorts of enterprises.
To answer your original question: I worked exclusively with Fortune 500 customers, as a vendor in the security and network infrastructure spaces. The customers weren't in any particular vertical, but included healthcare, utility, and finserv shops (I.e., risk averse businesses.)
I really didn't expect my original comment to be that controversial. In fact, it is almost tautological.
If you've worked successfully in sales, you have to understand the concept of a compelling event - if not by that specific name. In BANT, it's split between need and timing. In MEDDIC, it's "metrics" and "identify pain". Whatever you call it is immaterial, the substance is, effectively, in order to get the deal done, what change does the customer need/want, how important is this change to them, and what happens if they do nothing (put another way, can they avoid change?)
In product management, it is similarly a pretty basic element of market analysis to identify what features would be compelling to current and potential customers. You might bristle at that characterization of PM, so feel free to make it sound more strategic and thought-leadery, but that's basically the job.. Did you ever manage a product that was in a net new category, but where you knew you would be competing for and need to capture existing budget? Did you try to identify what compelling benefit ("change") you could offer potential customers to capture that budget? I sure hope so.
If you still don't like that, and are still in PM (or sales!), then have the courage of your convictions and on your next customer call to latch on to a Digital Transformation project, try focusing your pitch on 0% change and 100% stability. Let me know how that works out for you.
Underlying all of this is a simple truth: people buy to get some perceived benefit they don't already have. That is change, by definition.
If I were a clothing salesman, and you a clothing purchaser, and I tried to sell you the same outfit you were wearing when you walked into my store, you'd think I was nuts.
Now, reliability is certainly a thing people say they want, and something they weigh in their purchasing decisions. You'll get no argument from me on that. I sometimes acquired customers due to reliability problems they had with competitors, but that was extremely rare. It was something customers threatened more than they actually did. Devil you know, and all. Ironically, this is one situation where the fear of change usually prevails, at least in my experience.
What did happen -- regularly -- is I had customers who ran a full RFP process upon lifecycle refresh. Even if they had a solution that worked great, they were expected to survey the product landscape and make sure they were still buying the "right" thing, for some definition of "right". To the extent they swapped products on refresh -- and they sometimes did -- I don't see how one could describe that as anything but a bias for change over stability.
Another thing that happened regularly was analyst-induced/customer-championed Resume Driven Development. Healthcare company that runs everything on an AS/400? Better not get left behind and move to the cloud/microservices/fad of the week! Change > stability.
But, here's the thing: any change in condition, whether user visible or not, potentially impacts reliability. Simple expansions fail, due to scaling thresholds and other factors. Version upgrades fail - even narrowly focused patches introduce unexpected regressions. Net new and tech replacement projects in IT have abysmal success rates[0]. (And all are change.)
Nobody goes into these projects expecting failure, but that is very frequently what they get. Every single one of my customers, when asked (and we did ask!) would place stability as their #1 or #2 goal, yet they were constantly replacing stuff. Sometimes for good reason, sometimes for reasons I could not understand, sometimes for reasons I disagreed with, occasionally to address a legitimate reliability issue.
Just like the old investing adage that "price is what you pay, value is what you get," in enterprise tech, you can change the punchline to "change is what you get". It is what people are buying, whether they realize it or not.
0 - various studies: https://calleam.com/WTPF/?page_id=1445
I still suspect that it has to do with the demographics of the businesses being addressed.