MVP er et dårligt redskab

Minimal Viable Product (MVP) er et af de koncepter efter AGILE, der er mest misforstået. Det bliver ofte set som noget, der er billigt at bygge og kan fungere som et færdigt produkt. Sagen er bare, at det kan være billigt men MVP’er er typisk en frygtelig brugeroplevelse.

Når en MVP planlægges handler det i høj grad om at finde den begrænsning af features, der gør den brugbar men samtidig holder den minimal. Ideen er at den skal kunne lanceres til tiden og samle nok læring til at vurdere om produktet reelt skal bygges eller ej.

Microsoft forsøgte for lidt over 10 år siden at udgive styresystemet Windows RT som en MVP. Windows RT skulle være styresystemet til tablets og udvalgte laptops, men netop fordi MVP’en ikke havde de nødvendige funktioner, blev brugerne skræmt væk. Windows RT lignede Windows præcist som man kender det, men man kunne ikke bruge traditionelle Windows-programmer. I stedet kunne brugerne kun installere programmer fra Windows Store. Det forvirrede brugerne så meget, at de til sidst var nødt til at stoppe udviklingen af Windows RT.

MVP’er har også et andet problem: Ikke alt brugerfeedback er brugbart. Brugerfeedback skal kunne oversættes til en eller anden form for handling før, at den er brugbar. Da Google lancerede Google Glass som en MVP—eller prototype—var den kun tilgængelig for en række udvalgte explorers. Formålet var at de udvalgte brugere skulle levere feedback tilbage til Google baseret på deres oplevelser med produktet. Hurtigt blev det feedback fra dem, der ikke brugte brillerne, der definerede feedbacken: Bliver vores privatliv krænket af jeres briller? Og så blev folk med brillerne døbt Glassholes. Google var nødt til at stoppe udviklingen og fokuserede sidenhen på en enterprise-udgave som nu også er lukket.

MVP’er er ofte en dårlig brugeroplevelse. Når I er nødt til at skrabe alt det ikke-nødvendige fra, så kan det nemt resultere i en forvirrende eller decideret dårlig brugeroplevelse. Brugerne ser nødvendigvis ikke jeres MVP som en MVP men som et produkt. Hvis deres oplevelse med hvad de tror er et færdigt produkt er dårlig, så kommer de ikke igen. Det samme gælder bugs, der ikke blev prioriteret pga. deadlines eller intern støtte fra stakeholders, hvis kunder flygter fra et ufærdigt produkt.

Da en af verdens dårligste ideer blev til virkelighed, fik det navnet Peeple. Det skulle forestille sig at være et ”Yelp for people”. Mennesker kunne bedømme andre mennesker ligesom du ville med en restaurant på Trustpilot. Det som genierne utroligt nok ikke havde forudset var, at den med det samme blev brugt til mobning og chikane. Den MVP de skulle teste markedet med blev samtidig det sidste, de lavede. Kunderne havde derefter ingen tillid til produktet.

Hvis du sidder og drukner i post-its til et agilt møde om jeres næste lancering, og der bliver talt om at lancere det som en MVP, så spørg lige dig selv:

• Laver vi en MVP for at spare penge?
• Laver vi en MVP fordi der ikke er intern støtte til projektet endnu?
• Laver vi en MVP fordi vi hørt om det på et SCRUM-kursus?

Hvis du kan svare ja, så skal I nok ikke lave en MVP. Hvis I til gengæld vil lære, hvordan brugerne bedst bruger jeres nye idé, så er MVP et af mange værktøjer, der kan teste det. I langt de fleste til fælde er det dog et forfærdeligt værktøj.