Behavioral economics gives names to the two biggest phenomena affecting the pointlessness of MVP in replacing legacy systems: endowment effect and loss aversion. Both are at their highest when people are using a system for their daily work often for multiple hours a day. It has become wrapped up in their identity at work; in many cases, it is almost seen as synonymous with their job and the sense of self-worth they derive from that job. Their sense of ownership is strong.
Let’s break down these two phenomena and also look at some of the strategies in overcoming them.
Endowment effect
This was identified by Richard Thaler as part of his groundbreaking work in decision making. Essentially it states that people are more likely to retain an object that they own than acquire a similar object (either in value or appearance). To bring it closer to home for many of us, think about your relationship with the various bits of tech (software and hardware) that you use daily and the various conversations that you’ve had around why something that you own and use is better than the other thing. You imbue what you own with more virtues by the fact that you own it, and as mentioned earlier, people feel a sense of ownership for these systems even if they didn’t buy them with money.
To overcome this, you need to try and transfer that feeling of ownership to the new, replacement system. There are two great techniques to start that process: ethnographic research and co-design workshops.
Ethnographic research, the act of going to people and observing how they use your existing system in the broader context of getting their jobs done, gives incredible insights. Even just the act of listening to people, spending time with them and watching them work helps to create that sense of ownership, that sense of ‘belonging’, to the replacement system.
Co-design is a step further. It draws on people’s expertise and broader experience to illuminate a possible future. Co-design workshops allow people to have input into how things will work and gives them some understanding of the tradeoffs and challenges you’re facing. They begin to feel that they are a part of the creation of the tools that they will be using.
Both these techniques are great, however, you need to follow up with regular communication and relate that communication back to what you’ve seen and heard. People need to see that their input is being directly referenced to truly start that transfer of ownership. Even better, if you can reinforce the message with a tangible expression of what people have said, a piece of working software, that you can then evolve and build on based on people’s feedback.
Great, you might think, sounds like the perfect candidate for an MVP. Something small but still providing some of the functionality that they need but in a better way. Excellent idea, except for this nasty thing called ‘loss aversion’.
Loss aversion
As Kahneman and Tversky found in their research, you value your losses much more, around two to four times more, than any potential gains. Given what you generally have is a fully functioning system, anything less than that is likely to be perceived incredibly negatively. You only get one shot at that first impression, if it’s not great you’re going to spend a lot of time overcoming the ‘noise’ of people being much more vocal about their losses than their gains and it will make subsequent releases harder.
What can you do about it? Find ways to transfer psychological ownership as discussed earlier, communicate benefits that place your replacement system in a new paradigm, minimize losses, present options - people are more likely to take a riskier approach (and anything new is riskier) if ‘retain’ or ‘acquire’ are not the only two options.
SPV as an alternative to MVP
So what is it if it’s not a minimum viable product? I like to think about it as SPV or ‘shortest path to value’. This is a way of decomposing the needs of the new system(s) into a roadmap that aims to get valuable ‘chunks’ of functionality into the hands of users as soon as possible and with as minimal an impact on their existing work as possible. And then to follow that with the next valuable ‘chunk’ as quickly as possible so that people are reassured that they are not losing functionality overall. In enterprise, if functionality doesn’t appear in the first release it will never happen. Your roadmap should show them that they don’t have to fear loss because overall they will get what they need, and then deliver to that promise.
There are a number of models for establishing an SPV and the one that you choose will be dependent on the exact circumstances of your organization, technical landscape, systems being replaced and the ‘jobs to be done’. Some of the common patterns include:
End user segmentation
A useful pattern if you have little overlap between end user segments and each one uses a subset of the end functionality. A common use of this pattern is for any system where the organization wants a ‘whole of customer’ view but individual departments only need to interact with a subset of the information and/or functionality. Establish a longer term vision that incorporates the broader needs but test out that vision through building for the smallest set of needs first.
Process segmentation
Useful for systems that cover longer processes with no clear cut, stable boundaries around who will be using what part of the system. Many acquisition and fulfillment systems fall into this pattern. In developing a roadmap look for the natural breaks in the process, the times when people might batch up work to be done together, or hand it over to another person to do, e.g. looking for leads as opposed to fulfilling existing orders. These ‘breaks’ indicate natural replacement points; places where you can take that segment of the process and replace it with the new approach.
‘Competitive’ system
This is a good option if you’re looking to capture a new market or a different segment of an existing market. It’s particularly useful if you’re making a large shift in the underlying model of how the system works. Essentially, you create a much leaner new system that achieves many of the same goals as your existing one, incorporating all that you’ve learnt from your legacy — keeping the good, smoothing out convoluted flows, and focussing on the most important feature you may have created in your old system. You target your new system to your new audience. With this audience, you don’t have existing pre-conceptions you need to manage. Once you have success stories with your new end users, you can use this to start trialling it with the existing users and gradually move them across.
Whichever model works for you, creating a roadmap to deliver against it is a journey in itself, of exploring the tension between the old and the new, between losses and gains. There is a need to reassure people that you can deliver early and often while making every release meaningful and valuable across the user, business, and technical landscapes. It’s a tricky juggling act, just don’t feel pressured into creating an MVP, it’s unnecessary and a distraction to what your real goal is — how to deliver value across the board as soon as possible.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
