Med produktledelse, produktutvikling og transformasjon til den produktorienterte modellen høyt på agendaen i mange norske virksomheter, er det viktig at vi utviklere følger med i timen. Den “behagelige” tiden der vi bare kunne plukke ferdigdefinerte lapper fra backlogen er forbi. Vi må begynne å bry oss om å skape verdi fremfor å pushe mest mulig kode.

Effekter genererer verdi

Verdi kan være et vanskelig begrep å definere. Jeg ser på verdi som noe som er nyttig for en bruker, et selskap, eller for samfunnet. Optimalt sett jobber man med noe som skaper verdi for flere av disse, og helst alle tre samtidig. Hvordan man definerer verdi har derfor mye å si for hvordan vi forholder oss til arbeidet vi legger ned hver dag. Er en kodelinje verdi? Eller en skisse i figma? Eller et møte der man som team har jobbet skikkelig bra sammen? I mine øyne er dette aktiviteter som bygger opp under å skape verdi, men det er ikke verdi i seg selv, kun grunnlaget for et verdipotensiale. Verdien oppnås ikke før løsningene vi lager faktisk brukes av brukerne våre, og fører til en endring i adferd hos brukerne. Innen produktutvikling oversettes dette til fokuset på effekter (outcome) i stedet for leveranser (output). Når vi klarer å oppnå de effektene eller adferdsendringene vi ønsker, vil dette være med å generere den verdien vi er ute etter.

Koding er bare ett av verktøyene dine

Som utvikler kjenner man ofte på en slags trang til å lage noe, kode noe, bygge noe. Alle andre aktiviteter føles som tid brukt på noe annet enn det man skal, og man sitter kanskje med følelsen av å ikke ha gjort noe hvis man ikke har kodet. Koding er også det som gir oss mestringsfølelse, så det er helt naturlig å bli dratt mot dette. Poenget mitt er at vi må klare å stå imot denne trangen til å kode når vi ikke vet om det vi lager faktisk skaper verdi. Dersom vi skal lage de beste digitale produktene som brukerne våre elsker, så må vi være mer enn kodemaskiner der vårt eneste bidrag er å ukritisk pushe ut kode. Koding er kun ett av verktøyene i verktøykassa vår, og en moderne (produkt)utvikler må skjønne hvilket verktøy som skal brukes når. Den vanskeligste delen av jobben vår er ikke å skrive kode - dette er uansett noe som bare blir enklere ved hjelp av nye AI-verktøy - det vanskelige er å finne ut hvordan vi kan skape den verdien vi er ute etter.

I et moderne tverrfaglig produktteam er utviklerne som regel i overtall. Det betyr at virksomheter som ønsker å bevege seg mot den produktorienterte modellen er nødt til å ha med seg utviklerne på den samme tankegangen for å lykkes. Hvis ikke vil forkjemperne for dette nye paradigmet alltid være i mindretall. Som utvikler må man innse dette først som sist, og være nysgjerrig på hvordan denne måten å jobbe på fungerer.

Så hvordan lykkes man med produktutvikling som teknolog og utvikler?

Produktutvikling er vanskelig, og ikke noe man lærer seg over natten. Å bli god på produktutvikling handler ikke bare om å lese de hippeste bøkene innen fagfeltet og tro man er utlært. Det er krevende og utfordrende å få til i praksis selv om man har all teorien på plass. Nedenfor har jeg prøvd å komme med fem konkrete fokusområder eller prinsipper man kan følge dersom man ønsker å bli en god produktutvikler. Det kan føles som tidenes scope creep for utvikler-rollen, men dersom vi skal digitalisere Norge på best mulig måte med de ressursene vi har tilgjengelig nå, må vi utviklere gjøre vår del av denne endringsreisen også.

1. Delta i produktutforskningen

Marty Cagan sier det rett ut i boka Inspired. Ikke bruk utviklerne dine kun til koding - de kan by på så mye mer! Vi utviklerne er som regel personene i teamet som sitter tettest på produktet, fordi det er vi som skriver koden, reviewer den, deployer den, og passer på at alt fungerer som normalt. Det er ofte vi som kjenner mulighetsrommet til produktet best. Hva er enkelt eller vanskelig å lage, hvordan kan eksisterende funksjonalitet utvides, kan vi gjenbruke noen kjente mønstre fra eksisterende løsning? Når vi kjenner mulighetene og begrensningene til produktet vårt godt, er det enklere å innovere og komme med gode forslag til hvor neste bit med verdi kan ligge.

Innen produktutvikling har man to moduser som et produktteam skal bevege seg i mellom: kontinuerlig produktutforskning (Product Discovery) og kontinuerlige leveranser (Product Delivery). Vanligvis er utviklere tettest koblet på leveransene, og har tradisjonelt sett hatt større avstand til utforskningen av hva man skal lage. Som produktutvikler er det derimot helt essensielt å bidra inn i produktutforskningen sammen med produktleder og designer, fordi det er vi som ofte er best egnet til å finne en korteste-vei løsning gitt den tekniske konteksten vi sitter med rundt det eksisterende systemet. Cagan sier at det er viktig å innse to ting om produktutvikling: at halvparten av ideene våre ikke kommer til å fungere, og at vi sjeldent treffer med det vi lager på første forsøk og derfor trenger flere iterasjoner. Det er dette kontinuerlig produktutforskning skal bidra til å løse. I stedet for at de andre fagretningene bruker tid og ressurser på å undersøke løsninger som er teknologisk krevende, kan man som utvikler allerede tidlig i utforskningsfasen bidra til at man jobber med å lage et gjennomførbart produkt.

