Once upon a time, I co-founded a device management software company called Rapid Logic (eventually we sold it to Wind River for $67M), and we had an idea for a new product called SupportBot.
The idea behind SupportBot was that as we were in the business of making software tools that enabled network equipment vendors (think: Cisco, Nortel, Alcatel) to make their products (think: hubs, switches, DSLAMs, routers) smarter and more systematically manageable, we could build a type of gateway for watching when things go wrong, and then automatically either fix the problem or alternatively, notify the equipment operator (enterprises, carriers, datacenter operators, etc.) how to fix the problem.
Having had lots of behind-the-scenes access to the technical support department at our predecessor company, we knew that 95% of the support incidents have known resolution paths to them but that there is a huge inefficiency (read: cost) that occurs when trying to translate the customer’s non-technical explanation of what’s gone wrong into a “root cause” and then guiding the customer step-by-step to resolve the problem.
Needless to say, this was a big problem to solve, especially for a start-up, but also one with a very clear ROI since support incidents cost both vendors and consumers double digit dollars every time a support incident occurs.
One small fly in the ointment. As the end-customer would invariably have a heterogeneous, multi-vendor environment, the SupportBot solution, to be practical, would need to work across different hardware and software systems.
It would also need to be malleable enough to support a wide variety of different support incident use cases.
To do this, it would need to communicate with such systems in a pretty deep manner so as to get the data needed, track events when they occur and orchestrate configuration changes when necessary.
In past blog postings, I have referred to a strategic modus operandi called “ship the idea, fix it, and then iterate” whereby as rapidly as possible, you ship the most minimal, but meaningful, implementation of your product, with a goal of soliciting user feedback on bug fixes, usability snags and feature requests, which in turn drives a rapid release cycle until you hit a stasis point in the product.
In the case of SupportBot, we went a different way, and it literally saved our hindquarters.
Instead, we embraced The Spiral Model, a systems development methodology (conceived by Barry Boehm), whereby you assess the highest risk items of the project first -- BEFORE beginning development.
This way if there are core assumptions that have to go right for the project to succeed in realizing its outcome goals, you have not invested months in designing, coding and prototyping only to discover that you should have avoided the effort in the first place since, euphemistically speaking, the new vehicle is dependent upon a fuel that is commercially unfeasible.
After all, once man-months, dollars and reputations have been invested, undesirable truths are more difficult to see.
By contrast, before man-months, dollars and reputations have been invested, realization of those same hard truths is pretty much all you need to avoid going down a dead end road.
In the case of SupportBot, the core risk was that the support desk software vendors, whose infrastructure would already be in place in many of the environments where our solution would live, would not have any standardized way to share information on support cases and resolution paths with our system, leaving us with a bridge to nowhere.
After some research, however, we discovered that there was a nascent standard being pushed called the Solution Exchange Standard (SES) that promised to resolve a lot of these issues.
Of course, this only helped us if a broad range of vendors were poised to adopt it timely.
Understanding this as the binary risk, we reached out to the head of the consortium, bought him dinner and picked his brain on the likelihood of this protocol being adopted in shipping products any time soon.
The net-net was that vendors were paying lip service to the concept but when it came time to prioritize development decisions, SES never made the cut.
Armed with that knowledge, the SupportBot project was terminated on the spot, and we focused instead on more productive and profitable endeavors.
Related Posts:
- The Paradox of Developing New Products and Services
- Start in the Middle: a user experience product management methodology
- Innovation, Inevitability and Why R&D is So Hard
