MVP
MVP concept
Minimum Viable Product (MVP) is usually a testable product with a minimum set of functions, which brings value. MVP has just enough core features to deploy and run the product effectively.
MVP is a core artifact in an iterative process of idea generation, prototyping, data collection, analysis, and development. The process is iterated and built on user feedback. Iterations take place until a desirable product fit is obtained.
Traditionally, MVP is created to test assumptions that a new product is valuable and in demand on the market. Then, testing results and end users' feedback are utilized to understand what changes should be applied to the product or service and if it is profitable to develop the project overall.
MVP can be used for the following purposes:
- Test hypotheses and assumptions with minimal resources.
- Reduce wasted engineering hours.
- Get the product to customers as soon as possible.
- Accelerate end users' learning.
Let's consider the MVP principles:
Balance of effort and value. There is no need for code polishing or adding a lot of beautification to UI in terms of MVP. Make sure that a Business Process is functioning and can work successfully end-to-end to start involving users in MVP testing. You can realize some non-critical features or exception paths later.
Key functionality first out. Identify a minimum set of key features that help end users fulfill their needs once realized. You need to understand the process flow and the minimum process flow, user actions, and their interaction with the correct set of features that can meet the users' needs and start bringing value.
MVP in delivery
For the WorkFusion delivery, the idea of MVP is used differently. We do not create a new product to fit the market demand but, instead, want end users to receive value from automation as soon as possible. This approach allows the team to collect the maximum amount of feedback with the least effort. On the one hand, users receive value from the functionality earlier, and on the other hand, the delivery team receives feedback and a pipeline for improvements.
Instead of thinking of MVP as a POC of technical assumptions, think of it as an iterative process of automation adoption in a complex business system. If we consider the difference between POC and MVP, we can show it in an example of aircraft building. Let's say we need to build an aircraft. For POC, we create a small airplane model that flies at a distance of 100 kilometers and can deliver up to 500 kilograms of cargo. With an MVP approach, we collect all the requirements and design a boing that can fly safely at 1000 kilometer distance after the first iteration of development. After the second iteration, it can deliver cargo; after the third iteration, the weight of delivered cargo can be increased, and so on. So, the idea is that development is conducted in iterations when users start receiving and testing early most useful functionality.
To summarize, the idea of MVP approach is that the value brought by automation with WorkFusion can be adopted by end users quicker if the delivery process is split into iterations where a separate iteration brings new features to a full-scale process.
This approach is highly valuable because business users have difficulty envisioning the entire automated process, its benefits, and results. If they receive the most critical functionality realized end-to-end and when the rest features are added incrementally, it helps them to adopt the idea better. End users can test processes, provide relevant feedback or change requests in time, and shape requirements properly for other features. In other words, it is better to deliver three out of ten features end-to-end and give them to users for probation rather than deliver all features simultaneously.
To identify the scope of MVP correctly, the Data Analyst needs to define key functionality first with the help of the process flow, use case diagrams, user stories, and stakeholders' feedback. The most prioritized user stories should be detailed first.
Sometimes, it is challenging to deliver a completely functioning feature for end users' testing because it has dependencies on client systems' readiness or other Business Process parts. Then, it is essential to involve stakeholders in periodic reviews of the functionality and hold demo sessions.
Demo sessions
Demo sessions are aimed at reviewing the designed or implemented parts of Business Processes. The solution cannot have all features or not be fully functioning, but that is not compulsory for demo sessions.
The main aim of a demo is to provide more visibility for stakeholders and receive confirmation that the development is on the right track. A demo session is a source of user feedback when you are not ready yet to give the solution for testing, testing is cost-intensive at the current stage, or a client has no capacity to test.
For a demo, you can use mocked data or imitate some functionality as functioning even if it is not fully delivered yet. In such cases, demos can be aimed at feedback and visibility, and hypothesis testing. For example, if a client requests features that do not bring value and you want to prove it, or instead, a client is not confident about some features and considers options. Thus, you can show where the functionality is applicable in value and usability and, therefore, save time and effort in delivering useless features.
Testing hypotheses and holding demo sessions often can help you understand your target audience better and get their needs and pain points. It is extremely important and useful because not all the feedback or process gaps and bottlenecks can be realized and verbally communicated.
Demo sessions help pick up user feedback and ensure the expectations match the product. Feedback is used for other features' prioritizing and delivering, testing, and accepting the solution. It also helps users receive hands-on experience of the solution even before running it in production.
The earlier you start adopting the solution in a demo session or MVP testing, the more likely sign-off goes smooth.