Development Strategy: From MVP to Whole Product
Those who are engaged in the development of technology business (software development, Internet services, etc.), certainly read such books as “Overcoming the abyss” and “Inside the tornado” by Jeffrey Moore. Of these books, the reader knows the model of the life cycle of technologies on the market (although the model itself appeared earlier in a book by another author, which Moore himself does not hide in his works).
If these books are not familiar to you, the model is easily understood according to the scheme (taken from the site www.techlifecycles.com ):
The essence is as follows. When a new technology is introduced to the market, consumers are distributed on a scale of propensity to risk. First, the technology will be tested by innovators, then by early adopters, by early majority (late majority), and later by majority (late majority) and by laggards. The latter, if they buy technology, only if they have no more choice (for example, if it becomes an industry standard). Accordingly, there are very few innovators, a bit more early followers. But "serious business" begins when you have reached the early and late majority. And this stage can not be reached - between the early followers and the early majority there is the so-called "abyss" (due to several reasons that are described in the book).
')
Innovators and early followers form the so-called “early market”. But for such a market you need to make a product, and not just describe the idea in the presentation. The best dog breeders recommend using the MVP - Minimum Viable Product strategy to develop such a product. Those. development by minimal effort of a product that is not ashamed to show the early market. By the way, the term "dog breeders" is used here not only for red word. The goal of MVP is to verify the statement, as progressive American IT entrepreneurs say, “whether the dog will eat dog food” - that is, whether the invented product will be used (including for a fee) at all. Here the task is to balance the waste of resources to create a product that may not be needed by the market, and to create sufficient functionality to render the correct verdict “the market needs that the idea itself is bad). So, task number 1: determine the scope of MVP.
After the minimum product is made, tested on the market, the first customers appeared (namely, customers, not users) - you stand next to the abyss. To overcome it, other dog breeders (specifically, mentioned at the beginning of D. Moore) introduce the concept of a holistic product. This is a finished product that fully covers the needs of a specific niche in a large market in the area to which the product corresponds (it is argued that it is impossible to make such a product for the entire market at once — it’s hard not to agree). Having made such a product for a specific niche, you will kindle the hearts of that part of the early majority that corresponds to the chosen niche. And then the rest will catch up. About the choice of such a niche is well written in those same books. In the context of this article is important the fact that you need to make a complete product. The framework of which, as you already understood, needs to be defined. So, task number 2: determine the scope of a holistic product.
We make SmartNut - software (we distribute only on the SaaS model) to automate activities related to servicing customer service companies. And in this article we want to reflect our experience in delineating the framework of the MVP and the holistic product.
In our example, this is a business process automation system. From the definition, their main value is clear: to automate processes. And specifically, in our case we are talking about customer service processes (in the case of CRM systems, we’ll deal with sales processes, etc.). Consequently, the value of the system is in providing tools for automating and optimizing work at each step of the process. So, the key process for your product must be disassembled into its components.
So, the customer service process consists of:
And at each stage, you can come up with many tools that automate and optimize customer service. But we remember that the task is to make a product with minimal functionality that will have value for the client. We decided that the product will have at least some value, when at least some of the applications and maintenance tasks can be completely “passed” through the system. And in our case, we chose applications of the type “incident” (when the client reports a malfunction of something and it needs to be repaired without being shelved). As a result, the following high-level requirements for the first version of the product appeared:
Acceptance and registration of applications and maintenance tasks:
Planning the execution of applications:
Execution of applications:
2 status for the application (open / closed);
Monitoring and analysis:
Further, the requirements are detailed, but taking into account the dropping of all that is superfluous, which is not necessary for “pulling through” the process of incidental applications.
And so it turned out the boundaries of our minimum product, which we released a year ago. After that, we started the stage of closed testing (which lasted about a month), collected a lot of feedback.
With MVP - sorted out. Now go to a holistic product. As you remember from the prelude to the article, a complete product should be made for a specific niche and a specific task. It would seem that SmartNut has a narrow specialization (customer service) and a narrow niche (service companies). But here there is where to narrow. To overcome our chasm, we chose IT outsourcing from all sub-sectors of service companies. Namely, those companies that are engaged in subscriber maintenance of computer equipment and other 1C-s.
And in accordance with the specifics of these companies, in order to create a holistic product, we decided that the most correct way is to build meat for the “skeleton” of the 4 stages of the process:
Acceptance and registration of applications and maintenance tasks:
Planning the execution of applications and maintenance tasks:
Fulfillment of applications and maintenance tasks:
Monitoring and analysis:
(in bold, what was included in the MVP, in italics what was done after the MVP was released - everything else is ahead for the next 8 months).
And in this way we have outlined for ourselves the boundaries of the whole product, with which we will overcome the chasm before which we stand. How to develop a product after overcoming the abyss - we will write after we overcome it.
PS The text says almost nothing about communication with customers. But it is implied. This is a vital necessity. Requirements and prioritization of requirements largely come from them. Just an article not about how to interview clients.
If these books are not familiar to you, the model is easily understood according to the scheme (taken from the site www.techlifecycles.com ):
The essence is as follows. When a new technology is introduced to the market, consumers are distributed on a scale of propensity to risk. First, the technology will be tested by innovators, then by early adopters, by early majority (late majority), and later by majority (late majority) and by laggards. The latter, if they buy technology, only if they have no more choice (for example, if it becomes an industry standard). Accordingly, there are very few innovators, a bit more early followers. But "serious business" begins when you have reached the early and late majority. And this stage can not be reached - between the early followers and the early majority there is the so-called "abyss" (due to several reasons that are described in the book).
')
Innovators and early followers form the so-called “early market”. But for such a market you need to make a product, and not just describe the idea in the presentation. The best dog breeders recommend using the MVP - Minimum Viable Product strategy to develop such a product. Those. development by minimal effort of a product that is not ashamed to show the early market. By the way, the term "dog breeders" is used here not only for red word. The goal of MVP is to verify the statement, as progressive American IT entrepreneurs say, “whether the dog will eat dog food” - that is, whether the invented product will be used (including for a fee) at all. Here the task is to balance the waste of resources to create a product that may not be needed by the market, and to create sufficient functionality to render the correct verdict “the market needs that the idea itself is bad). So, task number 1: determine the scope of MVP.
After the minimum product is made, tested on the market, the first customers appeared (namely, customers, not users) - you stand next to the abyss. To overcome it, other dog breeders (specifically, mentioned at the beginning of D. Moore) introduce the concept of a holistic product. This is a finished product that fully covers the needs of a specific niche in a large market in the area to which the product corresponds (it is argued that it is impossible to make such a product for the entire market at once — it’s hard not to agree). Having made such a product for a specific niche, you will kindle the hearts of that part of the early majority that corresponds to the chosen niche. And then the rest will catch up. About the choice of such a niche is well written in those same books. In the context of this article is important the fact that you need to make a complete product. The framework of which, as you already understood, needs to be defined. So, task number 2: determine the scope of a holistic product.
Our answer to the question "What to do?"
We make SmartNut - software (we distribute only on the SaaS model) to automate activities related to servicing customer service companies. And in this article we want to reflect our experience in delineating the framework of the MVP and the holistic product.
In our example, this is a business process automation system. From the definition, their main value is clear: to automate processes. And specifically, in our case we are talking about customer service processes (in the case of CRM systems, we’ll deal with sales processes, etc.). Consequently, the value of the system is in providing tools for automating and optimizing work at each step of the process. So, the key process for your product must be disassembled into its components.
So, the customer service process consists of:
- Acceptance and registration of applications and maintenance tasks;
- Planning the execution of applications and maintenance tasks;
- Fulfill requests and maintenance tasks;
- Monitoring and analyzing the maintenance process.
And at each stage, you can come up with many tools that automate and optimize customer service. But we remember that the task is to make a product with minimal functionality that will have value for the client. We decided that the product will have at least some value, when at least some of the applications and maintenance tasks can be completely “passed” through the system. And in our case, we chose applications of the type “incident” (when the client reports a malfunction of something and it needs to be repaired without being shelved). As a result, the following high-level requirements for the first version of the product appeared:
Acceptance and registration of applications and maintenance tasks:
- Opportunity employee customer service to register an application.
Planning the execution of applications:
- Automatic calculation of the deadline in accordance with the regulations (aka SLA; by the way, then we realized that this could have been done for the minimum product);
- Lists of applications with the ability to filter and sort by the minimum number of parameters.
Execution of applications:
2 status for the application (open / closed);
- The ability to change the person responsible for the application;
- Notification by email responsible for the application;
- Ability to comment on applications;
- The ability to view additional information about the client and the contact person of the application (i.e., there is a requirement for the presence of a customer base and contact persons).
Monitoring and analysis:
- Lists of requests with the ability to filter and sort by the minimum number of parameters (this is also a control tool, like a planning tool);
- One report on completed applications in the context of customers responsible, in which, among other things, it will show which applications were completed on time and which did not.
Further, the requirements are detailed, but taking into account the dropping of all that is superfluous, which is not necessary for “pulling through” the process of incidental applications.
And so it turned out the boundaries of our minimum product, which we released a year ago. After that, we started the stage of closed testing (which lasted about a month), collected a lot of feedback.
With MVP - sorted out. Now go to a holistic product. As you remember from the prelude to the article, a complete product should be made for a specific niche and a specific task. It would seem that SmartNut has a narrow specialization (customer service) and a narrow niche (service companies). But here there is where to narrow. To overcome our chasm, we chose IT outsourcing from all sub-sectors of service companies. Namely, those companies that are engaged in subscriber maintenance of computer equipment and other 1C-s.
And in accordance with the specifics of these companies, in order to create a holistic product, we decided that the most correct way is to build meat for the “skeleton” of the 4 stages of the process:
Acceptance and registration of applications and maintenance tasks:
- The ability of an employee of the customer service to register an application ;
- The possibility of contacting the client to independently register the application from the personal account;
- Customizable claim types;
- Web application registration form with the ability to embed it into the site;
- Automatic registration of applications by email;
- API;
- Integration with external systems;
- Automatic creation of scheduled tasks on a schedule.
Planning the execution of applications and maintenance tasks:
- Lists of applications and tasks with the ability to filter and sort (with more criteria);
- Automatic calculation of the deadline in accordance with the regulations (SLA);
- Grouping the list of applications and tasks according to different criteria;
- Decomposition of applications and tasks (distribution of applications and tasks into several performers);
- Engineers Download Calendar;
- Periodic auto-informing of engineers on the list of works for the period (by email);
- Printed forms (work orders, certificates of completion, invoices for payment);
- Catalog of paid work (to fulfill paid applications);
- Integration with GIS to display the position of the serviced office on the map (in our case, Yandex.Maps).
Fulfillment of applications and maintenance tasks:
- 2 status for the application (open / closed) ;
- Opportunity to place an order in the status of “Postponed” (with the embedded logic for recalculating the deadline for SLA);
- The ability to change the person responsible for the application ;
- Notification by email responsible for the application ;
- SMS alerts engineers ;
- SMS notification of customers;
- Ability to comment on applications ;
- The possibility of correspondence with the client in the comments to the application through a personal account ;
- The possibility of correspondence with the client in the comments to the application via email;
- Ability to view information about service facilities (database of serviced equipment, CMDB);
- The ability to view additional information about the client and contact person of the application ;
- PDA interface;
- Mobile client;
- Customizable application statuses.
Monitoring and analysis:
- Accounting and analysis of labor costs;
- Extended reporting;
- Uploading lists to .xls.
(in bold, what was included in the MVP, in italics what was done after the MVP was released - everything else is ahead for the next 8 months).
And in this way we have outlined for ourselves the boundaries of the whole product, with which we will overcome the chasm before which we stand. How to develop a product after overcoming the abyss - we will write after we overcome it.
PS The text says almost nothing about communication with customers. But it is implied. This is a vital necessity. Requirements and prioritization of requirements largely come from them. Just an article not about how to interview clients.
Source: https://habr.com/ru/post/148020/
All Articles