Minimum Viable Product In Custom Software Development

How to make sure the results are in line with client’s expectations

It is not uncommon that clients’ expectations are not met by the software development service provider. MVP development, if not done right, can lead to misalignment in expectations and disappointment in the final result. How to avoid this? At what point does the problem arise, on whose side, the customer’s or the contractor’s, how to prevent it? I make a case for lean/agile practices in custom software development and share recommendations on how to mitigate risks in such situations.

MVP Definition

A minimum viable product (MVP) is a product with just enough features to satisfy early customers and provide feedback for future product development.

Gathering insights from an MVP is often less expensive than developing a product with more features, which increases costs and risk if the product fails, for example, due to incorrect assumptions. It may also involve carrying out market analysis beforehand. An MVP can be part of a strategy and process directed toward making and selling a product to customers. It is a core artifact in an iterative process of idea generation, prototyping, presentation, data collection, analysis, and learning. One seeks to minimize the total time spent on an iteration. The process is iterated until a desirable product/market fit is obtained, or until the product is deemed non-viable.

How do you determine the success of an MVP? An integral part of an MVP is the business hypothesis. MVP is the vehicle to test it. It enables the learning and provides the information to make an informed decision, whether to develop the product further or stop altogether.

What is an MVP hypothesis? And how do you know if it has been verified? In basic terms, a business hypothesis is a statement describing the customer segment, the problem they face, what the proposed solution to that problem is, and provides indicators that will allow gauging whether the hypothesis is true or not.

The idea is to test a business hypothesis with minimum effort and within the shortest timeframe. Although the average timeline for MVP development is 1–2 iterations (2–4 weeks), in some instances it may take longer. There is no set rule. The provider of software development services helps the client to shape the vision of the product. MVP is the first step towards that vision.

Note: It took us 4 months to develop the MVP of this product. Even though it took longer than “average” the product is showing a steady adoption by the users since it was launched (we know it because we have been tracking the metrics) and the investors provided funds for further development.

Early adopters

The product may have a multitude of users in the future. At the beginning, however, one should focus on early adopters. They are loyal and accept releases with minimal functions, and at times, architecture that is far from ideal. They are willing to provide valuable feedback and are eager to be the first ones to use the product.

A typical mistake is adding and developing functionality for every type of potential users. Economically, it wouldn’t make sense to do so. At this stage, we do not know which functions users will need and indeed use. Customer development methodology helps to shape the list of functionality and product features that will improve the bottom line.

Example

Let’s look at a hypothetical situation that unfortunately happens all too often in custom software development in Russia. With this example, I’d like to illustrate the following.

1. What typical mistakes I still see people do when developing an MVP.
2. What role hypothesis, metrics, and user stories play in expressing an MVP.

Meet Ivan and Oleg

Ivan is the head and owner of a private custom software development. His teams are fully staffed and pose all the competencies to carry out a software development project.

Oleg works for a medium-sized data-centric company that successfully launches products in its niche through well-tuned sales channels. The company sometimes outsource new product development.

Oleg and Ivan have built a trusted business partnership. Oleg and his team use Ivan’s company services quite regularly.

A need for a new product emerged in Ivan’s company. They needed a monitoring system, which would be used by the company employees. However, the experienced managers knew they could potentially take the system to the market to create additional revenue. Once Oleg had gone through the process of securing the budget for product development, he signed the contract with Ivan. (In this article, I briefly touched upon what to look out for in a software development service provider)

Now, to make my point, below I describe two approaches that may take place when working on a product. I admit the examples may come across as somewhat superficial and there may be a lot of blank spaces. But I intentionally draw the reader’s attention to the execution of the User Stories and the value of the final solution.

Approach #1

The business and system analysts interviewed Oleg to establish how he saw the realization of the functionality and draw a list of system requirements. They were asking questions that were focusing on the client’s understanding of the company’s needs and how the system should work: “How do you think the system should be realized?” and “In your opinion, what this function should look like?”

