11 ms·

Saying 'no' to keep crap out of products

102 points by samsolomon 11y ago

DomreiRoam 11y ago
I really think it is important to say 'No' and agree with the author but I think you can do this if the product you propose can be extended. I think the framework/product should propose some configurability or some extension points. Then your product can stay pure and people can still adapt it to fit their need. If you propose an API then it can be integrate with other product/tools/developmnent. If it embark scripting ability then the user can modify it's behaviour...
- mason55 11y ago
  Even still you have to be intelligent about the interfaces because you'll have to support them for approximately the rest of time immemorial.
  - cakes 11y ago
    The difference when developing some interfaces like that can be whether you "consume" them yourself or not. Building something without a known user base/use case (where the idea was just 'that sounds cool') and supporting it forever can lead to _different_ design decisions compared to those where you go "Hhmmm...well if we build it this way it is really good/bad and we can use it easier." Whatever you end up with, though, is definitely a "support forever" situation.
  - DomreiRoam 11y ago
    True, but you can still use something like features depreciation in java.
- 127001brewer 11y ago
  My impression was don't over-extend a product, such as Evernote or LinkedIn have done, and try to keep your product focused - similar to the Unix philosophy of "Do One Thing and Do It Well".
  - dividuum 11y ago
    I'm pretty sure you implied that, but just to be sure, I'd like to point one thing out: Doing one thing well won't help your product if there is no way to use other "things" that do their thing well. It seems like products often suffer from feature creep when there is no common way of interfacing with external products. I haven't used Evernote, but maybe the lack of proper ways to interface with external software on each platform was the main reason for them becoming bloated. Android with the intends system seems like one way of doing that but I feel it might not be powerful enough for most problems. Also you have no good way of guaranteeing the user experience if your surroundings might change in unpredictable ways. So it's not that easy.
  - DomreiRoam 11y ago
    Agree 100% . I think also by keeping the perimetre of the product under control; it is easier to understand for the user and the developer, it satisfy the principle of less surprise; it keep the vision and the focus in the long term and in then end make clearer what the product does and what cvalue it brings. I would say my reflection to achieve this would be to define - what is the product perimetre - what architecture/design principle will bring you capabilities and useful abstraction - what are the best interface/extension points for allowing user to extend the usage easily Then hard work, iteration and pivot
  - i386 11y ago
    Not always possible. Even in the unix world you need to use multiple single purpose tools to get something useful done and therein friction lies.
dan353hehe 11y ago
This reminds me a bit about what was mentioned in the book "good to great". A company, or in this case a product, can do everything at a level a little above garbage, or it can focus on its core competencies and be the best at something. The more features you add to a product, (in my mind) the worse it becomes.
- jib 11y ago
  I think it depends on the product. There are times that I want a Swiss knife. The office suite is a good Swiss knife for me, I want it to do a bunch of stuff ok, I don't want it to be the best layout tool, or presentation builder, or editor, I just want to be able to do something ok looking fast for a number of varied cases. There are times when I want the really great at one thing too and I don't want my Trello board to be a social network or so. I think it is more about identity of the product.
onion2k 11y ago
Is it actually possible to know ahead of launching a feature that it'll be crap, or is it that most features get launched and the ones that are receievd well by the users are deemed "good" while the ones that aren't are considered "crap"? We've all written things that we thought would be awesome that turned out to be disregarded by users, and deployed things we thought were pointless nonsense that turned out to be fantastically engaging features that users rave about. Can you really tell before you actually get proper feedback (eg the user seeing and using the feature, not just asking if they might like it because users say yes to everything)?
- dividuum 11y ago
  > Can you really tell before you actually get proper feedback [...] Probably not. But even if you built a feature that's not well received it's important to remove it again. I've seen plenty of projects that carry tons of mostly unused features (or better called technical dept at that point) with them.
- taurath 11y ago
  Yes it is - when you're developing a feature not for the users but for advertisers or monetization purposes.
  - TeMPOraL 11y ago
    I agree. That's a big subset of "crap" features you can know are bad beforehand. After all, you know exactly, if a given feature is designed to help the user, or to hurt the user, or even strong-arm them for money.
