Jag har märkt att skillnaden mellan produktdriven och användardriven utveckling är ett ämne som rör upp känslor bland entreprenörer och kanske ännu mer hos designers och utvecklare… Draget till sin spets kan man säga att det finns två läger, där det ena är ortodoxt produktdrivet och det andra ortodoxt användardrivet (i verkligheten finns så klart inslag av båda i de flesta företag).

Dessutom har man lite olika definitioner av vad begreppen egentligen innebär, och definitionen i sig är förknippad med starka känslor – min definition är alltid bättre eller mer exakt än din. Därför är det möjligen ett självmordsuppdrag att försöka förklara skillnaden mellan dem i ett blogginlägg, men ämnet är viktigt och intressant, så jag tänkte göra ett försök ändå. Om ni inte håller med kan ni alltid bidra själva i kommentarsfältet.

Produktdriven utveckling

En anledning till att diskussionen om produktdriven respektive användardriven utveckling tagit ny fart de senaste tio-femton åren är kanske Steve Jobs och Apples framgångar. Han förkroppsligade på många sätt produktdriven utveckling, och har bland annat sagt så här:

”People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.”

Exempel produktdriven utveckling

Många av de mest framgångsrika startupsen har börjat som en idé (produktdrivet) och därefter utvecklats och sökt sin marknad. Förutom Apple kan man nämna Facebook som exempel:

Istället för att utgå från ett problem eller behov, typ: “Hur kan man skapa ett socialt nätverk på internet som för människor närmre varandra?”, utgår man från en idé eller produkt och tänker “Vad händer om jag hackar Harvards intranät och lägger upp bilder på alla elever på internet?”(Facebook hette från början FaceMash och var en slags variant av Hot or Not, där två bilder på studenter dök upp bredvid varandra, för att ta reda på vem som var snyggast av dem).

Ett annat exempel hämtar jag från hemmaplan:

Sonen leker med plusplus, det är små plastbitar som har formen av två plus-tecken som sitter ihop. Det är en lite speciell form men man kan förstås göra en massa olika konstruktioner med dem, typ som den här giraffen:

Product Driven PlusPlus

Häromdagen satt vi och byggde med dem tillsammans. Märkligt nog kom jag då på ett nytt sätt att sätta ihop dem som jag inte riktigt hade tänkt på förut. Jag började labba med det och satte dem efter varandra på det nya sättet. Sonen frågade vad jag byggde och jag kunde inte säga annat än att jag inte visste. ”Jag bara testar en grej” svarade jag, och hans ögon blev stora som tallrikar. Det blev till slut en ring! Då började jag fundera på vad man kan använda den till – vilket ju är produktdriven design i sin enklaste form.

Produktdrivna företag är ofta (men inte alltid) ingenjörsdrivna. Ibland upptäcker man något nytt sätt att använda en teknik, man kanske får en ny funktion i en programvara eller på en kamera. Man vet inte riktigt vad man ska ha det till men börjar testa, labba, experimentera. Om någon frågar vad det ska bli så kan man inte svara för man vet helt enkelt inte – det är bara kul att testa vad man kan använda det till.

Efter ett tag kanske det leder fram till något som känns riktigt bra. Det där som känns riktigt bra är en stark idé, något som jag vill ta vidare som jag är övertygad om att fler ska kunna ta del av. Jag bygger vidare på det – fortfarande med en rätt bestämd grej i botten – min ursprungliga idé.

Så småningom märker jag att andra också är intresserade, jag börjar anpassa lite för att göra dem ännu mer intresserade. Det växer och jag letar till slut en marknad.

Användardriven utveckling

Inom användardriven utveckling utgår man istället ifrån ett problem man behöver lösa. Ett behov, något som behöver bli bättre. Man börjar leta lösningar. Man pratar med folk, man gör research, man kanske skriver ner för- och nackdelar med olika lösningar. Så småningom kommer man fram till några alternativ. Man börjar väga dem mot varandra. Kanske stämmer man av dem med någon annan. Och så går man vidare till att faktiskt börja lösa problemet.

Förespråkarna för användardriven utveckling skulle beskriva det här sättet att arbeta för lyhördhet och ödmjukhet, att man alltid utgår från kunden. Kritikerna skulle kanske kalla det osäkerhet och dålig fantasi.

Exempel användardriven utveckling

Exempel på användardriven utveckling finns ofta inom IT, men även inom sjukvård, livsmedelsindustrin och så vidare. Ett tydligt och känt exempel hämtar jag från Jönköping 2005, där njursviktspatienten Christian Farman ville sköta sin egen dialys. Han var övertygad om att han själv kunde fixa dialysen bättre på egen hand, han visste ju hur han ville ha det och ville inte vara styrd av personalens möjlighet att ta hand om honom.

