MVP låter kärnan ta plats

Lumo började närma sig en första färdig version. Bildarbetet flöt på, men en annan återkommande uppgift dök upp i tankarna: att ta bort bakgrunden från en bild.

Det skulle passa bra. Bilder behöver ofta både optimeras och friläggas. Att kunna göra allt på samma ställe kändes användbart.

Men hur skulle det passa in i flödet? Kanske behövde verktyget byggas om kring moduler, så att fler funktioner kunde läggas till senare. Vilken teknik skulle fungera på användarens egen enhet? Hur borde allt hänga ihop?

Snart gick tiden åt till att undersöka hur en betydligt större produkt skulle kunna byggas. Version ett hade börjat få uppgifter som hörde till version fyra.

Bilderna behövde bli klara för webben

Lumo växte fram ur ett återkommande behov. I olika arbeten behövdes bilder i rätt storlekar, optimerade för webben. Det var en uppgift som kom tillbaka gång på gång.

Många gratisverktyg gjorde arbetet halvdant och fyllde vägen med reklam, popups och annat som störde. Egna kommandoskript hade underlättat en del, men var sällan särskilt roliga att använda. Nästa gång de behövdes hade instruktionerna hunnit glömmas bort.

Ambitionen med Lumo var att göra det arbetet smidigare. Samtidigt fanns en nyfikenhet på hur mycket som kunde göras direkt på enheten. Kunde ett verktyg i webbläsaren kännas lika smidigt som ett program på datorn eller en app i mobilen?

Det gav den första versionen en tydlig uppgift: hjälpa användaren att optimera bilder för webben, med ett flöde som var enkelt att förstå och behagligt att använda.

En bra idé kan få vänta

Bakgrundsborttagning var en rimlig idé. Den löste ett närliggande problem och hade kunnat göra Lumo användbart i fler situationer.

Just därför var det lätt att fortsätta tänka på den.

En ny funktion förde med sig frågor om hela produkten. Om fler verktyg skulle tillkomma behövde kanske användaren kunna välja vilka steg bilderna skulle gå igenom. Då blev det intressant att fundera på ett mer flexibelt flöde. Och om flödet ändå skulle byggas om fanns det fler möjligheter att ta hänsyn till.

Varje fråga gick att motivera. Tillsammans innebar de mycket mer utveckling och flyttade slutet längre bort.

Här behövde arbetet hejdas. Bildoptimeringen var fortfarande kärnan. Bakgrundsborttagning och en större verktygslåda kunde komma senare.

Vad ska en MVP hjälpa till att förstå?

MVP står för Minimum Viable Product. Begreppet handlar om att ta fram tillräckligt mycket för att kunna lära sig något viktigt om produkten och dess användare. Eric Ries beskriver kärnan som att få kunskap om kunder med så liten arbetsinsats som möjligt.

Det gör avgränsningen till mer än en fråga om antal funktioner. Det behöver finnas en tanke om vad försöket ska ge svar på.

För Lumo var det relevant att undersöka om ett smidigare sätt att optimera bilder kunde bli ett verktyg människor ville använda i sitt återkommande arbete. Då behövde den första versionen ge dem möjlighet att uppleva just det.

Bakgrundsborttagning hade öppnat ett nytt användningsområde. Den hade också gjort det större och mer tidskrävande att prova den ursprungliga idén.

Vad behöver följa med i första versionen?

När nya idéer dyker upp kan tre frågor hjälpa till att hålla riktningen:

• Vilket arbete ska användaren kunna slutföra?
• Vad behövs för att det ska fungera och vara begripligt?
• Vilka tillägg gör produkten användbar för fler saker?

Den sista frågan ger plats åt bra idéer utan att alla behöver byggas direkt.

När en avgränsad version får användas blir det också möjligt att upptäcka sådant som var svårt att bedöma under utvecklingen. Var uppstår frågor? Vad känns omständligt? Vilka behov återkommer?

Det ger bättre underlag för nästa beslut än att försöka förutse hela produktens framtid från början.

I Lumo behövde det ursprungliga bildarbetet få behålla sitt fokus. Bilder skulle få rätt storlek och optimeras för webben på ett sätt som kändes bra att använda.

Idén om bakgrundsborttagning fanns kvar. Den behövde bara få vänta tills den första versionen hade fått en chans.