4 ms·

I don't get the use of the terminology here. Opportunity cost is the cost associated by not reaping the benefits of an alternative not being picked. This is a

I don't get the use of the terminology here. Opportunity cost is the cost associated by not reaping the benefits of an alternative not being picked. This is a cost from the perspective of the party making the choice. So in this story, 'opportunity cost' is not an explanation why something didn't happen. It is a side effect of something not happening. You could say the real opportunity cost in this story is the startup teams having a bunch of unhappy users. The explanation for the missing features is simply: they did something else. So better: "Never attribute to stupidity what is adequately explained by prioritisation"

brownbat 6y ago
Uncanny. I was also going to recommend that, maybe "ruthless prioritization," to emphasize that everyone is constantly busy and that these choices are sometimes unoptimizably hard. It would also draw a bigger distinction between the "strategic" decisions he describes at bigcos (which also involve opportunity costs!) Terminology aside, I did think he made a good point.
doodpants 6y ago
Yes, but another way of looking at it is that if you prioritize A over B, it's because the opportunity cost of not doing A would be greater than the opportunity cost of not doing B. So "prioritization" is another way of saying "minimizing opportunity cost".
- sfvisser 6y ago
  Sure, but talking about the opportunity cost of the thing you did pick feels backwards to me. Also, prioritization is not only minimizing cost, you’re probably also maximizing reward. So the calculation is more complicated anyways.
  - adrianmonk 6y ago
    I didn't see where the article talks specifically about which thing has an opportunity cost. As far as I can tell, it just says opportunity cost is the relevant phenomenon and leaves it to the reader to figure out which things have a cost and how all the math works out on that.
jasode 6y ago
>So in this story, 'opportunity cost' is not an explanation why something didn't happen. It is a side effect of something not happening. >You could say the real opportunity cost in this story is the startup teams having a bunch of unhappy users. The explanation for the missing features is simply: they did something else. The "opportunity cost" _is_ an explanation and your suggestion of shifting the label "opportunity costs" to apply to something else such as "unhappy users" is just adding to the misinterpretation. Let me try to bridge the gap between what the author wrote and your critique of it... Think of "explanations" as different levels: - level 1: Why is feature X missing? Because they did something else. - level 2: Why did they do something else? Because of opportunity costs. - level 3: Why are there opportunity costs? Because no company has infinite budgets, infinite programmers, and infinite time, and therefore, they must choose what _not_ to work on. - level 4: Why does the company not have infinite <anything>? Because that's what economists, philosophers, theoretical physicists, etc have observed in the visible universe so far and that's the framework of reality we're stuck with for the _practical_ purposes of running a company on Earth. The level 1 cause & effect is "correct" and "true" but also trivial, obvious, and uninteresting. The level 2 cause & effect is what the author is trying to explain. The levels 3 and 4 start getting into metaphysical discussion which might be intellectually entertaining but hard to apply to real life.
- sfvisser 6y ago
  > The "opportunity cost" _is_ an explanation and your suggestion of shifting the label "opportunity costs" to apply to something else such as "unhappy users" is just adding to the misinterpretation. I’m applying the exact definition quoted in the original article.
- JoshuaDavid 6y ago
  I think the level 1 explanation isn't entirely trivial, actually. There are several level 1 hypotheses one might have at that point. "Why is feature X missing?" 1. They decided to do something else, and by extension, not this (e.g. because of opportunity costs) 2. They decided not to do anything (e.g. because the product is abandoned) 3. They evaluated the possibility of adding feature X, and decided it doesn't make sense now, even if the resources to implement it were available (similar to the above 2 but it means feature X is unlikely to get implemented without some external thing happening to make it make more sense) 4. They evaluated the possibility of adding feature X, and decided it doesn't make sense ever (e.g. because it directly cannibalizes their primary business model) If you would like feature X as a customer or potential customer, you may care which of those is actually the case. If you are responsible for a large chunk of their revenue, and feature X is make-or-break for you, 1 and 3 are ok scenarios for you, but in scenarios 2 and 4 you're unlikely to have much luck. If you are evaluating whether or not to start using this product, scenario 2 may be alarming enough to make you choose another product entirely, and scenario 4 tells you important things about their business model. The article is suggesting that people overestimate the probability of explanations 2, 3, and 4, and that most of the time explanation 1 is the real one, especially for obvious shortcomings in a product. By the author's evaluation, explanation 1 is "opportunity cost", explanations 3 and 4 are "strategic reason", and explanation 2 isn't really covered (though it could fall under "opportunity cost" if you stretch).
