Live data from Hacker News

Build or don't build a software feature?

dont.build

11–20 of 45 posts

Re: Build or don't build a software feature?

#11
post #7

Great job on this decision making tool. One thing that might be missing - the business viability of the feature. All else being equal you prioritize features that add value to the company that builds them.

I'd guess that was intended to be captured with "how valuable is the feature to target users, truly?" If target users truly find the feature valuable then I guess that means the feature is adding value to the company.

Re: Build or don't build a software feature?

#15
Interesting visual tool and mental framework. Unfortunately, I think this would have "failed" in all the decision processes I have been a part of. Why? Each of the questions is valid, but bad decisions usually stem from incorrectly answering one of these questions.

> How valuable is the feature to the target users, truly?

Take this question for example. Accurately answering it is not always possible. A common mistake is to ask your users or take their word for how valuable they perceive a feature to be. That approach is better than nothing, but can often lead teams astray. This isn't because your users are stupid, it's because your users don't have the perspective that you have in terms of (a) what is possible, and (b) the knock-on effects of the feature on other aspects of the software value proposition.

Note: the above is _not_ true about bugs. If a new feature is actually a bug/issue fix raised by your users, they are usually right.

> What is the time, technical effort, and cost to build the feature?

Estimating technical effort is so difficult that it is an entire field in itself. When working on complex systems, you also have to consider the future complexity introduced when building on top of the new feature (linked to the last question).

Re: Build or don't build a software feature?

#18
Besides the first, all the measures here are relative, so I suppose it is up to the user to calibrate.

Take build cost. Suppose a project would take 2 engineers 4 weeks to build. A large team may call that a "2" but a small team would call it a "8".

Re: Build or don't build a software feature?

#19
This is a cool tool but it should differentiate between "users" and "customers" so that weighting is based on the potential for making paying users happy (or perhaps the word "user" should just be changed.) It also appears that these sliders are equally weighted but I find that these factors are NOT equally weighted based on a particular feature, the lifecycle of the product and the lifecycle of the company.
Post reply on HN