- jib 11y ago
  Sometimes you can know the likelihood. It's not a nihilistic hole that you throw things at and see what sticks. Stuff that people go out of their way to do, even though it isn't supported is a good clue. Stuff that someone keeps ranting about in your meetings is another. Stuff that bugs the hell out of you personally is a third. Iteration is more important than inspiration, but you certainly don't go into it blind?
- 11y ago
wefarrell 11y ago
I'd really appreciate an article that explained how to say "no" to stakeholders diplomatically. Most engineers and product people understand the danger of feature bloat but are at frequently at the mercy of people who don't. I lead a small engineering team at a product company working for non technical cofounders and this is the hardest thing about my job. Two policies I've implemented have helped me a great deal: 1) We must thoroughly discuss the problem before proposing solutions 2) New features must be discussed and fully fleshed out at least three weeks before they can be built.
- pedalpete 11y ago
  Maybe you're not saying 'no', you're saying 'not now'. Is it possible to go to the co-founder and suggest that only features which customers will use/buy get built? If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done. This works for engineering too. No 'refactoring' if it doesn't have a measurable benefit to the company. By taking this approach, the hope is that 1) the co-founder takes the time to consider what is most important, 2) can articulate that to you 3) the dev team understands why they are building the feature. For each feature in dev, have the co-founder write out the reason it is being built. Here's an example on the current product I'm working on. 1) We're redoing the search page because x% of users leave the site from that page without taking futher action. We aim to lower that number to x% 2) We're refactoring component x because it loads on every page and is far too slow. We'll improve response time by 600ms. This will extend page view time by x seconds and increase views by x% 3) We're going to stream our large files where we currently download the entire thing which causes customers to wait for x seconds. We'll see an x% improvement in page load, resulting in x more page visits. You get the gist. At first, I'd suggest the co-founder 'might' just make stuff up. But if you have something in writing that you can point back to, and then go back to him if it doesn't match up, he'll hopefully start giving it more thought. On the flip side, it is also possible that the co-founder has good reasons to request these features but maybe hasn't communicated them well to you and the rest of the dev team.
  - wefarrell 11y ago
    > If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done This isn't the problem. There are justifications for new features but adding too many turns the product into a mess. I'd like them to focus more on the problem we're trying to solve and think about the product holistically.
Animats 11y ago
Picture is unrelated. A classic "no" - Bob Lutz at GM killing a voice-input system for GM cars which let the driver operate most of the auxiliary systems by voice. It worked, but was just too clunky and embarrassing to use.
jkaljundi 11y ago
The hard thing as a PM is where to draw the line of something being needed or not. In idealistic world we all want to build just features that are used by most of the users. But is that most 90%? 51%? What if a core feature is needed by just 10 or 25%? The same goes for the kill line. Do you remove something if it's used by less than 50% of users? Or is it 10% or 1%? Values and priorities are nice, but even with those well listed the questions above stay. Intercom might talk about saying no, but it has grown from a simple single-feature product to an OS where mos people use just a small part of it. Preach or practice?
joelthelion 11y ago
I've also seen zealous appliers of this principle turn their product into crap by saying no to everything.
- jamtart 11y ago
  Have any examples? Curious.
WalterBright 11y ago
I've had a long career building products, and noticed a trend. When I build things that other people say that people want, they have been failures. When I build things that I want to use myself, other people tell me (almost without exception) that it will be a failure, yet they turn out to be successful.
- pedalpete 11y ago
  Part of me wants to argue that this is anecdotal, though I've seen something somewhat similar in my experience. I will say this, building something you want yourself gives you a particular insight into the need that is very difficult to get when finding out what other people want. Building personas of users is designed to help this, but you really have to be able to embody the persona. Plus, isn't it just more fun building stuff you yourself want?
  - WalterBright 11y ago
    > isn't it just more fun building stuff you yourself want? Of course! But the interesting point here is when I propose building things that I want, my colleagues insist that nobody else will ever want it, that I'm a unique snowflake in what I want. And yet when I do, they do. It happens over and over. I can't explain it.
- sanderjd 11y ago
  Sure, but the problem is that this is how we end up with so many solutions for the kinds of problems experienced by relatively wealthy programmers and entrepreneurs in relatively wealthy areas of developed countries, and so few solutions for the kinds of problems experienced by everyone else.
gonyea 11y ago
Counter point: WeChat. They keep piling new things into it just to screw around, and find gold in hilarious places. Just build for yourselves. People are mostly like you.

