5 ms·

I 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

by danjac 5y ago

I 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 that one thing a customer asks for but nobody else does. You end up wasting cycles and bloating the product with these one-off asks. Sometimes you have to stand your ground and say "no", because the ROI just isn't there. Startups in particular are vulnerable to this because they haven't got a large enough customer base and capital yet to comfortably say "no", and end up with features jammed into the codebase that are still there, years later, when the original customer that asked for them are long gone. There are exceptions of course - perhaps the feature is for some legal requirement e.g. "we need to show this specific set of Terms & Conditions before the user clicks Yes" they must have and can't live without.

amitport 5y ago
If it's in the enterprise sales phase then sales will just say "yes, no problem". Ideally they will talk with engineering, but...
- danjac 5y ago
  To be totally fair to sales people, it's very, very hard to say "no" when an enterprise customer is dangling a contract in front of your nose that means your company keeps the lights on for another year. But enterprise is really something you should look at if you really understand the niche, have lots of contacts, and plenty of patience and runway.
skeoh 5y ago
Somewhat related: https://en.wikipedia.org/wiki/XY_problem https://en.wikipedia.org/wiki/XY_problem
- jwally 5y ago
  This isn't somewhat related - it's the root cause :-)
_the_inflator 5y ago
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 (symptom vs. root cause)? Product development is incredibly hard to get it right. However, do less as a general advice. Think about Word and its feature overload. There is a downside to customer feature wants: clutter and distraction. Users of all kind are allergic to noise. Keep that in mind. I call this "friction free". I think in systems, as a general abstraction and modules. I classify features. For example Power Users can get a special Role and Admin area where you can abstract there needs away. Their productivity is different. I learned as a rule of thumb, that you should talk a lot to your customers and blend that with data. Data itself (usage tracking) is highly misleading. This is hard and I aim for general satisfaction level. People who like your products tend "get" your idea and don't fight it. Have fun! :)
- maigret 5y ago
  > 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.
  - antifa 5y ago
    That's weird, I always thought the absence of additional information and options were what was hindering me from performing easy tasks.
- HelloMcFly 5y ago
  Good doctors don't ask patients what medications they want, they probe about symptoms, context, desired outcomes, etc. I find this a reasonable (not perfect) analogy in my work as a consultant.
- 5y ago
duckmysick 5y ago
Customers are good at communicating there's a problem. They are bad at identifying a solution.
- jillesvangurp 5y ago
  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 that the customer insists they have and then confront their company with requirements that don't make sense. Closes the deal but sets everyone up for failure.
  - dragonsky 5y ago
    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.
    - TeMPOraL 5y ago
      This just shows how ass-backwards the whole industry is with its "standard practices", a lot of which I see repeated as advice in the thread. It goes like this: 1. Push a product (or these days, service) at people. Preferably a captive audience. In B2B, that may involve growing an "internal champion" at a customer company, preferably a manager that doesn't need the software themselves, that can be bamboozled by your sales people. 2. Don't explain how the product works or what it does to your sales people. That's techie stuff. Also, once you give your sales people the license to bullshit, it literally doesn't matter what the product does[0]. 3. Don't ask your users what they want or like. They don't know what they need. Rely on thorough surveillance instead, as a good "data-driven" shop you are. 4. If some users manage to somehow deliver feedback to you, ignore it. Users don't know what they want, and can't articulate solutions. 5. If the client does not understand how the software should be used, that again means they just don't know what they want. Interfaces are designed to be intuitive. No training is ever necessary. Software manuals? That's so 1990. 6. The so-called "power users" are making point 5 harder. Ignore them with extreme prejudice. After all, them being more productive doesn't earn us more money. It's a self-reinforcing pattern of industry-wide self-delusion. No wonder so many non-tech people hate technology. On the "XY problem" someone mentioned in this thread: one of the biggest problems on StackOverflow and other forums, and previously on IRC, is that quite often, the person asking for X actually wants to know X, not the Y, and they especially don't want to have their sanity or competence questioned. -- [0] - Per HG Frankfurt, bullshit is when you don't care if what you say is true or false, as the reality is orthogonal to the goal you want to accomplish.
mwcremer 5y ago
>Their feature requests are often a proxy for something else they aren't able to articulate. Our usual answer for this is: What are you trying to do?™
globular-toast 5y ago
Agree wholeheartedly on both points. My product owner needs to understand this. One of the difficulties is the users don't really know what's possible, so they'll come up with ideas based on the current solution. Often if you listen to them you'll realise they're actually battling against the current solution anyway and adding more features won't help with that.
Cthulhu_ 5y ago
I'm in this exact situation. We run a niche software product in the telecoms industry, and we have one major customer who is also the most opinionated on how it should work. They keep sending in feature requests (for the old, poorly written application), 'we' (i.e. the boss) keeps saying yes. I'm still here and there working on features that we apparently agreed to build for them over two years ago. At least the boss is learning to say no more.
inopinatus 5y ago
One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.
- bruce343434 5y ago
  Real life lazy evaluation, I like it