Tack vare att sjukhuset vågade tänka användardrivet och lyssna på sina patienters förslag blev det verklighet. Nu sköter Christian sin dialys själv, han har eget passerkort till självdialyspaviljongen och kommer ofta dit klockan sex på morgonen, vilket inte var möjligt tidigare eftersom personalen börjar först klockan sju. När personalen kommer har han ofta hunnit göra kaffe till dem också och gått till gymmet.

Hälften av dialysavdelningen på sjukhuset är nu öronmärkta för patienter som sköter dialysen på egen hand:

Om vi återvänder till exemplet med min sons plusplus-bitar igen:

Jag har tidigare försökt göra geometriska former med bitarna, som en kub. Det är svårt på grund av hur bitarna är utformade – men till slut har det gått. Jag fick en bild av ett problem och bestämde mig för att lösa det. Fick hålla på flera gånger och göra en mängd olika konstruktioner men fick till slut till det. Det här är behovs-/användardriven utveckling (man utgår från ett befintligt behov/problem och försöker lösa det, även om det inte fanns någon “kund” i det här fallet).

Produktdrivet eller användardrivet – vilket är bäst?

Produktdrivet vs. Användardrivet

 

I praktiken kan man förstås undra vad det gör för skillnad. Och det är inte säkert att det gör någon skillnad, för en produkt som fungerar på marknaden behövs båda två. Men i arbetet gör det stor skillnad: ett produktorienterat team tänker på ett annat sätt och prioriterar på ett annat sätt än ett användarorienterat. I viss utsträckning tror jag man kan säga att det produktdrivna är mer dominerande när det kommer till att starta något helt nytt medan det användardrivna är (eller borde vara) mer dominerande när det kommer till att utveckla något man redan har.

På Cruited är vårt angreppssätt mer behovs- och användardrivet. Vi startade företaget med en bild av ett problem – människor har problem med att söka jobb – men vi hade inte en exakt bild av vad problemet är, varför folk har problem med att söka jobb.

Det första vi gjort för att definiera problemet (och olika delproblem) har varit självklart: vi har pratat med folk som har det här problemet för att förstå det bättre. Vi har genomfört många intervjuer med potentiella användare, uppåt ett femtiotal. Sedan har vi gjort en kartläggning av behoven med den utgångspunkten – en så kallad effektkarta – och jobbat med att förstå och definiera det tydligare (läs mer om vad vi kom fram till här).

På vägen har idéer om produkter som kan hjälpa folk att söka jobb växt fram. Allteftersom har vi börjat skissa, bland annat i Design Studio. Ibland har det känts som att vi kört fast – vad är det egentligen vi gör? Vi har så sjukt många idéer på hur man skulle kunna lösa de här problemen. Men hur går det ihop: vad ska vi välja, vad är viktigt, hur VILL vi lösa det här problemet? Just den frågan, hur vi VILL lösa problemet, tror jag är ett exempel på skillnaden mellan produktdrivet och användardrivet:

Produktdrivet: “Det här en cool grej men vad ska vi ha den till?”

Användardrivet: “Här finns massa problem, men hur vill vi lösa dem?

Sammanfattningsvis tycker jag inte att man kan säga att det ena eller andra alltid är bättre. Det är definitivt skillnad mellan produktdriven och användardriven utveckling, men man kan lyckas med båda metodikerna som grund och kommer förr eller senare att behöva ta in inslag från båda för att lyckas.

Jag tror att det framför allt påverkar mycket hur man jobbar, vilka moment man oftast “kör fast” vid och vad man kommunicerar (på Internet Discovery Day står jag till exempel med en pitch som fokuserar på problembilden men saknar produkt – medan många andra kan ha motsatsen). 

Det påverkar säkert också vilken typ av produkter man får fram, produktdrivna produkter har säkerligen en del utmärkande drag och vice versa. Kanske påverkar det också hur ofta man lyckas med sina projekt, och hur stort man lyckas. Kan det vara så att användardrivna produkter har större sannolikhet att lyckas, men att produktdrivna produkter oftare blir verkligt revolutionerande när de lyckas? 

Vad tror du?

Några bra artiklar jag använt som inspiration för det här inlägget: 

Det är jag som skriver de allra flesta inläggen på vd-blogg. Om du har några tankar kring vad du just läste vore det super om du delar med dig i kommentarerna. Du hittar mig på bland annat LinkedIn och vill du ses eller höras så kollar du på kontaktsidan.