102 points by samsolomon 11y ago

I really think it is important to say 'No' and agree with the author but I think you can do this if the product you propose can be extended. I think the framework/product should propose some configurability or some extension points. Then your product can stay pure and people can still adapt it to fit their need. If you propose an API then it can be integrate with other product/tools/developmnent. If it embark scripting ability then the user can modify it's behaviour...

mason55 11y ago
Even still you have to be intelligent about the interfaces because you'll have to support them for approximately the rest of time immemorial.
- cakes 11y ago
  The difference when developing some interfaces like that can be whether you "consume" them yourself or not. Building something without a known user base/use case (where the idea was just 'that sounds cool') and supporting it forever can lead to _different_ design decisions compared to those where you go "Hhmmm...well if we build it this way it is really good/bad and we can use it easier." Whatever you end up with, though, is definitely a "support forever" situation.
- DomreiRoam 11y ago
  True, but you can still use something like features depreciation in java.
127001brewer 11y ago
My impression was don't over-extend a product, such as Evernote or LinkedIn have done, and try to keep your product focused - similar to the Unix philosophy of "Do One Thing and Do It Well".
- dividuum 11y ago
  I'm pretty sure you implied that, but just to be sure, I'd like to point one thing out: Doing one thing well won't help your product if there is no way to use other "things" that do their thing well. It seems like products often suffer from feature creep when there is no common way of interfacing with external products. I haven't used Evernote, but maybe the lack of proper ways to interface with external software on each platform was the main reason for them becoming bloated. Android with the intends system seems like one way of doing that but I feel it might not be powerful enough for most problems. Also you have no good way of guaranteeing the user experience if your surroundings might change in unpredictable ways. So it's not that easy.
- DomreiRoam 11y ago
  Agree 100% . I think also by keeping the perimetre of the product under control; it is easier to understand for the user and the developer, it satisfy the principle of less surprise; it keep the vision and the focus in the long term and in then end make clearer what the product does and what cvalue it brings. I would say my reflection to achieve this would be to define - what is the product perimetre - what architecture/design principle will bring you capabilities and useful abstraction - what are the best interface/extension points for allowing user to extend the usage easily Then hard work, iteration and pivot
- i386 11y ago
  Not always possible. Even in the unix world you need to use multiple single purpose tools to get something useful done and therein friction lies.

dan353hehe 11y ago

This reminds me a bit about what was mentioned in the book "good to great". A company, or in this case a product, can do everything at a level a little above garbage, or it can focus on its core competencies and be the best at something. The more features you add to a product, (in my mind) the worse it becomes.

jib 11y ago
I think it depends on the product. There are times that I want a Swiss knife. The office suite is a good Swiss knife for me, I want it to do a bunch of stuff ok, I don't want it to be the best layout tool, or presentation builder, or editor, I just want to be able to do something ok looking fast for a number of varied cases. There are times when I want the really great at one thing too and I don't want my Trello board to be a social network or so. I think it is more about identity of the product.

onion2k 11y ago

Is it actually possible to know ahead of launching a feature that it'll be crap, or is it that most features get launched and the ones that are receievd well by the users are deemed "good" while the ones that aren't are considered "crap"? We've all written things that we thought would be awesome that turned out to be disregarded by users, and deployed things we thought were pointless nonsense that turned out to be fantastically engaging features that users rave about. Can you really tell before you actually get proper feedback (eg the user seeing and using the feature, not just asking if they might like it because users say yes to everything)?

dividuum 11y ago
> Can you really tell before you actually get proper feedback [...] Probably not. But even if you built a feature that's not well received it's important to remove it again. I've seen plenty of projects that carry tons of mostly unused features (or better called technical dept at that point) with them.
taurath 11y ago
Yes it is - when you're developing a feature not for the users but for advertisers or monetization purposes.
- TeMPOraL 11y ago
  I agree. That's a big subset of "crap" features you can know are bad beforehand. After all, you know exactly, if a given feature is designed to help the user, or to hurt the user, or even strong-arm them for money.
jib 11y ago
Sometimes you can know the likelihood. It's not a nihilistic hole that you throw things at and see what sticks. Stuff that people go out of their way to do, even though it isn't supported is a good clue. Stuff that someone keeps ranting about in your meetings is another. Stuff that bugs the hell out of you personally is a third. Iteration is more important than inspiration, but you certainly don't go into it blind?
11y ago

