As we look at the number of new product announcements made by tech companies each day, we notice that a large percentage never quite achieve success. In some cases, the sizzle is better than the steak, and in others, the market doesn’t need or want a specific product.
Large technology companies are no different. They are constantly seeking to find the “next big thing” that will be a key part of future success and longevity. But sometimes there are so many products in the existing portfolio that a pare-down of the product set is a necessity.
Citrix XenClient is great example of this. When XenClient was first released in 2010, the hardware that would run it was a short list, and it was difficult to find a laptop that would support the very strict specifications. Once the hardware compatibility list expanded beyond a handful of device models as part of subsequent releases, it was difficult but finally somewhat reasonable to find hardware that actually could run XenClient.
Strike One. Severely limiting the functionality or hardware that works with a new product decreases acceptance. From a marketing or product management perspective, some feel that it’s good to provide a v1.0 product just to see if the market bites on it. After all, it takes a tremendous amount of time and money to release a new product, and it’s beneficial to have an initial market response to an initial version before committing even more resources.
However, an early release can be a two-edged sword, and potential market success may or may not be attributable to that v1.0 release. Why? If the new product isn’t quite ready for prime time, would-be adopters may install a trial or free version in the lab but never proceed with purchase because of stability, functionality, or other deficits. And they may never connect with the product or development team to let them know that it conceptually addresses a need but doesn’t meet the requirements for production. Or the product may not actually address a need, and the market responds with apathy. From a sales standpoint, both responses are the same: zero revenue.
Back to the XenClient example: somewhere around v2.1, I installed XenClient for the first time and started using it. Conceptually, XenClient was a great idea. It provided a hypervisor that enabled a user to run multiple operating systems on a laptop computer. However, the management part that was necessary to run XenClient was not something that your average user could do; only an IT person would be able to use XenClient without issue. The reality of running two operating systems at once and having three total was still pretty cool. But more importantly, I struggled to find a business case where XenClient was a necessary or even good technical solution.
Strike Two. Cool is good, but business relevance is critical. In order for a product to be successful, it has to address both business and technical requirements. As much as we love the engineers and developers who create new products, product managers or other business-minded people must determine whether there truly is a business need. If there’s any hesitation about whether there is a business need for a new technology, it’s likely that the product is doomed. Business relevance will be the key indicator as to whether anyone will actually be willing to buy the product.
This week, Citrix finally announced the end of XenClient. There has been almost no focus on XenClient recently, and so it was certainly no surprise that Citrix has announced that XenClient has been removed from the product set.
Strike Three. Paring down products is common, and it is necessary for technology companies as they determine what is relevant both from a business and from a technical perspective—as well as what isn’t. With the tremendous costs to bring new products to market, nurture those that have great potential, and maintain those that are achieving success, keeping the product set trimmed is essential.
Some products can achieve success after Strike One. If the product is released too early but the market wasn’t ready for it or the product needed to mature, it’s easy enough to recover from this early strike. But when the product is seeking a business need, rather than the business need driving the product, Strike Two is inevitable. While a home run is still possible after this second strike, if business relevance and product maturity don’t step up to new heights, Strike Three is inevitable.
XenClient … you’re out!
I had a good application for utilizing XenClient this year, but in late March we found Citrix waffling around regarding support. Our regional Citrix rep talked to the product manager who told him that XenCleint was not recommended for anything mission critical. That can be interpreted many ways, but I chose to interpret it as Citrix wasn’t going to support the product if you found a problem with it. The writing was on the wall when they axed the VP of the division earlier this year and ‘re-organized’ the development staff.
It’s a shame that the product development fell apart. I believe standards could address a lot of the problems. I’m hopeful that at some point in the future, Type 1 hypervisors will become like the BIOS is today, simply builtin to the motherboard by the manufacturers using a hypervisor standard. The current type 2 hypervisors just have too many management shortcomings to be practical. XenClient came very close, but it’s lack of PCI pass-through support and USB pass-through bugs were nagging problems.