Creating MVPP: a minimally viable product to be proud of

Day November 18, 2014 was the date of the public release of Optimizely's editor for iOS. This was a very significant event, as the release marked the end of a multi-month public beta test, during which the company's employees received a lot of user reviews, in accordance with which they were engaged in implementing many missing features. But until the launch of the application, one problem remained, in the process of solving which the whole team rallied: they did not feel pride in their product. To correct this problem, the guys went beyond the concept of MVP (English: “Minimum Viable Product” - “Minimally viable product”), expanding it to MVPP: “Minimally viable product that we are proud of” (English: “Minimum Viable Product we're Proud of ”). Below is a story about how it all happened, what employees at Optimizely learned in the course of work, as well as development tips that should help readers create cool products. Tips from the point of view of those who have just passed this way.

How did the MVPP concept come about?

Optimizely's iOS, the first public beta editor, was released in June 2014. By the time the product was not completed. But for the company an important factor in the further development and search for bugs was feedback from real customers. And after several months of work, enhanced by user feedback, the beta version of the product seemed sufficiently prepared for a public release. There was only one problem: the team did not feel a sense of pride in their product. He did not match their quality bar. There was a feeling that in front of people - a set of functions, screwed to each other without a single, holistic image. To solve this problem, it was decided to carefully study the user experience - a very dubious goal that could easily stretch the terms of work up to infinity, but did not reach the cherished development stage called “Done!”.
')
Before starting a thorough analysis, in order to direct it in the right direction, two fundamental things were clearly identified:

• firstly, the deadline is defined, which does not allow to fall into the cycle of endless polishing of the user interface;
• secondly, the Lean Startup methodology (English: “A Modest Startup”) became a source of inspiration and it was decided to take care only of such a set of functions that would constitute the very MVP - “minimally viable product”.
• The concept of MVP involves limiting the scale of the project. Conscious constraint, allowing time to deadline. But MVP says nothing about quality. So, in order to clarify for ourselves that the quality and desire to be proud of the final version of the product are now at the forefront, another letter “P” - “Proud” (“pride”) was added to the MVP abbreviation. This is how the MVPP concept was born - “the minimum viable product we are proud of”.

Creating a complete image

Having coordinated the selection of functions for the MVPP release, the author of this article and his colleague, the product designer, were walled up for the best (albeit short) part of the week in the discussion room to systematize user reviews. We have classified and streamlined user scenarios, building a coarse model for further action. This model was intended to further discuss the vision of the project with an expanded team. Fortunately, some previously collected usability research results were already at hand.



These layouts have proven extremely useful when planning work on design and functionality. Instead of abstract talk of ideas, developers faced concrete functions and a solid image. For example, everyone understood what was meant by the phrase "Improved adaptation of scenarios." Having sketches in their hands, it became much easier for team members to communicate with each other, their work gained concrete outlines, and the guys received inspiration for working hard to achieve a solid image of the product they were working on.

Six weeks of calendar ... and more!

To complete the work on MVPP, we needed three “sprints”. By “sprint” at Optimizely, most teams imply a two-week work cycle. The deadlines were set tightly, but the goal looked quite achievable - just by the time it had been planned - as it should be in the case of a well thought out deadline.

In the first "sprint" team achieved amazing results. All the main gears of the mechanism were assembled, moreover, without major changes or redesigns. There were also errors, there were also tasks on “dopilivaniyu”, and roughness for discussion. But, in general, the whole product core was assembled.

The impulse of the first “sprint” was transferred to the second one, during which they corrected the most significant bugs, filled in the gaps of the functionality and brought the user interface to mind.

The third, final, “sprint” was held with a new slogan: “Run a week earlier.” Although the guys have already concentrated on the idea of ​​MVPP, now the work was even more aimed-sniper. Every day during the “volatiles” they looked at the diagram on the board and asked themselves: “What would you be working on today, if the launch would be scheduled for tomorrow?”

When setting priorities, those tasks that did not remain important but were not really necessary for launch were spared.

In the first week of the final "sprint" during each meeting, the guys also went over all the back streets of the product to think once again: are they proud of the new editor for iOS. At the same time, they viewed the product from the point of view of user experience, catching bugs that could reduce the quality of work. At the same time, many functional errors were found and fixed. By the end of the week, Optimizely was proud of the result and was confident in its release.

About adrenaline rejection and the "advantages" of early release

November 10 - a week ahead of schedule! - the team Optimizely quietly and modestly released into the world of their product, worked on the concept of MVPP. Early start-up is not only good in itself; He also allowed him to take a full chest of oxygen to further “finish” the design and hunt for bugs. The accelerated release also gave the company time to reorganize all the components in order to prepare related MVPP products.

The teams working on a particular product do not release their creation alone; This process requires full-fledged cooperation between sales and marketing. In order for Optimizely customers to use the product, colleagues from different departments must also prepare materials for promotion and sales.

By November 18, the moment of public announcement of the final version of the product, the whole company was already genuinely proud of it.

Lessons learned in the process

When writing this article and describing the project as a whole, some tricks became clear to the guys from Optimizely, which will be useful in any team tuned to high quality and timely launch of their products:

Add the letter “P” to “MV”: P, Proud, Pride. With this approach, quality will become a pre-release requirement. The project, developed under the motto “minimally viable product, which we are proud of” ensures that each team member will work on the product, keeping in mind its quality. Each project is a compromise between release dates, quality and scale. It is difficult, very difficult to work simultaneously on all three indicators. Let's be honest: at the same time only two of them are realistic. Calling his project “MVPP”, Optimizely realized for themselves: the quality should not suffer.

Assign deadline. Deadline, hanging over each member of the team, focuses efforts and directs them in the right direction. It will not allow designers to go into the endless cutting of interfaces, will not allow developers to again and again iterate every rare case of a particular application of functionality. The deadline should be tough, but also necessarily real, inspiring the team a sense of urgency, urgency.

Focus on the least possible set of features that can provide maximum benefit to customers. The company has precisely clarified to itself exactly what functions should be redone. And, not less precisely, what functions can be remade on time. This approach did not allow the scale of the project to spread to impracticable dimensions and was able to get the team to focus on the implementation of the necessary tasks.

Layout begins before development. In our industry, this is an elementary truth, but it should be repeated again and again. Create realistic custom scripts, pre-mark the discussion points on the layouts. This approach will avoid uncertainty and quickly explain to all team members a holistic image of the product. He will also rally the team for a specific task.

Daily mileage on the product. In the case of Optimizely, product analysis provided two key strengths. First, several bugs were identified in the design and in the code. And, secondly, the constant analysis did not allow to forget about the additional letter “P” in “MVPP”. Each team member agreed that he was proud of the result and was confident in its launch. Let the debriefing and did our "flyers" for half an hour longer, but it was worth it.

Ask yourself: “And what would we do today, be the release set for tomorrow?”. The closer the release date, the better this issue cuts off the tasks that are required before launching from those that are better dealt with after the release.

“Lather. Wash off. Repeat

By expanding the boundaries of MVP to “a minimally viable product we are proud of,” Optimizely guaranteed quality as one of the requirements before launch. And, using the tool called “deadline”, they focused their efforts exclusively on the tasks that are crucial for the release. Thanks to a well-designed vision of the project, models and layouts, as well as a not-so-distant release date, you can unite the team to create a product that everyone who took part in its creation would be proud of.

And then repeat it again.