5 ms·

The solution to stack fallacy is simple but really counter-intuitive. All of the mentioned examples, I mean every single one, indicate a business trying to for

The solution to stack fallacy is simple but really counter-intuitive. All of the mentioned examples, I mean every single one, indicate a business trying to force its way into the higher level through business channels. For example, when a business wants into a higher level they make it a business priority to create a new product and attempt to drive the priorities of this next level product through their business objectives. That is an epic fail. It is important to instead concede that you don't know the needs of the consumers in the higher level, and if you think you do it is because you are guessing. The only way avoid the problem is to not attempt to move into the higher level, at least not intentionally and not through business priorities. This is extremely counter-intuitive because there are generally fewer expenses and greater market frequency at each higher level, which means superior revenue potential. Businesses exist to make money and to ignore moving up to the higher level means denying this potential (vast) revenue source. This doesn't mean you can't move into the higher level of the stack and be really good at it. It just means you cannot do so both intentionally and as a business objective. The solution is to double-down on where you already are with what you are already good at and focus on product quality of your existing products. Continue to improve where you are already good. Improvements and enhancements to existing products can gradually yield the next level as the improvements progressively open new potential in an evolutionary fashion. While getting to the next level this way is much slower it is also risk reduced and continues to associate your brand with quality and consume satisfaction. This will only work, though, if the goal is improving the current product and not acquiring revenue in that desired higher level. Think evolution and not revolution. It has to be a gradual, almost accidental, increase of capability based on meeting current consumer needs.

PhilWright 11y ago
I don't think this works in practice. I cannot see Oracle slowly adding extra features to its database until it becomes an actual CRM system. A CRM is not just a solution to a different business problem but also a logically different layer from a development perspective. You would have to build it as a product that sits on top of the database product. But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality. So although you can add features gradually and evolve your CRM offering you will not have a single customer until you have actually added enough features that make it actually usable. Nobody will buy your gradually evolving system until several years have passed and it works for some actual customers. In which case you have already spend alot of money and effort.
- jodrellblank 11y ago
  But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality This sounds a familiar argument - roughly what you're saying is that an eye cannot evolve, it has to be intelligently designed? :|
  - PhilWright 11y ago
    eh? I make no comparison between developing a minimum viable CRM product and claiming irreducible complexity in biological systems.
    - jodrellblank 11y ago
      I made the comparison with the kind of argument, because you made the same kind of argument. Nobody will buy your gradually evolving system until several years have passed and it works for some actual customer The parent was assuming people were already buying Oracle as a database (for example), and continuing buying Oracle as a database, and gradually getting CRM features coming with it. So people will always be buying the gradually evolving system, and it will always/increasingly usefully be working for some actual customer. But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality. "There's a minimum crew requirement" "What's the minimum crew requirement?" "Oh, er, one, I suppose". It has value as long as it has any value at all, there isn't a certain minimum level of functionality unless you assume either 'absent' or 'broken' is involved. By the time a single shipping useful feature rolls into a production release, it has value to anyone who wants that function. Or, potential value, at least. Like a proto-eye that has value as soon as it's a light/shadow sensitive cell. It wouldn't make sense to release one basic function as a CRM product - which is why the parent is talking about 'evolving' an existing product up to a higher stack layer, not trying to release a new product at a higher stack layer all at once. So although you can add features gradually and evolve your CRM offering you will not have a single customer until you have actually added enough features that make it actually usable Following the model where Oracle tries to build and launch a CRM product all at once, or Google try to build and launch a social network all at once - which is completely the opposite of the gradual improvement up to a higher level which the parent was suggesting. You're arguing "you can't gradually improve from where you are because that isn't releasing a finished product in one go", no it isn't, that's the point.
anshublog 11y ago
This is exactly what I (writer of the article) wanted to communicate. I wish I had said it as clearly. I agree with you on the problem with moving up. Not so sure about the gradual move up. Another path is to acquire and let them lead. Another is to appreciate the nuance and hire great product people. You need to find customer problems that you understand and can solve, not chase markets up the stack because they are bigger and "look easy".

PhilWright 11y ago

I don't think this works in practice. I cannot see Oracle slowly adding extra features to its database until it becomes an actual CRM system. A CRM is not just a solution to a different business problem but also a logically different layer from a development perspective. You would have to build it as a product that sits on top of the database product. But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality. So although you can add features gradually and evolve your CRM offering you will not have a single customer until you have actually added enough features that make it actually usable. Nobody will buy your gradually evolving system until several years have passed and it works for some actual customers. In which case you have already spend alot of money and effort.

jodrellblank 11y ago
But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality This sounds a familiar argument - roughly what you're saying is that an eye cannot evolve, it has to be intelligently designed? :|
- PhilWright 11y ago
  eh? I make no comparison between developing a minimum viable CRM product and claiming irreducible complexity in biological systems.
  - jodrellblank 11y ago
    I made the comparison with the kind of argument, because you made the same kind of argument. Nobody will buy your gradually evolving system until several years have passed and it works for some actual customer The parent was assuming people were already buying Oracle as a database (for example), and continuing buying Oracle as a database, and gradually getting CRM features coming with it. So people will always be buying the gradually evolving system, and it will always/increasingly usefully be working for some actual customer. But as a CRM system it has no value to the end customer unless it has a certain minimum level of functionality. "There's a minimum crew requirement" "What's the minimum crew requirement?" "Oh, er, one, I suppose". It has value as long as it has any value at all, there isn't a certain minimum level of functionality unless you assume either 'absent' or 'broken' is involved. By the time a single shipping useful feature rolls into a production release, it has value to anyone who wants that function. Or, potential value, at least. Like a proto-eye that has value as soon as it's a light/shadow sensitive cell. It wouldn't make sense to release one basic function as a CRM product - which is why the parent is talking about 'evolving' an existing product up to a higher stack layer, not trying to release a new product at a higher stack layer all at once. So although you can add features gradually and evolve your CRM offering you will not have a single customer until you have actually added enough features that make it actually usable Following the model where Oracle tries to build and launch a CRM product all at once, or Google try to build and launch a social network all at once - which is completely the opposite of the gradual improvement up to a higher level which the parent was suggesting. You're arguing "you can't gradually improve from where you are because that isn't releasing a finished product in one go", no it isn't, that's the point.

anshublog 11y ago

This is exactly what I (writer of the article) wanted to communicate. I wish I had said it as clearly. I agree with you on the problem with moving up. Not so sure about the gradual move up. Another path is to acquire and let them lead. Another is to appreciate the nuance and hire great product people. You need to find customer problems that you understand and can solve, not chase markets up the stack because they are bigger and "look easy".