
How we built the wrong feature - Jonovono
http://7shifts.com/how-we-built-the-wrong-feature/
======
InclinedPlane
Everyone who builds anything needs to realize this: don't let your users
dictate your features. They aren't inventors, they aren't designers, they
aren't developers, they're just users. And they can lead you astray.

Don't let users send you problem reports in the form of unimplemented feature
requests, if they do you need to retranslate them back into problem space
before ingesting them. This is a special case of "satisficing". The amount of
work that a user puts into figuring out what they "need" to solve their
problem is often trivial, and insufficient compared to the amount of work that
needs to actually go into feature development. More often than not users are
just going to tell you the first idea that comes into their head on how to
solve their problem. Sometimes that's fine, more often than not it's a
mistake. And it's a much worse mistake to dump lots of implementation work
into a feature that was designed based on a nanosecond of effort.

Take control of your own design, evaluate lots of options for solutions for
problems, take the time and effort to figure out which ones are actually good,
and then implement those. Don't become a marionette for user requests.

~~~
jboesch
Exactly. Letting users dictate how you design/implement something is more
often than not, a bad idea. When a client starts to do this, you need to draw
them back to the original problem by asking questions around it. This forces
them to elaborate on it, rather than getting caught up in their idea of a
"solution".

------
Jemaclus
Been there, done that, got a T-shirt. The "talk to two" idea is the best one
on the list. Find MULTIPLE people who want this product, get MULTIPLE use
cases, and then build a tool that is abstract enough to cover a variety of use
cases but solid enough to get the job done for them.

I can't tell you how much of my time has been wasted on toy features for
clients that never came on board.

