Should we modernize and rebuild our aging software?
It’s a question that’s frequently asked at virtually any company that’s been building software for a long time. There’s often a lot of internal pressure to rebuild older software. Executives could be looking to make a splash and increase shareholder value. Sales may be seeking a shiny new object to parade around to potential customers. It's possible marketing is in search of something to launch a new campaign around and increase brand value. The list can go on and on.
Reasons to rebuild
Beyond internal pressures, there is no shortage of reasons to undertake a rebuilding project. Some possible reasons could be:
Locally hosted or desktop software is difficult to update and costly to maintain.
UX patterns have evolved and rendered older software clunky to use.
The concept of mobile responsiveness/compatibility may not have existed when the original code was written.
Accessibility wasn’t a priority at the time of the original build, resulting in software that alienates some users and leaves the company vulnerable to litigation.
Years of one-off feature inclusions have transformed the original vision of the product into bloatware.
New competition is siphoning current users who are growing tired of slow progress to update the application.
Deal win rate is decreasing as potential customers look for more modern solutions to their problems.
While some of the reasons listed above may be more valid than others, there is little doubt that rebuilding a core software product provides immense value and many benefits for a company examining its current offerings and looking for opportunities to grow. However, before embarking on this journey (and let me tell you...it is definitely a journey), product owners and key stakeholders need to think carefully about why they’re rebuilding and how they’re going to achieve success.
5 strategic steps for rebuilds
1. Understand failure & define success.
Few things in software delivery are as dangerous and wasteful as embarking on a large project without clear metrics and definitions of what success in the project looks like. Simply having available resources and an idea to rebuild your old platform because it really needs to be refreshed is a good way to start down a path of poor return on your investment. Instead, lock down some concrete metrics. Some options include:
Reduce operational and maintenance costs by X% within 1 year of the release of the updated software.
Reduce installation and onboarding time for new clients by X days/weeks/months.
Deliver product updates to users every 2 weeks (compared to monthly/quarterly/annual updates of current software).
Increase customer retention from 85% to 95%.
Increase new deal win rate from 10% to 20%.
Increase product uptime from 95% to 99%.
To be successful in most of those beautifully-defined goals, you’ll need to have a good idea of the issues your current offering has. Hopefully, with a mature enough application, you’ve been collecting and analyzing user feedback for years. There may be some parsing of customer comments needed to get to the core of what’s bothering them, but larger themes should begin to emerge.
2. Seek clarity on the pain points of the current application.
In addition to the user feedback you’ve compiled and analyzed, talk to your support team or any other teams that are on the front lines of customer interaction. They get a lot of unfiltered customer feedback and more often than not, support teams don’t have a good way of getting that feedback analyzed or shared back to the product team.
Another route to take is to set up dedicated user testing sessions with actual customers. Leverage relationships that have been built over the years to identify customers that are invested in the success of the product. Prod these customers to think out loud as they show you how they use the software. As with any user testing, you’re not simply going to do whatever they tell you in these sessions. Use your findings to identify trends as they emerge and roll these up into issues that need to be solved as you build out the latest and greatest product.
3. Rethink the way you define Minimally Viable Product (MVP).
The definition of an MVP has become increasingly vague and loaded in the product development world. When you’re rebuilding software that already has paying customers, defining the MVP can quickly balloon into a ‘We have to rebuild every single feature from the old software, or this is doomed!’ mindset. Avoid this! Your team is going to be making a lot of assumptions (hopefully guided by data and customer feedback) about how to improve on the previous product, and that means you have to get working code shipped into production long before the last feature is polished and ready.
You can learn a lot about your assumptions by focusing your early releases on some limited end-to-end workflows before you add in every bell and whistle for the features involved in those workflows. For example, if a part of your application involves searching for items to purchase, the legacy version might allow users to save searches, auto-fill search terms, and automatically update the search results as the search terms are changed. In order to test your new approach for making a purchase, you could easily release your product without some of those nice-to-have features. Some of your assumptions regarding product discovery can be validated much sooner in the process.
Another option is to focus on one persona instead of trying to build for everyone. Just like the peril of going down the path of trying to get every feature fully developed right out of the gate, trying to satisfy the needs of every different type of user on your platform is a large effort that’s going to take a good amount of time. In order to learn quickly and iterate frequently, you’ll need to ship early and keep the focus on one key persona before expanding to others.
4. Keep an updated, external-facing roadmap.
A big key to success in your rebuild is going to be winning and keeping the trust of your customers as they start to use the new version. There’s a degree of expectation management involved since a lot of the customers’ initial reactions will be centered around the features that aren’t there yet. A great tool to combat that user frustration is a product roadmap for external consumption.
You will more likely than not have all sorts of internal roadmaps projecting out the next year and beyond with features tied back to specific backlog epics/stories. These roadmaps will be of great use in communicating with internal stakeholders and coordinating future release expectations. But the level of detail featured in internal roadmaps isn’t necessary for customer consumption.
For an external roadmap, your goal is to keep users informed and show your commitment to delivering frequent, material improvements to the application. Try using a now/next/later approach to roadmapping:
Customers will get the benefit of knowing the features in flight while simultaneously getting a chance to provide some additional feedback on the next/later items you’re planning. Roadmaps should never be set in stone, so having the flexibility to pivot is always valuable. Keeping your customers and any other external stakeholders in the loop will ensure you can spot those pivot opportunities when they arise.
5. Get your sales team involved early and often.
(This is probably most relevant in B2B organizations.)
Your product will only go as far as your sales team can sell it. If you’re rebuilding software that’s been sold for years, you’re going to need to get sales on board if you want them to sell the new product with the same vigor they’ve been selling the legacy product with. The sales team usually has a good understanding of what potential clients want, and their feedback is vital.
Remember that now/next/later roadmap above? Run the sales team through the roadmap as it evolves. They might point out something you haven’t prioritized that’s been the missing piece to winning recent deals. Or they might learn you’re about to release a great new feature that could be the difference in closing a deal with a key prospect.
Beyond telling them about the amazing things your team’s working on, show them! Product demos will unearth additional questions and feedback. Showing your sales team the new features will help prepare them as they go out and demo the software in the real world to potential customers. Empower your salespeople with the knowledge of which workflows they can show off, how to maneuver around parts of the application that aren’t built yet, and which demo accounts/data are up to date. People get excited when they see a killer demo of real software.
Set up for success
At the end of the day, these projects can be incredibly challenging and incredibly rewarding. Taking a longstanding, successful product into a new era is a crucial juncture for a company. Getting the right plans in place and executing on them effectively can significantly alter the future course of an organization.
By clearly defining success and calibrating early release expectations, you’ll get plenty of indicators telling you if you’re on the right path. Maintaining an external roadmap and looping in your sales team will ensure both current users and prospects trust you to deliver on your promises—and set you on the course for a successful rebuild.
Chances are, it took a long time to build the original software, and there have been years of releases and tweaks to get it to the current state. Rebuilding will not happen overnight. While rebuilds may seem like daunting projects to complete, success is absolutely attainable…and getting it right can pay enormous dividends for any organization.
