Hva vi prosjektfolk kan lære fra produktfolk
I Ruter jobber vi etter smidig arbeidsmetodikk. Dette innebærer at vi organiserer deler av arbeidet vårt i produkt-team. Produkt-team har en annen arbeidstilnærming og filosofi enn klassiske prosjekt-team. Vi i team Strategi og bærekraft må forstå produkt-filosofien (heretter: produktfolka) for å sikre at strategiarbeidet er kunde- og verdidrevet, og at våre leveranser er relevante for produktfolka som jobber etter smidig arbeidsmetodikk. Samtidig tror vi at vi har mye å lære fra produkt-tilnærmingen inn i våre prosjekter og arbeid for øvrig.
Formålet med denne flisen er å oppsummere noe av det vi mener vi kan lære fra produktfolka (og gjøre noen forsiktige forsøk på å antyde at det også kan tenkes å være noe læring motsatt vei). Dette er ikke ment å være en komplett eller eksakt oppsummering, men heller et bidrag til å samle våre tanker og et utgangspunkt for å diskutere problemstillingen med andre (og evt. også være til nytte for andre). Oppsummeringen er heller ikke ment å sette den ene skolen opp mot den andre, men å tydeliggjøre forskjellene mellom tilnærmingene for å lettere identifisere og bruke relevant læring.
Så — hva kan vi prosjektfolk lære fra produktfolk?
- Tydelig på formål — være mer opptatt av effekt enn leveranse.
Helt konkret betyr det: vi må være veldig bevisste på hva formålet med arbeidet, og hvilken verdi det skal gi (en leveranse fra vårt team har i seg selv sjelden direkte kundeverdi). Utforske om det er mulig å måle denne effekten/verdien på et vis. Vektlegge å kommunisere verdi/effekt til team-medlemmer, og ikke bare leveranser, en god prosjektprosess og aktiviteter for å levere.
2. Eierskap — få hele teamet med på å finne løsningen på problemet
Helt konkret betyr det: prosjektleder skal ikke presentere løsning, og aktiviteter. Start med å sikre god problemforståelse i teamet, selv om det er fristende å starte med å utforske hva som er best løsning/tilnærming. Dette er for så vidt i tråd med god prosjektmetodikk også, men innebærer kanskje å gå litt bort fra den stereotypiske oppfatningen av prosjektleder som skal være den som har styringen, kjører prosessen og har full kontroll. Hvilken retning arbeidet tar vil være mer opp til teamet. Dette vil medføre at prosjektleder (og eventuell styringsgruppe) må slippe litt opp og gi teamet frihet og mulighet til å påvirke retningen. Dette henger sammen med pkt 1 om at produktfolk først og fremst er opptatt av at leveransen er i tråd med kundenes behov og ønsker (kunder kan her være både interne og eksterne kunder). Produktfolk er mindre opptatt av å forholde seg til en rigid prosess, og tillater seg en mer utforskende rolle gjennom hele prosessen for å sørge for at problemet er riktig forstått og at kundenes behov ivaretas.
3. Autonomi — la dem som sitter nærmest problemet finne ut løsningene (henger tett sammen med eierskap i forrige punkt)
Helt konkret betyr det: Team med reell autonomi er mer motiverte og jobber bedre. Når prosjektleders jobb er å sikre gode rammer, gi forståelse og kontekst for problemet som skal løses (jf pkt over), må hvert teammedlem i større grad ta ansvar for hva som må gjøres og hvordan. Prosjektleder må altså lede (mer) gjennom å sette kontekst, ikke kontroll (fritt etter Reed Hastings). For å lykkes med denne tilnærmingen, er det også viktig at teamet holdes ansvarlig for resultatet («accountable») — både suksesser og mindre heldige vurderinger. Dette kan oppnås ved å skape en kultur som fokuserer på åpenhet, trygghet og viktigheten av læring på tvers av team og organisasjonen.
4. Testtilnærming — lage et minimum viable product (MVP) så snart som mulig og se om det funker (med ekte kunder, eller mottakere i organisasjonen).
Helt konkret betyr det: Selv om vi ikke utvikler programvare eller andre produkter og tjenester som kundene konsumerer, bør vi i større grad teste ut leveranser (en strategi, en presentasjon eller hva det måtte være) tidlig, framfor å lage en 100% ferdig leveranse. Gir det den verdien vi ønsket? Her kan det selvsagt være unntak. Men uansett, bør vi tørre å være åpne om det vi lager, og sende fra oss leveranser til andres vurdering, selv om vi vet at vi skal jobbe videre på det / det skal bli bedre (eller ikke engang vet om vi er på rett spor).
Et viktig aspekt ved dette er at risiko håndteres på en annen måte. For et produkts typiske risikoelementer[*] kan de reduseres ved å analysere og lage store risikooversikter og mitigeringsplaner, men i mange tilfeller avdekkes og håndteres relevante risikoelement mye bedre ved å teste MVPen i markedet (med ekte mennesker og ekte penger, som de sier).
*
value risk (vil nok kunder kjøpe produktet), usability risk (vil brukerne forstå hvordan produktet skal brukes), feasibility risk (kan produktet bygges) og business viability (funker produktet med vår øvrige virksomhet, herunder om det er lønnsomt totalt sett for virksomheten)
5. Skape energi og engasjement — vær tydelig
Helt konkret betyr det: Være bevisst at design er viktig, og hvordan vi kommuniserer for å skape forståelse for hva vi skal gjøre og oppnå. Vi må selge inn budskapet vårt til hjertet, ikke bare hjernen. ”An emotional buy-in beats the rational one any day” ([1] Espen Sundve, Oda). Bruk eller hent inspirasjon fra designere for å lage kommunikasjonsinnhold som treffer målgruppen (veldig ofte fordi det vil bli lettere å forstå hva vi faktisk forsøker å oppnå, og løsningen i tillegg ser smooth ut). Stjerne-organisasjonspsykolog Adam Grant ble nylig spurt av Nicolai Tangen [2] hva som er det mest undervurderte aspektet ved å skape en god kultur i et selskap. Svar: storytelling!
6. Vurder bruk av road map istedenfor detaljert prosjektplaner
Helt konkret betyr det: Enkle road maps (nå — neste — senere) er ofte vel så effektivt som en detaljert prosjektplan. Bruk prosjektplan på høyt nivå for å få oversikt over tidsfrister, leveranser o.l., men styr (i større grad) fortløpende prioriteter gjennom road maps.
7. Bruk written narrative framfor PowerPoint (i mange sammenhenger)
Helt konkret betyr det: Ppt kan fungere for mye, men i mange tilfeller er det mer effektivt å skrive ut problemstillingen. Gode, skriftlige notat gjør det enklere for mottakere å sette seg inn i materien (som dette notatet er et godt eller dårlig eksempel på). Forsøk å skrive ned problemstillingen (fra et par linjer, til lengre notater) og be møtedeltakere lese gjennom i forkant. Møtet kan da bli mye mer effektivt og rett på sak (eks. kan man unngå å informere om noe halve møte vet fra før). Samtidig kan notater også være veldig effektivt for å fremme egen tenking[3] og i å nå mange med viktige budskap. Det er mye lettere å bullshitte gjennom ppt enn word, overfor andre og enn selv. Begrepet written narrative brukes ofte. Det er det samme som et notat, men det høres mer spennende ut.
Andre viktige elementer i produkt-tenking som vi bør vite om (men som kanskje ikke er så relevant for Strategi og bærekrafts-/prosjektfolks dag-til-dag-arbeid)
- Ende-til-ende-ansvar. Unngå handovers i størst mulig grad. Dem som utvikler løsninger, skal også leve med løsningene i drift.
- Deltakere i teamet rapporterer til teamet/product manager. Linjeleder har personalansvar, men skal ikke ha noe mening om hvordan tiden som allokert til et team brukes.
Og i all ydmykhet — hva kan produktfolka lære av oss prosjektfolk?
¿ Fange opp viktige problemstillinger som vil treffe produktutviklingen på et eller annet tidspunkt
Smidig tjenesteutvikling kan kanskje bli for opphengt i dag-til-dag-oppgaver og ikke fange opp det som potensielt kan treffe utviklingen lengre ned i gata. En prosjektleder som tvinges til å tenke gjennom hele prosjektplanen, med milepæler og risikovurderinger, vil enklere kunne fange opp hva som må håndteres (ofte av andre enn produkt-teamet selv) tidligere.
¿ Styringsgrupper kan hjelpe med å sikre forankring og fange opp viktige avhengigheter tidlig
For produktfolk er styringsgrupper umoderne (påstand på litt ustø grunn). Styringsgrupper skal styre prosjektet — det vil produktteamet gjøre selv, jf punktene om autonomi og eierskap over — men, samtidig har styringsgrupper kanskje en vel så viktig jobb med å sikre forankring av arbeidet (eksempelvis ved at ledergruppen er informert el. konsulert om et viktig arbeid og eventuelle føringer/hensyn derfra ivaretas), og at viktige problemstillinger og avhengigheter til andre deler av organisasjonen ivaretas. Produkt-teamene skal helst være så lite avhengige av andre som mulig, men i praksis vil det ofte være mer avhengighet enn man ønsker, og det kan stoppe framdrift om det ikke fanges opp tidlig.
¿ Kan det tenkes at vi er bedre til å lage business case?
Jo — produktfolk er opptatt av å identifisere verdien produktet skal skape, og at dette skal måles fortløpende (med bruk av MVPer og gradvis utrulling osv). Og ja — det å lage store, detaljerte business cases up-front, kan ofte ikke gi så mye verdi når vi ikke aner hvordan markedet faktisk vil ta imot produktet vårt. Samtidig, tror vi at det å snekre sammen et relativt high-level business case tidlig, kan gi en indikasjon på om produktet er lønnsomt, og gjøre det lettere å ettergå forutsetningene som ligger til grunn. Alt kan — og skal — ikke kunne regnes hjem. Men, bruk av business case tidlig, vil — igjen påstand — kunne gi bedre prioriteringsdiskusjoner i selskapet. Det som uansett blir viktig er at produktteamene rigges slik at nøkkelressurser som skal ivareta disse hensynene er inkludert i teamet.
🍀
[1] https://uxdesign.cc/what-is-a-great-product-strategy-really-d22b14d54e8
[2] https://open.spotify.com/episode/6xn6TVYIdVe1EhNUAbFlmN?si=d52eeb283a9c41ee
[3] https://www.linkedin.com/posts/johangjarum_digger-denne-snutten-fra-richard-rumelt-activity-7077898347918823424-dx6M?utm_source=share&utm_medium=member_desktop