logicallee 6y ago
maybe this will help: you see a man rushing along and he notices a twenty dollar bill. He starts moving toward it but looks at his watch and rushes off. You pick the bill up, and it is indeed $20. Why didn't the man pick it up? It's free money. It's true that it's free money. However, the man might have something that he's rushing to that in that instance, he's decided is worth more than $20. Perhaps it's a very important job interview, for example. So while it is a free $20, it also costs him a job. that's why he can't afford to pick it up. You don't have the same opportunity cost. For you the $20 didn't potentially cost a job. So you pick it up. Developers are perhaps in a similar situation. Let's say there is a bug that is so horrendous, every month 5% of your userbase leaves saying "We are leaving because you don't do x." Another 5% of your userbase is on forums desperately asking for x, saying they will start paying you the moment you do it. Why don't you pick up all these customers? All you have to do is x! Perhaps the reason you're not picking up these customers is because you have another feature that increases your reach by a factor of 5. So, although you could retain 5% of your users who are leaving, and pick up 5% of users who would join, you have another 500% of your users who you are buying by investing your time in doing y instead of x. You can't "afford" to do x, because then you wouldn't be doing y. In essence, you are rushing to an interview instead of picking up the bills your customers and potential customers are waving in front of you hoping you'll take it. Is your analysis of the opportunity cost rational and correct? Maybe not. But this mentality does explain why a whole lot of software is extremely buggy and has forums full of people asking for simple bug fixes and features, all of which are ignored while the company pursues new customers. The company feels they "can't afford" to incur the opportunity cost of fixing their bugs, because they'd be losing out on the new customers they could be getting by focusing on new features instead. This is also why making a big scene in the news gets a bug fixed very fast. Now you're not just "paying" with your dollars, which the company would ordinarily snub. you're paying with the dollars of all the new customers who are reading about their response in the press; and the company cares a lot more about those new customers than it does about you. so it fixes your bug, because now it can't afford not to.
TheOtherHobbes 6y ago
It's a little more complicated, but not much. The real problem is failing to estimate opportunity costs correctly. If you need to get Product X out the door and you spend two years rewriting it, you have to failed at basic cost/benefit analysis. That's simple. More complicated: the user POV can look very different to the PM POV. Which is always a bad thing. I use a number of DAWs, and on some DAWs the PMs keep adding releasing new versions with new features that are interesting, but non-essential. Meanwhile version x.0 is always broken in important ways, and may be so broken it's literally unusable. And some bugs are just never fixed. From one POV they need to ship n+1.0 to keep the annual upgrade cycle humming and the income stream ticking over. From another, these companies accumulate a lot of frustration and ill-will, and when a realistic alternative appears not a few users jump ship. So they lose that income anyway. What's the ideal solution? Other DAW companies ship updates less often. They rely on positive PR, better marketing, and general customer good-will. They seem to be doing okay. I have no idea how the financials work out, or if they're even comparable between two products that are nominally identical but are used by different demographics. Even so - the critical point is that someone in the management food chain should at least be attempting to assess these strategic trade-offs. To an outsider it often looks as if this isn't happening. Instead, the org made a decision a long time ago, the decision has never been updated or challenged, and now the org is just following it robotically whether or not it still makes commercial sense.
mcnamaratw 6y ago
The terminology is fine. "Why haven't you already done X?" "We were doing Y, we thought it was more important." There is more than one way to refer to this familiar situation. I could say "opportunity cost," I could say "priority," I could say "limited resources." I could pick one of those and say the others are all wrong, but what do I gain by doing that?
breischl 6y ago
It is a little bit obscure, and saying "prioritization" would probably be clearer. But it does actually work. When there are high-value things to do, then that is the opportunity cost of doing low-value things instead. ie, by doing the low-value thing you incur opportunity cost equal to high-value thing. If we implement Feature Y, we can make $$$. If we fix Bug X, we can make $. So the opportunity cost of Bug X is $$$, the benefit of Bug X is only $, so we're not going to fix it right now.

