4 MVP design challenges a business analyst needs to solve

written bySenior Business Analyst, EPAM Anywhere

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.

What does an MVP stand for?

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.

Wrong and right MVP schema
Source: Oksana Kovalchuk - Medium.com

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.

How a business analyst can address MVP design challenges

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.

Challenge #1. Understanding the business domain

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:

  • Identifying subjects along with their characteristics and relationships between them
  • Learning terminology specific to the business domain
  • Identifying objects along with their characteristics and relationships with the subjects
  • Detailing business processes and how they relate to objects and subjects
BA knowledge areas scheme

Challenge #2. Defining the MVP roadmap

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:

  • Product vision definition. We used Product Vision Board (PVB), a popular visual tool that allows presentation of the vision in a comprehensible way, while also answering key questions so the team can understand and follow the vision.
  • User personas definition. User personas are fictitious representations of the users of a product or a service. They help the team understand the users’ motivations, behaviors, frustrations, pains, and needs.
  • Story mapping. Developed by Jeff Patton, this technique seeks to identify a series of essential functionalities that ensure that the product fulfills its vital functions.
As an output, it was easy to prioritize features with the MoSCoW technique, because we were able to put each feature in the most, should, could and would categories based on cost, time, and scope constraints.

Challenge #3. Writing user stories

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:

  • Defined and clarified system boundaries by drawing a context diagram. This helped me gain a better understanding of the flow of information between the system and external sources.
  • Identified legacy systems to be consumed and why they were required.
  • Helped with refining requirements and analyzing their dependencies and impacts.
  • Participated in meetings arranged by the UX/UI design team to enhance use cases.
  • Made a service map to identify all services that would be consumed for different features.
  • Requested technical documents (ACLs, WSDLs, response examples, error code documentation).
  • Documented and visualized the MVP definitions that could be useful to the team and that hadn’t yet been centralized in any way.

Challenge #4. Dealing with PoCs

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:

  • Minimizing and optimizing costs and time
  • Getting user feedback faster
  • Possibly generating first users after the MVP release
  • Attracting investors’ attention

The benefits of PoCs include:

  • Attracting initial investors
  • Saving time
  • Assisting selection of the right technology
  • Opportunity to stay one step ahead of the competition

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!

written bySenior Business Analyst, EPAM Anywhere
get the latest tech insights, career growth, and lifestyle tips right in your inbox