Saying 'no' to keep crap out of products | Hacker News Reader

Saying 'no' to keep crap out of products

blog.orangecaffeine.com

102 pointssamsolomon31 comments

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

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

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

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.

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?

Great point. Every "feature" is a bet, based on the vision and values in the post. It can have 3 outcomes: worked perfectly as expected, worked in ways that we didn't expect, or just failed. So you lean from it and decide whether to keep it, tweak it, and remove it.

There was a child post of this which was deleted, but I thought was very on the mark. (It was likely deleted because it said things about a certain BigCO internals that potentially weren't public)

That being said, I'd like to independently re-echo the thrust of that post because I did feel the contribution was key:

There are often internal channels in large companies that the boots on the ground use to communicate with each other in a more informal fashion. I've noticed across multiple companies that this is a FANTASTIC leading indicator for the success of a feature. For however much flak engineers get for not being "people persons" or however you put it, or needing "Designers" to guide their customer facing work, I've seen significant correlation between popular sentiment and feature success. Perhaps at the end of the day, enough of our outlook as "consumers" remains to properly instruct us despite whatever programmer bent we may have; or more pessimistically, our own sentiment on what we're making subconsciously impacts our output in a meaningful way.

So to end this ramble briefly; I think we CAN tell, the powers that be just need to look in the right places, and listen well if they do.

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.

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.

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.

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?

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

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.

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?

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.

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.

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

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.

> I'd really appreciate an article that explained how to say "no" to stakeholders diplomatically.

"How about this instead" is always better than "no", but that depends on being able to discover their true pain-point rather than what they think could make them happy.

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.

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

Even still you have to be intelligent about the interfaces because you'll have to support them for approximately the rest of time immemorial.

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.

True, but you can still use something like features depreciation in java.

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

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.

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

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.

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.

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

Have any examples? Curious.

Reply on news.ycombinator.com