Slik velger du verktøy produktteamet ditt faktisk kommer til å bruke

Les transkripsjonen:

Vi prøver ut transkribering av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Hannah Clark: Kan du, uten å telle, raskt si hvor mange innlogginger du bruker på jobb i løpet av en vanlig uke? Hvis du ikke vet det, kan du trykke på pause og prøve å telle. Jeg tipper at tallet er overraskende. En rapport fra CloudZero fra 2024 viste faktisk at en gjennomsnittlig ansatt bruker 36 skybaserte tjenester per dag, mens teknologiteam bruker dobbelt så mange.

Ganske sprøtt, ikke sant? Og her er en annen sprø ting som sannsynligvis ikke vil overraske deg. Ifølge CloudZeros studie fra 2023 blir over 53 % av SaaS-lisensene ikke brukt. Med andre ord: Til tross for organisasjonens konstante behov for verktøy som støtter de unike arbeidsprosessene våre, sløser vi bort masse penger på verktøy som av en eller annen grunn bare ikke passer.

Dagens gjest er Moshe Mikanovsky, grunnlegger og ledende produktcoach i Products for Good og medvert for Product for Product-podkasten. Moshe har jobbet med produktutvikling og programvareteknikk siden 1989. Et viktig fokus for ham de siste årene har vært å hjelpe produktteam med å ta bedre beslutninger om hvilke verktøy de skal ta i bruk.

Moshe har utviklet et omfattende rammeverk som hjelper organisasjoner med å velge de riktige verktøyene for behovene sine. Det øker bruken og produktiviteten, samtidig som unødvendige utgifter reduseres. Vi diskuterer noen av høydepunktene i rammeverket, som kan hjelpe deg med å velge bedre verktøy allerede i dag. La oss sette i gang.

Velkommen tilbake til The CPO Club-podkasten. I dag har jeg med meg Moshe Mikanovsky. Han er grunnlegger og ledende produktcoach i Products for Good.

Moshe, tusen takk for at du blir med oss i dag.

Moshe Mikanovsky: Takk for invitasjonen, Hannah.

Hannah Clark: Vi begynner på samme måte som alltid. Kan du fortelle litt om bakgrunnen din og hvordan du har kommet dit du er i dag?

Moshe Mikanovsky: Ja, jeg begynte som programvareutvikler for mange år siden. De første 20 årene av karrieren jobbet jeg på teknologisiden. Jeg var heldig nok til å jobbe for små organisasjoner, eller ute i feltet, faktisk med kunder og brukere. Jeg tror derfor at jeg utviklet en del av empatien min for brukerne og behovene deres.

Etter 20 år bestemte jeg meg for å gå over til produktledelse. Det er det jeg har jobbet med de siste 14–15 årene. Jeg liker det virkelig godt. Jeg liker å snakke om produktledelse, hjelpe andre med å bygge produkter og se hva som finnes der ute, hva som fungerer og hva som ikke fungerer, samt lære nye metoder.

Alt som handler om produkt, er en del av det som får meg opp om morgenen.

Hannah Clark: Du er i godt selskap her.

I dag skal vi snakke om noe jeg tror alle er opptatt av, nemlig verktøy – og hvordan produktteam kan ta bedre beslutninger når de velger verktøy for organisasjonene sine. Det er en vedvarende utfordring. Dette er også et viktig ekspertiseområde for deg. Hva var det som først inspirerte deg til å lage rammeverket for produktvalg som vi snart skal snakke om?

Moshe Mikanovsky: Jeg har en podkast som jeg har vært med på å lede i fire år sammen med vennen min, Matt Green. Den heter The Product for Product.

I podkasten ser vi i hovedsak på verktøy som produktfolk bruker. Dette har alltid vært interessant for oss begge, men fra ulike utgangspunkt. For Matt begynte interessen da han gikk over til produktledelse. For min del handler det om at jeg tidligere har prøvd ulike produkter og valgt produkter fordi ingen andre valgte dem for meg, og jeg måtte gjøre jobben selv.

Det er alltid interessant å se hva som finnes der ute. Det er det vi gjør i podkasten. Etter hvert som vi spilte inn episoder om ulike temaer og ulike typer produkter, innså jeg at det finnes fellestrekk i hvorfor folk bruker bestemte produkter, hva de liker ved dem og hva de ikke liker.

