Category Archives: Software Development

Minimum Viable Replacement: A new approach to replacing old systems

“We need to retire the old system by X date, so what’s the MVP we can deliver by that date to replace it?”

“What?” you ask, alarm bells going off in your head.

“You know, the 20% of the capabilities that meet 80% of the customers’ needs. We can always enhance the system later. We’re agile, and we can’t let better get in the way of good enough, plus there’s a bunch of stuff that’s only being used by a single customer, so they’ll just have to deal with it, plus the new Web version will be much easier to use.”

And so begins yet another digital destruction, er digital transformation, initiative. As someone who’s witnessed multiple multimillion dollar agile release trainwrecks, I’m going to introduce you to the concept of Minimum Viable Replacement, a new framework to help you replatform and retire systems. 

Minimum Viable Product vs Minimum Viable Replacement

In the world of agile everyone talks about minimum viable products, that smallest set of capabilities required to meet a segment of your customers’ needs. The concept popularized by Eric Reis in the book Lean Startup, is great for startups, and for companies entering entirely market or product segments.

Most companies are not startups, and instead spend most of their time enhancing and replacing existing systems to take advantage of new technologies and address competitive threats, not developing entirely new capabilities for entirely new markets, therefore MVP is absolutely the wrong approach for replacing legacy systems. 

If your company has been around for a decade or longer, then you need to be thinking in terms of Minimum Viable Replacement 90% of the time!

Think about it, your company has grown from a small company into a much larger company over decades, with multiple products serving customers of different sizes and business units across multiple geographies and markets, each with their own specific requirements. 

If you’re in the B2B space, your largest customers drive the majority of the revenue, and therefore get special features and customizations just for them, so rather than thinking about your largest customers as a segment, you really need to think of each of your ginormous customers as a key segment that will be very costly to walk away from.

And over those years, your software and other systems have been modified time and time again in order to meet the specific demands of your largest customers, fight off competitive threats, enter new markets, etc. Oh, and many of the people who made those changes have been synergized, retired, transferred, died, so no one even knows what all the systems do, and for whom they do it. 

On top of that you will encounter the Paper Clip problem, where creative users, have figured out how to get your system to work in all sorts of ways it was never designed for.

And finally, even as you’re trying to replace your old systems, customer, regulatory and competitive demands are still forcing you to enhance the existing systems, even as you are trying to replace them. 

As a result delivering a minimum viable replacement is typically exponentially more complex, costly and risky than launching an MVP, as you can destroy your company if not done right.

 An MVR = multiple MVPs

For the purposes of this article, a Minimum Viable Product is simply a validated hypothesis that a certain minimum level of functionality is enough to meet a specific market segment need. 

The key to a successful MVP is to solve a specific segment’s challenges first, instead of trying to solve multiple needs across multiple markets. 

A minimum viable replacement is usually the exact opposite. Instead of having to solve the needs of a very specific customer segment, you need to solve the needs for every customer segment.

An MVR is the sum total of all the MVPs required to transition existing customers and retire existing systems. So not only do you have to potentially replace all of the existing capabilities in order to keep your existing customers happy, you have to get your users to migrate to the new systems.

Especially in the B2B space, where software applications are generally integrated into larger processes and ecosystems, getting customers to migrate often takes much longer, and is much harder than even replacing the core capabilities. 

In addition, especially if you are in the B2B market, you cannot underestimate the importance of designing for the extreme use cases. Why? Because those edge use cases are often critical for your largest customers.

Remember, one percent of your customers will drive 90% of your complexity, so if you design and architect for the 80%, there is a good chance that your solution won’t scale to support your largest customers. 

A good way to envision this is to think about a 100-story condo. The “regular” folk live on the first 99 floors with 12 foot ceilings, fairly standard bathrooms, etc. and pay $10K in rent annually.  The 1% live on the 100th floor with their own swimming pool, heli pad, 40-foot ceilings, and all sorts of other crazy things, and pay $1M annually. If you design for the first 99 floors initially, and then get to the last floor, only to discover that 40-foot ceilings and a helipad are critical requirements, what’s the probability your design and architecture will support these “crazy” use cases.

Each of your largest customers, especially if you have done a lot of customizations, may need to be treated as its own segment with an associated MVP in order to successfully meet their needs. 

In fact, you may decide to have two entirely separate approaches. Standard architecture and design for the 99% and entirely custom solutions for the 1%, but that leverage shared services whenever possible.