brownbat 6y ago

Uncanny. I was also going to recommend that, maybe "ruthless prioritization," to emphasize that everyone is constantly busy and that these choices are sometimes unoptimizably hard. It would also draw a bigger distinction between the "strategic" decisions he describes at bigcos (which also involve opportunity costs!) Terminology aside, I did think he made a good point.

doodpants 6y ago

Yes, but another way of looking at it is that if you prioritize A over B, it's because the opportunity cost of not doing A would be greater than the opportunity cost of not doing B. So "prioritization" is another way of saying "minimizing opportunity cost".

sfvisser 6y ago
Sure, but talking about the opportunity cost of the thing you did pick feels backwards to me. Also, prioritization is not only minimizing cost, you’re probably also maximizing reward. So the calculation is more complicated anyways.
- adrianmonk 6y ago
  I didn't see where the article talks specifically about which thing has an opportunity cost. As far as I can tell, it just says opportunity cost is the relevant phenomenon and leaves it to the reader to figure out which things have a cost and how all the math works out on that.

jasode 6y ago

>So in this story, 'opportunity cost' is not an explanation why something didn't happen. It is a side effect of something not happening. >You could say the real opportunity cost in this story is the startup teams having a bunch of unhappy users. The explanation for the missing features is simply: they did something else. The "opportunity cost" _is_ an explanation and your suggestion of shifting the label "opportunity costs" to apply to something else such as "unhappy users" is just adding to the misinterpretation. Let me try to bridge the gap between what the author wrote and your critique of it... Think of "explanations" as different levels: - level 1: Why is feature X missing? Because they did something else. - level 2: Why did they do something else? Because of opportunity costs. - level 3: Why are there opportunity costs? Because no company has infinite budgets, infinite programmers, and infinite time, and therefore, they must choose what _not_ to work on. - level 4: Why does the company not have infinite <anything>? Because that's what economists, philosophers, theoretical physicists, etc have observed in the visible universe so far and that's the framework of reality we're stuck with for the _practical_ purposes of running a company on Earth. The level 1 cause & effect is "correct" and "true" but also trivial, obvious, and uninteresting. The level 2 cause & effect is what the author is trying to explain. The levels 3 and 4 start getting into metaphysical discussion which might be intellectually entertaining but hard to apply to real life.

sfvisser 6y ago
> The "opportunity cost" _is_ an explanation and your suggestion of shifting the label "opportunity costs" to apply to something else such as "unhappy users" is just adding to the misinterpretation. I’m applying the exact definition quoted in the original article.
JoshuaDavid 6y ago
I think the level 1 explanation isn't entirely trivial, actually. There are several level 1 hypotheses one might have at that point. "Why is feature X missing?" 1. They decided to do something else, and by extension, not this (e.g. because of opportunity costs) 2. They decided not to do anything (e.g. because the product is abandoned) 3. They evaluated the possibility of adding feature X, and decided it doesn't make sense now, even if the resources to implement it were available (similar to the above 2 but it means feature X is unlikely to get implemented without some external thing happening to make it make more sense) 4. They evaluated the possibility of adding feature X, and decided it doesn't make sense ever (e.g. because it directly cannibalizes their primary business model) If you would like feature X as a customer or potential customer, you may care which of those is actually the case. If you are responsible for a large chunk of their revenue, and feature X is make-or-break for you, 1 and 3 are ok scenarios for you, but in scenarios 2 and 4 you're unlikely to have much luck. If you are evaluating whether or not to start using this product, scenario 2 may be alarming enough to make you choose another product entirely, and scenario 4 tells you important things about their business model. The article is suggesting that people overestimate the probability of explanations 2, 3, and 4, and that most of the time explanation 1 is the real one, especially for obvious shortcomings in a product. By the author's evaluation, explanation 1 is "opportunity cost", explanations 3 and 4 are "strategic reason", and explanation 2 isn't really covered (though it could fall under "opportunity cost" if you stretch).

