Live data from Hacker News

Build or don't build a software feature?

dont.build

31–40 of 45 posts

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

#31
post #29
post #27

Just a bit of a nitpick (or issue for non native speaker) maybe, the answers are confusing in relationship to the title. Title: Don't build (or build) that feature Answer: Yes I think the way I selected the questions (high impact, low effort) it should tell me to build, but as I read it, the tool tells me either to not build or answers an OR question with yes or no.

"Go" or "Hold on" would be better?

I think "build" / "don't build" would be best.

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

#34
post #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…

> but bad decisions usually stem from incorrectly answering one of these questions.

Then change your answers. For me, this kind of method of assigning numbers to aspects of a choice and combining them in some way is there not to be an oracle, but to direct your thoughts or discussions within a group.

For example, if you gut tells you a feature is definitely worth it, but a tool like this says it’s only borderline useful, that shouldn’t make you immediately discard the feature, but make you consider

- whether the list of aspects is complete

- whether you judged the existing ones correctly

- whether your gut was right (e.g. if your gut says its worth it, but you also think its hard to implement and only moderately useful. Clearly, something is wrong or missing there)

When making a group decision, a big advantage is that this moves you from exchanging opinions “I think we should do A; you think we should do B” to more concrete discussion “I think it’s worth a lot and easy to implement; you think its worth something but too hard to support for what it’s worth. Let’s discuss those two separately”.

Items about which there’s strong disagreement even after discussion may even trigger postponement “let’s get a better idea about how hard/useful this is first”

The only way to make an informed decision is by thresholding on some number scale, but as you say, it also is impossible to assign numbers to aspects of a solution.

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

#37

The value seems to range from 5% to 95%, is that to leave room for uncertainty?

That's because the sliders only go down to 1, not 0 (if you change the HTML and set the "min" value to 0 you can get to 0% or 100%). I guess it makes sense because none of the answers could possibly be 0 as far as I can see.

Or perhaps as an optimisation he could set the total to 0% or 100% immediately if certain answers are set to 0 - for example, if no user need the feature, it should be 0%, or if the time and cost is 0, it should be 100% (although that's absurd), etc.

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

#38
post #34
post #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…

> but bad decisions usually stem from incorrectly answering one of these questions. Then change your answers. For me, this kind of method of assigning numbers to aspects of a choice and combining them in some way is there not to be an oracle, but to direct your thoughts or discussions within a group. For example, if you gut tells you a feature is definitely worth it, but a tool like this says it’s only borderline use…

Good point. It could be interesting to make this into a multiplayer tool. Allow each member of a team to answer the questions and then focus the debate around the questions where there is the most disagreement.

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

#39

> This page requires Javascript to function. Missed an opportunity to present the “don’t build” reasoning! :-)

I have yet to meet someone in real life who disabled js on the browser

Every single person with JS disabled browses HN

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

#40
As someone often advocating for not building features, after playing with this a little bit I do think some of the constants* behind it's formula are a little off toward the pessimistic/negative outcome.

If a very complex feature is of true high value to 90% of my users, it seems uncontroversially worthwhile: the tool gives me "No, but a close call (48%)"

I'd suggest putting a little more weight on value & user importance and a little less weight on complexity/effort.

Otherwise, GREAT tool. Even just as an aid to get across the idea that some features should not be built, which is often not understood.

*for reference, weights are currently as follows:

# users: 10

effort: -15

user importance: 20

biz complexity: -15

value: 20

risk: -20

Post reply on HN