11 ms·

It’s Time for ‘Maximum Viable Product’

188 points by herbertl 4y ago

Yorch 4y ago
¿What about the concept of plug-ins? Developing plug-ins as optional feature and let the users to decide.
version_five 4y ago
> "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/#felony-contempt-of-business-model 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
- jxramos 4y ago
  There’s some truth to that sentiment about a bleak and grayer horizon. Now I shop in tech while looking over my shoulder waiting to get mugged by some shady dark patterns and outright user hostility. It’s not friendly solve my problems territory but a menacing gauntlet of wolves waiting to feast on the next unsuspecting prey to leak all their user data back to some awful place. It’s a bit hyperbolic but that’s the color of the feelings wandering around some new tech product. I just experienced this tonight shopping for a barcode scanner and having no clue how they operate and wondering what beastly proprietary software will have to be installed and worrying about all the security junk surrounding that. Turns out they’re not too bad, basically many can go into a keyboard mode.
givemeethekeys 4y ago
We'll hopefully see more of this as unlimited money dries up and people will have to think harder about allocating resources.
ChrisMarshallNY 4y ago
Simplicity is really difficult. 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 https://jenson.org/The-Simplicity-Shift.pdf
- ShredKazoo 4y ago
  Thanks for your comment! 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?
  - ChrisMarshallNY 4y ago
    Well, it's hardly more than a pamphlet. The book is physically, quite small, and each page is done in fairly sparse font. Took me about a day and a half to read. It's not a technical book. It's aimed at Marketing and Product Management folks. Jenson isn't a tech. He's a product designer. One of the best in the world. But the main gist of the book is about prioritizing features. Remember that it was written, when the peak of phone technology was the Motorola RAZR, with its tiny screen, and people were writing “m.” mobile sites in WML. It recommends a pretty intense selection process, with a lot of bathwater being thrown out, and care, taken, not to include the babies in that. The methodology that I developed, based on this philosophy, was what I call "Front of the Box/Back of the Box." Say we have a boxed product on a store shelf. The front of the box is facing out. You only want to list no more than three main features, in big font, on the front of the box, to catch the buyer's attention. The buyer then takes down the box, and turns it around, so you can list, maybe four features, on the back, in smaller font. The rest of the features are listed on the sides of the box, in even smaller font. When we look at our feature set this way, it requires a brutal triage. We need to do away with the thought that "Every Feature is Precious," and select the three (maximum) "Front of the Box" features, etc. This also affects the project design and implementation, as well. We need to make sure that the "Front of the Box" features are done first, even if they are not the most problematic or challenging features. They are the ones that will be important to the end-user. That way, when the inevitable "crunch time" comes, and we are tossing out features, the ones we toss out, are the "Side of the Box" features.
hu3 4y ago
Minimum Lovable Product. A PO once said that. And it stuck as something I should strive for. I also practice Minimum Lovable Code.
jxramos 4y ago
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.
- twobitshifter 4y ago
  I think this is the solution - a maximum viable product that can be extended to meet niche use cases.
reidjs 4y ago
I love the idea of considering the maximum viability of a product. we could even combine the two to create a viable product range for shipping a new product
satvikpendem 4y ago
> 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.
- bruce511 4y ago
  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.
crazygringo 4y ago
> 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...?
- coder-3 4y ago
  Yep came here to say this. The article is incorrect in the diagnostic and thus the prescription
- lukemercado 4y ago
  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. We'll see where it all lands :D
mberning 4y ago
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.
- lostmsu 4y ago
  This. I grokked this when I tried to contribute to Unigram (an alternative Telegram client) in 2021. Back in school and even university circa 2010, what I expected from chat apps is passing around text messages salted with a few UI features like parsing and displaying emoji, highlighting links and maybe sending files. These days there are hundreds of types of messages alone, plus you also have all kinds of metadata exchange, social graph stuff, group management etc. When writing this comment, I feel like the whole IM industry would win from following Unix philosophy a bit more. But it is never going to happen because companies want to lock users in.