Vi intervjuet alltid brukere av produktene, med mindre det var en oppstartsbedrift. Da finnes det ikke så mange brukere, og vi inviterer inn grunnleggeren. I de fleste tilfeller intervjuer vi imidlertid brukere. De har allerede innsikt og kunnskap om hvordan produktet brukes, hva som fungerer og hva som ikke fungerer. På bakgrunn av dette samlet jeg mange av vurderingene og tingene man bør se etter, og satte alt sammen i ett rammeverk som jeg liker å dele med andre.

Hannah Clark: Etter din erfaring, hvis vi først skal snakke om noen av feilene folk gjør før vi går inn på den riktige måten å gjøre dette på, eller et rammeverk for hvordan organisasjonen kan gjøre det best mulig: Hvilke er de vanligste feilene produktorganisasjoner gjør når de velger nye verktøy, og hvilke konsekvenser får disse feilene vanligvis?

Moshe Mikanovsky: Jeg tror hovedsakelig det handler om hvordan de velger verktøyene, og at de ikke undersøker hvor godt verktøyet passer til organisasjonen. Det er det første. I tillegg handler det om at de ikke virkelig forstår verktøyene før de velger dem. Det er ganske vanlig.

Vi blir alltid veldig begeistret for det nye verktøyet. Vi ser på det og undersøker de ulike funksjonene det tilbyr. Vi føler, eller tror, at det vil dekke behovene våre. Men når vi begynner å ta det i bruk, oppdager vi kanskje at det ikke er helt slik vi trodde. Eller kanskje vi bare så på markedsføringsinformasjonen på leverandørens nettsted, og den fortalte ikke hele historien.

Demonstrasjonene forteller heller ikke alltid hele historien, og det kan finnes ulike fallgruver som vi oppdager underveis. Det jeg ofte ser, er derfor at verktøyet ikke passer best for organisasjonen, og at man ikke har forstått godt nok hvordan produktet faktisk vil fungere for dem.

Hannah Clark: Ja, det gir mening.

La oss gå gjennom utvelgelsesprosessen din. Rammeverket ditt begynner med å identifisere problemer, deretter prioritere og lage en kortliste, før man sammenligner verktøyene. Det er altså mye forarbeid før man i det hele tatt kommer til selve sammenligningen.

Hvorfor er dette forarbeidet så viktig før man begynner å sammenligne funksjoner?

Moshe Mikanovsky: Jeg prøver å angripe nesten alt jeg gjør som et produkt, fordi jeg har jobbet som produktperson i så mange år. Derfor gjorde jeg det samme med dette. Det er svært viktig å forstå hvilket reelt problem vi prøver å løse.

Vi ønsker ikke å bygge funksjoner for en løsning som ingen kommer til å bruke. På samme måte trenger vi ikke bestemte funksjoner hvis det ikke finnes et problem som må løses. At alle andre gjør noe, betyr ikke at du også må gjøre det, eller at måten andre gjør det på, passer til hvordan organisasjonen din fungerer.

Derfor handler det innledende arbeidet, før man ser på alle funksjonene, om å forstå hvilke reelle problemer man prøver å løse. Man må forstå hva arbeidet består i, og hva produktteamets oppgave er – altså hva man trenger å velge disse verktøyene for. Deretter må man prioritere mellom alt dette.

Noen ganger kan vi ikke kjøpe alle produktene med én gang. Noen ganger er selv budsjettet for ett produkt større enn det vi kan få. Derfor må vi prioritere det største problemet vi har akkurat nå. Det er kanskje ikke alltid et problem, men noe som tar lang tid å gjøre, eller hvor det er mye rot som må ryddes opp i.

Med utgangspunkt i det største problemet kan man prioritere og si: «Dette er det vi må se etter først.» Deretter kan man nesten lage et veikart for valg av produkter og for å ta dem i bruk.

Hannah Clark: Jeg vil snakke litt om noe interessant ved prosessen du bruker for å sammenligne verktøy, nemlig produktfilosofi, som er det første kriteriet.

Hva mener du med produktfilosofi, og hvorfor er dette viktig? Hvordan ser forskjeller i filosofi egentlig ut, og hvordan påvirker de hvor godt verktøyet passer til en organisasjon?

