How to detect feature overload in your MVP and fix it?

MVP (sometimes wrongly taken for a minimum valuable product) is a Minimum Viable Product that allows you to get meaningful feedback from users. In other words, this is a hypothesis application, launching which you expect confirmation or refutation. The purpose of such an application is to collect information, not to conquer the market or generate profit. Based on the information gathered, your team either gets the green light to dive into the development of a full-fledged project or switches to another hypothesis. However, MVP's initial failure does not have to lead to a complete rethinking of the idea and approaches to its implementation. Thoughtful analysis of the feedback gained can reveal the shortcomings of conceptually successful features and, after making some edits, you can return to testing the updated hypothesis.

Sometimes the purpose of building an MVP isn't obvious. Remember, an idea is not the target result. Thus, stay patient and trust the battle experience of a released prototype, albeit with minimal functionality. By running MVP, you can:

• Save money without investing in an obviously prospectless project;
  
• Check if your product actually interests potential users;
  
• With the help of iterations, find out which direction of development will be the most optimal;
  
• Collect a base of potential customers and find early adopters of your product.
  

Lack of understanding of the strategic importance of MVP testing is not the only problem encountered when developing a project. Sometimes we observe a completely opposite situation: the client wants to implement a significant part of the planned features or sometimes all of them. This approach completely violates the very essence of MVP and often leads to:

• a significant delay in time-to-market;
  
• doubling the work by changing the additional features that didn't meet the expectations;
  
• running out of budget faster and not meeting your targets

Any application claiming to be an MVP should be first of all lightweight and fast in development, so a 2-3 months period should sound reasonable. If the team feels that this time will not be enough to implement the intended functionality, then a good decision would be to revise the priorities or MVP's terms of reference.

Another indicator of project overload can be excessively large tasks. Basically, we recommended spending no more than 3-4 days to complete an average task. In some particular cases, this number can rise up to 8-10 business days. If you have more and more such "particular cases" in your schedule, then it is time to think about breaking them down into smaller pieces, or, if this is not possible, then raise the question of the need to perform this particular task for MVP creation.

Here's another good way: answer the question of how many tasks you need to complete so that the goal of building an MVP is achieved. If there is no exact answer and in general it is rather difficult to formulate it, then it's the first sign of trouble. Optimized MVPs must always stay focused. Without a precise objective, you won't be able to realize when you've crossed the line and begun overstuffing your MVP with features.

Make sure you genuinely know which features are created to meet the needs of your key user group. Before you start building an MVP, you should have a really good understanding of who your key end-users are. The very rationale behind creating an MVP is that it should allow you to verify your key assumptions with a certain client group, as opposed to trying to cater to the needs of all potential clients. In case you widen your target audience too much you immediately get into a trap of adding excessive features.

The simple answer is "figure out what do you want to achieve and prioritize your features". Never try to make your MVP perfect – better focus on the functionalities that are absolutely necessary. Down below we provide a few recommendations on how you can slim down your overstuffed MVP:

Decide on what of your product assumptions are crucial to the project. Think about what actions you expect your users to take, then remove any product assumptions that don't meet those criteria.

Define the critical purpose you are releasing the MVP. Just ask yourself why do you need it? 3 months of development requires a reasonable amount of resources and you really want to answer that question clearly before you spend them. When answering, be as specific as you can be and avoid vague formulations – they will only deceive you with a false feeling of going in the right direction.

Create a mind-map for features. Put yourself in your client's shoes and write down the steps as you would work through them. Figure out those features lacking which your project will become useless and build a hierarchical table of subtasks and support features. To make it more representational and effective, you can use different online tools but traditional paper and a pen will do as well.