202405031400 Minimum Viable Replacement: A New Approach to Replacing Old Systems

Introductory article for the framework

About 100x as long as needed and poorly written. Did not even introduce a “framework” in the end, literally just set up the problem and ended with GLWTS. But the slides are good.

The problem: Replacing an existing system is the exact opposite of an MVP

If you’re trying to retire a legacy platform — instead of having the luxury of just solving very specific customer segment needs — you need to solve the needs for every customer segment using your software! [...] Instead of trying to solve the needs of just one small segment, you now have to deliver 20 years worth of software development for thousands of customers across multiple countries and segments to retire the system [...] Consequently, we need to prove that the new technology matches or exceeds the value of the old technology for our existing customer base.

Retiring systems takes longer and costs more than your executives want to hear

Stir Trek Talk

• Charlie Brown kicking the ball, but yet we think it’ll work this time
• Turns into deadline driven development
• Problem is that expectations are out of alignment with reality
• Ignore laggards and edge cases but laggards are biggest customers and edge cases are your critical risks

Embrace uncertainty

• Reject plans, embrace complexity (as in the real world is uncertain/complex)
• Enterprise iceberg of unknown 80/20 or w/e arbitrary
• Uncertainty + complexity = risk => drive risk
• If you have 20 phases that are 90% certain waterfalled, you get 12% probability the end is on time

Focus on risk reduction

• Invert red-green status, start as red because of risk/uncertainty and then gets greener as surer
• There aren't many risks for the last few things that we put off. We put off the uncertain ones, the edge cases, and (lots of time) the few most important, custom, risky, scaled ones. Looked at averages, not extremes where the risk and uncertainty lie.
• Impact "hyper-pareto-ism" idea of 99/1 vs 80/20 on split of value. Super long tail with hyper valuable single customers

Understanding Augmentation vs Replacement

• System A exists, add system B is augmentation, but then taking A away is making it a replacement. People can be happy with B being 99% of A but won't be when A is now unavailable.
• Loss Aversion — we value things we have 2x as much as things we only might get. Or in a reverse way, losing things you have is psychologically challenging because you might need it or something.

Minimum Viable Replacement

• "All capabilities, work, and experiences required to migrate users from one technology, system or process to another."
• MVP enhancement idea doesn't really work. Can go shoes -> truck via bike but can never replace the truck with a bike or shoes afterward.
• MVP gets one slice/segment, asks "is there a market?"
• MVR know there's a market and needs to address multiple segments
• Early adopters aren't typically the largest customers, laggards are. In the middle there's the "easy majority"
• Need to design and architect for the 1% but then build the 99% first. Can't design/architect for the 99% first because it won't work at the final huge scale/need/weirdness or w/e
  • Enterprise iceberg again "here be dragons"
• Not only the product and capabilities, we have to do more of the migration work etc since they're so big and valuable. We can tell a little customer "the migration's on you", but not the biggest.
• Analyze your application usage by feature/capabilities (yes, normal practice but also) map all those features/capabilities/usage to the customers and customer segments then split out dependencies and everything
• Consolidate and automate wherever possible, self service, de-customize, but don't shy from custom if needed (should have been designed for to begin with)
• Identify key barriers to adoption and identify potential solutions
  • This phase can last 2, 3, 10, 20, 100x longer than dev
  • The more tightly integrated they are, the longer the timeline

Use the watermelon detector

• De-risk delivering bad news
• Watermelon is green for a long time on status until sudden explosion into red
• Identify and mitigate common risks
• Ask questions like "does the team have experience working together or with this tech?" which will give you a confidence/risk idea of how uncertain things are
• Ask does it match capabilities to identify adoption risk "yes all and exceeds (low risk)", "mostly yes (medium)", and "some but not all (high)"
• Identify and track risks, prioritize, assign ownership, create mitigation plans, implement.
• email kevinjmireles@gmail.com for copy of watermelon detector sheet