DevTeam.Space Product Development Blog

Explore our in-depth product development tutorials and new technology announcements published by our software development experts

All articles

How To Effectively Manage An MVP In Your Enterprise Company

In our guide “How to make your organization Agile?”, I explained how the concept of the “Minimum Viable Product” (MVP) is key to Agile.

Enterprises that have worked with traditional business processes for decades face big challenges to transform themselves into Agile-driven organizations. Managing MVPs is one such challenge.

How to effectively manage an MVP in your enterprise? Read on, as this is exactly what I explain here. Let’s start with a recap of a few basics.

Contents

What is a Minimum Viable Product (MVP)
Why MVPs matter to Agile
The benefits of the Agile MVP approach
MVPs in the enterprise context: “Minimal Enterprise-Viable Product” (MEVP)
Managing a minimal viable product in an enterprise context
Planning to build a strategic MVP in your enterprise?

What is a Minimum Viable Product (MVP)

A “Minimum Viable Product” (MVP) is a version of a new product, and the creators of it have built it with the least possible effort. You build an MVP to validate what you have learned about your potential customers.

While conceptualizing your product, you build a hypothesis about how your customers might respond to it. You also conduct market surveys to gather more information. However, none of these can replace an experiment in the market.

An MVP allows you to conduct that experiment. It might be closer to the prototype you had zeroed in on rather than the end-product with all features. Nevertheless, it allows you to gain real insights about what your customers want. Read more about MVP in “Defining MVP, MMF, MMP, and MMR”.

Why MVPs matter to Agile

The importance of MVPs in Agile lies in the fact that MVPs help the Agile teams to plan and execute iterations intelligently. While Agile project management is now very popular, its root lies in the Agile software development lifecycle model.

As I have explained in “What is software development life cycle and what you plan for?”, the Agile SDLC model involves iterations of development, testing, and getting feedback. An Agile team incorporates the feedback in the next iteration, which may be called a “Sprint” if you use a technique like “Scrum”.

However, how will you get feedback from the market? You will need to offer a product to users, even if it’s a basic version of what you finally plan to offer to your users. This product should deliver the basic functionalities it offers, which will allow users to evaluate it.

This simplest version of your product is an MVP, which the users can evaluate. It enables you to gain market feedback so that you can plan your next iteration. Read “MVP is the Key to Agile project management” for more insights.

The benefits of the Agile MVP approach

There are several benefits of MVP development, e.g.:

  • It’s cheaper to develop an MVP since it will have the most basic features.
  • Since you are not trying to create the perfect product in the very first iteration, developing an MVP app is faster.
  • Considering that you are offering only the very basic features during MVP development, you will need to code lesser. Your product support requirements will also be minimal.

These factors combine to give you a quick “Time-to-Market”, which enables you to get market feedback quicker. Read more about this in “Advantages of using a minimum viable product approach”.

MVPs in the enterprise context: “Minimal Enterprise-Viable Product” (MEVP)

MVPs in the context of start-ups dominate most discussions about MVPs, however, enterprises are using the MVP approach too. “Minimal Enterprise-Viable Product” (MVP) is a term commonly used when describing an enterprise developing an MVP.

There are differences between MVPs in the start-up context and MEVPs. These differences arise since MEVPs need to meet the viability requirements of enterprises, which are different from start-ups.

These differences are as follows:

  • Start-ups have a limited number of clients to start with, therefore, they can afford more trial-and-error iterations. On the other hand, enterprises can’t have the same leeway.
  • A start-up can start with a monolithic architecture for its MVP and later use the microservices architecture. Enterprises need to design their MEVPs for scalability from the very beginning.
  • Start-ups commonly use open-source technologies, however, enterprises need to carefully plan before using such technologies. Enterprises need to consider factors like licensing, scalability, etc.

You can read “MVP for enterprise: great potential, great danger” to learn more about this.

Managing a minimal viable product in an enterprise context

How do you go about the product lifecycle management for an MVP in the context of your enterprise? I will now explain the steps involved, which are as follows:

1. Identify the business needs and understand what the market requires

This is the very first step in your MVP journey, and this involves asking several questions. Given the importance of this step, you need the business and project stakeholders to actively participate in the required meetings.

You need to ask the following questions during these meetings:

  • Do you see an opportunity gap or a performance gap? If you aren’t addressing some of your opportunities, then you have an opportunity gap. On the other hand, if your organization isn’t performing optimally, then you have a performance gap. Read more about this in “Danger Zone: Are you Ignoring your opportunity gap?”. You build an MVP only if there’s a gap.
  • What are your competitors doing to address this gap?
  • What should you do differently from your competitors?
  • In the long term, what are the goals you want to achieve with this product?

2. The discovery session

At this point, the project team might only have a vision concerning the product or the app. The team doesn’t have any more information about it.

