Hva er OST? 🧀

Hvis du jobber i et produktteam, og gjør det sammen med en designer, så har forhåpentligvis hørt om Opportunity Solution Trees (OST). Dette rammeverket som ble populærisert av Teresa Torres i boken hennes, Continuous Discovery Habits, er skikkelig i vinden for tiden.

Det er med god grunn! Det er et fantastisk verktøy for å flytte fokus vekk fra hva du produserer, aka løsninger, til hva du ønsker å oppnå av effekt. Ofte tenker man “hvis jeg lager dette, så kan det potensielt gi denne og denne verdien til brukeren”, men når du bruker OST så begynner du heller med å finne ut nøyaktig hva du ønsker som sluttresultat, og jobber deg bakover for å finne ut hvordan du kan komme deg dit. Da finnes bare løsningene som direkte løser behovene brukeren har for å oppnå effekten du ønsker.

Men, når jeg hører snakk om OST, så er det som oftest i fra perspektivet til produktledere og designere. Dette tror jeg kommer av at hvis man skal lage en god OST, så er det et stort behov for å drive med kontinuerlig innsikt for å kvantifisere behov, og når det er gjort så må man prioritere hvilke muligheter man skal angripe først. Det er jo helt essensielt for skjønne behovene, men i bunn å grunn så har ikke brukerne fått noe verdi i fanget før det har blitt laget en løsning.

Rammeverket er laget for å brukes av en produkttrio bestående av produktleder og designer som allerede er nevnt, men det er når vi snakker om løsning at det tredje benet på produktkrakken skinner: oss utviklere. Det er vi som kjenner kodebasen "where the magic happens". Hvordan ting er skrudd sammen på en slik måte at produktet vårt lever, og er de som i bunn og grunn må implementere løsningene dere lander på.

Vi bruker OST for å avdekke antagelser om hvor ønskelig en løsning er for brukerne og hvor levedyktig den er for virksomheten. Men utviklere er spesielt kvalifiserte til å vurdere gjennomførbarheten: Kan vi faktisk bygge dette, og gir det mening for virksomheten vår? Å avklare dette tidlig er kritisk, da det er frustrerende for teamet om mye tid går med til å planlegge en løsning som senere viser seg umulig å implementere.

Så her er det viktig å involvere seg tidlig! Ta eierskap til mulighetene, og start en grundig brainstorming rundt det tekniske mulighetsrommet og hvordan det kan dekke alle behovene. Men hvordan gjør man det? Her er noen spørsmål du kan stille deg selv for å vurdere hvor gjennomføre løsninger er:

Harmoniserer løsningen med det du allerede har? 🎶

Du lager ikke løsninger i et vakuum. Å lage en teknisk løsning betyr at man må skrive kode. Med mindre du starter et helt nytt produkt så gjør du det ikke uavhengig av annen kode. Alle løsninger vi implementerer for å dekke nye behov, må alltid ses i kontekst av produktet vi allerede forvalter.

Akkurat slik som en designer må se hvordan løsningen vil påvirke eksisterende brukermønstre, så må vi ha en forståelse av hvordan det tekniske grunnlaget for løsningen spiller på lag med den eksisterende kodebasen. Hvor lett er det å utvide koden for å få plass til løsninger for dette behovet? Hvor mye av den eksisterende koden må omskrives for å kunne gjennomføre dette?

Dette påvirker hvor raskt vi kan levere, og jo raskere løsningen kommer i produksjon, desto raskere kan vi levere verdi og lære om vi var på rett spor.

Er dette en bærekraftig løsning?🌱

En ting er om løsningen passer inn med det du allerede har, men vil det egentlig være lett å holde lysene på for løsningen i fremtiden? Øyeblikket koden er i produksjon så er det en del av forvaltningsarbeidet til teamet.

