This is a beautiful thing for your competition to be doing in the market. This mostly applies to start ups who are exploiting a gap in platform player’s offering where the gap is most likely going to be closed but not anytime (2-3 years) soon. And in fact it may technically infeasible (de-feasible?) to do so with their current organization, architecture and IP.
During a sales training on competitive positioning in a complex selling situation for a emerging start up in the enterprise software space two issues stood out; one is sales is not that complex if you are talking to the right person(s), second if your product is a superior solution how do you demonstrate this fact to the potential customer?
After an hour or so of the usual our product does X better than theirs, and customers pick us because of X,Y, and Z it occurred to me. A number of platform players continue down the path of Incompetent Technical Persistence because they have to. What does Incompetent Technical Persistence mean?
For example you have an application that runs really well with and adds dramatic value to a platform vendor’s application. The platform vendor is trying to engineer your application into a commoditized feature, but realistically and known only to you, they are going about it the wrong way. But the platform player persists. The build, release updates, iterate, add a feature, iterate, break it with an update, lose a few marquis accounts to you, complain to you that you need to “work more closely together,” ask for your input on features and functions, iterate, lose, release and complain. This is Incompetent Technical Persistence.
After this “ism” hit me I looked at a number of client’s applications where they are afraid the platform vendor will run them over, but they need not worry. In fact I would encourage them to follow the advice of Napoleon Bonaparte (paraphrasing here);
“Never interrupt your enemy when he is making a mistake.”
Incompetent Technical Persistence creates opportunity, it is near impossible to engineer your way out of as each misstep causes more and more issues farther down the dev road that they do not know yet. In fact one effective preso I saw actually graphed the platform player’s iterations and subsequent reiterations in their drive for mediocrity. This is powerful stuff to show that Incompetent Technical Persistence is a huge risk factor to IT infrastructure. As the customer hopes and trust the platform player to “get there,” and yes these people still exist, a visual reminder of the abject failure of delivering a key functional component will put the entire platform success at risk speaks to a tangible solution.
During a sales training on competitive positioning in a complex selling situation for a emerging start up in the enterprise software space two issues stood out; one is sales is not that complex if you are talking to the right person(s), second if your product is a superior solution how do you demonstrate this fact to the potential customer?
After an hour or so of the usual our product does X better than theirs, and customers pick us because of X,Y, and Z it occurred to me. A number of platform players continue down the path of Incompetent Technical Persistence because they have to. What does Incompetent Technical Persistence mean?
For example you have an application that runs really well with and adds dramatic value to a platform vendor’s application. The platform vendor is trying to engineer your application into a commoditized feature, but realistically and known only to you, they are going about it the wrong way. But the platform player persists. The build, release updates, iterate, add a feature, iterate, break it with an update, lose a few marquis accounts to you, complain to you that you need to “work more closely together,” ask for your input on features and functions, iterate, lose, release and complain. This is Incompetent Technical Persistence.
After this “ism” hit me I looked at a number of client’s applications where they are afraid the platform vendor will run them over, but they need not worry. In fact I would encourage them to follow the advice of Napoleon Bonaparte (paraphrasing here);
“Never interrupt your enemy when he is making a mistake.”
Incompetent Technical Persistence creates opportunity, it is near impossible to engineer your way out of as each misstep causes more and more issues farther down the dev road that they do not know yet. In fact one effective preso I saw actually graphed the platform player’s iterations and subsequent reiterations in their drive for mediocrity. This is powerful stuff to show that Incompetent Technical Persistence is a huge risk factor to IT infrastructure. As the customer hopes and trust the platform player to “get there,” and yes these people still exist, a visual reminder of the abject failure of delivering a key functional component will put the entire platform success at risk speaks to a tangible solution.
Comments