- jerrre 5y ago
  A quick way to teach users never to click that button again, I'd say.
  - jjk166 5y ago
    If they'ed rather not click the button than get you to fix the button, clearly they don't need a working button.
- alvarlagerlof 5y ago
  I would run from that product.
  - jaywalk 5y ago
    You would never know that this was happening.
MayeulC 5y ago
> not to blindly just give customers what they ask for, but to figure out what they really need Classically called an xy problem: https://xyproblem.info/ https://xyproblem.info/
zhdc1 5y ago
One piece of advice I was told years ago as an intern. If a customer wants it, they have to pay for all of it, and once it's done, you have the right to provide it as a feature or service to other customers as you see fit.
arethuza 5y ago
"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.... :-)
- marcus_holmes 5y ago
  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.
  - arethuza 5y ago
    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.
marcus_holmes 5y ago
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.
- TeMPOraL 5y ago
  Wasting time and money on this sounds like just deserts for being too pushy with one's sales techniques.
- donatj 5y ago
  I never even considered this. Given the number of times we've built some really stupid feature because a potential big client had it as a requirement, I bet at least a few were just telling us to go away.
  - marcus_holmes 5y ago
    The standard way of finding this out is to ask them to pay at least something towards developing the feature. If they're genuinely interested but genuinely need this feature, this is reasonable and they'll be agreeable. If they're not actually interested, then this doesn't make any sense for them and they'll refuse.
berkes 5y ago
> "but to figure out what they really need." I've had a boss who was very "pragmatic". Used to come up with concrete and practical solutions all the time. "We need to add a button here" or "We need an extra tab that only X can see" and so on. Wasn't pragmatic at all, just listened to the customers, then translated their requests into what he thought would be the simplest (cheapest, fastest) to implement. While this sounds Lean, it really is a sure way to accumulate an immense mess of complexity, legacy and clutter in no time. What we really needed was some design sessions to translate the customers' request into something that fit the product and matched a vision (or to disregard it, it that fit is not found).
rawoke083600 5y ago
Since we sharing :) One "trick/lesson" I learned from working with a "big dist system" (think scraping-jobs) with lots of clients(read unique errors) and requirements was: Never-ever-ever do: if(client->id=123){ //do special workaround,process,feature or magic-dance }else{ //normal non-magic-dance,process,flow } The only "allowed method" for implementing such code was to add a "JobOption" to the client-config. Thus you have: if (client->joboptions->magic_dance){ //magic-dance-feature-workaround } You'd be surprised that over time how many clients have "similar requirements" but different combinations and just being able to do a checkbox-check on their job-config (enable magic-dance) was gold for maintenance and keeping out the spaghetti code! It was the 'greatest of sin's in our org to write "if client->id=123"

by danjac 5y ago

amitport 5y ago

If it's in the enterprise sales phase then sales will just say "yes, no problem". Ideally they will talk with engineering, but...

danjac 5y ago
To be totally fair to sales people, it's very, very hard to say "no" when an enterprise customer is dangling a contract in front of your nose that means your company keeps the lights on for another year. But enterprise is really something you should look at if you really understand the niche, have lots of contacts, and plenty of patience and runway.

skeoh 5y ago

Somewhat related: https://en.wikipedia.org/wiki/XY_problem https://en.wikipedia.org/wiki/XY_problem

jwally 5y ago
This isn't somewhat related - it's the root cause :-)

_the_inflator 5y ago

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 (symptom vs. root cause)? Product development is incredibly hard to get it right. However, do less as a general advice. Think about Word and its feature overload. There is a downside to customer feature wants: clutter and distraction. Users of all kind are allergic to noise. Keep that in mind. I call this "friction free". I think in systems, as a general abstraction and modules. I classify features. For example Power Users can get a special Role and Admin area where you can abstract there needs away. Their productivity is different. I learned as a rule of thumb, that you should talk a lot to your customers and blend that with data. Data itself (usage tracking) is highly misleading. This is hard and I aim for general satisfaction level. People who like your products tend "get" your idea and don't fight it. Have fun! :)

maigret 5y ago
> 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.
- antifa 5y ago
  That's weird, I always thought the absence of additional information and options were what was hindering me from performing easy tasks.
HelloMcFly 5y ago
Good doctors don't ask patients what medications they want, they probe about symptoms, context, desired outcomes, etc. I find this a reasonable (not perfect) analogy in my work as a consultant.
5y ago

duckmysick 5y ago

Customers are good at communicating there's a problem. They are bad at identifying a solution.