Moshe Mikanovsky: Noe jeg har lagt merke til gjennom samtaler med folk, og som også bygger på mine egne erfaringer og erfaringene til medverten min, Matt, er at vi ikke er like når det gjelder hvordan vi liker å jobbe, hvordan vi liker å kommunisere, eller hva vi legger vekt på.

Det er dette jeg plasserer under filosofi. Noen av oss ønsker for eksempel ett produkt som løser alt, med alle funksjonene vi trenger. Da trenger vi ikke å ta i bruk noe annet. Men vi vet at slike produkter ofte ikke går særlig dypt i hver enkelt funksjon, selv om de dekker et bredt område.

For andre er filosofien: «Jeg vil ha det beste av det beste for hvert enkelt problem jeg har.» De ønsker at verktøyene skal være integrert, slik at alt snakker sammen, men det gjør også løsningen mer kompleks. Det er bare ett eksempel på en filosofi: Hva er vi egentlig som organisasjon?

Det kan være vanskelig å definere dette hvis man ikke vet hvordan organisasjonen fungerer eller hvem som tar beslutningene. Likevel er det viktig å se etter denne informasjonen, fordi den hjelper deg med å finne et bestemt produkt eller lage en kortliste over produkter.

En annen slik filosofi handler om hvorvidt du ønsker at produktet skal være fleksibelt eller forutsigbart. Noen produkter lar deg lage hvilken som helst arbeidsflyt og definere hvilke felt du vil. Det kan være ganske generisk, men samtidig fleksibelt. Hver organisasjon vil ta det i bruk på litt forskjellige måter. Andre produkter i samme kategori kan være svært forutsigbare og si: «Nei, du må jobbe på denne måten. Det er slik vi har bygget det.»

Jeg sier ikke at det ene er bedre enn det andre. Noen ganger handler det om hvor moden organisasjonen er, ikke nødvendigvis hvor tidlig den er i byggingen av et produkt. Hvis man for eksempel ikke kjenner en bestemt måte å gjennomføre sprinter eller behandle en oppgaveliste på, og får et forutsigbart produkt, kan produktet lære dem prosessen.

Men det lærer dem den bare på én måte, selv om det finnes mange andre måter å gjøre det på. Når de blir mer modne, vil de kanskje føle seg mer komfortable med et produkt som er langt mer fleksibelt.

Dette er noen av faktorene i rammeverket jeg ser etter, før man undersøker funksjonene: Hva er kulturen vår, og hvilke typer produkter passer best for oss?

Hannah Clark: Når vi snakker om fleksibilitet, er det et annet kriterium jeg vil utfordre deg litt på: behovet for løpende teknisk arbeid. Hvordan bør team vurdere de tekniske ressursene som trengs for å integrere ulike verktøy, og hvordan kan dette henge sammen med produktets langsiktige suksess?

Moshe Mikanovsky: Dette henger også sammen med en form for filosofi – min filosofi for produktutvikling generelt, både i mitt eget selskap og når jeg rådgir andre selskaper. Ingeniørene våre bør først og fremst konsentrere seg om merverdien vi skaper, og ikke finne opp hjulet på nytt med ting som millioner av andre utviklere allerede har utviklet.

På samme måte ønsker jeg ikke at utviklerne mine skal bekymre seg for funksjoner som meldinger i appen eller produktanalyse, siden dette allerede finnes i verktøyene vi har i dag. Jeg foretrekker at de integrerer det én gang på en svært enkel måte og deretter kan glemme det.

Da kan produktlederen, eller andre utenfor utviklingsteamet, definere det som må defineres for å få mest mulig verdi ut av produktet. Noen produkter i samme kategori krever imidlertid utviklere fortløpende, fordi man må definere hendelser eller hvordan meldinger i appen skal se ut.

For meg – og dette er igjen personlig, ikke nødvendigvis riktig eller galt – er det bortkastet tid for utviklerne. Jeg foretrekker at de arbeider med verdi som er unik for organisasjonen vår.

Hannah Clark: Når vi snakker om virksomhetsverdier og de mer unike tingene, har du også nevnt at kulturelle faktorer, som virksomhetens verdier og kommunikasjonsformer, kan påvirke valg av verktøy. Jeg synes det er veldig interessant.

Kan du fortelle om hvordan dette fungerer i praksis, og hvordan disse mindre håndgripelige elementene kan påvirke hvilke verktøy som lykkes i en organisasjon?

