Abandonați-vă ideile preconcepute și aflați de ce companiile de succes adoptă MVP ca o cheie pentru a-și face clienții fericiți.
De Arbi Vartan și Jeff Brinkerhoff
Slalom iubește Agile. Suntem entuziasmați de beneficiile reale și măsurabile pe care am văzut că afacerile le obțin de pe urma acestuia și vorbim despre unele dintre cele mai mari avantaje ale sale într-o serie de articole pe blog și un webinar Agile gratuit – vizionați la cerere.
Produsul MVP, sau Minimum Viable Product, este de bază pentru practica Agile. Și este, de asemenea, ceva care generează rezistență. I-am auzit pe clienții noștri spunând lucruri de genul: „Directorii noștri nu vor minimul – ei vor cea mai bună calitate posibilă”. Într-adevăr, de ce nu ați vrea să faceți tot ce e mai bun? Este o întrebare grozavă, dar care se bazează pe o neînțelegere a MVP.
Cucerit de Frank Robinson în 2001 și popularizat de Eric Ries prin cartea sa Lean Startup, MVP-ul a devenit un pilon al echipelor de produse performante din întreaga lume. De ce a fost Google atât de dominant pentru atât de mult timp? De ce face Apple unele dintre cele mai populare produse din lume? De ce Netflix nu numai că a supraviețuit, dar a prosperat dincolo de modelul lor de afaceri inițial? Mulți factori au contribuit, dar un fir comun este că toți aceștia folosesc MVP.
Atunci ce este MVP? Iată care este definiția lui Eric Ries: Acea versiune a unui produs nou care permite unei echipe să colecteze cantitatea maximă de învățare validată despre clienți cu cel mai mic efort.
După cum arată clar această definiție, MVP-ul nu este un produs cu cea mai mică funcționalitate posibilă necesară pentru o lansare publică. Nu are nimic de-a face cu lansarea publică a unui produs deloc. Mai degrabă, MVP este cheia utilizării metodei științifice pentru construirea produselor. Este pur și simplu un mecanism de învățare validată, folosit pentru a testa ipoteze și a descoperi ce va satisface nevoile clienților.
Luptați-vă de termen dacă trebuie – dar păstrați conceptul
La Slalom, am integrat conceptul de MVP atât în modul în care construim produse pentru companii, cât și în modul în care ne asociem cu acestea pentru a profita de beneficiile încorporării principiilor și practicilor Agile în modelul lor de afaceri. Cu toate acestea – după mai mult de douăzeci de transformări Agile în întreprinderi și sute de parteneriate în diverse industrii – am descoperit că uneori este mai simplu să nu forțăm utilizarea unor termeni precum MVP. Unii au trecut la termenul „Minimum Lovable Product”, iar Henrik Kniberg (cunoscut mai ales pentru munca sa cu cultura inginerească Spotify) propune utilizarea termenilor „Earliest Testable”, „Earliest Usable” și „Earliest Lovable Products”.
Carecare dintre acești termeni este în regulă. Agile se referă la echipe mai fericite și mai productive – nu la terminologie. Abordarea noastră față de acest concept sau față de orice alt concept Agile interpretat greșit și neclar este să sărim peste cuvânt și să punem următoarele trei întrebări:
- De ce să o facem? În cazul MVP-ului, este vorba de învățarea rapidă, precum și de principiile care stau la baza acestuia: satisfacția clientului, îmbunătățirea continuă și simplitatea.
- Ce ar fi necesar pentru a-l face în compania mea? Oh, puterea de încadrare! În loc să vă întrebăm dacă o puteți face, ne concentrăm asupra blocajelor – organizaționale sau de altă natură. Răspunsul la această întrebare ia adesea forma unui buy-in din partea unor indivizi despre care se credea că sunt de neînduplecat.
- Și dacă nu am face-o? O altă strategie de încadrare: concentrați-vă pe costurile de a vă chinui cu status quo-ul. Acest lucru poate crea un sentiment de urgență și poate stabili alinierea în jurul unui nou mod de lucru.
Iată o poveste despre pericolele status quo-ului: Un proiect pentru o companie cu care am lucrat recent a implicat petrecerea a șase luni pentru o versiune majoră de software cu impact asupra a peste 200 de utilizatori interni. S-au închis într-o cameră și au finalizat construcția și toate testele. Și abia în acest moment au solicitat feedback de la o mână de reprezentanți ai analiștilor de afaceri – nu de la utilizatori reali. Acest tip de activitate de tip „checkbox”, prea târziu pentru a avea un impact real și fără o concentrare reală asupra învățării validate, cu greu poate fi calificată drept solicitare de feedback. Este de fapt o încercare de validare a inevitabilului.
Rezultatul a fost previzibil. Având în vedere că se cheltuise deja atât de mult timp și bani, s-au simțit obligați să meargă mai departe, iar toți cei 200 de utilizatori au respins noul software din cauza performanțelor lente și a lipsei de utilizare. Șase luni și peste 12 milioane de dolari au fost cheltuite, cu doar arătarea cu degetul între echipele de afaceri și de tehnologie ca dovadă.
Imaginați-vă acum același scenariu cu un MVP implementat unui grup de utilizatori finali la începutul proiectului. Dezvoltatorii ar putea să învețe imediat ce greșesc, apoi să implementeze alte MVP-uri, îmbunătățindu-se iterativ cu fiecare dintre ele până la implementarea unui produs final – dezvoltat cu și aprobat de utilizatori reali. Un alt beneficiu: Utilizatorii din grupul de testare ar fi investiți temeinic în proiect și l-ar evangheliza în rândul colegilor lor.
Am văzut exact acest scenariu desfășurându-se și de aceea credem cu tărie în MVP – indiferent cum alegeți să îl numiți.
.