Typically, most companies underestimate just how much complexity they’ve taken on to support their largest customers, and just how little concern the largest have for your desires to retire your systems, which leads to massively underestimating both the amount of work required to replace the legacy capabilities required, but also how many years it will take to get their largest customers to transition.

Unfortunately, the MVP approach almost guarantees that companies will fall into this trap, since it focuses on what’s the least we can do to declare victory based on a paradigm that has ABSOLUTELY nothing to do with retiring legacy systems

As long as you embrace the fact that it takes years to replace decades of development, not months or days, and that the road to retirement will be much longer than anyone anticipated, then you can plan for the unexpected, and take advantage of opportunities as you implement new components.  

After having been through multiple replatforming initiatives, i.e. from DOS to Windows, Windows to Web, Web to mobile, Mainframe to cloud, etc. here are just a few questions you’ll want to ask as you plot your replacement strategy are:;

  1. How much revenue comes from the top 1% of our customers?
  2. Do we understand the edge use cases, e.g. how the system is used to close the books at the end of the year, or when there is a regulatory audit?
  3. Who are our top customers, and what types of customizations have we done for them?
  4. How deeply integrated are our systems integrated into their systems? And how difficult will it be for them to adopt our new systems?
  5. What are all the downstream applications and organizations using our systems, inside and outside our company?
  6. How are these individuals and organizations using our systems and the data they produce?
  7. Can we segment our customer base by capability requirement? If so then can we Identify MVR requirements for each segment?
  8. Are there new underserved segments that don’t currently use our existing product because they can’t afford it, implementation complexity or because it’s not available on X platform, e.g. mobile, that would be happy that would be happy with a true MVP?
  9. Is the new product an extension of the old and should be initially sold as an add on or is it a true replacement? Sometimes you can start by offering an enhancement which can be sold as an add on and then later integrate core replacement functionality. 
  10. Is it better to piss off your existing user base or potential users? Oftentimes, we build functionality for a specific niche or customer and have to make hard choices about whether it’s worth supporting existing customers vs. serving a broader set of new customers. Just be prepared for the blowback as what makes sense on paper to you may not make sense to the VP of sales or service dealing with irate customers or trying to hit their quarterly targets.

HIRE RAY GREEN NOW! Award-winning roboticist making sandwiches instead of building apps and robots

image (1)

Ray Green , Kevian (7-yearsold) and Jaimyiah Moore (Kevian’s mom) working on their new robot in preparation for the 2019 IEEE SoutheastCon Open Hardware Competition in Rob Fortenberry’s workshop. 

HIRE RAY GREEN NOW! What are you waiting for? He almost single-handedly beat hundreds of other engineering students and graduates from 48 universities, including Georgia Tech and Clemson, to place second in the 2018 IEEE SoutheastCon Open Hardware Competition!

Instead of applying his brilliance building robots, writing code and doing design work, he’s making sandwiches at Panera at night after a long day of studying at Code School.

“The thing about Ray is he’s not just brilliant, but he’s so good!” explained his mentor Robert Fortenberry. And by good he means the sweet kid in the photo, so willing to help others.

“He actually would have won the entire competition as his robot actually got the top score, but when he checked in, he forgot to bring his logo flag  and that was the difference between first and second place.”

Ray and Rob are emblematic of the opportunity that needs to be nurtured in Memphis. Rob has devoted his time and money to helping young people achieve greatness. His own son won the competition at 10-years old and he now coaches multiple teams from Memphis.

Ray is that diamond who doesn’t even realize his own value, winning the competition was barely mentioned on his resume.

“So you participated in the IEEE Hardware Competition? Did you win anything?” I asked after reviewing his resume.

“Actually, I came in second.”

“Was it a high school competition?

“No it was college.”

“How many?”

“Not sure, about 50.”

Piqued, I threw out a few college names, “So did you beat Georgia Tech or Florida State?”

“Uh, yes… Is that a big deal?”

I nearly fell out of my chair. Here’s a brilliant, naïve, hard-working kid from Memphis, @Tech901 graduate and @Code Crew student who beats hundreds of other competitors from top engineering schools in 11 states, and has no idea whether that’s a big deal or not!

Good news for you, is he’s available now for part-time work and is graduating in just a few months, so grab him now. Also, he and Rob’s other Memphis teams need sponsors  for the 2019 competition in April, so hurry and support greatness before someone else beats you to it!