logicallee 6y ago

maybe this will help: you see a man rushing along and he notices a twenty dollar bill. He starts moving toward it but looks at his watch and rushes off. You pick the bill up, and it is indeed $20. Why didn't the man pick it up? It's free money. It's true that it's free money. However, the man might have something that he's rushing to that in that instance, he's decided is worth more than $20. Perhaps it's a very important job interview, for example. So while it is a free $20, it also costs him a job. that's why he can't afford to pick it up. You don't have the same opportunity cost. For you the $20 didn't potentially cost a job. So you pick it up. Developers are perhaps in a similar situation. Let's say there is a bug that is so horrendous, every month 5% of your userbase leaves saying "We are leaving because you don't do x." Another 5% of your userbase is on forums desperately asking for x, saying they will start paying you the moment you do it. Why don't you pick up all these customers? All you have to do is x! Perhaps the reason you're not picking up these customers is because you have another feature that increases your reach by a factor of 5. So, although you could retain 5% of your users who are leaving, and pick up 5% of users who would join, you have another 500% of your users who you are buying by investing your time in doing y instead of x. You can't "afford" to do x, because then you wouldn't be doing y. In essence, you are rushing to an interview instead of picking up the bills your customers and potential customers are waving in front of you hoping you'll take it. Is your analysis of the opportunity cost rational and correct? Maybe not. But this mentality does explain why a whole lot of software is extremely buggy and has forums full of people asking for simple bug fixes and features, all of which are ignored while the company pursues new customers. The company feels they "can't afford" to incur the opportunity cost of fixing their bugs, because they'd be losing out on the new customers they could be getting by focusing on new features instead. This is also why making a big scene in the news gets a bug fixed very fast. Now you're not just "paying" with your dollars, which the company would ordinarily snub. you're paying with the dollars of all the new customers who are reading about their response in the press; and the company cares a lot more about those new customers than it does about you. so it fixes your bug, because now it can't afford not to.

TheOtherHobbes 6y ago

It's a little more complicated, but not much. The real problem is failing to estimate opportunity costs correctly. If you need to get Product X out the door and you spend two years rewriting it, you have to failed at basic cost/benefit analysis. That's simple. More complicated: the user POV can look very different to the PM POV. Which is always a bad thing. I use a number of DAWs, and on some DAWs the PMs keep adding releasing new versions with new features that are interesting, but non-essential. Meanwhile version x.0 is always broken in important ways, and may be so broken it's literally unusable. And some bugs are just never fixed. From one POV they need to ship n+1.0 to keep the annual upgrade cycle humming and the income stream ticking over. From another, these companies accumulate a lot of frustration and ill-will, and when a realistic alternative appears not a few users jump ship. So they lose that income anyway. What's the ideal solution? Other DAW companies ship updates less often. They rely on positive PR, better marketing, and general customer good-will. They seem to be doing okay. I have no idea how the financials work out, or if they're even comparable between two products that are nominally identical but are used by different demographics. Even so - the critical point is that someone in the management food chain should at least be attempting to assess these strategic trade-offs. To an outsider it often looks as if this isn't happening. Instead, the org made a decision a long time ago, the decision has never been updated or challenged, and now the org is just following it robotically whether or not it still makes commercial sense.

mcnamaratw 6y ago

The terminology is fine. "Why haven't you already done X?" "We were doing Y, we thought it was more important." There is more than one way to refer to this familiar situation. I could say "opportunity cost," I could say "priority," I could say "limited resources." I could pick one of those and say the others are all wrong, but what do I gain by doing that?

breischl 6y ago

It is a little bit obscure, and saying "prioritization" would probably be clearer. But it does actually work. When there are high-value things to do, then that is the opportunity cost of doing low-value things instead. ie, by doing the low-value thing you incur opportunity cost equal to high-value thing. If we implement Feature Y, we can make $$$. If we fix Bug X, we can make $. So the opportunity cost of Bug X is $$$, the benefit of Bug X is only $, so we're not going to fix it right now.