A discovery session is a crucial step in the MVP product development lifecycle since it offers clarity about the product to the development. Following are the characteristics of a discovery session:

  • Discovery sessions are short, e.g., they might last 2-3 days.
  • These sessions are intense, and they require effective participation from the stakeholders.
  • A discovery session might involve interviews with the business stakeholders and/or users, requirements clarification meetings, etc.
  • The team tries to understand who the users of the product are during a discovery session.
  • Discovery sessions aim to explain to the team about the users’ needs that the proposed product will meet.
  • A project team uses discovery sessions to understand the key metrics for determining whether the product is successful.
  • Discovery sessions should map the users’ journey completely. This exercise should answer questions like how a user should start using the software, the workflow of the user, what end goal the user should reach, etc.
  • You should aim to understand the value of the proposed product from the users’ perspective during a discovery session. Ask questions like “what tangible gains a user could have from the product?”.

Read more about this process in “Lean inception”.

3. Create a “Pain and Gain Map”

Now that you have concluded the discovery session, you have the required clarity about what your app should offer. While that’s great, how would you prioritize the features that you will offer in your MVP app?

Creating a “Pain and Gain Map” can help you with this. It’s a popular tool, which helps you to see where your users can derive optimal value from. You can create a “Pain and Gain Map” by taking the following steps:

  • Revisit the needs of your users, and see where they need help.
  • Categorize the pain points of the users by assigning priorities to them, i.e., which pain points are the most prominent ones?
  • Document the gains to users when you resolve these pain points. Quantify the gains wherever possible, and use detailed qualitative statements when you can’t quantify the gains.
  • This helps you to identify the most impactful features in your product, furthermore, you will be able to identify the features that have a lesser impact.
  • You should use a chart format to create a pain-and-gain map, prioritizing the features along the way.

Read more about this in “Pain-Gain Map”. With this tool, you can make more informed decisions about which features you should include in your MVP.

4. Decide on the features to include

You now have enough information on which features deliver maximum value to your users. The next step is to decide on features that you should include in the MVP, and identify features for subsequent iterations.

You can use various tools and techniques for this, e.g.:

4a. Opportunity statements:

You can create statements for each opportunity that you have identified. Include as much quantifiable information here as you can.

4b. Breakdown of features

Provide a breakdown of features you will include in your product roadmap.

4c. Prioritization matrix

Based on the importance of the features, prioritize them in a matrix based on their impact and urgency. You should include the features with high impact and high urgency in the MVP. Read more about prioritization matrix in “MVP & feature prioritization”.

The features with high impact and low urgency should be revisited, and you can do the same for the features with low impact and high urgency. You could decide to exclude features with low impact and urgency.

5. Plan your project

Now that you have decided about the features you will include in the MVP, you should plan the project. You need to adopt an approach that gives you the best chance of success. This involves the following:

  • Onboard the right people: You need to get a competent project manager (PM), furthermore, you should onboard an experienced IT architect. Business analysts, UI designers, developers, testers, and DevOps engineers are the other roles that you should staff. I recommend that you onboard a field expert development team for complex projects, as I have explained in “Freelance app development team vs. field expert software development teams”.
  • Organize the team: You should use the “Scrum” technique to organize the team, and I will talk about it shortly.
  • Decide about creating a web app, a native app, or a hybrid app. Remember that native apps deliver the best user experience to mobile users, however, hybrid apps are less expensive to develop. “Progressive Web Apps” (PWAs) fall somewhere between the native and hybrid apps.
  • Identify managed cloud platforms that you might use. “Platform-as-a-Service” platforms like AWS Elastic Beanstalk can make it easier to develop web apps, as I have explained in “10 top PaaS providers for 2019”. Similarly, “Mobile-Backend-as-a-Service” (MBaaS) platforms like AWS Amplify can reduce your mobile backend development effort.
  • Identify IDEs that you may use, e.g., Android Studio for Android development. If you are developing an iOS app, then you should use Xcode, whereas Eclipse is a robust IDE for developing web apps.
  • Use a mobile device and browser lab on the cloud, which will help you to test your app against all devices and browsers. A good option is pCloudy since they offer over 5,000 device-browser combinations.
  • Depending on your features, you could benefit from using market-leading application programming interfaces (APIs) and software development kits (SDKs). Remember to plan the architecture of the project well since using too many 3rd party APIs can introduce several external dependencies.
  • Use the right guidelines for UI design, e.g., “Human Interface Guidelines” for designing the UI for an iOS app, “Material design” guidelines for Android app UI design, etc.

6. Use the “Scrum” technique

We at DevTeam.Space recommend that you use the “Scrum” technique to manage the MVP development and further iterations. It’s a tried-and-tested technique for Agile projects.

You should do the following:

  • Organize your team as a “Scrum team”, which is a cross-functional team where developers and testers work together.
  • The PM should perform the role of a “Scrum master”.
  • The team plans “Sprints”, i.e., iterations in meetings called the “Sprint planning meetings”.
  • Project status reporting takes place in meetings called the “Daily stand-up meetings”.
  • The business stakeholders review the app in “Sprint review meetings”, where the team demonstrated the app.
  • After the business stakeholders approve a sprint, the team conducts a “Sprint retrospective meeting”. It’s a lessons-learned exercise.

Read more about this technique in “How to build a Scrum development team?”.

Planning to build a strategic MVP in your enterprise?

While this guide will help you to manage the process, remember that enterprise software development tends to be complex. Consider engaging a reputed and trusted software development company for such projects. Read “How to find the best software development company?”, which will help to find one.