> And you can understand why it happens! Developers love to develop; marketers want new stuff to market. Adding new features, shipping new code, is fun and exciting. Merely maintaining a successful app? Bleah. So dull. That drives a lot of feature creep, right there.
> The thing is, we can usefully flip this concept on its head! What if more developers developed a sense for the “maximum” number of things a product should do — and stopped there?
I'm sorry, but the author misunderstands entirely the reason for feature creep. It generally has nothing whatsoever to do with "fun" or developers "wanting to develop" or marketers "wanting to stuff to market".
Rather it has to do with segments of customers genuinely needing a given feature, and they won't buy the product unless it has the feature.
There's the old quote about how 80% of the people only use 20% of the features -- but then the punchline is that they're all using a different 20%.
That screenshot of all the Word toolbars? Guess what. There are different user segments that actually use each one of those toolbars. Yup.
So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish. If you're a business and you want to make money and you'll profitably sell to more customers if you can build in a new feature, then you do it.
Why would any company restrict itself to an arbitrary "maximum" and leave money on the table...?
As an example I offer up a review of an Open Source Word-Alternative back in the early 2000's.
The reviewer liked the product enough, but slated the fact it didn't have a word counter. Now, I for one, have never cared about the number-of-words in a document. But, it turns out, journalists tasked with writing a 2000 word review _really_ care.
With great popularity comes great variability, and more "corner cases" matter.
Incidentally the solution is not fewer features, but better UI. Notice thats a very old screenshot of Word. Whereas Word to day looks very different, has the same (or greater) feature set, and a much more streamlined interface. The much-hated-on ribbon bar is actually a better interface than endlessly-deep menus and a million toolbars.
Also wouldn't most devs much rather fix bugs in an existing app than add features?
Piling more chairs on top of each other to get features out the door can be demoralizing. You know it's going to collapse under its weight eventually, and you're just speeding the company along to The Big Expensive Rewrite.
But fixing bugs? An actual chance to make things better? That is satisfying.
> So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish
I disagree, I think the Unix philosiphy solves the problem. You build simple tools that do one thing, and do that one thing well, but you make it easy for the tools to work together and then you can have pieces that do one simple thing while still serving needs.
When new needs come up that aren't addressed by current tools you simply put together another simple tool that does that.
It's not the only cause but empire building[1] is a very real phenomenon. Maximum viable features is a very interesting concept but it's just that, a concept, nobody says you have to stick to it, it can just be a tool in your toolbox to limit scope creep. One thing I don't have too many of is tools to limit scope.
> the punchline is that they're all using a different 20%.
The problem is that each additional features imposes costs on those users who don't need it. An example would be JIRA. JIRA is designed to have every feature possible. But as a cost it is hellishly slow and is hard to find anything in.
Each additional 20% of the features you support cuts the UI and technical effort that can be put into the other 20%s of features.
The end result is the standard big corporate apps that feel heavy weight despite doing what feels like a pretty simple thing.
It makes sense for companies to do it. Because the cost is born by the consumers.
I liked some of the takes on building Minimum Lovable Product (MLP) instead. Retaining the focus on why people would want to use it, and with your vision for the product central.
Scope and feature creep has nothing to do with customers. It happens in all creative endeavors, most of which do not have anything like customers. It happens in art, music, hobby programming, event planning, etc etc. Everything.
If you sit down to try to write a program that no one will ever see but yourself, you will have to fight against feature creep. It comes from the creators themselves. It's basic human nature to find it easier to desire things than to restrain oneself.
> Why would any company restrict itself to an arbitrary "maximum" and leave money on the table...?
Because when there's too much options and features users are going to be overwhelmed.
Also, feature creep has nothing to do with developers wanting or not wanting, those are product decisions.
I saw that in the past with an ecommerce, we had a good portal, then stakeholders in corporate that need to justify their salary started shoving more and more stuff, now what was a simple search-find-pay has become interrupted and overwhelmed with features and information.
>Rather it has to do with segments of customers genuinely needing a given feature, and they won't buy the product unless it has the feature.
there is another reason feature creep happens for certain categories of products, which is regulation. If a law is passed mandating industry X needs to support Y that feature will be added for any product wanting to sell to the market that has mandated the feature.
any analysis that misses these kinds of real world scenarios is not that interesting.
I agree with you on your points but the quote even contradicts itself here.
Adding new features is fun and exciting but feature creep is bad?
What is feature creep if not new features? (Well new features + the idea that we're adding more features than we're thinking about their implementation and/or before the app does what it set out to do in the first place)
I've been exploring this concept a bit at my startup for our B2B offerings. Where I've landed is a robust set of feature toggles that Sales and Account Management configure. Within the confines of your Microsoft Word toolbars analogy; since the software we offer is similar to SaaS and delivered via a web browser this effectively means we can "hide" the toolbars that the client isn't interested in.
This is all pretty early days, but my hope is that we can iterate the core "have feature toggles" concept to the point where we have the ability to turn functionality and function accessibility on across many verticals. I hope that one day internally we can configure things a per-customer and per-user-persona basis. I also hope that one day we can expose some of those switches to admins and/or everyday users, possibly with paywalls or other strictures.
How about maximum viable product definitions for go to market? I've worked with PMs that have engineering build-build-and-rebuild delaying release until they feel it is "good enough", or what I think is really going on, "perfect". Then it gets into the hands of users who don't care about most of what the PM felt was important or necessary. In those cases (what I call "Steve Jobs syndrome) it would've been nice to say the product was limited to doing x, y, and z for the release.
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.
That's the difference between having features people use, and having features people think they will be used - communication.
Often times customers come with feature requests but dev/biz fail to translate that into problem resolutions.
"I want it to export all my data for this time period", should be followed by an in depth discussion on why that's needed, whose going to do perform the task, how often, under which circumstances.
A bad translation more often than not translates to bad UIs, half-features, and hours upon hours wasted on dev time and customer support time.
The more powerful machines have become, and the larger the screens we work with (I am writing this on an LG 49" ultrawide), the easier it becomes to jam a bunch of stuff in there.
A good exercise for Keeping It Simple, Stupid (KISS), is to write firmware for fixed displays, or mobile device software (although mobile devices are starting to look more and more like full-sized computers, these days).
I learned religion from Scott Jenson's excellent The Simplicity Shift[0]. It was written before the iPhone.
Most of the tips in there, could be applied to desktop/laptop computer software. I used to use his "triage" methodology, in the days that we wrote host software, at my old job.
This book is over 100 pages long -- any chance you could summarize some of the most important ideas, like the "triage" methodology, so we can figure out if we want to read it?
A good product is like art. It requires a vision and the ironwill to actually achieve it. It requires ruthlessly deleting features and annoying a subset of users for the greater whole.
In terms of teams, I don't think "developers" are here to blame. Where are the product managers? And I don't mean the project managers pretending to be product managers. Great products require the vision of a designer, organizational skill of a product manager and developers to be able to implement and/or tell everybody is asking for something feasible with current technology.
> What if more developers developed a sense for the “maximum” number of things a product should do — and stopped there?
Then what? Follow this line of reasoning to its terminal (or shall we say, maximal) conclusion: developers would be laid off or fired (or at best shifted to another product, which might not be what makes money for the business, so back to an increased risk of being laid off or fired). Tell your boss that the product is done, no more updates needed, and see how well it goes for you.
We already know why feature creep happens, people need to work to survive. One of the few ways to prevent this occurs in open source, where people's livelihood is (generally speaking) not tied to their output. If we want feature creep to stop, we would have to live in a society where people wouldn't need to work to survive. I'm sure that will come with AI automation soon enough, if ChatGPT and Stable Diffusion and other adjacent programs are anything to go by.
You are correct to frame this in economic terms. It is very much an economic issue as much as a software issue.
Assume for the moment you had a sales driven model, like say Word did in the era of those screenshot.
Your whole business depends on more sales. Developers, support, admin - stop selling for a month and the business goes under.
More customers means more support, which means more overhead, which means sales has to increase in pace. This clearly isn't sustainable (so, no one gets support.)
Part of those sales goes to existing customers. (upgrades). Which means new features.
It's a treadmill to dream up new things just so there are things to sell as part of the upgrade.
Recognizing this route could only end in a crash we switched to a SaaS model. Now support is a priority (and we'll funded), programming, and random new features less so. Customers get better support, programmers get rewarded for fixing bugs, new features can be considered, well planned, and done properly on a decent time scale.
And if the business never sells another copy, it's OK. Support remains funded.
It's a much better model for customers, for support and programmers, and ultimately yes, better for business owners as well.
> "The saddest thing for me about modern tech’s long spiral into user manipulation and surveillance is how it has just slowly killed off the joy that people like me used to feel about new tech. Every product Meta or Amazon announces makes the future seem bleaker and grayer."
I was reminded of this quote (from Shannon Vallor who I don't know via a Cory Doctorow post https://pluralistic.net/2022/10/20/benevolent-dictators/#fel...). It's not even just about having too many features anymore, it's about having actively user hostile features that want to manipulate you into doing things or steal your data.
The article mentions Word / MS Office which is the prototype for this. They long ago crossed the Rubicon into the "too many features" domain, but recently they have moved into "connected experiences" - we want to upload everything you write and will dark pattern you into some technicality of consent, plus nonsense like accessibility checker that complains about things I do in internal company presentations while (outside of connected experiences, through some other scam to steal my data) uploads all my charts to MS servers and captions them for me so that blind users will now they are "a picture of a chart"
Anyway, that turned into a rant. Tldr, 2005 was about too many features, 2022 is about ultra manipulative features that try to steal your data and impose tech designers' world view on users
This makes me think of something Antoine de Saint-Exupery said, "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
I’d rather see maximally extensible products where users can customize extensions around existing products. If certain features are not wished maybe some mechanism to prune them as if they were an extension themselves that could be uninstalled.
I have a few problems with TFA, not least of all the fact that properly managed developers don’t generally add features for fun. Neither do marketeers, mostly those guys are just trying to interpret signals from their market and perhaps trowel some bait out there. However…
It is a brave product manager that declares his product more or less feature-complete. Because it is a far more frightening proposition for a company to begin a new product, perhaps only their 2nd ever, rather than glom-on extras to their first-born.
It’s one thing to manage a backlog of features into a product (or to discard them), but quite another to have the clarity of vision for your product that allows you to repeatedly say “no” even in the face of clear customer demand for functionality. Functionality that really belongs in your 2nd app, not your 1st. Even if you as a product manager have that clarity, you’ve then got to get the rest of the company behind you. IMO the only thing harder is getting a company to kill a product that needs killing.
We can’t avoid feature creep as viable company leaders because we would miss out on new customers. Maintaining a good UI amid constantly added features is really a product design issue. The real problem is rogue teams/line level product managers working in silos and missing opportunities to solve for feature demands with better planning and product design.
There are plenty of products have iterated over decades and maintained the same simplicity, think Ableton Live. I would even give Word some credit in that it has recovered from the earlier mess the author points out by delivering a toolbar architecture through its ribbon menus and advanced settings to hit those less common use cases while maintaining a level of approachability. Sometimes all it takes is a step back and a bit of thought on design.
If your product is too simple it is easily copied by a competitor. Competition for limited customers is where most feature creep comes from. The fear that if you don’t do X then a customer will go elsewhere. When you are catering to the whims and sales cycle of 20 or 30 customers all hell breaks loose.
Ultimately, it's features per se, but the UI / UX that reflects those features. The point begin, a UI / UX paradigm that support 10 features might not be the ideal paradigm for say 20 features. Just look at the Word screenshot in the article.
You can't keep adding to a broken paradigm and get ideal results. True, that might disrupt current users but done right they'll eventually appreciate it if you've made the tool less friction-y. An alternative is to give user the option to see what they want and ignore what they don't. Maybe allow them to change background colors so their most used features are easier to see?
Put another way, it's not how much you say, it's how you say it.
> [image of slider going from red "min" to green "max"]
> This is what you get when you search for “Maximum” on Pixabay, not really sure what’s going on here.
This image succinctly summarizes the problem that the article is talking about. (It's an actual case of "an image is worth a thousand words".) The correct color scale would have green in the middle and red both on the "minimum" and the "maximum" side. Instead, "maximum" somehow has a generalized positive connotation, even though it is just as far away from "optimal" as "minimum".
I've written this on HN before. The most important thing to remember about the Minimum Viable Product is that, no matter what you may call it or try to think about it, it's still version 1.0. And that means when you start working on the follow on version, you will inevitably run into the second system effect.
Only because you've been referring to v1 as the MVP, everyone thinks launching the "real first version" will be a straight forward process. Only it won't be, because it's v2.0 and the second system effect blindsides everyone and the result is even worse.
Honestly, I just kind of marvel that all us monkeys can hit keys on a typewriter and something usable comes out. Seriously, humans are bad at writing working code, maintaining working code, and shipping working code. That things usually work despite this is amazing. Yes, much software (and probably more than 50% of SaaS) is actively user hostile. Yes, centralization is bad and seems to be getting worse. For all that, there are tens of thousands of usable desktop software packages that usually work. Amazing times.
Yeah, I work in software development for an app with a large user base from over 20 years. This would never work, mostly because the demands of the users not only keep changing, but we constantly have ways to improve the core functionality as new technology/platforms get developed over time. Besides, our competitors would never agree to some kind of "maximum" either, so we would lose those users to our competitors.
I think the real point/value here is having the vision/will/ability to know when to say "no", and to say it. It's exceedingly rare for companies and products and etc to be and remain clear on their purpose/point/intent, so they lack clear guidance on when "no" is the right answer. "Somebody wants to pay us a lot for this" is basically never a good reason for "yes".
If the industry followed something like the Unix philosophy, the definitions of Minimum and Maximum Viable Product would eventually converge. But the trend is still to build morbidly obese products that attempt to solve dozens of problems, instead of building one good solution at a time. There is no straightforward way to fix it, since it's what most businesses think they need.
[+] [-] crazygringo|3 years ago|reply
> The thing is, we can usefully flip this concept on its head! What if more developers developed a sense for the “maximum” number of things a product should do — and stopped there?
I'm sorry, but the author misunderstands entirely the reason for feature creep. It generally has nothing whatsoever to do with "fun" or developers "wanting to develop" or marketers "wanting to stuff to market".
Rather it has to do with segments of customers genuinely needing a given feature, and they won't buy the product unless it has the feature.
There's the old quote about how 80% of the people only use 20% of the features -- but then the punchline is that they're all using a different 20%.
That screenshot of all the Word toolbars? Guess what. There are different user segments that actually use each one of those toolbars. Yup.
So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish. If you're a business and you want to make money and you'll profitably sell to more customers if you can build in a new feature, then you do it.
Why would any company restrict itself to an arbitrary "maximum" and leave money on the table...?
[+] [-] bruce511|3 years ago|reply
The reviewer liked the product enough, but slated the fact it didn't have a word counter. Now, I for one, have never cared about the number-of-words in a document. But, it turns out, journalists tasked with writing a 2000 word review _really_ care.
With great popularity comes great variability, and more "corner cases" matter.
Incidentally the solution is not fewer features, but better UI. Notice thats a very old screenshot of Word. Whereas Word to day looks very different, has the same (or greater) feature set, and a much more streamlined interface. The much-hated-on ribbon bar is actually a better interface than endlessly-deep menus and a million toolbars.
[+] [-] LAC-Tech|3 years ago|reply
Piling more chairs on top of each other to get features out the door can be demoralizing. You know it's going to collapse under its weight eventually, and you're just speeding the company along to The Big Expensive Rewrite.
But fixing bugs? An actual chance to make things better? That is satisfying.
[+] [-] kneebonian|3 years ago|reply
I disagree, I think the Unix philosiphy solves the problem. You build simple tools that do one thing, and do that one thing well, but you make it easy for the tools to work together and then you can have pieces that do one simple thing while still serving needs.
When new needs come up that aren't addressed by current tools you simply put together another simple tool that does that.
[+] [-] fncivivue7|3 years ago|reply
> the punchline is that they're all using a different 20%.
You could try creating different products.
1. https://www.investopedia.com/terms/e/empirebuilding.asp
[+] [-] Sevii|3 years ago|reply
Each additional 20% of the features you support cuts the UI and technical effort that can be put into the other 20%s of features.
The end result is the standard big corporate apps that feel heavy weight despite doing what feels like a pretty simple thing.
It makes sense for companies to do it. Because the cost is born by the consumers.
[+] [-] coder-3|3 years ago|reply
[+] [-] rapnie|3 years ago|reply
https://news.ycombinator.com/item?id=30799083
[+] [-] usea|3 years ago|reply
If you sit down to try to write a program that no one will ever see but yourself, you will have to fight against feature creep. It comes from the creators themselves. It's basic human nature to find it easier to desire things than to restrain oneself.
[+] [-] epolanski|3 years ago|reply
Because when there's too much options and features users are going to be overwhelmed.
Also, feature creep has nothing to do with developers wanting or not wanting, those are product decisions.
I saw that in the past with an ecommerce, we had a good portal, then stakeholders in corporate that need to justify their salary started shoving more and more stuff, now what was a simple search-find-pay has become interrupted and overwhelmed with features and information.
[+] [-] bryanrasmussen|3 years ago|reply
there is another reason feature creep happens for certain categories of products, which is regulation. If a law is passed mandating industry X needs to support Y that feature will be added for any product wanting to sell to the market that has mandated the feature.
any analysis that misses these kinds of real world scenarios is not that interesting.
[+] [-] shadowfoxx|3 years ago|reply
Adding new features is fun and exciting but feature creep is bad?
What is feature creep if not new features? (Well new features + the idea that we're adding more features than we're thinking about their implementation and/or before the app does what it set out to do in the first place)
[+] [-] lukemercado|3 years ago|reply
This is all pretty early days, but my hope is that we can iterate the core "have feature toggles" concept to the point where we have the ability to turn functionality and function accessibility on across many verticals. I hope that one day internally we can configure things a per-customer and per-user-persona basis. I also hope that one day we can expose some of those switches to admins and/or everyday users, possibly with paywalls or other strictures.
We'll see where it all lands :D
[+] [-] notjoemama|3 years ago|reply
[+] [-] sriku|3 years ago|reply
[+] [-] continuational|3 years ago|reply
[+] [-] efitz|3 years ago|reply
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.
[+] [-] rudasn|3 years ago|reply
Often times customers come with feature requests but dev/biz fail to translate that into problem resolutions.
"I want it to export all my data for this time period", should be followed by an in depth discussion on why that's needed, whose going to do perform the task, how often, under which circumstances.
A bad translation more often than not translates to bad UIs, half-features, and hours upon hours wasted on dev time and customer support time.
[+] [-] ChrisMarshallNY|3 years ago|reply
The more powerful machines have become, and the larger the screens we work with (I am writing this on an LG 49" ultrawide), the easier it becomes to jam a bunch of stuff in there.
A good exercise for Keeping It Simple, Stupid (KISS), is to write firmware for fixed displays, or mobile device software (although mobile devices are starting to look more and more like full-sized computers, these days).
I learned religion from Scott Jenson's excellent The Simplicity Shift[0]. It was written before the iPhone.
Most of the tips in there, could be applied to desktop/laptop computer software. I used to use his "triage" methodology, in the days that we wrote host software, at my old job.
[0] https://jenson.org/The-Simplicity-Shift.pdf
[+] [-] ShredKazoo|3 years ago|reply
This book is over 100 pages long -- any chance you could summarize some of the most important ideas, like the "triage" methodology, so we can figure out if we want to read it?
[+] [-] pyrolistical|3 years ago|reply
In terms of teams, I don't think "developers" are here to blame. Where are the product managers? And I don't mean the project managers pretending to be product managers. Great products require the vision of a designer, organizational skill of a product manager and developers to be able to implement and/or tell everybody is asking for something feasible with current technology.
Its not easy, which is why so many products suck.
[+] [-] marcinzm|3 years ago|reply
Which generates bad PR and companies like to avoid that. I've seen quiet a few highly voted hacker news threads which get angry at:
- A feature being removed from something.
- An app adding metrics and analytics to track feature usage.
[+] [-] satvikpendem|3 years ago|reply
Then what? Follow this line of reasoning to its terminal (or shall we say, maximal) conclusion: developers would be laid off or fired (or at best shifted to another product, which might not be what makes money for the business, so back to an increased risk of being laid off or fired). Tell your boss that the product is done, no more updates needed, and see how well it goes for you.
We already know why feature creep happens, people need to work to survive. One of the few ways to prevent this occurs in open source, where people's livelihood is (generally speaking) not tied to their output. If we want feature creep to stop, we would have to live in a society where people wouldn't need to work to survive. I'm sure that will come with AI automation soon enough, if ChatGPT and Stable Diffusion and other adjacent programs are anything to go by.
[+] [-] bruce511|3 years ago|reply
Assume for the moment you had a sales driven model, like say Word did in the era of those screenshot.
Your whole business depends on more sales. Developers, support, admin - stop selling for a month and the business goes under.
More customers means more support, which means more overhead, which means sales has to increase in pace. This clearly isn't sustainable (so, no one gets support.)
Part of those sales goes to existing customers. (upgrades). Which means new features.
It's a treadmill to dream up new things just so there are things to sell as part of the upgrade.
Recognizing this route could only end in a crash we switched to a SaaS model. Now support is a priority (and we'll funded), programming, and random new features less so. Customers get better support, programmers get rewarded for fixing bugs, new features can be considered, well planned, and done properly on a decent time scale.
And if the business never sells another copy, it's OK. Support remains funded.
It's a much better model for customers, for support and programmers, and ultimately yes, better for business owners as well.
[+] [-] version_five|3 years ago|reply
I was reminded of this quote (from Shannon Vallor who I don't know via a Cory Doctorow post https://pluralistic.net/2022/10/20/benevolent-dictators/#fel...). It's not even just about having too many features anymore, it's about having actively user hostile features that want to manipulate you into doing things or steal your data.
The article mentions Word / MS Office which is the prototype for this. They long ago crossed the Rubicon into the "too many features" domain, but recently they have moved into "connected experiences" - we want to upload everything you write and will dark pattern you into some technicality of consent, plus nonsense like accessibility checker that complains about things I do in internal company presentations while (outside of connected experiences, through some other scam to steal my data) uploads all my charts to MS servers and captions them for me so that blind users will now they are "a picture of a chart"
Anyway, that turned into a rant. Tldr, 2005 was about too many features, 2022 is about ultra manipulative features that try to steal your data and impose tech designers' world view on users
[+] [-] alex-|3 years ago|reply
[+] [-] givemeethekeys|3 years ago|reply
[+] [-] jxramos|3 years ago|reply
[+] [-] twobitshifter|3 years ago|reply
[+] [-] nickdothutton|3 years ago|reply
It is a brave product manager that declares his product more or less feature-complete. Because it is a far more frightening proposition for a company to begin a new product, perhaps only their 2nd ever, rather than glom-on extras to their first-born.
It’s one thing to manage a backlog of features into a product (or to discard them), but quite another to have the clarity of vision for your product that allows you to repeatedly say “no” even in the face of clear customer demand for functionality. Functionality that really belongs in your 2nd app, not your 1st. Even if you as a product manager have that clarity, you’ve then got to get the rest of the company behind you. IMO the only thing harder is getting a company to kill a product that needs killing.
[+] [-] lemax|3 years ago|reply
There are plenty of products have iterated over decades and maintained the same simplicity, think Ableton Live. I would even give Word some credit in that it has recovered from the earlier mess the author points out by delivering a toolbar architecture through its ribbon menus and advanced settings to hit those less common use cases while maintaining a level of approachability. Sometimes all it takes is a step back and a bit of thought on design.
[+] [-] mberning|3 years ago|reply
[+] [-] chiefalchemist|3 years ago|reply
You can't keep adding to a broken paradigm and get ideal results. True, that might disrupt current users but done right they'll eventually appreciate it if you've made the tool less friction-y. An alternative is to give user the option to see what they want and ignore what they don't. Maybe allow them to change background colors so their most used features are easier to see?
Put another way, it's not how much you say, it's how you say it.
[+] [-] majewsky|3 years ago|reply
> This is what you get when you search for “Maximum” on Pixabay, not really sure what’s going on here.
This image succinctly summarizes the problem that the article is talking about. (It's an actual case of "an image is worth a thousand words".) The correct color scale would have green in the middle and red both on the "minimum" and the "maximum" side. Instead, "maximum" somehow has a generalized positive connotation, even though it is just as far away from "optimal" as "minimum".
[+] [-] russellbeattie|3 years ago|reply
Only because you've been referring to v1 as the MVP, everyone thinks launching the "real first version" will be a straight forward process. Only it won't be, because it's v2.0 and the second system effect blindsides everyone and the result is even worse.
Don't be fooled by the siren call of the MVP.
[+] [-] BirAdam|3 years ago|reply
[+] [-] Tokkemon|3 years ago|reply
[+] [-] ergonaught|3 years ago|reply
[+] [-] mkl95|3 years ago|reply
[+] [-] aidenn0|3 years ago|reply