Hvor lett det da er videre å skalere og bygge på, å feilsøke når bugs blir oppdaget eller å refaktorere i fremtiden kan ha en betydelig påvirkning på kapasiteten til teamet fremover. Kodebasen vokser og vokser, som betyr mer og mer må forvaltes, men jeg kan love deg at kapasiteten av folk til å forvalte den aldri vokser i samme tempo. Derfor er det ekstremt viktig å tenke på hvor mye tid det vil koste deg å jobbe med løsningen på langt sikt.

Eier du hele løsningen? 🤝

Hvor kjipt er det ikke å lage en fantastisk løsning som funker super smud for brukeren, men så viser det seg at APIet du har kobla deg på for å få tak i dataen du trenger skal avvikles om et halvt år? Avhengigheter til andre team og tredjeparter har en stor påvirkning på både fart og flyt i hvordan man får utviklet ting.

Dersom teamet ditt eier alle brikkene som må til for å løse problemet, så gir det større grad for fleksibilitet av hvordan man kan bygge løsningen. Produserer vi dataene vi ønsker å bruke, eller må vi konsumere de fra andre team?

Kan du måle det du har laget? 📊

Flott, løsningen går ikke i ball på det du har, og det er blir ikke mye mikkmakk å forvalte det heller. Herlig, men klarer du å måle effekt på løsningen? Å evaluere hypoteser krever konkrete datadrevne målinger for å bekrefte eller avkrefte om løsningen gir ønsket effekt!

Hvis du lager en ny funksjonalitet som kan slås på med en knapp, så kan du kanskje måle hvor mange som bruker den relativt til det du hadde forventet. Men, hvordan måler man noe mer søkt som "bedre kvalitet på søkeresultater"? Det er viktig å gjøre en formening om målbarhet i prioriteringen, slik at du ikke bygger i blinde.

Vet vi hvordan vi lager dette? 🤔

Det er stor forskjell på å lage en løsning ved hjelp av verktøy eller metoder du er kjent med eller ikke. Av og til, så krever en løsning på et problem at du må gjøre ting du ikke kan. Kanskje teamet må ta i bruk et nytt rammeverk eller bibliotek som ingen har kjennskap til fra før av, og da er det viktig å regne med at dette kommer til å krever mer ressurser for å implementere.

Er løsningen verdt tiden som må settes av til kompetansebygging, eller ville man gått for en annen mulighet i stedet hvor teamet stiller bedre rent teknisk? Dette blir fort en faktor å regne med hvis man jobber med stramme tidsfrister.

Nå kan du prioritere, med omhu! 🤩

Når du har gjort en slik teknisk gjennomgang av hva du ser som potensielle løsningsrom for de ulike behovene, så sitter du på uvurderlig viktig kompetanse for å velge de rette mulighetene å satse på i en OST!

Dette betyr ikke at du alltid skal velge mulighetene som er enklest å gjennomføre, men at gjennomførbarhet er én faktor i et større regnestykke. Muligheter som er sterkt ønsket av brukerne og gir høy nytteverdi, er de mest fruktbare og bør prioriteres. Gjennomførbarhet kan deretter avgjøre om en mulighet er en lavthengende frukt som bør satses på raskt, eller om den er pil råtten og kan forkastes med en gang.

Her er det også lurt å inkludere alle i hva det er som gjør at man mener at noe ikke er gjennomførbart! Det sparer mye tid for designere når de skal drive med konseptutvikling hvis de vet at en viss type data kommer fra en kilde man helst ikke ønsker å jobbe med.

Et siste tips er å huske at dette ikke er en engangsøvelse. Akkurat slik som at du må drive med kontinuerlig innsikt, så er det viktig å kontinuerlig evaluere løsninger etter hvert som ting utvikler seg. Når en ny datakilde blir tilgjengelig, eller man har fått ny kompetanse i teamet, så er det lurt å tenke om det påvirker noen av avgjørelsene som gjorde at man ikke kunne oppsøke muligheter i OSTen tidligere På denne måten holder du alltid øye på hva som er viktig for at produktet skal gi effekten du ønsker for dine brukere og virksomhet!

Takk for meg og lykke til med å finne de rette behovene å løse! 🎄