This is the 4th and last post in the series about why the MVP method, as described by Eric Ries in The Lean Startup, is more challenging than it first appears. Many organisations, large and small, refer to it. In fact it’s sometimes hard to find product road maps or project plans that don’t make reference to an “MVP.” However, few are able to apply even the most basic tenets of the MVP method, and instead fall back on traditional development paradigms which results in what I call the MPP.
Previous posts discussed the organisational and personal obstacles to applying the method. Let’s look at the technical challenges. I find this is something that is often glossed over, probably because the method is based on startups, which may not have to deal with as much legacy complexity as larger organisations.
The first hurdle is often the technical environment. Organisations that have existed for decades struggle under a heavy weight of technical and business complexity. Developing new products in this environment invariably leads to dependencies on other products, teams, systems and departments.
The method that Eric Ries describes demands quick iterations. You have to build, learn and adapt in a rapid fashion. This works in a small start up where the environment is relatively simple, or should be.This is very hard to do when your product relies on a collection of systems and teams for some of its functionality. Think of a bank trying to develop an app for corporate banking. The app might have to get customer data from one place/system, account data from another, loan info from somewhere else and so on. These systems may be developed by other teams, or worse, by 3rd parties, and may be further complicated by acquisitions and ongoing system replacements or modernisation.
The second technical challenge is that the methodology uses a “scientific” approach; you should be relying on data more than expert analysis and opinion. You should be constantly refining and adjusting your plans based on user data, customer data, performance data coming from the use of your product. If your product doesn’t provide this data in a timely fashion or if you aren’t confident in the reliability of that data, you’re in trouble.
The third and last reason I’ll describe is more cultural than technical. Development teams often don’t like refactoring or revisiting the same feature or code multiple times, and will quickly blame the product owner or manager for not making up their minds or for being incompetent. This is partly the “I know everyone else’s job better than they do” phenomenon, which is not exclusive to software developers. I also call this the Ayn Rand syndrome, but that sometimes gets me in trouble. However, it’s also because in general developers want to build new things and solve new problems.The maintenance of existing features is often delegated to junior developers, partly as a way for them to learn but also because it can be tedious reviewing code someone else wrote and it’s not as exciting as putting your stamp on a new feature.
The solutions to these challenges are not simple, but can be summarised fairly quickly:
Remember that the Lean Startup methodology revolves around building, measuring and learning. Eric Ries describes this learning as conducting experiments to understand your market and customer, but if you are working in a very complex environment, you may also have to consider experiments for your team to understand the technical challenges.
Work with your team to identify unknowns or technical risks and plan to test these as part of your build-measure-learn cycles. Don’t fall into the trap of planning your architecture in advance though. Keep an eye open for unknowns and try to avoid having too many in one increment.
Focus on reducing complexity. Easily said, harder to do. Find ways to simplify, preferably by removing things that aren’t delivering value, not rebuilding them or refreshing them. Within your product, make sure your team considers refactoring part of every effort.
Focus on data first. If you want to use the MVP method, you have to rely on data, and therefore that data has to be reliable and readily available. If you find yourself with a product that doesn’t provide you with the data you need, that should be the first thing on the road map, before any major features.
Be transparent about the data and your decisions. I’ve harped on this in a few posts now, but there is a reason that the Agile Manifesto recommends collaboration over contract negotiation, that one of the 3 values of Scrum is transparency, and that one of the 5 principles of the Lean Startup is Innovation Accounting. It builds trust, it encourages input and it ensures that everyone involved is part of the solution.
Why are requirements so hard? 