The term “Demand Incompatibility” is the unofficial motto here at Formation Data Systems. My co-founder Andy does a great job explaining what “demand incompatibility” means to our employee culture in his blog.
In this post, I will explain why I believe that everyone in business should make the concept of “demanding incompatibility” a key element of his or her overall management approach. In this first part I will explain the origin of the term Demand Incompatibility.
I was in a meeting with a potential customer (I will use the name John to protect the innocent). I had asked John to review our architecture and product plan. At the end of my presentation John’s first comment went something like “Very impressive but can you run as a software layer on top of my existing storage arrays? That would be fantastic!”
Me: “Sorry. No; that is not in our plan.”
John: “We have a huge investment in our existing storage and it is critical that we be able to leverage our existing assets into the future. Others are doing it with what they call ‘Software Defined Storage.’ I think you should reconsider. Compatibility is a ‘must have’ for us.”
I faced a classic problem. The first rule of startups (especially enterprise ones) is that you should try to fit seamlessly into the existing environment. I was (intentionally mind you) breaking Rule #1. I believed we were doing the right thing so I pressed the point.
Me: “I am sorry to hear that. Respectfully, I would suggest that you should make the requirement just the opposite. I believe you should ‘demand incompatibility.’”
John laughed out loud including a comment that I interpreted as “you have got to be joking”. He managed to follow up with the obvious question. “Why?”
I addressed their critical business needs, those that I had learned from previous meetings. As in many cases, it boiled down to speed (the need to execute more quickly), complexity (the need to have a system that is easier to operate), and overall economics. Like many companies, they saw what AWS et al. were charging for public cloud storage. He knew that their costs were literally an order of magnitude too high.
“Here is the issue,” I said. “Transformational benefits come from transforming. If we built a product that put a veneer over your existing systems, it would come at an incremental cost to you. We could make it look simple from a user perspective but it would actually be more complex and expensive for you to operate. Our transformational improvements in cost and complexity come from building a new architecture from the ground up. AWS, Microsoft Azure, Facebook and Google all effectively did the same thing. That is how they got to where they are today.”
Please note that Formation is highly compatible with modern applications and I am not saying that all compatibility is bad. What I do believe is that most great innovations must break the mold and color outside the lines. “Legacy Compatibility” is a buzz kill.
After much more conversation what was amazing is how we turned this perceived negative into a feature that the customer now deems critical. They are now convinced that any product that runs on “legacy storage” will never be able to provide a transformational result.
They now “demand incompatibility.”
Mark…
Good concept, the challenge will be that finding the person in the company that truly wants to change the status quo. Good luck!
Posted by: Omrqz | 03/30/2014 at 06:07 AM