Hacker News Reader

Comment by onion2k | Hacker News Reader

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

View on HN

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.

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

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?

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.

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.

Reply on news.ycombinator.com