I work for a large company and when discussing a product with a startup/small company, usually in a relatively new market, I've noticed interesting behaviour:
Before I meet, I try to think of ways their product could be provide benefit including non-obvious ones. So I ask if their product does this or that, and why I think it could be useful.
Some companies tell me: it is on the road map, or why they think the feature will never be used, or an explanation of why it is extraordinarily difficult to implement. Cool. You probably know what you are talking about and I learned something interesting (to me anyway).
Other companies take it as a feature demand. I find this bizarre, because I have barely (or never) used their product. Some almost seem insulted that limitations in their product are being raised. Not my intention, and that raises a huge red flag, for "The lady doth protest too much, methinks"
I also hate demos of enterprise solutions. The feature details never matter to the financial buyer. What actually affects the financial buyer are product implementation delays caused by a major problem such as resiliency functionality or interoperability. Extending the timeline affects other projects, the budget, and the pushes out the timeline for the benefit to be realized. Edge cases and niche features don't, the business will usually sign off on production with an agreement that these issues will be resolved by the vendor. Rarely do the big problems arise in demos, but the small manageable ones do. The technical buyer is thrilled that their pet requirements are met, and the financial buyer is furious that their programme was a failure.
People get offended by unsolicited advice all the time. Regardless of your intentions, that's how some people will perceive it. It's worse if they know you haven't used their product, because that makes you seem like you're flippantly handing out advice. You're likely giving off the impression that you think you're right without any experience or consideration of their product.
None of that actually discredits your suggestions though; you could be right.
As a counter example, some people are PoC||GTFO types who wouldn't take offense easily but would rather punch holes in your argument. Seems like you might be jumping in with the advice before you know if it's that kind of environment.
I have thing thing. I think if you're going to punch holes in someones argument then you should also commit yourself to figuring out if it can saved. Otherwise you're just being an ass. That said one thing I'm aware of is one should be careful when giving advice that you aren't dragging their vision through the mud either.
I also hate demos of enterprise solutions. The feature details never matter to the financial buyer. What actually affects the financial buyer are product implementation delays caused by a major problem such as resiliency functionality or interoperability.
Yes I've seen this a lot. The whizzy front end stuff in the demo is irrelevant.
> Other companies take it as a feature demand. I find this bizarre, because I have barely (or never) used their product.
This is something that I've seen constantly from the PMP/offering manager/product manager types and have been in the room where it happens. The thing that is utterly baffling is that it's usually a vague intent from an interested but not current user but then the person writing down these imagined requirements asks zero follow-up questions in a complete disservice to the user. So for example 'does your product use AI' or 'do you have a slack integration' open ended questions turn into firm requirements 'to close the deal' internally but with a completely headless goal. When I am usually in the room I at least give the customer the dignity of trying to work out what their idea/perceived benefit is with them so I can accurately transmit the knowledge to the team. Often someone more experienced with the product's offering can solve the real customer use case with existing features that just doesn't have the same label.
My favourite firing of a software company was when they expressed that they were refocusing from clear stability initiatives to machine learning driven analytic dashboards. This was even though this was a customer retention meeting company to company that was spawned over threats to not renew... because of stability issues.
What do you think is a happy medium between the technical buyer and the financial buyer if not a demo?
My company is having trouble with this right now, in that we built a tool for the users with some higher level features managers would like, but it's still 3 ranks below the person purchasing the software. Even pitching it as a cost savings, they reply with "oh, my teams don't have trouble with that so we're not wasting money on it" then someone lower usually cuts in and says "well, we've been having trouble with it recently..."
The number of features sales has told us some big sale hinged on, that subsequently no one has used, is very high.
We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.
I could give almost limitless examples where we've been forced to drop everything and jump on implementing a hacky version of a new feature because sales convinced the CTO we were going to lose a major client if we didn't implement it asap.
They were usually never used, or used by an incredibly small percentage of users.
The platform ended up a complete mess because of the number of hacky features implemented and was a nightmare to maintain.
I'm sure we ended up losing more business due to the instability of the platform than we gained from adding these.
It's incredibly frustrating for the engineering teams who continually warned of the risks of rushing these things in without any analysis of usage.
>>or used by an incredibly small percentage of users.
Sometimes it is not the number of users that need the feature but just 1 or 2 very important users... The ones that have the final say over Yes we use this, or no we do not
The interesting question is whether it was a mistake. Just because it was eventually rolled back, doesn't mean it wasn't worth it to win the large customer.
I once worked with a CEO who would always answer "Yes" to questions about whether the product did something, much to my horror as Director of Engineering.
Mind you his approach actually seemed to work - people would ask things in sales meetings then you'd never hear of that request again. It only went wrong in one sales meeting where one person realised what his approach was and started asking for sillier and sillier things....
>>We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.
Did you close the booking because of that feature? That type of decision is sometimes dependent on the financial situation of the company.
> Customers tell the right problem, but never the right solution.
Thanks, I threw this on my phone’s lock screen.
I have a strong intuition along the same lines, but find it hard to phrase on the spot when explaining to stakeholders (and myself) why issues filed should not be considered actionable as is.
XY problem is invoked when someone is asking for help, to get to the bottom of the problem.
I am dealing specifically with product users or prospective users who, possibly via stakeholders, request new features to implement.
The tip I quoted is very helpful with the latter as means of explaining why feature request should not be treated as actionable to stakeholders. Until I manage that, neither XY nor any other approach can be used.
Change means your way of doing things won't work anymore, and you'll have to waste time and money figuring out why.
Change means that your fixes for when things go wrong won't work anymore.
Change means months of hitting new edge cases.
Change is scary.
Once you have a solution that works well enough for your use case to succeed, your motivation to adopt change goes through the floor. The bigger the organization, the worse the worst case scenario, and the lower the appetite for change.
I really, really wish that Slack would learn this. Their constant creep in features means I lose about a cumulative hour every other week trying to do something that I once knew how to do.
Reminds me of Microsoft Office's latest big UI change, removing drop-down menus in favor of "toolbar ribbons". Went from being a power user / expert to a complete novice over night. I always wonder if there's a better way to make those types of transitions.
Constant change is a nuisance. When I'm working on a task I want to be able to concentrate on doing that task, not relearning my tools for the umpteenth time.
If the new feature doesn't affect my current workflow, then great! I can ignore it until I'm ready. The trouble, as the article notes, is the application making me aware of this brilliant new feature. Often application developers do this either by breaking a workflow and forcing interaction with the new feature or otherwise nagging me while I'm wanting to do something else.
Education outside of the application (tutorials, good documentation, blogs, etc) is perhaps a better way of driving adoption of features.
Nothing to do with the content but the pop up for 'lack of dark mode optimisation' on this website is more annoying than the actual lack of dark mode optimisation
Thanks for getting back to me. I wasn't expecting a response. As you've mentioned below it is now off which is great. It was just a very jarring, personally I feel its best to allow users to make their own opinions of the experience, I don't find the dark mode experience that bad at all. The text is white and the background is black. Good enough for me!
A good sign is when people are trying to do something using a complex workaround because they need it that badly, and you can implement a change to make it easier.
If they haven't even attempted to do it now, chances are they won't after you implement a new feature.
Readit News
Before I meet, I try to think of ways their product could be provide benefit including non-obvious ones. So I ask if their product does this or that, and why I think it could be useful.
Some companies tell me: it is on the road map, or why they think the feature will never be used, or an explanation of why it is extraordinarily difficult to implement. Cool. You probably know what you are talking about and I learned something interesting (to me anyway).
Other companies take it as a feature demand. I find this bizarre, because I have barely (or never) used their product. Some almost seem insulted that limitations in their product are being raised. Not my intention, and that raises a huge red flag, for "The lady doth protest too much, methinks"
I also hate demos of enterprise solutions. The feature details never matter to the financial buyer. What actually affects the financial buyer are product implementation delays caused by a major problem such as resiliency functionality or interoperability. Extending the timeline affects other projects, the budget, and the pushes out the timeline for the benefit to be realized. Edge cases and niche features don't, the business will usually sign off on production with an agreement that these issues will be resolved by the vendor. Rarely do the big problems arise in demos, but the small manageable ones do. The technical buyer is thrilled that their pet requirements are met, and the financial buyer is furious that their programme was a failure.
My 2 cents.
None of that actually discredits your suggestions though; you could be right.
As a counter example, some people are PoC||GTFO types who wouldn't take offense easily but would rather punch holes in your argument. Seems like you might be jumping in with the advice before you know if it's that kind of environment.
Yes I've seen this a lot. The whizzy front end stuff in the demo is irrelevant.
This is something that I've seen constantly from the PMP/offering manager/product manager types and have been in the room where it happens. The thing that is utterly baffling is that it's usually a vague intent from an interested but not current user but then the person writing down these imagined requirements asks zero follow-up questions in a complete disservice to the user. So for example 'does your product use AI' or 'do you have a slack integration' open ended questions turn into firm requirements 'to close the deal' internally but with a completely headless goal. When I am usually in the room I at least give the customer the dignity of trying to work out what their idea/perceived benefit is with them so I can accurately transmit the knowledge to the team. Often someone more experienced with the product's offering can solve the real customer use case with existing features that just doesn't have the same label.
My favourite firing of a software company was when they expressed that they were refocusing from clear stability initiatives to machine learning driven analytic dashboards. This was even though this was a customer retention meeting company to company that was spawned over threats to not renew... because of stability issues.
My company is having trouble with this right now, in that we built a tool for the users with some higher level features managers would like, but it's still 3 ranks below the person purchasing the software. Even pitching it as a cost savings, they reply with "oh, my teams don't have trouble with that so we're not wasting money on it" then someone lower usually cuts in and says "well, we've been having trouble with it recently..."
We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.
They were usually never used, or used by an incredibly small percentage of users.
The platform ended up a complete mess because of the number of hacky features implemented and was a nightmare to maintain.
I'm sure we ended up losing more business due to the instability of the platform than we gained from adding these.
It's incredibly frustrating for the engineering teams who continually warned of the risks of rushing these things in without any analysis of usage.
Sometimes it is not the number of users that need the feature but just 1 or 2 very important users... The ones that have the final say over Yes we use this, or no we do not
Video conferencing vendors would talk about this a lot until Zoom ate their lunch, then suddenly their principles about not adding features go away.
Mind you his approach actually seemed to work - people would ask things in sales meetings then you'd never hear of that request again. It only went wrong in one sales meeting where one person realised what his approach was and started asking for sillier and sillier things....
Did you close the booking because of that feature? That type of decision is sometimes dependent on the financial situation of the company.
Yes, but who cares if they used the feature or not (!?!) the question was, did the buyer think it was 'essential' for the deal to go through.
I mean, cynically of course, but it matters.
Thanks, I threw this on my phone’s lock screen.
I have a strong intuition along the same lines, but find it hard to phrase on the spot when explaining to stakeholders (and myself) why issues filed should not be considered actionable as is.
I am dealing specifically with product users or prospective users who, possibly via stakeholders, request new features to implement.
The tip I quoted is very helpful with the latter as means of explaining why feature request should not be treated as actionable to stakeholders. Until I manage that, neither XY nor any other approach can be used.
Change means things will break.
Change means your way of doing things won't work anymore, and you'll have to waste time and money figuring out why.
Change means that your fixes for when things go wrong won't work anymore.
Change means months of hitting new edge cases.
Change is scary.
Once you have a solution that works well enough for your use case to succeed, your motivation to adopt change goes through the floor. The bigger the organization, the worse the worst case scenario, and the lower the appetite for change.
I sincerely believe IT people of the future will look back unkindly on this trend.
Deleted Comment
If the new feature doesn't affect my current workflow, then great! I can ignore it until I'm ready. The trouble, as the article notes, is the application making me aware of this brilliant new feature. Often application developers do this either by breaking a workflow and forcing interaction with the new feature or otherwise nagging me while I'm wanting to do something else.
Education outside of the application (tutorials, good documentation, blogs, etc) is perhaps a better way of driving adoption of features.
[1]https://en.wikipedia.org/wiki/Pareto_principle
If they haven't even attempted to do it now, chances are they won't after you implement a new feature.