3 ms·

> You work in enterprise software sales and you think people buy change? That is bizarre and shocking. I worked (past tense,) and, yes, they buy change, regard

> You work in enterprise software sales and you think people buy change? That is bizarre and shocking. 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.

JohnFen 2y ago
> 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 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.
- marcusb 2y ago
  Are you a software engineer, product management, or in sales?
  - JohnFen 2y ago
    I have been all three at various points in my career.
    - marcusb 2y ago
      That's surprising to me. (I won't be like the other commenter and say it is "shocking" or "bizarre". Just surprising.) 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 https://calleam.com/WTPF/?page_id=1445
      - JohnFen 2y ago
        I seem to have touched a bit of nerve. That wasn't my intent. I was just expressing that my personal experience is a bit different from yours. I was not saying that your experience isn't valid or true. I find the difference interesting and was just pondering what the reasons for it are. I still suspect that it has to do with the demographics of the businesses being addressed.

JohnFen 2y ago

> 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 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.

marcusb 2y ago
Are you a software engineer, product management, or in sales?
- JohnFen 2y ago
  I have been all three at various points in my career.
  - marcusb 2y ago
    That's surprising to me. (I won't be like the other commenter and say it is "shocking" or "bizarre". Just surprising.) 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 https://calleam.com/WTPF/?page_id=1445
    - JohnFen 2y ago
      I seem to have touched a bit of nerve. That wasn't my intent. I was just expressing that my personal experience is a bit different from yours. I was not saying that your experience isn't valid or true. I find the difference interesting and was just pondering what the reasons for it are. I still suspect that it has to do with the demographics of the businesses being addressed.