
Saying 'no' to keep crap out of products - samsolomon
https://blog.orangecaffeine.com/the-art-of-saying-no-db012a22cd28#.sbmur7q01
======
onion2k
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)?

~~~
taurath
Yes it is - when you're developing a feature not for the users but for
advertisers or monetization purposes.

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

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

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

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

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

~~~
pedalpete
I'm comparing this to a similar situation I was in recently trying to advise a
group to focus on one problem, not all the possibilities.

That is the simple statement, as you said '[how does this feature address] the
problem we're trying to solve'?

Sometimes adding too many features turns the 'product into a mess', but I
would argue that is not always the case. It sounds to me like you have very
little confidence in the co-founder to make the right decisions. That may be
well justified, it may not be. Sorry I can't help any further.

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

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

~~~
127001brewer
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
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.

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

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

~~~
jamtart
Have any examples? Curious.

