Don’t Let Technology Changes Turn into Technical Debt

Technological evolution doesn’t stop. It doesn’t go on vacation, it doesn’t take a victory lap, it rarely even pauses long enough to catch a breath. There’s always something new on the horizon. Our products and solutions are built atop these technologies, relying on servers and programming languages, databases and messaging protocols, devices, and APIs. These are all yesterday’s news by the time we start incorporating them into our products, and by the time we ship a release they’re ancient history. The clock is already ticking. So how can IT managers make room for the changing technology landscape on the IT roadmap to minimize technical debt? For a better understanding, check out our video below defining technical debt.

Build for today, anticipate tomorrow

Companies don’t have the luxury of waiting around for the ideal technology to be available. We have revenue targets to hit, demanding customers to satisfy, and various stakeholders to communicate with. So we place our bets using the available knowledge and expertise at our disposal to bring things to the market.

For example:

We buy a car today instead of waiting for that self-driving, flying vehicle because we need to get places now and don’t have the luxury of waiting around for the next big thing. Our customers aren’t going to wait around either, and someone else will scoop them up if we don’t.

The key to building a product that will be successful in the short term and continue to thrive in the years to come is simple—acknowledge the inevitable. Leaders must have visibility into what’s coming and plan accordingly.

When should you reassess your tech?

Technological innovation represents both threats and opportunities. The threats come in two flavors:

  1. Your product will get “old”
  2. Your competitors will leapfrog you

Products relying on outdated tech doesn’t always spell doom. Most customers will tolerate things being a little slower or clunkier, a UX that isn’t intuitive, or lack of functionality they didn’t know they wanted. But over time those quaint idiosyncrasies or annoyances transform into hair-pulling frustration for customers and embarrassing shortcomings for executives and salespeople.

Meanwhile, competitors may use new tech to bring the next generation of solutions to the market. That’s either because they skipped the last generation (which you were busy building) or they’re a new entrant not weighed down by a legacy of old tech.

While both flavors of these competitors will eventually face the same situation your product faces today, for the moment they’re seen as “next-generation” while you’re seen as “yesterday’s news.”

Pros and cons of adding technology changes to your roadmap

The technology that fuels those encroaching on your market opportunity can prove valuable for your own solutions. Assess which newly introduced tech can benefit how you deliver your own product lines. Evaluating new tech should be a perpetual part of your job.

Something else to factor in is whether current or future competitors could potentially use the new technology to their own advantage. Additionally, even if you ultimately decide to forego the new tech, you’ll still need to explain why that’s the case to customers and coworkers who’ve seen the headlines and want to know why your company isn’t adopting it.Build Your First Visual Product Roadmap ➜

6 Technical Debt Risk Questions to Ask Yourself

Don’t fall into the trap of evaluating new technology in a vacuum. It’s easy to get sucked in by the romance, excitement, and marketing of it all. Instead, develop a consistent checklist that level sets whether you really need a particular tech.:

  • Does it address a problem/shortcoming in our current product?
  • Is there a strong financial and practical ROI for adopting it, including both the upfront and long-term costs?
  • Will we be the guinea pigs or has it already been thoroughly tested with real-world experience in an environment and scale similar to ours?
  • Is there proper support and ongoing maintenance planned for it by a reputable company with staying power?
  • What happens if we don’t adopt this now?
  • Most importantly, is this benefitting our end users more than whatever we’re sacrificing to add this?

Your checklist may vary, but screening every new technology using the same filters will keep everyone honest.

Planned obsolescence

Almost every technology-driven product has a limited shelf life if it continues unchanged. Your CRM solution won’t survive as-is once email addresses get replaced by the next big communication protocol.

Look at your own products. It should be obvious that upgrades and enhancements are going to happen. The question is do you stay competitive and efficient and start planning now to make the required improvements or do you wait for things to break and customers to complain before addressing things in a crisis mode.

In the agile world, your products must invest in new technologies or risk technological debt. In doing so, your product roadmap is far less disruptive and more proactive. It gives teams the opportunity to staff up accordingly and develop some in-house expertise in the new technology you’ll leverage while also setting proper expectations on the velocity of new functionality (versus underlying technology and infrastructure) that stakeholders and customers will see.

Make technology upgrades in your roadmap

You know new tech is coming, you know you’ll need to utilize some of it, and you know that doesn’t happen for free. So why build a roadmap that resides in a fantasy land where you’ll never have to migrate to a new database or leverage an updated API?

There are typically two reasons people don’t include pure technology upgrades in their roadmap: fear and uncertainty. Fear tends to come from the idea that if products aren’t cranking out enough “new stuff” that the product won’t be competitive, sales and marketing won’t have enough to talk about, and the budget will be cut because it can’t take that many people to deliver so little.

On the uncertain side of the house, predicting exactly which technology you’ll need to adopt and when it will be both mature and ready to dovetail with your product’s needs is tricky business. No one wants to declare prematurely that they’ll need Betamax in every hotel room or integration with Google+ to remain viable contenders.

But going full ostrich and sticking your head in the sand isn’t doing anyone any favors; you’re merely setting your stakeholders up for disappointment down the line. While it may not be easy at first, own the fact your company must devote resources to technology upgrades and getting out ahead of it in the agile roadmapping process. This will set proper expectations and build up your credibility.

Minimize technical debt

Technical debt is unavoidable but can be minimized. Deal with it continually so the investment is more incremental than monumental. If you’re always chipping away at it proactively, you’re saving your team from multiple releases and months of work to solely keep your product current.

While every single release may not have the room or a need for upgrading the underpinning technology, most of them do. Build work into product roadmaps that create a culture of conscientiousness today and avoid spending a whole lot of time playing catch-up.

Making technology goals and tasks a regular occurrence in roadmaps sets the expectation that the organization is committed to maintaining and improving in this area. By always including it frequently and regularly, technology improvements will simply be viewed as table stakes and not an infringement on feature development.

Prognostication and placeholders

With a roadmap stretching months or possibly years into the future, it may be hard to nail down exactly which new technologies warrant a slot on the schedule. Therefore you’ll need to hedge your bets.

As new technologies emerge and their impacts and opportunities become clear, they can earn a coveted place in your product roadmap. But if things are still fuzzy, there’s no harm in penciling in a particular upgrade or migration with the understanding that new information may deprioritize, delay or even cancel that particular move.

It’s far easier to take something off the roadmap without ruffling any feathers than it is to squeeze something in, so it’s a much better strategy to plan for it all and then only build some of it.

Don’t let the rat race distract you

Technology is not a product, merely a means to an end. Create products that solve real, ongoing problems, and their value has staying power even if their execution relies on older tech. You can’t fall too far behind, but “good enough,” reliable products with a solid track record have real staying power in a market full of upstarts with little proof of ongoing success.

Sure, some customers may take their chances, hoping they’re betting on a winner and fearing obsolescence, but plenty of individuals and companies find true merit in relying on an old standby. They’ve too often seen pretenders to the throne flame out fast, taking down early adopters in their wake.

If your product still does what you say it does—and that something is still what customers want—there will be plenty of people willing to bet on reliability over the cutting edge. We recommend that you still plot a path that eventually incorporates relevant new technologies.

Your technical debt belongs on your product roadmap—alongside other strategic elements of your product’s plans and goals. Learn how in Why Technical Debt Roadmaps Don’t Work.