What to do when a fake MVP is unmasked?

Tips and tricks to rescue your product

As a designer, you may be required to work on the scope of a project which is nothing more than a set of priorities wrongly presented as a “Minimum Viable Product”.

The MVP concept can be misused to cut out anything that appears too complex or for including an excess of features to guarantee user satisfaction. The main victim of this is the user experience, which will subsequently be defined by the wrong rationales.

As a last line of defense before starting development, designers should have good reflexes to identify these situations. It’s even better when you can help re-establish consistency on a product.

One could say it is not the designer’s role to frame product prioritization. Although this is not completely wrong, as designers, being user-centric means caring about the product’s outcome, and therefore helping get it back on track when misconception risks are detected. We could even go further and act as product design facilitators.

Let me develop this further.

A fake MVP can hide a lack of maturity on a project which is not ready for the design process. When there is pressure to come up with a good idea during the UX phase, product owners can rush through the scoping phase, leaving designers without clear documentation to start.

Before falling into the trap of prototyping based on various uncertainties, first you should refocus the project onto Product Framing and User Research.

1. Identify the uncertain elements

An issue often observed with MVP’s is when they contain elements whose design or technical feasibility are uncertain. You should be able to establish how confident project stakeholders are on what the business wants to deliver.

To do this, you can carry out an exercise using the assumption matrix. Define each element based on two factors. First, confidence: is the evidence for it strong or weak. Second, priority: is it important or not. Then use the matrix to place each item where they lie along the x and y axis.

The area which is both important and has strong evidence will likely become part of the MVP. The zone which is not important and has weak evidence will likely be dropped from the first version.

The red zone, corresponding to the important stories but with weak evidence, will be the most sensitive. These will require the project stakeholders to launch further studies that may delay delivery if the content cannot be dropped from the first version or split into smaller feasible stories.

I worked on an application whose product owner exposed a lot of “must-have” features to deliver with a strict timeline. When starting the design process, I felt doubts on development side regarding the feasibility of some features. Also considering my design assumptions, I convinced the project to carry out an assumption matrix workshop.

As expected, this exercise clarified priorities and highlighted the need for further analysis on uncertain items. At the end, the PO faced a real dilemma: choosing between delaying the MVP to include all his initial priorities, or reducing its scope which was too big. The scope has been finally reduced.

2. Split and distribute value across the whole experience

Story mapping can help maximise user value of the initial solution. It helps to prioritise user stories, ensuring that the most important features are addressed first, keeping the focus on the end-users.

It’s a very powerful concept if it’s used in collaboration with business and technical experts. It also has to be used at the right time, ideally after defining user flows and wireframes, to help stakeholders have an accurate view on the product.

We break the map down into thematic sections based on the different stages of the journey. This ensures features will be prioritised across the whole user experience.

Representing the different versions visually allows us to easily identify prioritisation conflicts. For example, when an item has been prioritised in version 1, but is dependent on an item placed in version 2, it will probably be dropped from the MVP.

When it comes to splitting the product, if the first version doesn’t bring any value to users, then don’t plan to deliver it. Either delay it so that you can add the missing values. Or review your slicing in order to be more accurate in the value you’re bringing without being forced to deliver too big an MVP.

Be careful not to over-anticipate the content of future versions. The MVP is the most essential, and all subsequent versions will be confirmed by lessons learnt from real usage.

I started a client portal project with a detailed scoping document, including a pre-defined MVP based on design thinking concepts. Presented in an Excel file, project stakeholders didn’t understand that the sum of these features listed did not equal a consistent product but was simply a features wish list.

Starting the user flows, the product owner quickly realised that their MVP version was outdated and required additional features and screens. After validating the wireframes , we conducted a story mapping workshop to refine our MVP, focusing on key user paths. The workshop led to a much more consistent MVP, facilitating final design work and clear communication with all stakeholders.

I got good feedback on the story mapping exercise, mainly from IT teams who regretted not having it earlier to avoid useless studies and pricing work.

3. Review your User Research

If no value is clearly identified in your MVP, you should put the design work on pause and refocus on the value proposal with your project stakeholders. When elements such as personas or user flows are neglected or even absent, it is likely the project won’t be targeted at solving the real problem.

