As the creator of a software product, there are two fundamental ways to grow your revenue: your market grows overall, or you take away market shares from your competitor. It’s tempting when you have built a product for a fairly limited and now stagnant market to look to adjacent or similar market categories for a place to grow. The meeting usually goes something like this.
Marketing: “Hey, what about using our shopping list app for keeping track of other lists? Maybe we could use it to track the NFL draft.”
Product: “Well, if we want to do that, we’ll have to add these 27 features.”
Engineering: “We didn’t build this app for that purpose. We should just rewrite a new app that supports shopping lists and the NFL draft.”
I’ve written quite a bit about the true cost of rewrites. It’s possible, but a long and expensive proposition. How should a software vendor react to declining revenue and an aging software application? If rewrites are costly and slow, how can a company not end up way over-invested and behind the curve? How can you use your expertise and technology to capture a new market?
What I often suggest to companies that approach 8th Light wanting to do a big rewrite is to instead start a new or derivative product. This new product, unencumbered by having to satisfy customers in the existing market, can develop a streamlined and fit-for-purpose solution to take on the new market. The new application can have all of the rapid development advantages that a competitive product would have entering the market, while at the same time being able to build on top of the product knowledge that the company’s team already possesses.
A product built in this way can reach into the new market more quickly than can an expensive and slow rebuild effort. By generating revenue much earlier, the new product begins to pay for itself more quickly than a rewrite investment.
Eventually, the product may become feature-rich enough that it begins to reach back into the original product market and start to cannibalize sales. This disruption would start to happen roughly at the same time a rewrite effort would have been ready for rollout. The major difference is that instead of a risky migration, there is a successful and proven alternative for the old markets.
When the new product starts to disrupt the old one, it may be time to reduce costs on the old project and move it towards sunset. You can transition the development team onto the new product along with the hard-won lessons they’ve learned maintaining and aging product. Alternatively, there may be a very long tail of revenue with entrenched customers that can be captured on the old product. If operations can be made profitable, it would make sense to carry the old system on for many years without putting the pressure of growth and new customers on it and rotating your development team members between the two.
A word of warning: don’t expect that spinning up a new engineering team to build a new product is sufficient. If you want to disrupt yourself, you have to behave as a disrupting startup would. The new team will need to be agile and iterate quickly. The effort needs real cash and market pressures to keep it honest. I’ve too often seen a large company dump years of cash into a new product that the market just isn’t receiving. The investment needs to have a fixed runway to see if the market for a new product is really there.
We've talked a lot about the true cost of rewrites, and how tempting it can be to scrap your legacy system and start all over. However, it's rarely the practical solution for a business. Developing a new variant of your application is one way to reinvest in a quality product that doesn't eat into your existing success while still offering flexibility and growth for the future.
