Question: How can I avoid cannibalizing sales of an existing product with a new product?
I have an existing product that I am planning to introduce a new update version. The update version is needed due to competition.
My question is how to manage the new product planning so that it will not impact the sales of the existing product, or at least minimize impact on current sales.
For example: How late I should go to avoid letting sales and/or customers know about the new product? And what are the considerations to migrate existing customers to buy new product?
You have elected to respond to competitive pressures by releasing more product. I’m going to assume (danger danger) that this was the best approach, but I’ll come back to this later.
You’re concerned that customers will stop buying the old product as they wait for the new one.
You’re right. Once knowledge of a new version gets out into the wild, prospects will wait for it, slowing down sales cycles to evaluate the new version if these new features are truly core to its competitive position.
One challenge is that your sales folks and sales engineers are probably aware that there’s a new version cooking and have been telling prospects “that’s fixed in our next version” or “we add that in the next release.” It’s entirely possible they know this because you told them. This has the impact of slowing down sales. It also has the impact of putting your sales channels on the defensive.
If you’ve taken the extraordinary step of publicizing the features in this new release to a broader audience, this will also slow down sales. It will also aggravate buyers who are not on maintenance contracts who purchased your software prior to news of the new feature(s). And depending on how often you spring these new releases on the market in response to competitive pressures, you may earn the reputation of being a follower who isn’t anticipating customer needs.
So now let’s look at your question of “how to manage the new product planning so that it will not impact the sales of the existing product, or at least minimize impact on current sales.”
For planning purposes, the best way to address this by baking it into a rigorous roadmap process. When I was the product manager for InstallShield, we had a schedule for releasing new versions of the product in the spring and fall of each year — customers and prospects came to anticipate when new stuff would land, and we were able to structure our marketing (and revenue expectations) around that schedule.
In the absence of a regular release calendar, again I recommend a structured way of communicating new capabilities to the channel. I’m not suggesting you treat them like mushrooms (“keep them in the dark and feed them s__t”), but that you wait to publicize the full range of product capabilities to them — with associated sales enablement tools — until a fixed time before the launch, perhaps a month. It’s hard to control the flow of information, but it’s better to ramp up the channel once with comprehensive data than it is to dribble half-facts and non-actionable information to them over a long period of time. This helps reduce the impact on sales because it reduces the “freezing effect” of ersatz announcements on current sales cycles.
The second approach to minimizing the impact on current sales is to push maintenance harder or to offer some form of 30-day upgrade guarantee to buyers. This should be tuned to your particular type of software and the length of your sales cycle, but it helps buyers feel like they can buy now and still get the benefit of new stuff. Note that this works best if you’re doing a super job of controlling the flow of information and doing a good job of communicating with customers about new releases.
Without knowing more about your product and the problems you’re seeking to solve, it’s hard to be more specific. But I can offer the following universal truth: the best response to a competitive action is not always an equal and opposite reaction. Did you really need to respond to their capability with a similar one? It could be that they are working to redefine the problem in the minds of the customer to steer the solution closer to their core competency, not yours. It could also be that they are trying to throw you off your release cycle by putting a “must have” feature into the market and calling you out to respond to it immediately.
But the most insidious possibility is that the feature — while important to a vocal subset of the target audience — really isn’t that important in a strategic sense. Did you really confirm that the capability is necessary to solve the core problem at the heart of your product strategy? To put it in Pragmatic terms, does it help solve a problem that is “urgent, pervasive and which people are willing to spend $ to fix”?
You can’t assume (there’s that word again) that the competition is addressing a compelling need just because they took action. Sometimes you need to respond to a feature with words: “The competition thinks the problem you have is x, so they released feature foo. What we’ve learned from talking to companies like yours all over the country is that the problem is actually y, and here’s our strategy for addressing it. What’s unfortunate is that while feature foo doesn’t get you any closer to solving your problem, it is really appealing to some users. Here is how we address it with our current product with bar…”
Product management can’t solve every market problem with product. This leads me to the very brief answer to your last question: “what are the considerations to migrate existing customers to buy new products?”
The answer is “do a better job of solving their problems than the other guy, and do so in keeping with a strategy that they understand and value.” Selling software isn’t like gavage — give your customers a compelling reason to move and they will.