This post points to perverse economic incentives as being one possible cause, but I have also seen this happen in open-source projects. It's a matter of listening to the wrong people, in my view. User feedback is incredibly valuable, but when user feedback comes in the form of GitHub issues rather than careful testing and conversation, the team will inevitably find themselves building more and more and more for no real benefit.
I've quoted this before, but what Don Norman says in The Invisible Computer still applies:
"Don’t ask people what they want. Watch them and figure out their needs. If you ask, people usually focus on what they have and ask for it to be better: cheaper, faster, smaller. A good observer might discover that the task is unnecessary, that it is possible to restructure things or provide a new technology that eliminates the painstaking parts of their procedures. If you just follow what people ask for, you could end up making their lives even more complicated."
The problem here is that the propensity to add bugs and features is disproportionate across the user base. Some people get a kick out of adding feature requests and being 'noisy'. Some people have an important or good idea but will never take the trouble to post it.
The problem, then, is being able to sort between this and not only (a) keep the active community members on-side and (b) find a way to flesh out those hidden requirements from less-engaged people.
Of course the other issue is when community requests are not necessarily profitable for the company that provides them.
Users mean well. Basically, they want to be part of the process. They are trying to help you solve the problem. It's way too easy to fall into the "If we just had this one feature" trap. Sales staff love coming up with feature requests and the developers love having something they can sink their teeth into.
1. Your users leverage unintended behaviours, which obstructs your ability to move forward with meeting needs with intended behaviours in your intended target market (unfortunate but very real)
2. You know if you add or improve existing features, you can access more users, or an prospective user worth more than the existing ones
3. It's a passion project and you want it to function/look/whatever a certain way
I've encountered all of these, and each time it becomes a pretty big pain to make progress.
Everyone who builds anything needs to realize this: don't let your users dictate your features. They aren't inventors, they aren't designers, they aren't developers, they're just users. And they can lead you astray.
Don't let users send you problem reports in the form of unimplemented feature requests, if they do you need to retranslate them back into problem space before ingesting them. This is a special case of "satisficing". The amount of work that a user puts into figuring out what they "need" to solve their problem is often trivial, and insufficient compared to the amount of work that needs to actually go into feature development. More often than not users are just going to tell you the first idea that comes into their head on how to solve their problem. Sometimes that's fine, more often than not it's a mistake. And it's a much worse mistake to dump lots of implementation work into a feature that was designed based on a nanosecond of effort.
Take control of your own design, evaluate lots of options for solutions for problems, take the time and effort to figure out which ones are actually good, and then implement those. Don't become a marionette for user requests.
A product is great. The company providing the product raises lots of money.
Investors want a return on their investment and the founders want a big payday. So the company starts adding lots of features to increase sign-ups, conversions, and revenue.
But these features often poison the user experience. Even as lots numbers go up in the near-term, the product withers and dies as users defect.
The key is to ignore the feature request, and focus on the problem.
Users don't come to you with problems, they come to you with shitty solutions.
You need to take their solution, reverse engineer their real problem from that, then work out a good solution for that problem that fits well with your product.
This is often a scope problem. In open-source software, or corporate software not-well-managed, it's easy to take on too many features. This can happen by trying to address issues and PRs that should be rejected as out-of-scope. Or saying know to a request from another team, or a customer.
I wish that I had good advice that would fix this issue for you. Unfortunately, if I could, I'd be so busy and have such an incredibly high hourly rate that I wouldn't have time to reply to comments on Hacker News....:)
I've learned a couple of things about users. The biggest one is that users tend to make a value judgement about your product very quickly. They're not even entirely conscious of the factors that went into making the decision. Often, they'll try to use logic to justify why they feel the way they feel...and one major way they do this is via feature requests. Unfortunately, since they are just grasping for straws, adding this feature often does not resolve the initial feeling that your product is not right for them.
Best of luck to you - I'm certainly in your corner and wish you an incredible amount of success!!
Feature requests are really prone to this. Customers will only ask for features they can imagine, not the ones that really solve their problem. A significant chunk of the time the customer is better served by a different feature that takes less work.
This is why i don't like tender-based software projects. The tender already describes the features needed, and they must be built even if they are suboptimal for the problem domain.
Fundamentally any feature request is just an engineering problem. Sometimes they're interesting, sometimes they're not. If you trust whoever makes these issues on your board (or whatever it is you use), why would it be demotivating? You know you're building stuff folks want, because making sure that's the case is what the person making those issues is trying to do.
If you can't trust your coworkers, every workplace is demotivating.
The corollary to this is also that if nobody likes your product, adding more features to it isn't likely to help. Lots of developers also fall into that trap.
As a developer, I have built many features. I wouldn’t say all, but many of them were a waste of everyones time. These features were usually built because the product group told us to build them. I found product teams make these decisions based upon some customer interviews, email feedbacks, phone complains and mostly their “gut”. And its hurts the most when we would bust our asses building and releasing it, to only realize that our customers are not using it. Reasons vary from customers wanting X and we building Y to the user flow not being right. Its further disappointing to learn after a release that customers didn’t even care enough to click on the feature i built, forget about using it.
Prioritizing what to build, which features to double down on and which ones to ignore, what to prototype and what to scrap etc. are all important questions which the product team needs to decide. In their defense I feel like these are difficult questions. To me its just that I don't think they can afford to get this wrong. Building the wrong features, maintaining them and then eventually killing them is very expensive and just a moral killer.
The question in my mind is can product teams make better product decisions? Why do we have to ask developers to build things, release it and then learn whether customers really wanted it. To address this issue and empower product teams I have built www.featureKicker.com. It enables teams to deploy features before building them, collect feedback, analyze data and make better, more informed, data backed decisions. It enables a product manager to look a developer in his or her eye and say “I need you to build X and I need it done by Y. I have Z number of customers waiting for it. Here you can read what they have to say”.
I would love to hear from the community of what they think of this solution. I want to help companies make better product decisions and am looking at the community for guidance.
There are certain customers and prospects, and certain industries, where this is endemic, where you just have to stop listening to customers. Sometimes they actually do not know what they want/need. If you faithfully log feature requests, you might find there is very little commonality. If you still have a customer base, it just might mean you actually serve your target audience/industry something useful.
Without getting into too deep a discussion of features, this development attitude of “implement everything, let them use what they want” is historically awful. The developers lose focus on what they are making, the users lose focus on what they are using. Eventually a platform that does a great job of any of the ten things that yours does poorly is a superior product and its creators are praised for shipping such a clean and minimal product.
I forget who said this (Paul Buchheit, maybe?), but it made a lot of sense to me: don't listen to your users, watch your users. Figure out what they're trying to accomplish -- via usability testing and analytics -- and use that to inform product development.
Feature blight is a separate issue. It's good to try out lots of stuff, but you can't just vomit out feature after feature -- you have to iterate. After you release a feature, watch how people use it. If they're not using it, tweak it or axe it. Features need to earn a permanent place in your app.
It's not just customers. The same thing happens with internal stakeholders. I've seen products where there is basically zero actual software design because development is driven entirely by short term feature requests.
The impression I have, in the humble projects and companies I work with, is that it's more related to the decision-makers.
So many features are added based on whims, decided on meeting rooms and based on engineers or managers gut feelings, that it actually seems normal for software to get complicated. If we tried to keep the new features somewhat restrained to things we actually are confident that users want (by doing user research!), maybe the piling of new features would slow down.
If you're spurning customers away, very few will come back and tell you they are leaving. This is often the reason why developers seldom get it and embrace that signal.
More features do not necessarily translate to better outcomes. Features will often be measured at a point in time. It has to be good enough for people to use a product and not inconvenient enough for people to run away.
More development does not mean more usage. Imagine someone in utilities connected your home to a power supply and then decided to periodically change it just because they need to show that they work - and not to be useful to you. Would you like that? That sort of active development thing is found seldom outside the subscription based SaaS business.
Case in point: AWS, you have dozens of services launched every quarter and maybe its developers there get bored and launch new services, yet most people use those few key services a lot and are happy to stick around as long as things don't break terribly.
The issue is that we've come to liken features and bloat with usage. Then we assume our customers want that bloat and can afford to do so. Mostly at that point, companies are optimizing for their own development over customers needs. Over a period of time we get disillusioned that our bloated software is often what our customers need. Then when that doesn't work well, try explosive methods such as platform obsolescence. Thus leading to loss of sustainability.
This post points to perverse economic incentives as being one possible cause, but I have also seen this happen in open-source projects. It's a matter of listening to the wrong people, in my view. User feedback is incredibly valuable, but when user feedback comes in the form of GitHub issues rather than careful testing and conversation, the team will inevitably find themselves building more and more and more for no real benefit.
I've quoted this before, but what Don Norman says in The Invisible Computer still applies:
"Don’t ask people what they want. Watch them and figure out their needs. If you ask, people usually focus on what they have and ask for it to be better: cheaper, faster, smaller. A good observer might discover that the task is unnecessary, that it is possible to restructure things or provide a new technology that eliminates the painstaking parts of their procedures. If you just follow what people ask for, you could end up making their lives even more complicated."
reply