Creating MVPP: the smallest viable product you can be proud of

The day of 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 the many months of public beta testing, during which the company employees received a lot of user reviews, according to which they were involved in introducing many missing features. But until the launch of the application, there was one problem, in the process of solving which the whole team rallied: they did not feel pride in their product. To fix this problem, the guys went beyond the framework of the MVP concept (English: “Minimum Viable Product” - “Minimum Viable Product”), expanding it to MVPP: “the minimum 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 Optimizely employees learned along the way, as well as development tips that should help readers create cool products. Advice from the point of view of those who have just come this way.

How the concept of MVPP came about

Optimizely's iOS first public beta was released in June 2014. By that time, the product was not completed. But for the company, feedback from real customers was an important factor in the further development and search for bugs. And after several months of work reinforced by user reviews, the beta version of the product seemed quite prepared for a public release. There was only one problem: the team did not feel proud of their product. It did not match their quality standard. 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 time to infinity,

Before starting a thorough analysis, in order to direct it in the right direction, two fundamental things were clearly indicated:

• firstly, a deadline is defined that will not allow you to fall into the cycle of endless polishing of the user interface;
• secondly, the Lean Startup methodology became a source of inspiration (English: “A modest start-up”) and it was decided to take care of only such a set of functions that will make up the very MVP - “minimally viable product”.
• The concept of MVP implies limiting the scope of a project. Conscious limitation, allowing to catch up to the deadline. But MVP says nothing about quality. So, in order to understand for ourselves that from now on, quality and the desire to be proud of the final version of the product are paramount, we added another letter “P” to the abbreviation MVP - “Proud” (“pride”). This is how the MVPP concept was born - “the minimum viable product we are proud of.”

Creating a holistic image

After agreeing on a selection of functions for the MVPP release, the author of this article and his colleague, the product designer, walled up for the best (albeit short!) Part of the week in the discussion room in order to organize user reviews. We categorized and streamlined user scenarios, building a rough model of what to do next. This model was intended to further discuss the vision of the project with an expanded team. Fortunately, some pre-assembled usability research results were already at hand.



These layouts turned out to be extremely useful when planning work on design and functionality. Instead of abstract talk about ideas, the developers faced specific functions and a solid image. For example, everyone understood what was meant by the phrase “Improved scenario adaptation”. Having the sketches in their hands, it became much easier for the team members to communicate with each other, their work took on specific outlines, and the guys got an inspiration to work hard to achieve a complete image of the product they were working on.

Six weeks of the calendar ... and go!

To complete the work on MVPP, we needed three sprints. By “sprint” at Optimizely, most teams mean a two-week work cycle. The deadlines were set tightly, but the goal seemed quite achievable - exactly by the time that was planned - as it should be in the case of a well-designed deadline.

In the first sprint, the team achieved amazing results. All the main gears of the mechanism were assembled, moreover, without major changes or redesigns. There were still errors, and there were tasks to “finish off”, and roughness for discussion. But, in general, the whole product core has been assembled.

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

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

When setting priorities, those tasks that remained important but were not spared really necessary to run.

In the first week of the final “sprint” during each meeting, the guys also went through all the corners of the product to once again think: are they proud of the new editor for iOS. At the same time, they examined the product in terms 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 were confident in its release.

About adrenaline rush and "advantages" of an early release

November 10 - a week ahead of schedule! - The Optimizely team quietly and modestly released its product to the world, worked out according to the MVPP concept. Early start is not only good in itself; he also allowed to gain a full chest of oxygen for further “finishing up” the design and hunting for bugs. Also, the accelerated release gave the company time to reorganize all components in order to prepare related MVPP products.

Teams working on a single product do not release their creation alone; this process requires full cooperation between the sales and marketing departments. 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 time of the public announcement of the final version of the product, the whole company was sincerely proud of it.

Lessons that were learned in the process

When writing this article and describing the project as a whole, the guys from Optimizely became aware of some tricks that would be useful in any team that was set up for high quality and timely launch of their products:

Add the letter “P” to “MV” : P, Proud, Pride.With this approach, quality will become a mandatory pre-release requirement. The project, developed under the motto “minimum viable product that 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’s difficult, very difficult to work on all three indicators at the same time. Let's be honest: only two of them are realistic at the same time. Calling their project “MVPP”, Optimizely realized for themselves: quality should not suffer.

Assign a Deadline.A 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 out of interfaces, and will not allow developers to iterate again and again every rare case of a particular application of the functional. The deadline should be tough, but also necessarily real, inspiring the team with a sense of urgency, urgency.

Focus on the smallest feature set that can maximize customer benefit. The company clearly realized for themselves which functions should be redone. And, no less accurately, what functions can be redone on time. This approach did not allow the scale of the project to creep to impossible sizes and was able to force the team to focus on the implementation of the necessary tasks.

The layout begins before development. This is an elementary truth in our industry, but it is worth repeating it again and again. Create realistic user scenarios, outline discussion points in advance on layouts. This approach will avoid uncertainty and quickly explain to all members of the team a holistic image of the product. He will also rally a team to perform a specific task.

Go over the product daily. In the case of Optimizely, product analysis provided two key benefits. Firstly, several bugs were identified in the design and in the code. And secondly, the constant analysis did not let us forget about the additional letter “P” in “MVPP”. Each team member agreed that he was proud of the result and confident in its launch. Let the debriefing and made our "flies" half an hour longer, but it was worth it.

Ask yourself: “What would we do today if the release was scheduled for tomorrow?” The closer the release date, the better this question cuts off the tasks that are mandatory before launching from those that are better to do after the release.

“Lather. Rinse off. Repeat ”

Expanding the boundaries of MVP to the“ minimum viable product we are proud of ”, Optimizely guaranteed quality as one of the requirements before launch. And, using a tool called “deadline”, they focused their efforts solely on tasks critical for the release. Thanks to a well-developed vision of the project, models and mock-ups, as well as a not-so-distant release date, you can rally a team to create such a product that everyone who took part in its creation would be proud of.

And then repeat it again.