Hacker News new | past | comments | ask | show | jobs | submit login

I have seen that before. You kill yourself refactoring a feature only to find out it's never or barely used. Deleted code and features are the best.



You hamstring the product to make a feature work one way then find out that what they really wanted would have been easier to implement but they never asked because they thought that would be harder.


Almost all feature requests are asking to implement a particular solution rather than asking to come up with a solution to solve a particular problem.

The way I try to solve this is to ask "why?" as many times as it takes to get to a fundamental business problem. Then it becomes easier to have a user story (as opposed to a specific feature request) and come up with other solutions that can be measured against the story. It also helps to keep the product focused, as it's easier to tell when a story is not for your target market vs a feature request -- and then you can make a conscious decision to either stay away or deliberately expand to that market.


That is why social skills and good analysts are important.


I've been fighting this problem for my whole software development career (more than 35 years now and no end in sight).


When this happens a couple times you start sounding like Honey from the Incredibles.

It’s difficult not to sound combative when they say they want a convertible but you have to wheedle out of them that they want to take a proverbial road trip through monsoon season. No, you get a Land Rover with a snorkel or you wait, pal.

So bossy and difficult. Why won’t you just give us what we asked for? These meetings would go so much faster.


I once worked on a feature that apparently lots of clients were asking for. It took 4 weeks to implement. Went to production. Never heard anything of it. 2 years later if we could modify the feature to work for another usecase. I looked at the database. The feature had never... ever... been used.... rows returned = 0


That's why its important not to believe what customers and product managers say what features they want. I have had a ton of occasions where it turned out that what they really wanted was totally different from what the devs were told.


Yeah, I always ask our user stories to have a 'background' section explaining the problem and reason for the feature request so it can help us understand the importance and purpose of the feature.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: