
Ask HN: How do you avoid distractive features while building a project? - theSage
While building something I find that a lot of things get added to the project which does not actually solve the core problem but is nice to have once the core has been solved. This happens at work and other places. What is a good way to avoid this kind of noise since it takes time away from solving the actual problem?
======
malux85
Ask yourself are you doing this because it's needed, or because you know how
to do it. Many programmers would rather rationalise "we need feature X" and
then sit there and code, because they like coding, they know how to do it, and
the alternative activity (e.g. Marketing or talking to customers) is harder,
has more unknowns, and they're uncomfortable with the uneasiness of the
unknown.

This was my problem for a long time, and I was in denial about it and over-
emphasised the importance of features so I could code instead of sell.

But once I accepted it as a fault in myself, I could compensate for it, then I
actually started making money.

I see this a LOT in my friends

~~~
theSage
I think I'm guilty of this.

------
nicolasd
When checking out a new branch or planning a new feature - ask yourself, if
you would deploy it today and the customer sees it - will he notice it/benefit
from it. Of course this does not work for all features/long-term things, but
it helps to look at it from a customer perspective. First focus is: customer
gets his job done (core features & UX) Second focus is: customer is happy
using your product (these are all the other things that are nice to have +
UI).

------
twobyfour
Keep a list of things you want to add on once the core is done. Be ruthless
about putting things on that list instead of into the product. The more
exciting items you have on that list, the better motivated you'll be to put
other items on that list instead of directly into the product so that you can
finish the core product sooner and get to the fun features.

------
nestorherre
There are tons of ways, but ultimate is up to you if you wanna follow any of
them.

One is using the Pareto principle: Ask yourself if the feature you want to
work on is on the 20% side which solves the core problem, or if it belongs to
the 80% leftover.

