Carlos Cardona, Senior Business Analyst at EPAM Anywhere, shares his personal experience of tackling MVP design challenges that he faced as a business analyst on one of his past projects.
Many companies and entrepreneurs understand that releasing the first version of a product without testing it on real users is risky. This is why there is a minimal viable product (MVP) being designed somewhere in the world every day.
When developing an MVP, both the solution (what the user needs) and the problem (what the product should do) are unknowns. Getting it right requires an iterative process that combines hypothesis tests and experiments with data gathering and feedback to identify the user's problem. As part of the process, prototypes and multiple versions of the product are developed, and user feedback is collected and incorporated into successive versions of the product.
That is where business analysts come into the picture. Below, I explain the four challenges that I, as a business analyst, had to solve during MVP implementation for a Colombian company on a project I worked on before joining EPAM Anywhere.
A minimum viable product (MVP) is a version of a product that allows the team to obtain as much validated information about users as possible, with the least amount of effort. This process allows for rapid quantitative and qualitative analysis of the market response to a particular product or feature.
An MVP provides only those features required for demonstrating the product to the user. The ultimate aim is to avoid developing products that users won't find valuable, and to maximize the amount of information obtained about users with the limited resources available.
It is important to treat an MVP as a completed product in its own right. Users should receive a solution that is functional, reliable, usable, and attractive. The features included should be just enough to fulfill the product's purpose. Any advanced functionality should be excluded from the MVP scope to save time, effort, and money. An MVP, however, is not only about basic functionality; reliability, usability, and UX are also critical components.
Despite its name, MVP is much more than just a product. In reality, it is a process and a strategy for creating and selling a product to a group of users. MVP is a continuous process of generating ideas, and developing and presenting prototypes, in addition to collecting, analyzing, and learning from data. It also requires customer interaction, defining metrics, and analyzing results. If your goal is merely to build something quickly, you probably don’t need an MVP.
As IT consultants, business analysts have expertise in both business and technology. This combination of skills helps organizations achieve their goals by translating business needs into clearly defined requirements. Business analysts should strive to minimize the gap between what users need and what they get, while delivering the highest business value.
Before joining EPAM Anywhere, I had the opportunity to work as a business analyst on a crowdfunding product for small businesses in Colombia. Its MVP implementation presented many challenges. Below, I share a bit about this experience and some of the decisions that I made to address those challenges.
The first challenge I faced was to understand the business domain. I was dealing with an industry that was new to me, with its own business rules and objectives. I gradually began to participate in meetings with the client, to understand their needs and to gather information about business processes and the relevant technical documentation.
This wasn’t enough for me. I felt I needed to dive deeper and study the business domain as a whole by:
The second challenge I faced was participating in the definition of the MVP roadmap and the prioritization of features. For me, this was something new, since I couldn’t yet be certain which activities and tools would help us achieve our purpose. With the help of the technology provider that participated in the construction of the MVP, we completed three activities that helped us determine the critical functionalities that we wanted to include in the MVP:
Next, I had to write the user stories. This project was the first time I worked according to the agile methodology. Sprint after sprint, I improved my writing so that the team understood what we should deliver and for what purpose. I always wondered: how do I get the details in the user stories right?
To improve my user story writing skills, I did the following:
Finally, the last challenge I faced was supporting the process of creating proofs of concept (PoC).
We needed PoCs to help us choose the best third-party solution to integrate with. It was essential for me to understand how the third-party APIs worked, how to send requests, and how to interpret the responses obtained. At this stage, I also had the opportunity to use tools such as POSTMAN and SOAP UI.
It’s critical for a business analyst to understand the difference between an MVP and a PoC. An MVP can be determined by many PoCs, but they are not the same thing, even though they can be combined during product development.
A PoC is a very small internal project carried out to evaluate the feasibility, scalability, and profitability of a future project. It is used to verify technical concepts, such as the method to be applied, technology, or integration. It is a fundamental step in creating a prototype, and can be applied to different sectors to analyze their market potential and calculate potential profitability.
An MVP is the foundation on which PoCs work; it contains viable features and provides relevant information for future business decisions. A PoC gives us an idea about a product’s market acceptance and potential growth.
To sum up, the benefits of MVPs are:
The benefits of PoCs include:
I hope sharing my experience will help you on your own journey, even if it’s your first ever MVP design project. Wishing you luck!