Moshe Mikanovsky: Ja, absolutt. Jeg kan gi deg et eksempel fra et sted jeg jobbet, hvor vi hadde store problemer med asynkron kommunikasjon. Det var svært frustrerende for meg, fordi vi jobbet eksternt, og man skulle tro at asynkront arbeid er noe som hjelper deg å samarbeide bedre uten å måtte være i faste møter.

Vi måtte imidlertid hele tiden delta i faste møter for å få ting fremover. Vi valgte også å bruke et system for oppgavelister – jeg tror det var Jira. I slike systemer kan man definere epos i et Confluence-dokument og historier med akseptansekriterier.

Man forventer at folk skal lese dette og samarbeide i kommentarfeltet, på en eller annen måte asynkront. Men det fungerte bare ikke. Hver gang folk sa «Jeg så ikke det» eller tok opp saken i møter, tenkte jeg: «Men alt dette ligger jo der.»

Det var et kulturelt problem som påvirket hvor nyttig bruken vår av produktene var. Jeg følte noen ganger at jeg svømte mot strømmen. Jeg måtte holde en hel økt bare for å forklare hva asynkron kommunikasjon er og hvorfor den er viktig. Jeg husker ikke om det faktisk hjalp.

Det er dette jeg mener. Det er bare ett eksempel på hvordan organisasjonen fungerer. Et verktøy kommer ikke nødvendigvis til å løse dette. Et verktøy kan gjøre kommunikasjonen bedre hvis man legger inn innsatsen som kreves for å bruke det. Et verktøy kan forbedre prosessene hvis det passer til måten organisasjonen arbeider på.

Vanligvis er det ikke motsatt, selv om verktøyet kan bidra til å endre hvordan virksomheter arbeider. Jeg ville først sett på hvilke kulturelle begrensninger organisasjonen har, og deretter tilpasset verktøyet til disse.

Hannah Clark: Det gir mye mer mening.

La oss gå tilbake til sammenligning av funksjoner, nå som vi har snakket om forarbeidet og noen av faktorene man bør vurdere før man går inn i detaljene om hva verktøyet tilbyr.

Mange team går selvsagt rett til sammenligning av funksjoner og priser når de vurderer verktøy. Hvorfor kommer disse faktorene så sent i evalueringsrammeverket ditt?

Moshe Mikanovsky: Hovedsakelig fordi jeg ikke vil at folk først skal se på resultatene de kan oppnå med produktet, men på effektene de prøver å oppnå.

Funksjoner er sannsynligvis det enkleste å sammenligne. Organisasjonene vil også fortelle deg at de har denne og denne funksjonen. Men når du ser nærmere på detaljene – som noen ganger er publisert og andre ganger ikke – oppdager du om det faktisk er funksjonene du forventet.

Noen ganger bruker leverandørene ulik terminologi. Noen ganger har de svært ulik prising for de forskjellige funksjonene. Det er helt greit, men som regel er det opp til oss som forbrukere å gå gjennom alle detaljene for å finne riktig produkt.

Det viktigste er likevel at vi velger og tar i bruk verktøy basert på ønskede effekter, ikke bare leveranser. Det holder ikke å si «Jeg kan gjøre dette og dette, derfor er dette verktøyet bedre enn det andre.»

Hannah Clark: Jeg vil gå inn på den kanskje mest frustrerende delen av å ta i bruk et nytt verktøy: å få alle til å bruke det og bli enige om hvordan organisasjonen skal bruke det.

Selv etter at man har gjort et omfattende arbeid for å finne riktig verktøy, gjøre tilpasninger og vurdere alle disse tingene, må man fortsatt få folk til å bruke det – og bruke det på samme måte. Hvilke strategier er viktigst for å sikre vellykket bruk i hele organisasjonen?

Moshe Mikanovsky: Den første er å velge riktig verktøy, eller i det minste det minst uegnede verktøyet du finner, for det vil alltid finnes utfordringer. Det andre er selve utvelgelsesprosessen. Den er krevende og avhenger av hvem som eier prosessen, og hvilken styringsmodell man har for eierskap og valg.

Man kan også få motstandere allerede på dette tidspunktet. Jeg har ikke en konkret anbefaling akkurat nå. Det er noe jeg tenker på, og jeg kommer sannsynligvis til å utvide rammeverket litt i fremtiden, når jeg får mer informasjon fra andre.