jillesvangurp 5y ago
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 that the customer insists they have and then confront their company with requirements that don't make sense. Closes the deal but sets everyone up for failure.
- dragonsky 5y ago
  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.
  - TeMPOraL 5y ago
    This just shows how ass-backwards the whole industry is with its "standard practices", a lot of which I see repeated as advice in the thread. It goes like this: 1. Push a product (or these days, service) at people. Preferably a captive audience. In B2B, that may involve growing an "internal champion" at a customer company, preferably a manager that doesn't need the software themselves, that can be bamboozled by your sales people. 2. Don't explain how the product works or what it does to your sales people. That's techie stuff. Also, once you give your sales people the license to bullshit, it literally doesn't matter what the product does[0]. 3. Don't ask your users what they want or like. They don't know what they need. Rely on thorough surveillance instead, as a good "data-driven" shop you are. 4. If some users manage to somehow deliver feedback to you, ignore it. Users don't know what they want, and can't articulate solutions. 5. If the client does not understand how the software should be used, that again means they just don't know what they want. Interfaces are designed to be intuitive. No training is ever necessary. Software manuals? That's so 1990. 6. The so-called "power users" are making point 5 harder. Ignore them with extreme prejudice. After all, them being more productive doesn't earn us more money. It's a self-reinforcing pattern of industry-wide self-delusion. No wonder so many non-tech people hate technology. On the "XY problem" someone mentioned in this thread: one of the biggest problems on StackOverflow and other forums, and previously on IRC, is that quite often, the person asking for X actually wants to know X, not the Y, and they especially don't want to have their sanity or competence questioned. -- [0] - Per HG Frankfurt, bullshit is when you don't care if what you say is true or false, as the reality is orthogonal to the goal you want to accomplish.

mwcremer 5y ago

>Their feature requests are often a proxy for something else they aren't able to articulate. Our usual answer for this is: What are you trying to do?™

globular-toast 5y ago

Agree wholeheartedly on both points. My product owner needs to understand this. One of the difficulties is the users don't really know what's possible, so they'll come up with ideas based on the current solution. Often if you listen to them you'll realise they're actually battling against the current solution anyway and adding more features won't help with that.

Cthulhu_ 5y ago

I'm in this exact situation. We run a niche software product in the telecoms industry, and we have one major customer who is also the most opinionated on how it should work. They keep sending in feature requests (for the old, poorly written application), 'we' (i.e. the boss) keeps saying yes. I'm still here and there working on features that we apparently agreed to build for them over two years ago. At least the boss is learning to say no more.

inopinatus 5y ago

One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.

bruce343434 5y ago
Real life lazy evaluation, I like it
jerrre 5y ago
A quick way to teach users never to click that button again, I'd say.
- jjk166 5y ago
  If they'ed rather not click the button than get you to fix the button, clearly they don't need a working button.
alvarlagerlof 5y ago
I would run from that product.
- jaywalk 5y ago
  You would never know that this was happening.

MayeulC 5y ago

> not to blindly just give customers what they ask for, but to figure out what they really need Classically called an xy problem: https://xyproblem.info/ https://xyproblem.info/

zhdc1 5y ago

One piece of advice I was told years ago as an intern. If a customer wants it, they have to pay for all of it, and once it's done, you have the right to provide it as a feature or service to other customers as you see fit.

arethuza 5y ago

"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.... :-)

marcus_holmes 5y ago
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.
- arethuza 5y ago
  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.

marcus_holmes 5y ago

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.

TeMPOraL 5y ago
Wasting time and money on this sounds like just deserts for being too pushy with one's sales techniques.
donatj 5y ago
I never even considered this. Given the number of times we've built some really stupid feature because a potential big client had it as a requirement, I bet at least a few were just telling us to go away.
- marcus_holmes 5y ago
  The standard way of finding this out is to ask them to pay at least something towards developing the feature. If they're genuinely interested but genuinely need this feature, this is reasonable and they'll be agreeable. If they're not actually interested, then this doesn't make any sense for them and they'll refuse.

berkes 5y ago

> "but to figure out what they really need." I've had a boss who was very "pragmatic". Used to come up with concrete and practical solutions all the time. "We need to add a button here" or "We need an extra tab that only X can see" and so on. Wasn't pragmatic at all, just listened to the customers, then translated their requests into what he thought would be the simplest (cheapest, fastest) to implement. While this sounds Lean, it really is a sure way to accumulate an immense mess of complexity, legacy and clutter in no time. What we really needed was some design sessions to translate the customers' request into something that fit the product and matched a vision (or to disregard it, it that fit is not found).

rawoke083600 5y ago

Since we sharing :) One "trick/lesson" I learned from working with a "big dist system" (think scraping-jobs) with lots of clients(read unique errors) and requirements was: Never-ever-ever do: if(client->id=123){ //do special workaround,process,feature or magic-dance }else{ //normal non-magic-dance,process,flow } The only "allowed method" for implementing such code was to add a "JobOption" to the client-config. Thus you have: if (client->joboptions->magic_dance){ //magic-dance-feature-workaround } You'd be surprised that over time how many clients have "similar requirements" but different combinations and just being able to do a checkbox-check on their job-config (enable magic-dance) was gold for maintenance and keeping out the spaghetti code! It was the 'greatest of sin's in our org to write "if client->id=123"