Kommentar: «Skal du utvikle produkter som er i direkte kontakt med brukeren, bør du vite hva de spiser til frokost»

Innlegg av Kim Iversen, gründer og daglig leder i Zendera. 

Zendera sender teamets utviklerne ut i felt - med mål om å skape bedre løsninger enn selskapene med store summer øremerket research. 

Det er brukerne de aller fleste bedrifter tjener penger på, men de færreste ansatte kjenner dem. I visse jobber er det kanskje ikke et stort behov, men skal du utvikle produkter som er i direkte kontakt med brukeren bør du vite hva de spiser til frokost.

Produktutvikling er utrolig vanskelig. Ofte er det en lang prosess med prøving og feiling gjennom tusenvis av små beslutninger. For å sikre at de store beslutningene er de rette, ligger det mye arbeid i markeds- og brukerundersøkelser. Felles for de fleste bedrifter er at de som gjennomfører undersøkelsene sjeldent er de som utvikler produktet. Dermed må informasjon kommuniseres fra de som har undersøkt til de som skal utvikle.

Min erfaring er at dette er en av de mest kritiske oppgavene - og en oppgave som er umulig å utføre perfekt. For du klarer ikke å samle inn all data, alt brukeren sier eller gjør, og ikke gjør. Den som er hos brukeren vil føle det, men slite med å formidle det. Dermed vil utvikleren som ikke har vært ute hos kunden ha et dårligere utgangspunkt for å ta tusenvis av de rette beslutningene.

Kapitalsterke selskaper kan bruke store ressurser på markeds- og brukerundersøkelser, dokumentere undersøkelsene grundig og deretter formidle informasjonen i hele bedriften. Det garanterer heller ikke et perfekt resultat, de fleste kapitalsterke må også prøve og feile. Mindre kapitalsterke bedrifter, som de fleste startups er, kan ikke gjennomføre like ressurskrevende prosesser. Dårligere prosesser fører ofte til dårligere resultater, noe vi selv har opplevd.

For å øke kvaliteten på prosessen har hele vårt team begynt å delta i informasjonsinnhentingen. De er ute for å bli kjent med kundene, se deres behov og føle stemningen på kontoret eller i bilen. Informasjonen de samler for seg selv er mye mer detaljert enn hva noe rapport kan formidle. Det gjør at alle har mye mer å bidra med når vi tar de store beslutningene i fellesskap og de står mye stødigere til å ta tusenvis av små beslutninger som til sammen blir systemet vårt.

Det er kanskje ikke alltid like lett å sende hele teamet ut til kunder. Da må en være kreativ. Vi utvikler transportsystemer for budbilselskaper. Vi “startet” et budbilselskap for èn dag hvor vi tilbudte gratis frakt i Oslo. Da måtte teamet gjennom hele prosessen fra å opprette en konto og ulike brukere, laste ned apper, ta i mot, fordele, kjøre, godkjenne og fakturere ordre. Jeg har aldri sett dem mer stresset! Det har nok heller aldri vært en mer stressa “budbilsjåfør” midt i Torgata på en lørdag formiddag. Den dagen fikk alle en mye bedre forståelse av våre brukere og hvordan vårt system er i bruk. Mange dumme løsninger ble oppdaget.

Det er ikke en skalerbar prosess, men det er noe som kan gjøre at vi som en liten bedrift klarer å skape bedre løsninger enn de større. Vi gjør også andre tiltak som er mer skalerbare, som å la utviklerne også være de som tar seg av support. Da får de høre kundenes problemer og kundene får snakke med de som kan fikse dem.

Hele prosessen har en stor bivirkning. De ansatte blir mye mer motiverte til å løse utfordringene til våre brukere. For de har vært ute å kjent på utfordringene selv, de har snakket med brukerne og fått noen ansikter å referere til, og de har en bedre forståelse av hvor stor betydningen vår programvare kan ha for brukerne. Noe som gjør at sannsynligheten for at vi skal skape et suksessfullt system øker drastisk.