Tips for Rewriting a Digital Product

Rewriting an existing product is often a cost-centric exercise that can feel like a joyless necessity. But instead of replacing like-for-like and providing a carbon-copy of the old product, you should see the rewriting effort as an opportunity to innovate, to create more value for the users and the business, as I explain in this article.

See the Rewriting Effort as an Opportunity to Innovate

A digital product is commonly redeveloped for two reasons: It has accumulated too much technical debt or its technologies are outdated, but the product is still needed—be it to generate revenue, support other revenue-generating products, or automate business processes and increase productivity. Consequently, rewriting efforts are often focused on replacing like-for-like: The users get the same product dressed up in new technologies.

While this approach works, I wastes the opportunity to innovate and create more value for the users and business. Wouldn't it be great to make the product better, improve the user experience and add brand-new features? Take Microsoft Office as an example. The company enhanced its productivity suite in recent years by decluttering the user interface and adding new features like collaboration and Skype integration, not just by replacing existing code.

Start with Product Discovery

But before you start compiling a product backlog with the new features the product should provide, take a step back and find out who actually uses your product, why people employ it, which user journeys they carry out, and which existing features they mainly use. This requires some user research and product discoverywork, for example, observing users and conducting problem interviews, as well as analysing any analytics data you may have available.

A great way to leverage the data you've collected and discover improvement opportunities is to create a consumption map. Such a map visualises the steps users take and any issues they encounter like waiting, delays, and errors (as I explain in more detail in my book Strategize). For revenue-generating products, you should also investigate if the product is still effectively differentiated: Do users have a compelling reason to choose it over competitors’ offerings? A great way to answer this question is to create a Strategy Canvas, as I describe in my article "Make Your Product Stand Out with the Strategy Canvas".

Additionally, give the development team members the opportunity to carry out some technology exploration to ensure that the redeveloped product will be built in the right way. Would a micro services-based architecture or machine learning be beneficial, for example?

Finally, capture your insights and describe the product’s current strategy: the people it serves, the value it creates for the users and business, and its key features, for instance, by using my Product Vision Board.

If you find it hard to justify carrying out the necessary discovery work, then look at the inaction risk, the risk of not making the necessary changes and providing a carbon copy of your product: Which benefits would you lose, such as increasing user satisfaction by simplifying the product and saving maintenance cost by removing features? Then try to quantify these benefits and compare them to the discovery investment required.

Explore Your Strategic Options

Next, examine the options to move your product forward: Should you continue to provide one, cohesive offering? If so, can you remove some features or lean them out? It’s not uncommon in my experience that over time, features are added to a product in order to accommodate requests from powerful stakeholders—not necessarily because they benefit the majority of the users. These are prime candidates for removal. Additionally, consider if you can add or enhance features to make your product stand out, and if you can improve the user journeys, for example, by eliminating steps, improving touch points, and reducing delays.

If, however, the user base has evolved into a larger, heterogenous group, consider creating different product variants to address the subgroups—think of Microsoft Visio Standard and Professional as examples for variants of the same product. Alternatively, you may want to unbundle one or more features into a new product, as Facebook did with Messenger in 2014 when the company released the messaging feature as a stand-alone app.

Capture your decisions and document the new strategy for your product, for instance by creating a new, forward-looking Product Vision Board. Before you proceed, carefully investigate your board for any major risks and assumptions. If you find some, take the time to validate them. Otherwise you risk implementing an unvalidated and potentially incorrect strategy.

Incrementally Replace the Product

Chances are that the existing product has grown over many years. Replacing it in one go may require a significant amount of time and money and it carries the risk of discovering issues late in the process. Incrementally replacing your product, for example, by using bimonthly releases that progressively enhance the product, avoids these issues. What’s more, it allows you to collect user feedback and data and discover issues and opportunities at an early stage. But it also means that you have to keep the old product working until the new one is ready to substitute it.

If you decide to create variants or unbundle features, determine which variant you will offer first or which product, the original or the new one, you are going to initially develop—unless you are able to create both in parallel. And if you look after a commercial product, you may have to find a small group of customers who are willing to be innovators/early adopters of the redeveloped product in exchange for the ability to influence its development.

Once you have identified the right way forward, capture your decisions in a product roadmap like my GO Product Roadmap. You should now be in a good position to stock the product backlogand create the right user stories.

Invest in Quality and Proactively Manage Your Portfolio

Several years ago, I worked on a new telco product that was destined to replace its predecessor. The new offering, built with cutting-edge technologies, was intended to have a superior user experience and significantly reduced maintenance cost. Unfortunately, the development effort took longer than expected. To avoid further delays, management decided that the development teams should do whatever they could to get new features out as fast as possible; development practices such as test-driven development, pair programming, and continuous integration were seen as unnecessary and went out of the window. Sadly, the new product’s code ended up being as messy and buggy as the old one thereby invalidating a major reason for developing it.

While this story may sound extreme, rushing out product replacements is not uncommon in my experience. Organisations sometimes procrastinate the redevelopment effort for so long that quickly having the new product available becomes absolutely mandatory. To avoid this mistake, make sure you are aware of the technical debt in your productand start a re-writing effort early enough.

Additionally, you should do what you can to ensure that the new product has the right architecture and a clean code base, that it is easy to extend and maintain. Use a Definition of Done, only accept work results that comply to this definition, and encourage the development team(s) to apply agile development practices.

Finally, establish a portfolio management processand track your products's life cycle stage. Pay close attention to your cash cows and pets (formerly known as dogs) and make sure that you invest early enough in new products to replace them and avoid having to rush out their replacements. This makes it considerably easier to carry out the necessary discovery and strategizing work and develop a product with the right quality.

Learn More

You can learn more by attending my Product Strategy and Roamap training course and reading my book Strategize.