Hvis mange deltar i utvelgelsesprosessen, kan det for det første ta svært lang tid å velge. For det andre: Har dere samtykke, eller har dere konsensus? Det er også et kulturelt spørsmål i organisasjonen. Og hvem eier produktet – ikke bare fra et utvelgelsesperspektiv eller når det skal tas i bruk?

Tidligere var det ofte IT som eide produkter i organisasjonen, fordi det var programvare som måtte installeres på en datamaskin. Da eide IT produktet, men brydde seg kanskje ikke så mye om hvorvidt det faktisk ble tatt i bruk på en vellykket måte. Derfor trengte man en annen intern forkjemper for å gjennomføre dette. Eierskap er derfor også viktig.

I dag, med produktdrift, kan dette være enklere for organisasjoner som har et slikt team. Jeg synes dette passer godt inn under produktdrift, særlig hvis man ønsker å standardisere prosessen i hele organisasjonen. Da kan teamet forstå behovene til de ulike teamene, forskjellene mellom dem og vanskelighetene ved å ta verktøyene i bruk.

Det kan være personlighetsutfordringer, prosjektbegrensninger eller mange andre ting. På samme måte som noen av oss må jobbe hardt for at produktene våre skal tas ordentlig i bruk hos kundene våre, må man jobbe med dette internt.

Dette gjelder B2B-produkter, og alle produktene vi snakker om, er B2B-produkter. Hvis du utvikler et B2B-produkt, vet du sannsynligvis hva jeg snakker om, og du har kanskje større forståelse for dette. Hvis du ikke bygger B2B-produkter, kan det være vanskeligere å se sammenhengen. Det er ikke alltid enkelt.

Det avhenger av størrelsen på organisasjonen, hvor mange prosjekter og produkter dere har, og mange andre forhold. Overordnet vil jeg si at det handler om hvem som tar beslutningen, hvem som eier produktet, hvilken styringsmodell dere har, hvordan folk faktisk aksepterer beslutningene og hvordan dere fører arbeidet videre – også gjennom iterasjoner.

Man trenger ikke ta i bruk alt med én gang. Man kan prøve forskjellige ting og deretter iterere, slik man ville gjort med ethvert annet produkt.

Hannah Clark: Ja, det gir mening. En introduksjonsprosess som er litt mer trinnvis. I denne situasjonen har du i det minste bedre tilgang til brukerne dine, så det er en fordel.

Moshe, tusen takk for at du ble med oss i dag. Dette har vært svært informativt. Jeg tror det har vært nyttig, fordi vi alle på et eller annet tidspunkt må velge nye verktøy, og hele prosessen med å ta dem i bruk kan bli litt av en reise. Vi setter stor pris på rådene dine. Hvor kan folk lære mer om rammeverket for produktvalg som du har utviklet, og komme i kontakt med deg på nettet?

Moshe Mikanovsky: Takk selv, og takk for invitasjonen. Alle kan ta kontakt med meg på LinkedIn. Du finner meg ved å søke på etternavnet mitt, Mikanovsky. Nettstedet mitt er productsforgood.co. Jeg har rammeverket som et Miroverse-brett, og det er publisert på Miroverse. Jeg har en lenke til det på nettstedet mitt under ressurser.

Jeg deler det også med deg, slik at du kan legge det i episodebeskrivelsen. Jeg deler det gjerne med alle. Du kan kopiere det og begynne å bruke det. Det finnes forklaringer der, og mange ressurser inne i rammeverket, blant annet en Airtable-liste over produkter med kategorisering.

Det er fortsatt under utvikling, fordi det hele tiden kommer nye produkter. Hvis du oppdager at noe mangler, må du gjerne kontakte meg på LinkedIn. Jeg vil gjerne høre fra alle.

Hannah Clark: Ja, vi gleder oss til å dele det. Tusen takk for alle ressursene og for tiden din.

Moshe Mikanovsky: Bare hyggelig. Tusen takk, Hannah.

Hannah Clark: Takk for at du lyttet. For flere gode innsikter, veiledninger og verktøyanmeldelser kan du abonnere på nyhetsbrevet vårt på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved å abonnere på The CPO Club der du vanligvis hører på podkaster.