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.
Those feature requests might be, say, integrations with other software they run (often one-off internal software) that they'd otherwise end up doing themselves. They want to see if "just asking nicely" will be enough to get that work done, rather than having to plan a whole project around it (even though it obviously would translate to you having to plan a whole project around it.)
No - users actually do want more features. They want more features than you can ever hope to deliver. Figuring out which features they will actually appreciate is the tough part. Your competitors are working very hard to build those features before you can. Your competitor's sales team is already cold calling your users.
Lightweight software is easy. As an engineer, I appreciate it, but it's not what the average user wants.
To be blunt, and along the lines of most other posts here... I'm skeptical that you're targeting the needs of your users.
Feature creep comes out when you want to target what 100% of everyone wants to do 100% of the time. You probably need one rock-solid platform that 80% of your audience wants, and make it so much faster, easier, and intuitive than everyone else.
You need to get your users addicted to your software, not huck out new features and hope one sticks.
That's correct, we don't tend to add dispensable features without multiple users asking for it. Of course, features you demand would mean the world to you, but from where I stand, a feature bloat is the last thing in my mind. And the funny thing is, some users find it reasonable.
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.
Almost all feature requests are asking to implement a particular solution rather than asking to come up with a solution to solve a particular problem.
The way I try to solve this is to ask "why?" as many times as it takes to get to a fundamental business problem. Then it becomes easier to have a user story (as opposed to a specific feature request) and come up with other solutions that can be measured against the story. It also helps to keep the product focused, as it's easier to tell when a story is not for your target market vs a feature request -- and then you can make a conscious decision to either stay away or deliberately expand to that market.
Even with an entire top-down team dedicated to serving the user and not corporate interests (which would be all but impossible, except in the world of open source), you'll always have a few stray users asking for features that not everybody wants, and there will be perpetual arguments about which features would benefit most users.
At the end of the day, the problem isn't that software is user-hostile, or written for engineers or corporate surveillance, but that nobody will ever agree 100% on what features should go into any piece of software.
Nice idea that of these people dedicated to evaluating customer's ideas/suggestions.
As a (hopefully competent enough) end-user, I can confirm how for some reasons the process of accepting (or refusing if it is the case) feedback or suggestions is often alien to many developers/programmers.
I don't know if this is due to them being too busy with other (possibly more important) things, if there is some sort of arrogance involved (i.e. the way the program is written is already perfect) or if there is some other reason, but surely to try and convince some software makers (I am talking about specific, "narrow", business software) that "feature x" is not needed or implemented in such a way that makes working with the program much slower or possibly making it more prone to errors is often a lost battle.
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.
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.
This has been my experience too, but with a slight difference - the new feature is very often an ask from sales, who are trying to close either a big new sale, or a big renewal. The prospect/customer demands some obscure feature that like 1% of our users will use (at most), but they’re a big prospect/customer. Product/UX/dev push back, say we should be working on features, performance and reliability that will benefit most customers, but it’s hard to come up with the precise revenue impact of this. Sales are better at convincing execs, and “this will help us close a $1 mil/year deal” is very tangible, so the new feature gets built.
This is kind of a symptom of “the buyer isn’t the user”, though. Often we build these features, then monitor usage, and the customer that demanded it doesn’t even use it! Or we build it, and it doesn’t matter, we still don’t close the sale.
I think the core issue is “building for users” and “building to close specific sales” are often strongly at odds with one another, and most of the time “building to close specific sales” wins.
So true. Adding features just makes more work for you. It doesn't mean more users or more active users. See I think when users request features the subtext is they're actually giving you an excuse for why they don't use your product more or don't use it at all. Features won't change lack of interest. And yet new features are so much fun to add when you enjoy your work. Just don't expect users to care. And don't expect to get paid.
i) the people who push features don't actually use them;
ii) people overestimate the pain users will go through to reach their services;
iii) in a lot of businesses it's actually really _hard_ to advocate doing nothing - no new features, no further investment, no changes. So something is done because something seems better than nothing, and thuse the product slowly accumulates cruft.
One of the reasons that we have feature creep is that many (most?) software teams either don’t know to, or don’t know how to, dissect feature requests from customers.
Imagine one of your customer requests a feature, e.g. “add a button on form X that transmogrifies a foo into a bar and then copies it to form baz”.
The request is communicating multiple things and blurring them together. First, your customer is telling you that they have a business problem that needs to be solved, eg converting foos into bars and making them available to other business processes. Second, they are telling you that in their current process in their business, which likely is centered on particular people with particular personalities, the best solution for them (“best” here means “least amount of stuff I have to change and grief I have to deal with”) is a button that does the conversion and then takes the next step in their workflow.
If you build the feature exactly as requested, it will likely only delight exactly one customer.
On the other hand, if you decompose the request into its different constituent parts, and then build the unique features in such a way it can be composed into arbitrary workflows, you are likely to delight many customers.
In my example, maybe you build some kind of library function that converts foos into bars, and then have a general way to compose it. If I were writing Microsoft Excel, I might implement a ConvertFooToBar() function and make it available in both formulas and in script.
In other words, dissect customer requests carefully, implement the uniqueness and throw away customer specific workflows in favor of composability. In fact it’s a lot like the Unix philosophy.
There are other kinds of feature requests that may not initially seem to fit this model, like security features. One I have gotten a lot (and made myself) is “federated login”. You still need to dissect these to separate business problem from workflow, eg the business problem might be “I don't want you having a list pf all my users and their passwords”; again you need to aim for composability while solving the business problem.
Separately, at a previous job, we stopped using the term “minimum viable product” because such MVP products are almost invariably shitty. Instead, we adopted the term “minimum lovable product”, implying that the product must not only be useful and fit for purpose but must also not be onerous to use; you don't want customers to discard it as soon as anything else comes along that isn't as painful.
As others have said, thank you for articulating this so well. As a developer, I've often gotten feature requests which seem crazy at first, but then make sense once I understand better the context in which it will be used or the degree to which it will make a customer or other user happy.
At the same time, it's really valuable to have a manager (and other stakeholders) who listen to the "This __really__ complicates our code and will take X weeks to implement, why don't you try this as a procedural workaround ..." suggestions that I make at times.
I really agree with your point that this type of thing strengthens my investment in the team and the product.
people seem to confuse adding features to additions in the interface. Most of the times users are either subconsciously frustrated by a problem or that there isn't a solution for it yet (i.e. why someone else hasn't solved it yet).
perfection??? I think most software sucks so much that it doesn't do anything useful. It would be better to try and get your product to do just one thing that is useful for one person.
Aiming for perfection is just an excuse for not building something useful.
It feels like progress, but it's not.
reply