- ChrisMarshallNY 4y ago
  That depends. If the simplicity is artful, then the copy just “doesn’t feel right.” Anyone remember the Movado watch? When it came out, there was nothing like it. A lot of competitors tried copying it, and they just looked cheap. It eventually fell out of fashion, but it commanded top dollar, the whole time, despite the copycats. I never liked it, and would not have brought one, but I have to respect the design. The same could be said for Apple’s stuff. Not all of it is something worth copying, but they are a multi-trillion dollar company, regardless of the hate heaped on them. Nowadays, it’s actually fairly easy to copy complex stuff; especially if a lot of that UI is the result of leveraging standard chrome in a framework.
ergonaught 4y ago
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".
efitz 4y ago
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.
- rudasn 4y ago
  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.
BirAdam 4y ago
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.
russellbeattie 4y ago
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. Don't be fooled by the siren call of the MVP.
aidenn0 4y ago
All I know is that if it's smaller than the minimum viable product or bigger than the maximum viable product, then it's not viable.
alex- 4y ago
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."
Tokkemon 4y ago
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.
emodendroket 4y ago
I've heard a lot of carping about products being "bloated" with "too many features" but I have never seen someone (including myself) stop using a tool because it was too powerful. Perhaps this is a personality trait; either you're a vi person or an emacs person (even if you don't actually use one of those most of the time).
- rerdavies 4y ago
  WordPerfect Syndrome. People who have been scarred by the experience of learning a nightmare product are reluctant to move on to more capable tools that are much easier to learn.
  - emodendroket 4y ago
    I think it's more that the alternatives are missing one or two things they can't live without.
- yjftsjthsd-h 4y ago
  > I've heard a lot of carping about products being "bloated" with "too many features" but I have never seen someone (including myself) stop using a tool because it was too powerful Not because it's "too powerful", no; you'd stop using it because of the fallout. A newer, sleeker alternative comes out with 20% of the features, resulting in a cleaner, faster UX that eats market share (Trello/Jira). Bugs accumulate until people give up. New users open the program, take one look at 3 stacked toolbars of unintelligible options, and go devise workflows that let them avoid opening it again. Structural problems ironically make it hard to add new features so it starts getting rejected. The features are fine, but they're not free.
  - emodendroket 4y ago
    > A newer, sleeker alternative comes out with 20% of the features Yes, and everyone tries it and sees it's missing their one rare feature that they use all the time and that's the end of that dalliance. In the words of jwz, "Mozilla is big because your needs are big."
rerdavies 4y ago
ninja'd by jxramos Another interesting model that avoids user-interface bloat is installable extensions. For example, Visual Studio and Visual Studio Code. Instead of making EVERY feature accessible via menu, right-click-menu, and ribbon or button bars all the time, make only those features that have been installed available.
pyrolistical 4y ago
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. Its not easy, which is why so many products suck.
- marcinzm 4y ago
  >It requires ruthlessly deleting features and annoying a subset of users for the greater whole. 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.
mkl95 4y ago
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.
nickdothutton 4y ago
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.
sacrosancty 4y ago
lemax 4y ago
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.
- drpixie 4y ago
  we would miss out on new customers You're right about the thinking. But that thinking is flawed. Must product X be used by everyone? No, there are (literally) millions of customers out there - pick a segment and serve it well.
- epolanski 4y ago
  That stems from the wrong idea that a software has to grow endlessly in its user base and revenue. You start offering A, then you offer everything from A to F, putting complex strains on design and overwhelming your users over and over. Then you start losing the customers that liked A but find the software too bloated.
nixpulvis 4y ago
I get what the title is going for, but I feel obligated to mention that the word 'viable' covers the complaint. If you have only the set of features you need, that's an MVP.
chiefalchemist 4y ago
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.
asah 4y ago
Lol, and investors should accept Maximum Viable Valuation.
aranaur 4y ago
"maximum viable" or "Maximally viable" is an effectively unattainable target. At what point do the developers ship?
rurtrack 4y ago
Idk I like to think MVP stands for Minimum Valuable Product
- coldcode 4y ago
  At my last (non tech, extremely large) employer we joked that every product (supporting our business, not standalone) was Maximum Viable Product, as every user story was required for launch, including endless change requests. Sometimes we even shipped something when they ran out of ideas...
__MatrixMan__ 4y ago
Isn't this more or less solved by a well thought out plugin ecosystem?
cateblanchett 4y ago
I hate bloat and feature-soup as much as the next person. But market forces will always push companies to keep adding more and more to otherwise simple products.
majewsky 4y ago
> [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".

188 points by herbertl 4y ago

¿What about the concept of plug-ins? Developing plug-ins as optional feature and let the users to decide.

> "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/#felony-contempt-of-business-model 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

jxramos 4y ago
There’s some truth to that sentiment about a bleak and grayer horizon. Now I shop in tech while looking over my shoulder waiting to get mugged by some shady dark patterns and outright user hostility. It’s not friendly solve my problems territory but a menacing gauntlet of wolves waiting to feast on the next unsuspecting prey to leak all their user data back to some awful place. It’s a bit hyperbolic but that’s the color of the feelings wandering around some new tech product. I just experienced this tonight shopping for a barcode scanner and having no clue how they operate and wondering what beastly proprietary software will have to be installed and worrying about all the security junk surrounding that. Turns out they’re not too bad, basically many can go into a keyboard mode.

givemeethekeys 4y ago

We'll hopefully see more of this as unlimited money dries up and people will have to think harder about allocating resources.

ChrisMarshallNY 4y ago

Simplicity is really difficult. 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 https://jenson.org/The-Simplicity-Shift.pdf

ShredKazoo 4y ago
Thanks for your comment! 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?
- ChrisMarshallNY 4y ago
  Well, it's hardly more than a pamphlet. The book is physically, quite small, and each page is done in fairly sparse font. Took me about a day and a half to read. It's not a technical book. It's aimed at Marketing and Product Management folks. Jenson isn't a tech. He's a product designer. One of the best in the world. But the main gist of the book is about prioritizing features. Remember that it was written, when the peak of phone technology was the Motorola RAZR, with its tiny screen, and people were writing “m.” mobile sites in WML. It recommends a pretty intense selection process, with a lot of bathwater being thrown out, and care, taken, not to include the babies in that. The methodology that I developed, based on this philosophy, was what I call "Front of the Box/Back of the Box." Say we have a boxed product on a store shelf. The front of the box is facing out. You only want to list no more than three main features, in big font, on the front of the box, to catch the buyer's attention. The buyer then takes down the box, and turns it around, so you can list, maybe four features, on the back, in smaller font. The rest of the features are listed on the sides of the box, in even smaller font. When we look at our feature set this way, it requires a brutal triage. We need to do away with the thought that "Every Feature is Precious," and select the three (maximum) "Front of the Box" features, etc. This also affects the project design and implementation, as well. We need to make sure that the "Front of the Box" features are done first, even if they are not the most problematic or challenging features. They are the ones that will be important to the end-user. That way, when the inevitable "crunch time" comes, and we are tossing out features, the ones we toss out, are the "Side of the Box" features.

hu3 4y ago

Minimum Lovable Product. A PO once said that. And it stuck as something I should strive for. I also practice Minimum Lovable Code.

jxramos 4y ago

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.

twobitshifter 4y ago
I think this is the solution - a maximum viable product that can be extended to meet niche use cases.

reidjs 4y ago

I love the idea of considering the maximum viability of a product. we could even combine the two to create a viable product range for shipping a new product

satvikpendem 4y ago

> 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.

bruce511 4y ago
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.

crazygringo 4y ago

> 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...?

coder-3 4y ago
Yep came here to say this. The article is incorrect in the diagnostic and thus the prescription
lukemercado 4y ago
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. We'll see where it all lands :D

mberning 4y ago

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.

lostmsu 4y ago
This. I grokked this when I tried to contribute to Unigram (an alternative Telegram client) in 2021. Back in school and even university circa 2010, what I expected from chat apps is passing around text messages salted with a few UI features like parsing and displaying emoji, highlighting links and maybe sending files. These days there are hundreds of types of messages alone, plus you also have all kinds of metadata exchange, social graph stuff, group management etc. When writing this comment, I feel like the whole IM industry would win from following Unix philosophy a bit more. But it is never going to happen because companies want to lock users in.
ChrisMarshallNY 4y ago
That depends. If the simplicity is artful, then the copy just “doesn’t feel right.” Anyone remember the Movado watch? When it came out, there was nothing like it. A lot of competitors tried copying it, and they just looked cheap. It eventually fell out of fashion, but it commanded top dollar, the whole time, despite the copycats. I never liked it, and would not have brought one, but I have to respect the design. The same could be said for Apple’s stuff. Not all of it is something worth copying, but they are a multi-trillion dollar company, regardless of the hate heaped on them. Nowadays, it’s actually fairly easy to copy complex stuff; especially if a lot of that UI is the result of leveraging standard chrome in a framework.

ergonaught 4y ago

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

efitz 4y ago

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.

rudasn 4y ago
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.

BirAdam 4y ago

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.

russellbeattie 4y ago

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. Don't be fooled by the siren call of the MVP.

aidenn0 4y ago

All I know is that if it's smaller than the minimum viable product or bigger than the maximum viable product, then it's not viable.

alex- 4y ago

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

Tokkemon 4y ago

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.

emodendroket 4y ago

I've heard a lot of carping about products being "bloated" with "too many features" but I have never seen someone (including myself) stop using a tool because it was too powerful. Perhaps this is a personality trait; either you're a vi person or an emacs person (even if you don't actually use one of those most of the time).

rerdavies 4y ago
WordPerfect Syndrome. People who have been scarred by the experience of learning a nightmare product are reluctant to move on to more capable tools that are much easier to learn.
- emodendroket 4y ago
  I think it's more that the alternatives are missing one or two things they can't live without.
yjftsjthsd-h 4y ago
> I've heard a lot of carping about products being "bloated" with "too many features" but I have never seen someone (including myself) stop using a tool because it was too powerful Not because it's "too powerful", no; you'd stop using it because of the fallout. A newer, sleeker alternative comes out with 20% of the features, resulting in a cleaner, faster UX that eats market share (Trello/Jira). Bugs accumulate until people give up. New users open the program, take one look at 3 stacked toolbars of unintelligible options, and go devise workflows that let them avoid opening it again. Structural problems ironically make it hard to add new features so it starts getting rejected. The features are fine, but they're not free.
- emodendroket 4y ago
  > A newer, sleeker alternative comes out with 20% of the features Yes, and everyone tries it and sees it's missing their one rare feature that they use all the time and that's the end of that dalliance. In the words of jwz, "Mozilla is big because your needs are big."

rerdavies 4y ago

ninja'd by jxramos Another interesting model that avoids user-interface bloat is installable extensions. For example, Visual Studio and Visual Studio Code. Instead of making EVERY feature accessible via menu, right-click-menu, and ribbon or button bars all the time, make only those features that have been installed available.

pyrolistical 4y ago

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. Its not easy, which is why so many products suck.

marcinzm 4y ago
>It requires ruthlessly deleting features and annoying a subset of users for the greater whole. 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.

mkl95 4y ago

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.

nickdothutton 4y ago

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.

sacrosancty 4y ago

lemax 4y ago

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.

drpixie 4y ago
we would miss out on new customers You're right about the thinking. But that thinking is flawed. Must product X be used by everyone? No, there are (literally) millions of customers out there - pick a segment and serve it well.
epolanski 4y ago
That stems from the wrong idea that a software has to grow endlessly in its user base and revenue. You start offering A, then you offer everything from A to F, putting complex strains on design and overwhelming your users over and over. Then you start losing the customers that liked A but find the software too bloated.

nixpulvis 4y ago

I get what the title is going for, but I feel obligated to mention that the word 'viable' covers the complaint. If you have only the set of features you need, that's an MVP.

chiefalchemist 4y ago

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.

asah 4y ago

Lol, and investors should accept Maximum Viable Valuation.

aranaur 4y ago

"maximum viable" or "Maximally viable" is an effectively unattainable target. At what point do the developers ship?

rurtrack 4y ago

Idk I like to think MVP stands for Minimum Valuable Product

coldcode 4y ago
At my last (non tech, extremely large) employer we joked that every product (supporting our business, not standalone) was Maximum Viable Product, as every user story was required for launch, including endless change requests. Sometimes we even shipped something when they ran out of ideas...

__MatrixMan__ 4y ago

Isn't this more or less solved by a well thought out plugin ecosystem?

cateblanchett 4y ago

I hate bloat and feature-soup as much as the next person. But market forces will always push companies to keep adding more and more to otherwise simple products.

majewsky 4y ago

> [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".