Hacker News new | past | comments | ask | show | jobs | submit login
Decisions, Decisions or Why Baskets of Options Dominate (medium.com)
69 points by KentBeck 8 days ago | hide | past | web | favorite | 8 comments

There is an underlying assumption that a basket of features = sum(individual features). That is true sometimes, but other times a bunch of features launched together have a compound aggregate value - they're much more valuable launched together than individually.

But for cases where that's not true this is an excellent insight.

The part I didn't understand was the P50. Why do you get a demerit if you do 100% of everything, and how is discovering and solving an objective discovered along the way encouraged? I would love if the author or someone else explained it to me. Overall a great article.

Bit of advice: I'd mention early in the article and/or the title that this will apply to product thinking. I was curious about the financial part and pleasantly discovered that it uses this learning in product development - though way far down the page, I almost didn't finish reading it.

"P50 goals address sandbagging."

Hitting 100% when the expectation is ~50% means implies a really bad estimate, or that the estimates were a lie, probably in an attempt to look good.

Which on the face of it almost seems reasonable; but it seems that this would just introduce another form of sandbagging.

"What are your goals for this quarter?"

"Make the color of the button to be green instead of red and World Peace"

> [A bunch of features] are much more valuable launched together than individually.

More than that, they are often dependent on one another - maybe not so much if you are just polishing a mature product, but much more so at startup, when you are aiming for MVP.

And a feature does not become an 'option' just by putting it on a list; you have to work on it to have a possibility of 'exercising' it. To be fair, the article sort-of acknowledges this, but does not recognize the extent to which this weakens the metapor.

In the P50 scenario, I can only guess that hitting all the goals earns a demerit is because it indicates sandbagging. Well, there is an obvious way to avoid that outcome...

Author makes a good point, but wouldn't the cost of decisions map to the options analogy as the cost of the option, which has to be paid no matter if you exercise or not?

I'm no financial wonk but in his example if the $1 stock has a $.1 option and holding the stock has an up/flat/down outcome of +$1/0/-$1 the option scenario goes from +$1/0/0 to +$.9/-$.1/-$.1. If the outcomes are evenly distributed expected value for holding is 0 and for the option goes from $.33 to $.23. It's still positive if the option is cheap enough. Back to the project planning metaphor maybe a road map has a single option cost but weekly cycles are a series of options that eat away at your expected outcome.

Sounds like the "premium paid" on a basket of options is realized in more decisions. Quote: "The shift to options on baskets is consistent with people trying to minimize the number of decisions they make."

Instead of saying that a basket of options is a minimization of decisions, I would say that it's admitting that most decisions are answered with a series of statistical odds. If you can play a game where you think that the system has missed the boat on some small chunk of statistical possibility, for instance, if you think that the market is missing the potential for wealth in genetic analysis with artificial intelligence, then you push some moderate percentage of additional wealth or leverage in that direction.

This is the actual state of the world. Most real world decisions aren't actually yes/no. It's probability analysis, which is a far more difficult yet more accurate model of decision making.

It is a very interesting topic and a good article. I did prefer Don Reinertsen's discussion of it though (I was lucky enough to see and meet him at a Yow! conference in Melbourne)

There is a video of the talk here: https://www.youtube.com/watch?v=wyZNxB172VI

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact