Hacker News new | ask | show | jobs
by axg11 1563 days ago
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).

2 comments

> 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.

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.
> 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

"Hey Jack, we've been asking for an edit button for years! It's not that difficult."