wefarrell 11y ago

I'd really appreciate an article that explained how to say "no" to stakeholders diplomatically. Most engineers and product people understand the danger of feature bloat but are at frequently at the mercy of people who don't. I lead a small engineering team at a product company working for non technical cofounders and this is the hardest thing about my job. Two policies I've implemented have helped me a great deal: 1) We must thoroughly discuss the problem before proposing solutions 2) New features must be discussed and fully fleshed out at least three weeks before they can be built.

pedalpete 11y ago
Maybe you're not saying 'no', you're saying 'not now'. Is it possible to go to the co-founder and suggest that only features which customers will use/buy get built? If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done. This works for engineering too. No 'refactoring' if it doesn't have a measurable benefit to the company. By taking this approach, the hope is that 1) the co-founder takes the time to consider what is most important, 2) can articulate that to you 3) the dev team understands why they are building the feature. For each feature in dev, have the co-founder write out the reason it is being built. Here's an example on the current product I'm working on. 1) We're redoing the search page because x% of users leave the site from that page without taking futher action. We aim to lower that number to x% 2) We're refactoring component x because it loads on every page and is far too slow. We'll improve response time by 600ms. This will extend page view time by x seconds and increase views by x% 3) We're going to stream our large files where we currently download the entire thing which causes customers to wait for x seconds. We'll see an x% improvement in page load, resulting in x more page visits. You get the gist. At first, I'd suggest the co-founder 'might' just make stuff up. But if you have something in writing that you can point back to, and then go back to him if it doesn't match up, he'll hopefully start giving it more thought. On the flip side, it is also possible that the co-founder has good reasons to request these features but maybe hasn't communicated them well to you and the rest of the dev team.
- wefarrell 11y ago
  > If it doesn't add to sales, or have some actionable metric as to why it is being added to the product, it doesn't get done This isn't the problem. There are justifications for new features but adding too many turns the product into a mess. I'd like them to focus more on the problem we're trying to solve and think about the product holistically.

Animats 11y ago

Picture is unrelated. A classic "no" - Bob Lutz at GM killing a voice-input system for GM cars which let the driver operate most of the auxiliary systems by voice. It worked, but was just too clunky and embarrassing to use.

jkaljundi 11y ago

The hard thing as a PM is where to draw the line of something being needed or not. In idealistic world we all want to build just features that are used by most of the users. But is that most 90%? 51%? What if a core feature is needed by just 10 or 25%? The same goes for the kill line. Do you remove something if it's used by less than 50% of users? Or is it 10% or 1%? Values and priorities are nice, but even with those well listed the questions above stay. Intercom might talk about saying no, but it has grown from a simple single-feature product to an OS where mos people use just a small part of it. Preach or practice?

joelthelion 11y ago

I've also seen zealous appliers of this principle turn their product into crap by saying no to everything.

jamtart 11y ago
Have any examples? Curious.

WalterBright 11y ago

I've had a long career building products, and noticed a trend. When I build things that other people say that people want, they have been failures. When I build things that I want to use myself, other people tell me (almost without exception) that it will be a failure, yet they turn out to be successful.

pedalpete 11y ago
Part of me wants to argue that this is anecdotal, though I've seen something somewhat similar in my experience. I will say this, building something you want yourself gives you a particular insight into the need that is very difficult to get when finding out what other people want. Building personas of users is designed to help this, but you really have to be able to embody the persona. Plus, isn't it just more fun building stuff you yourself want?
- WalterBright 11y ago
  > isn't it just more fun building stuff you yourself want? Of course! But the interesting point here is when I propose building things that I want, my colleagues insist that nobody else will ever want it, that I'm a unique snowflake in what I want. And yet when I do, they do. It happens over and over. I can't explain it.
sanderjd 11y ago
Sure, but the problem is that this is how we end up with so many solutions for the kinds of problems experienced by relatively wealthy programmers and entrepreneurs in relatively wealthy areas of developed countries, and so few solutions for the kinds of problems experienced by everyone else.

gonyea 11y ago

Counter point: WeChat. They keep piling new things into it just to screw around, and find gold in hilarious places. Just build for yourselves. People are mostly like you.