These issues, which can be spotted at different steps in the design process, challenge the product owner if they have a certain solution they want you to provide. Whilst you don’t want to find these issues during usability testing, it’s still not too late fix them.

Don’t hesitate to refine the basic User Research scoping set with your stakeholders. It can help to reveal if the initial user research exercises were not completely understood or if you’ve missed something on the user needs.

I worked on a document exchange service with customisable security levels. Relying on the scoping set provided, I start designing without being challenged too much by the product owner. However, during usability testing, a key user revealed that the proposed solution was useless because it did not work with external clients, which represented 90% of their interactions…

The PO prioritised only the internal perimeter which was easier to develop. Not being able to readjust our product on time, we delivered the “MVP” as designed, knowing it wouldn’t fully meet user needs until future iterations.

4. Review your learning plan

Before I became familiar with the concepts of UX metrics, I used to rely mainly on the business KPIs provided by the project. I then understood that the level of new users onboarded, or the increase of the Net Business Income was not always synonymous with a good user experience.

On UX projects, we now push product owners to think about the objectives they want to achieve by contributing to a design process. These objectives can be related to Adoption, Engagement or Retention and they are key in identifying the value brought by the design approach. The signals and metrics you’ll associate to the objectives allow you to measure the success of the MVP.

Without this sort of learning plan, you won’t know with accuracy if your goals are being achieved and what adjustments are needed to improve the user experience. Make sure the plan is established before going too far with your design work.

If the project team is not willing to invest much time on it, propose using at least basic metric indicators to measure adoption and engagement on proposed features. This will help to frame the MVP priorities by focusing on usage that brings you closer to achieving the project’s objectives. It will also prevent working on unclear priorities after you deliver the MVP.

Don’t hesitate to explore documentation on Google HEART framework if you want to learn more about measuring user experience.

I’d been asked to work on the web analytics for an application whose marketing team complained about low subscriptions rate. The project delivered the MVP while being totally blind to metrics. Once accessing the analytics, they were lost in a mass of data they didn’t know how to figure out.

By defining a conversion objective, they were now able to raise relevant questions about user profiles, traffic sources, impacts of marketing campaign… This allowed us to isolate key metrics to track where the experience was broken. This finally led to adjusting the screens to better place these subscription options in user paths.

5. Proof-of-concepts

If it’s too complex to launch the previous reframing phases with your project, you can help to visualise better the targeted solution.

Ideally this should be done through wireframes. However, if this is not enough, you may need to go a little bit further in a proof-of-concept phase and reflect deeper on how the future solution can be materialized. By seeing screens, features, data , buttons, filters… products owners and developers can better measure the costs and stakes of developing a solution and the gap between what they wish for and what is feasible in the short-term.

As the goal is to help projects take a step forward with their solution, don’t be too picky on the prototype details. High-fidelity prototypes should only be done for the confirmed MVP experience, when considerations of functionality, technicality and design are certain. For the future targeted elements, wireframes or proof of concepts often suffice to visualise the concepts.

A colleague initiated a design process focusing on a single business use case considered an “MVP”. The use case represented was the most frequent faced by users, so the product owner thought it would provide the most essential value of the product.

Due to delivery constraints, they didn’t want to invest on user research, assuming the first use case could be easily replicated across other business areas. Anyway, to ensure product scalability my colleague proposed proof-of-concept screens, illustrating the solution’s efficiency beyond first perimeter.

These screens exposed a global user experience that they had to consider in order to reach their goals… This helped a lot on the prototype iterations, allowing discussions about value, scalability, and feasibility considerations, that finally ended up with a much better consistent MVP version.

Conclusion

I have uncovered several ways to help avoid your product starting out with a bad structure based on a fake MVP.

My main advice is to focus on Product Framing and User Research practices while staying agile in your approach to consider your company’s and project’s context. Don’t hesitate to go directly to proof-of-concept screens if you feel this is the most appropriate solution to unblock the situation.

In the end, if it’s established that the product design is at risk, take advantage of your perspective as a designer to be persuasive and convince project stakeholders to adjust their strategy.

Thanks for reading! Don’t hesitate to drop a comment and share your feedback.

Additional editors: Honor Pattisson and Morgane Peng

This article concludes a series on Minimum Viable Products, which started with the publication ‘How to Unmask fake MVP during the design process’.