2. Brukeren i fokus

Et godt produktteam har brukeren i fokus. Teresa Torres mener at de beste produktteamene snakker med brukerne sine hver uke i en eller annen form. Som utvikler på teamet er det kanskje nærliggende å tenke at denne delen av jobben kan overlates til produktleder og designer. Her mener jeg vi utviklere også må koble oss på - både i brukerintervjuer og analyse av innsikt! Som nevnt er utviklerne en stor kilde til innovasjon. Når vi da hører førstehånds tilbakemeldinger fra brukerne våre, gjør dette større inntrykk på oss enn å bli gjenfortalt funnene i etterkant. Ved å samle på innsiktsøyeblikk får vi både mer eierskap til brukerne våre og problemene de står i, samt øker vår egen kunnskap rundt domenet vi jobber med.

3. Støttespiller for andre fagfelt

En annen utfordring med at utviklere er i overtall i teamene, er at det legger opp til flaskehalser hos de andre fagretningene. Derfor er det viktig å hjelpe de andre rollene slik at mulige løsninger kan bygges og testes raskere. Et team der utviklerne ofte venter på faglige, designmessige eller juridiske avklaringer, fører til at man heller plukker andre mindre viktige oppgaver i mellomtiden. Dette er med på å forringe fokuset til teamet, ettersom at utviklerne jobber med én ting, og design/produkt/fag jobber med avklaringer av andre ting. Resultatet er i økende grad handovers mellom fagdisiplinene i stedet for ekte tverrfaglig samarbeid. I slike situasjoner er nøkkelen at utviklerne utfordrer de andre fagområdene og hjelper til med å løse flaskehalsene, selv om det ikke nødvendigvis innebærer programmering. Dette kan være å bidra med innsiktsarbeid, sette opp workshop sammen med produktleder, eller skrive risikoanalyse med juristen. Hele teamet må bidra til å fjerne det som hindrer oss fra å skape verdi, selv om arbeidsoppgavene som kreves for å gjøre det ligger utenfor hva vi mener er vårt faglige domene.

4. Måling av effekter

All kode vi skriver som ikke skaper den effekten vi ønsker, var potensielt bortkastet tidsbruk, skaper større kognitiv last hos utviklerne på teamet, må vedlikeholdes, og er teknisk gjeld som senker farten ved nyutvikling. Det er også en alternativkostnad her som er tid vi kunne brukt på å skape faktiske verdiskapende løsninger. Hvordan vet vi at vi har oppnådd effekt og skapt verdi, hvis vi ikke måler hvordan produktet vårt brukes i produksjon? En god kollega av meg sier at "Hvis du ikke har et produktmålingsverktøy, så driver du ikke med produktutvikling". Også her må utviklerne på banen. Første steg er å sette opp målinger og dashboards i produktmålingsverktøy som feks Posthog, Mixpanel, Amplitude eller lignende. Deretter må man ta i bruk målingene for å styre prioriteringer, ta datadrevne beslutninger og måle effekt. Ved å jobbe etter hypoteser endrer man fokuset i teamet fra antall oppgaver i Done-kolonnen i kanbanboardet, til om man har klart å bekrefte eller avkrefte en hypotese i stedet.

5. Fremme produktkultur

En del av det jeg mener ligger i ordet produktkultur er blant annet å jobbe ekte tverrfaglig, smidig (det er fortsatt relevant i produktutvikling, hvis det skulle være noen tvil), og være nysgjerrig på andre fagfelt. Kanskje har du en produktleder eller produktdesigner på teamet ditt du kan sparre med rundt akkurat disse temaene som er nevnt i denne artikkelen. Noen team og organisasjoner har kommet lenger enn andre på reisen mot å innarbeide seg en god produktkultur. Det eneste som er sikkert er at vi alltid kan forbedre oss. Produktutvikling er et omfattende fagfelt, og det er mye man skal kunne. Veien er lang, og den går ikke nødvendigvis rett frem, så her må vi støtte hverandre på ferden. Som (produkt)utvikler på teamet er det derfor viktig at vi hjelper både produktlederen, designeren og andre utviklere på teamet med å hver dag bli bittelitt bedre på produktutvikling, for å sammen skape en produktkultur i teamet.

Oppsummert

Å være produktutvikler handler om så mye mer enn å bare skrive kode. Personlig merker jeg selv at jo mer jeg er delaktig i å finne ut om vi lager de riktige tingene, jo mer jeg har brukeren i fokus, jo mer jeg jobber med de andre fagfeltene, og jo mer jeg er opptatt av å lære av målinger og se effekter, jo mer eierskap får jeg til produktet og teamet mitt. Det gjør det rett og slett morsommere å være på jobb, samtidig som vi jobber riktigere. Da skaper vi et team av missionaries, som Cagan kaller det. Dersom veien dit føles overveldende, ta utgangspunkt i de fem punktene nevnt over, og velg deg en av de du ønsker å bli bedre på.

For en produktutvikler...

1. viser interesse for andre fagfelt
2. jobber ekte tverrfaglig med teamet for å lage det beste produktet
3. er interessert i og sitter tett på sluttbruker
4. tar ansvar der teamet trenger det
5. bryr seg om å skape verdi i stedet for å pushe kode