I was a consultant and I used the rule of 3 whys. When a customer asks for a feature, get back to the root concern by asking "why"?
When users never use the features they asked for
161–170 of 228 posts
Re: When users never use the features they asked for
#162Earlier quoted context omitted.
Customers are good at communicating there's a problem. They are bad at identifying a solution.
They are actually bad at both. They usually start by telling you an imagined solution to the problem they think they have. Then you need to pick that apart to figure out what the real problem is that they have and convince them of a solution that will actually solve their issue. Sales people, depending on their experience, are not a whole lot better. They'll happily sell solutions that don't yet exists for problems t…
I wonder how many of these feature requests are because the client does not understand how the software should be used? It could be that it is not designed to solve there problem, and having purchased it they are trying to get some utility from it. Would not be the first time that had been forced to use a system that was not suitable.
Re: When users never use the features they asked for
#163I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…
"but to figure out what they really need."
I actually had a senior manager at a large company I once worked for tell me after we demoed a new feature that had been added for his team: "that may be what I asked for but its not what I want".
It can be hard to come up with a constructive reply to stuff like that.... :-)
Re: When users never use the features they asked for
#164I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…
Exactly these 2 points. I as a PM for a platform may sound arrogant, however I strictly adhere to the phrase: Only what customerS need, not what they want. I also rely on numbers and classification: does this feature help one or more user? Which type? Power User(s)? Everyday normal users? Is this just emotional, a want or need? How much does a user benefit from the change? Can we do better, are we missing something (…
> clutter and distraction. Users of all kind are allergic to noise
It's actually worse than this - additional information and option hinders the users. It make them less able to find, understand and successfully perform otherwise easy tasks. At some point, it also make them stop use the product. Those major drawbacks are important to state to all stakeholders.
Re: When users never use the features they asked for
#165I was a consultant and I used the rule of 3 whys. When a customer asks for a feature, get back to the root concern by asking "why"?
Re: When users never use the features they asked for
#166I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…
"but to figure out what they really need." I actually had a senior manager at a large company I once worked for tell me after we demoed a new feature that had been added for his team: "that may be what I asked for but its not what I want". It can be hard to come up with a constructive reply to stuff like that.... :-)
This is why I always build things as iterative prototypes. Get something in front of the customer asap, so they can tell you what's wrong with it. Trying to get humans to accurately and completely describe what they want in a spec is doomed to failure.
Re: When users never use the features they asked for
#167Earlier quoted context omitted.
Pretty much this. A lot of the work would have been roughly equivalent to trying to de-minify some JS. With a modern IDE the task would have been a lot easier. I don’t know if Eclipse had refactoring assistance built into back then, but if it did, I’d never even heard of the idea. I was sitting on not much more than a year of programming experience at the time.
Eclipse had refactoring from the start. It was pretty advanced IDE for the time.
It had to be, given that it was basically Visual Age for Smalltalk rewritten in Java.
Hence why it had, and still keeps it, a Smalltalk like code navigation.
Re: When users never use the features they asked for
#168I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…
Also the "feature spiral of death" when a customer's feature request is really just them trying to say "no" politely. There is no amount of features that will make them say "yes". But once they've started down this road it's very difficult for them to admit that they didn't want any of the features they're asking for, they just want you to leave them alone.
Re: When users never use the features they asked for
#169Earlier quoted context omitted.
"but to figure out what they really need." I actually had a senior manager at a large company I once worked for tell me after we demoed a new feature that had been added for his team: "that may be what I asked for but its not what I want". It can be hard to come up with a constructive reply to stuff like that.... :-)
This is why I always build things as iterative prototypes. Get something in front of the customer asap, so they can tell you what's wrong with it. Trying to get humans to accurately and completely describe what they want in a spec is doomed to failure.
Indeed, and if this chap hadn't seen the multiple mockups and iterations during development I might have had some sympathy.
Edit: We eventually found out it was pure office politics, nothing to do with what we had actually built.
Re: When users never use the features they asked for
#170Building the feature right is hard. They might want it, but not the way you built it.