How they went about documentation

They also studied and described the various systems deployed by the client. And based on obtained information they put a Technical Specification Document which contained the following sections:

• the list of devices and protocols to be integrated with the system;
• the exact number of devices in each data center;
• non-functional requirements and functional requirements of the MVP expressed as user stories.
• user stories were expressed as follows (the scope of the requirements was much greater but I will focus on a small scope for this article):

1. As an Administrator, I can download a chatbot through my mobile messenger.
2. As an Administrator, I want to receive timely alerts from the chatbot in case a critical incident occurs at the parts of the system I’m responsible for. (A definition and characteristics of a critical incident followed by an example. The server’s CPU is working at 100% utilization for a certain period)
3. As an Administrator, I want to be able to send the following commands to the system to address the critical incident, such as ‘Stop’, ‘Start’, ‘Restart’, ‘Reload’, etc)
4. As an Administrator, I want to be able to request the system to provide access to the consolidated information in graphic form, to be able to assess many indicators and make an informed decision (Indicators that could be displayed in graphic form in a web- or mobile application were also listed)
5. As a System, I need to integrate with the Zabbix server to identify its configuration.
6. As a System, I need to interact with Zabbix agents to collect information about the applications.
7. As a Senior Administrator, I want to see activities of all the administrators and see active incidents.
8. As a Senior Administrator, I want to have access to and see the history of actions of each Administrator.

In addition, Oleg wanted to have a sleek user interface.

The designers drew the chatbot conversation flow, added visualization of required technical metrics of the system, created filter lists to view a history of administrators’ activity. The overall system logic looked as follows:

Ivan was responsible for requirements decomposition and risk calculation. Once the cost estimate of the MVP development was ready, he sent it to the client. To Oleg’s dismay, the cost estimate was higher than the budget approved. Oleg and Ivan started looking into how they could reduce the functionality to keep the cost to the minimum. However, after they removed a few features, Oleg was reluctant to reduce it any further as he felt the remaining functionality was the bare minimum. Ivan checked in with the analytical data and design mockups, and could not see a way around either. Oleg kept on pushing and insisted on a discount. Ivan honored the long-lasting partnership and cut down the cost by reducing the rate.

So the development of an MVP began. Whilst the programmers were writing code, a few user scenarios surfaced. The software testers found a couple more. Oleg introduced some changes along the way. Once deployed, the system started collecting data. It became apparent that the number of scenarios and the system design had to be corrected. Although the system was working, it was not entirely what Oleg was expecting.

Outcomes

Ivan was at a loss. He had to reduce the marginality of the project. Besides, there was additional work caused by the corrections that happened along the way. He didn’t feel that change requests would have helped the situation as he was aware of Oleg’s budget and it was a fixed-price contract. There was simply no room for change requests.

Oce MVP was released, Oleg initiated a pilot within the company and was collecting the feedback from the users. He could not tell whether the MVP was successful. There were no metrics to gauge by. Product Managers could not make an informed decision as to how to market the solution effectively to potential buyers. All in all, no one had the valuable knowledge to make a call on the further development of the product, persevere or pivot.

Ivan lost money on this project. Chances are he will refuse to continue to work with Oleg after all. And Oleg will have to find a new development team, practically starting all over with them by briefing them on the project, building new working relationships and effective dialog, all of which takes time, thus costs money. This is a no-win situation that leaves both parties dissatisfied.

Approach # 2

In this instance, Ivan’s team used a product-oriented approach and did the following.

• Clarified who the potential stakeholders and users of the system were;
• Created user personas, identified their goals and motivation in using the system;
• Described the main and supporting business processes that the user base was operating within;
• Held a series of interviews.

They asked all the stakeholders questions, such as:

• Why do you need this system?
• What goals are you trying to achieve with the help of the system?
• What tasks should it perform?
• Who will use this system?
• What are the competitors in the market?
• What will happen if you never develop this system?
• Imagine that you are using the system. How would you know if it has been implemented successfully? How would you know if it was unsuccessful?

Some answers were hard to decipher: “Well, I need the system to provide better control over the staff and see the closed incidents reports”. Then the analytics had to ask additional questions and use the 5-Why technique to get to the bottom of things. “Why do you need to see the staff reports and control them? What will happen if you do not do that?” etc.

The potential user interviews were based around the following questions:

• How do you perform your tasks when situation X occurs?
• How do you go about solving the problem X now?
• Have you tried solving this problem differently?
• In your opinion, how this functionality should be realized?
• What value do you hope you will get with the help of the system?
• What harm could this system do?

MVP template

The Analytics were working to get clear goals, metrics and enough information to describe the solution in the following format.

Hypothesis Statement

Sometimes an in-depth interview isn’t sufficient to fill out the template. This article, which is published at the Scaled Agile Framework website, provides information on what it takes.

Using the information entered in the MVP-template, the team created user personas, described leading indicators that the new system would impact, and the processes the users employ to fulfill their jobs. This has produced the following user story map.

User Story Map Framework

The blue blocks contain a description of leading indicators. Underneath each blue block, there is a yellow block describing the process within which the users work. Below, there are minimal solutions that can impact each indicator within this process. The development team draws a line under the user stories at the very top, thus defining the functionality for the MVP. Doing so, they can vary the number of user stories impacting the leading indicators. This gives flexibility in controlling the cost of the MVP.

The blue blocks contain a description of leading indicators. Underneath each blue block, there is a yellow block describing the process within which the users work. Below, there are minimal solutions that can impact each indicator within this process. The development team draws a line under the user stories at the very top, thus defining the functionality for the MVP. Doing so, they can vary the number of user stories impacting the leading indicators. This gives flexibility in controlling the cost of the MVP.

Business objectives and product metrics was the starting point for the MVP in this scenario. The product decomposition illustrates how the goals lead the choices for the functionality of the product.

The decomposition informs the choices of what functionality to prioritize in the product backlog. This will help to ship a working version of the system faster. Consequently, this will aid in noticing and fixing unexpected scenarios as early as possible, which otherwise would cost more at the later stages.

In conclusion

Form experience of working in custom software and product development, I know that the technical Specification Document on its own does not guarantee transparency of the client’s expectations. It makes all the difference in how the requirements are gathered and what methods are used in creating the product before coding begins. Client expectations can be quite elusive if not approached with the right set of tools. Results of the development process based solely on documentation may be rather disappointing

However, some powerful techniques and methods allow for achieving positive results. For example, instead of User Story Mapping, one can use Impact Mapping. Or, Total Value Opportunity comes in handy when developing a product for internal company use.

Afterword

In this article, I’ve combined my experience and the experience of other professionals in the field who I reached out to before writing this post. I asked a question of whether others had faced a situation similar to the one I have described above. I’d like to say thanks to all the people who responded to my inquiries, provided answers and shared their experiences and opinions. Situations, whereby documentation is used as a sole source of information about clients’ expectations, are not rare at all.

Some answers were pointing the finger of blame to the analytics and those responsible for documentation. Others said that to avoid such a situation an Agile approach should be used. Some emphasized that documentation is not the main instrument to communicate requirements, decisions, and artifacts. They also suggested that a working version of the product must be deployed to validate the results, learn and document something that is of value, whilst UX/UI design and the rest can wait till later stages. All of the answers certainly gave food for thought and aided in writing this article.

Disclaimer1: It is not one-size-fits-all. I’m just trying to illustrate that it is possible to save time and money by avoiding certain mistakes.

Disclaimer 2: The situation described in the article is hypothetical, all characters are fictitious. I intentionally omitted a range of details to convey the main idea and to keep the article concise. Please do not judge harshly.