Working Software is Not MVP: Why Did I End Up With Solution B?

If you read our previous article on why Working Software is not MVP, you may have come to realize that your current software implementation is eerily similar to “Solution B,” a solution that is “working” but difficult to maintain and expand to current business needs. Or perhaps you’re embarking on a digital transformation project just now, and you’d like to avoid making a large investment only to end up in this situation.

Either way, let’s dive into the common reasons behind “Solution B” so that you can prevent it from happening (perhaps again).

Poor Quality Blueprint

Most software platforms that companies invest in provide some level of documentation and tooling to help get started. However, written documentation only goes so far when you encounter the nuanced questions of a real project and can’t find the answers with a web search. And tools provided by the software vendor are often great for building a shining demo, but don’t ladder effectively into an enterprise solution (that’s your concern, not theirs). A true subject matter expert (SME) with proper tooling is irreplaceable in navigating these muddy waters to produce a solid solution that leans into the strengths and avoids inherent weaknesses of the platform.

Looking One Step Ahead

MVP is not the time to “figure it out as we go.” If you were to navigate treacherous terrain with your head down looking just ahead of your feet, you may never fall into an abyss, but your path is sure to wind back and forth from one peril to another, and you will likely need to backtrack multiple times. So often teams use Agile as an excuse for looking only one step ahead, getting started without a fully thought-out plan. To be fair, this often works fine when a platform is established and you’re plowing through sprint work. But in the foundational stage of a project, it’s critical to understand and build for the future you want multiple steps down the road.

Too Many People Involved

No one would recommend laying a 100-brick wall with 10 bricklayers, but in software we see this suggestion all the time.  The question isn’t whether 10 developers can get the job done faster than 2, but whether the larger team will produce a solution that is as cohesive as the smaller team. When you’re starting from ground zero on a new project, without patterns yet established and Solution A versus Solution B in the balance, coordinating between a few highly experienced technicians to develop a fully cohesive solution is much more tenable than with a larger team.

Missing Specialization

Digital transformations often involve technology that is analogous to technologies already in place, and the people working with those technologies at your company are almost certainly intelligent, skilled people. But when companies sponsor a professional race car, they don’t put out a memo seeking a driver from everyone who drove into the office that day. Using another analogy, I can reliably swap an electrical light fixture in my home, but making major changes inside the main electrical panel on my own would be highly risky. I’m enabled to leverage my own skills to make additions and modifications to my home today because someone who does electrical work every day as their career was hired to establish the electrical architecture when the house was built.

Too Much Duct Tape

We’ve all run into the situation – something with our house or car breaks when we don’t have the time or money to fix it correctly, and so we reach for the roll of duct tape. Seemingly it can “fix” anything, and we know too well how often that “temporary” fix becomes permanent. With complex software platforms, there’s generally many ways to accomplish a goal, making it very easy to find workarounds to bugs and paper over challenges with solutions that are “good enough.” Duct tape is great as a temporary solve in a critical situation, but too often a spider web of tape ends up as Solution B. Avoiding this situation in MVP requires a team that’s “seen it all” so that pitfalls are avoided and proper solutions implemented without blowing the timeline and budget, keeping duct tape relegated for emergencies.

Vendor or Third-Party Dependencies

Software vendors and professional services companies often provide canned solutions (not to be confused with accelerators) that appear to be a quick start to your project. Given the packages are “canned,” your ability to modify them goes only as far as extensions are supported, and often once you’ve extended those solutions all bets are off in terms of future updates and compatibility. When one of your needs requires changing functionality buried deep within the vendor’s library, you’re faced with bad and worse choices of waiting on the vendor to provide a solution or (most often the case) rewriting large parts of the library into your custom code, building towards Solution B. What starts as a simple, clean platform built on vendor dependency libraries almost always becomes a mess of overrides and workarounds as you layer on your requirements. Software accelerators provide a much more flexible and future-proof alternative.

The first three to six months of your project will largely determine whether you end up with a solid, extensible, maintainable Solution A, or the opposite (and unfortunately more common) Solution B. Don’t be short-sighted. Avoid the above pitfalls and you will enjoy the return on investment in your digital transformation for years to come.