Let’s all play a game of buzzword bingo. But instead, let’s name those words that denote practices which pragmatically improve our understanding of how we work, without resulting in confused shrugs. I’ll start: The ubiquitous MVP (minimum viable product) has wedged itself into our ways-of-working, thanks to the likes of the startup/lean/agile revolution. It made sense to software developers racing to push a new digital product/feature to market. It didn’t, however, make a whole lot of sense to those annoying designers– the ones that want to understand a product’s place, its context, and its purpose along the customer’s journey. It made even less sense to customer strategists– the ones who need to understand the position of an MVP in context of the overall direction, objective and vision of the project and company.
The MVP-and most rapid methodologies born from startup land- work great when you have 1. A small team, 2. Few constraints (other than resource and money) and 3. Zero legacy (ie: building from the ground up). Pivoting in this scenario is organic, and the MVP enables start-ups to do so in line with the product vision, as Eric Ries had intended.
For large organisations and complex ecosystems, the startup model begins to break apart. In these contexts, the minimum viable product approach becomes less viable as a way of working. It may rapidly push out features to market, but it often eventually loses sight of the bigger picture that the MVP approach is aiming to contribute towards, resulting in some form of design/tech or desirability debt that never gets resolved. The agile manifesto is unfortunately lost in many change management programs, with product owners and sponsors simply pushing for faster waterfall initiatives guided within a sprint-based approach. As such, product roadmaps are generated with features and initiatives laid out over a 3–5 year horizon for delivery. Or, the agile methodology results in initiatives and features that are continuously iterated without any direction around why this continuous change is necessary. Now, what is the problem with these scenarios?
- It relies on a product-centric view of delivery to market
- It sacrifices human-centric and holistic opportunities found across the end-to-end customer experience
- It disables large companies from being able to pivot meaningfully and strategically with agility, frequency and consistency towards the strategic vision
- All of the above
The common risk with lean/agile methodologies is it is inherently product-centric. The terminology (despite promoting customer collaboration) still remains focused on the iterative delivery of a product and its features, losing sight of the position and impact of the product across the customer value chain.These issues are magnified when placed into large organisations. What results is a distinct gap between the now and the future-state, with teams rapidly pushing a huge backlog of MVP’s to market and losing sight of the strategic vision and overall impact to customer experience.

A Minimum Viable Experience
Like most terms du jour, the minimum viable experience (MVE) is not a brand new concept. It emerged circa 2013 as a result of the startup/Agile boom and the broader vernacular around the experience economy. The MVE was a logical love-child, however, little development has been proposed around what it is, what it means and how it could be used. An MVE is a tactical, flexible strategy. It bridges the gap between execution and static strategic plans that often collect dust on a shelf. An MVE embodies your strategic vision, and brings it to life.
The most bang for your buck with an MVE
After much trial and error, I have found myself landing on a structured approach towards adopting the MVE concept for the assistance of developing agile customer and design strategy in large organisations. Using an MVE for strategic direction and continuous delivery requires four key steps that blend design and agile approaches:
- Identify your target customer and conduct baseline research (if you haven’t done so already) to understand your customers’ current and ideal experiences with your product-service
- Develop a set of experience principles from your customer research
- Write up an end-to-end future-state storyboard based on your experience principles
- Review and revise this future state experience with your key stakeholders to assess timing, tech, delivery, viability, etc
- Identify your key MVP features for design and delivery across your MVE
- Identify the date by which all of the MVP features that support your MVE could be delivered. Re-shape as necessary if this end-date is too far-out into the future. I recommend sticking to 6 month MVE cycles
- The MVE becomes your interim strategic objective that aligns to your vision and/or future state direction and experience principles, allowing you to reframe and pivot every 6 months if needed. It is a strategic package that knits together your MVP’s in a meaningful way
As you may have guessed, the MVE steals methods and approaches from service design practice. This is also due in part to the common redundancy found when producing customer journey maps and/or blueprints in fast, agile working environments. Like strategic roadmaps, a service blueprint is often a great glossy vision of the future with little tactical methods on how to resourcefully and strategically implement the end-to-end service experience. After the initial stakeholder showcase, these artefacts ultimately collect dust.

Now for some news..
This is a high-level breakdown of how to approach and apply the MVE concept for strategic planning and design delivery inside of a lean/agile way of working. There is a lot of detail that is obviously left out, including how to visualise your MVE and update/iterate the strategy in line with sprint cycles, agile ceremonies and corporate strategy. It would be far too cumbersome to describe this strategic MVE approach in a blog post, so I am currently detailing the MVE as part of a book-slash-guide on strategic design practice.
Yes, yes, I know…not another design book. I had debated whether to contribute to the already saturated opinion pieces published on design. To be honest, part of the drive for publishing is to formally document all of the learnings, readings and practices I have accumulated in my head. In addition, I am not only time-poor but impatient- particularly when it comes to reference material to assist with day-to-day practice. Thus, no wordy vignettes or self-congratulatory case studies that omit useful details will be found here. This book will be fast, factual, honest, relevant and to the point.
So please, email or comment what you are frustrated with or would like to see in a design book, and one focused on design strategy.