Sådan vælger du værktøjer, som dit produktteam faktisk vil bruge

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Hannah Clark: Hurtigt spørgsmål: Kan du uden at tælle fortælle mig, hvor mange logins du i øjeblikket bruger på arbejdet på ugentlig basis? Hvis du ikke ved det, så tryk på pause og prøv at tælle. Jeg vil vædde på, at tallet er chokerende. Faktisk viste en rapport fra CloudZero fra 2024, at den gennemsnitlige medarbejder i øjeblikket bruger 36 cloudbaserede tjenester om dagen, mens ingeniørteams bruger dobbelt så mange.

Vildt, ikke? Og her er endnu en vild ting, som nok ikke vil overraske dig. Ifølge CloudZeros undersøgelse fra 2023 bliver over 53 % af SaaS-licenserne ikke brugt. Med andre ord spilder vi trods vores organisations konstante behov for værktøjer, der understøtter vores unikke arbejdsgange, en masse penge på værktøjer, som af den ene eller anden grund bare ikke passer.

Min gæst i dag er Moshe Mikanovsky, grundlægger og ledende produktcoach hos Products for Good og medvært på Product for Product-podcasten. Moshe har arbejdet med produktudvikling og softwareteknik siden 1989, og et af hans primære fokusområder i de senere år har været at hjælpe produktteams med at træffe bedre beslutninger om de værktøjer, de vælger at implementere.

Moshe har blandt andet udviklet en omfattende ramme, der hjælper organisationer med at vælge de rigtige værktøjer til deres behov og dermed øge anvendelsen og produktiviteten, samtidig med at spildte udgifter reduceres. Vi taler om nogle af højdepunkterne i denne ramme, som kan hjælpe dig med at vælge bedre værktøjer allerede i dag. Lad os komme i gang.

Velkommen tilbage til The CPO Club-podcasten. I dag har jeg Moshe Mikanovsky med. Han er grundlægger og ledende produktcoach hos Products for Good.

Moshe, mange tak, fordi du vil være med i dag.

Moshe Mikanovsky: Tak, fordi du inviterede mig, Hannah.

Hannah Clark: Vi starter, som vi altid gør. Kan du fortælle os lidt om din baggrund, og hvordan du er nået dertil, hvor du er i dag?

Moshe Mikanovsky: Ja, jeg begyndte som softwareudvikler for mange år siden. De første 20 år af min karriere arbejdede jeg på ingeniørsiden. Jeg var så heldig at arbejde for små organisationer og ude i felten, hvor jeg faktisk arbejdede sammen med kunder og brugere. Så jeg tror, at jeg der udviklede en del af min empati for brugerne og for det, de har brug for.

Derefter besluttede jeg efter 20 år at gå over til produktledelse. Det har jeg arbejdet med de seneste 14-15 år. Jeg holder virkelig meget af det. Jeg elsker at tale om produktledelse, jeg elsker at hjælpe andre med at bygge produkter og at se, hvad der findes derude, hvad der virker, og hvad der ikke virker, samt at lære nye metoder.

Alt ved produktudvikling er en del af det, der får mig ud af sengen om morgenen.

Hannah Clark: Du er kommet til det rette sted.

I dag skal vi tale om noget, som jeg tror, alle interesserer sig for, nemlig værktøjer. Hvordan produktteams kan træffe bedre beslutninger, når de vælger værktøjer til deres organisationer. Det er en vedvarende udfordring. Og det er også et vigtigt ekspertiseområde for dig. Hvad inspirerede dig oprindeligt til at skabe den ramme for produktvalg, som vi snart skal tale om?

Moshe Mikanovsky: Jeg har en podcast, som jeg har været medvært på i fire år sammen med min ven Matt Green. Den hedder The Product for Product.

I podcasten gennemgår vi grundlæggende de værktøjer, som produktfolk bruger. Det har altid været interessant for os begge, om end fra forskellige vinkler. For Matt begyndte interessen, da han gik over til produktledelse, og for mig handlede det om at afprøve forskellige produkter og vælge produkter, fordi ingen andre valgte dem for mig, og jeg selv måtte udføre arbejdet.

Det er altid virkelig interessant at se, hvad der findes derude. Det er det, vi laver i podcasten. Og gennem optagelserne af forskellige episoder om forskellige emner og forskellige typer produkter indså jeg, at der er nogle fælles træk i forhold til, hvorfor folk bruger bestemte produkter, hvad de kan lide ved dem, og hvad de ikke kan lide.

Vi interviewede altid brugere af produkterne, medmindre det var en startup. I så fald er der ikke så mange brugere, så inviterer vi grundlæggeren. Men i de fleste tilfælde interviewer vi brugere. De har allerede indsigt og viden om, hvordan produktet bruges, hvad der fungerer, og hvad der ikke fungerer. På den måde samlede jeg en masse viden om begrundelser og ting, man bør se efter, og det fik mig til at samle det hele i én ramme, som jeg elsker at dele med andre.

Hannah Clark: Ud fra din erfaring, hvis vi først vil tale om nogle af de fejl, folk begår, før vi går videre til den rigtige måde at gøre tingene på eller en ramme for, hvordan man gør det bedst muligt for sin organisation: Hvad er nogle af de mest almindelige fejl, som produktorganisationer begår, når de vælger nye værktøjer, og hvilke konsekvenser fører de typisk til?

Moshe Mikanovsky: Jeg tror primært, det handler om, hvordan de vælger værktøjerne, og om at de ikke undersøger, om værktøjet passer godt nok til organisationen. Det er det første. Det er også i høj grad det, rammen handler om. Men det handler også om, at man ikke rigtig forstår værktøjerne, før man vælger dem. Det er meget almindeligt.

Vi bliver altid meget begejstrede for det nye værktøj. Vi leder efter det, ser på de forskellige funktioner, det kan tilbyde, og føler eller tror, at det vil opfylde vores behov. Men når vi begynder at implementere det, opdager vi måske, at det ikke præcis er, som vi troede. Eller måske så vi kun markedsføringsoplysningerne på leverandørens websted, og de fortalte ikke hele historien.

Demonstrationerne fortalte måske heller ikke hele historien, eller der var forskellige faldgruber, som vi først opdagede undervejs. Så det, jeg ofte ser, er, at værktøjet ikke passer optimalt til organisationen, og at man ikke har forstået godt nok, hvordan produktet faktisk vil fungere for dem.

Hannah Clark: Ja, det giver mening.

Lad os så gennemgå din udvælgelsesproces. Din ramme begynder med at identificere problemer, derefter prioritere og lave en kortliste og så sammenligne værktøjer. Der er altså en hel del forarbejde, før man overhovedet når til selve sammenligningen.

Hvorfor er dette forarbejde så vigtigt, før man begynder at sammenligne funktioner?

Moshe Mikanovsky: Jeg tror, det er som med ethvert andet produkt. Jeg forsøger efter så mange år som produktperson at anskue næsten alt, hvad jeg gør, som et produkt. Det samme gjorde jeg med dette. Det er virkelig vigtigt at forstå, hvilket reelt problem vi forsøger at løse.

Vi ønsker ikke at bygge funktioner til en løsning, som ingen vil bruge. På samme måde har vi ikke brug for bestemte funktioner, hvis der ikke er et problem, der skal løses. At alle andre gør noget, betyder ikke, at du også skal gøre det, eller at den måde, andre gør det på, passer til din organisation.

Derfor handler det indledende forarbejde, før man ser på alle funktionerne, om at forstå, hvilke reelle problemer man forsøger at løse, og hvad produktteamets arbejde eller opgave faktisk er. Det er på baggrund af dette, at man skal vælge værktøjerne. Derefter skal man prioritere mellem alle disse ting.

Vi kan ikke altid købe alle produkter med det samme. Nogle gange er det endda svært at få budget til ét produkt. Derfor må man prioritere det største problem, man har lige nu. Det er måske ikke altid et problem; det kan også være noget, der tager lang tid at udføre, eller hvor der er en masse rod, som skal ryddes op.

På baggrund af det største problem prioriterer man og siger: Okay, det er det, vi først skal undersøge. Derefter kan man næsten skabe en køreplan for valg og efterfølgende implementering af produkterne.

Hannah Clark: Jeg vil gerne tale lidt med dig om noget interessant ved den proces, du bruger til at sammenligne værktøjer, nemlig produktfilosofi, som er det første kriterium her.

Hvad mener du med produktfilosofi, og hvorfor er det vigtigt? Hvordan ser forskellene i filosofi egentlig ud, og hvordan påvirker de et værktøjs egnethed til en organisation?

Moshe Mikanovsky: Noget, jeg har lagt mærke til gennem mine samtaler med folk, og som også bygger på mine egne erfaringer og min medvært Matts erfaringer, er, at vi ikke er ens i forhold til, hvordan vi gerne vil arbejde, hvordan vi gerne vil kommunikere, og hvilke ting vi lægger vægt på.

Det er det, jeg lægger ind under filosofi. Nogle af os vil for eksempel gerne have ét produkt, der løser alt, så alle de funktioner, vi har brug for, findes samme sted. Vi behøver ikke implementere noget andet. Men vi ved, at sådanne produkter ofte ikke går særlig dybt med hver enkelt funktion; de går til gengæld meget bredt.

Andre har den filosofi, at de vil have det bedste af det bedste til hvert specifikt problem. De vil gerne have det integreret, så alt taler sammen, men det øger også løsningens kompleksitet. Det er blot ét eksempel på en filosofi: Hvem er vi egentlig som organisation?

Det kan være svært at definere, hvis man ikke ved, hvordan organisationen arbejder, og hvem der træffer beslutningerne. Men det er vigtigt at undersøge, fordi det hjælper en med at finde frem til et bestemt produkt eller en kortliste over produkter.

En anden filosofi handler om, hvorvidt man ønsker, at produktet skal være fleksibelt eller fastlagt. Nogle produkter giver mulighed for at oprette den arbejdsgang, man ønsker, definere de felter, man ønsker, og så videre. Det er nogle gange meget generisk, men også fleksibelt. Hver organisation vil implementere det på en lidt anden måde.

Nogle produkter i samme kategori kan være meget fastlagte og sige: Nej, du skal arbejde på denne måde. Vi har kun bygget det på den måde. Jeg siger ikke, at den ene løsning er bedre end den anden. Nogle gange handler det om organisationens udviklingstrin, ikke så meget om hvor tidligt i deres produktudvikling de er, men mere om deres modenhed.

Hvis de for eksempel ikke kender en bestemt måde at arbejde med sprint, backlogprioritering og alle disse ting på, og de får et produkt, der er fastlagt omkring det, kan produktet lære dem processen. Men det lærer dem kun én måde, selv om der findes mange andre måder at gøre det på.

Når de bliver mere modne, føler de sig måske mere trygge ved at bruge et andet produkt, der er langt mere fleksibelt. Det er nogle af de elementer, jeg ser efter i rammen, allerede før man ser på de enkelte produkter: Hvad er jeres kultur, og hvilke produkttyper passer bedst til jer?

Hannah Clark: Når vi taler om fleksibilitet, er der et andet kriterium, jeg gerne vil spørge ind til, nemlig behovet for løbende teknisk arbejde. Hvordan bør teams vurdere de tekniske ressourcer, der kræves for at integrere forskellige værktøjer, og hvordan kan det hænge sammen med produktets langsigtede succes?

Moshe Mikanovsky: Det hænger også sammen med en form for filosofi. Min filosofi, når jeg bygger produkter for min egen virksomhed eller rådgiver andre virksomheder, er, at vores ingeniører virkelig bør fokusere på den merværdi, vi skaber, og ikke genopfinde hjulet med ting, som millioner af andre udviklere allerede har udviklet.

På samme måde ønsker jeg ikke, at mine udviklere skal bekymre sig om funktioner som beskeder i appen eller produktanalyse, som allerede findes i de værktøjer, vi har i dag. Jeg foretrækker, at de integrerer det én gang gennem en meget enkel integration og derefter stort set glemmer det.

Derefter skal produktchefen eller andre uden for udviklingsteamet have mulighed for at definere det, der skal defineres, for at få mest mulig værdi ud af produktet. Men nogle produkter i samme kategori kræver faktisk løbende hjælp fra ingeniører, fordi man skal definere hændelser, der skal udløses, eller bestemme udseendet og funktionaliteten af beskeder i appen.

For mig, og igen er det min personlige holdning, er det spild af udviklernes tid. Jeg foretrækker, at de arbejder på den værdi, der er unik for vores organisation.

Hannah Clark: Når vi taler om virksomhedsværdier og de mere unikke ting, har du også nævnt, at kulturelle faktorer som virksomhedsværdier og kommunikationsstile kan påvirke valget af værktøjer. Jeg vil meget gerne høre en historie om, hvordan det fungerer i praksis, og hvordan disse mindre håndgribelige elementer kan påvirke, hvilke værktøjer der får succes i en organisation.

Moshe Mikanovsky: Jeg kan give dig et eksempel fra et sted, hvor jeg arbejdede, og hvor vi havde meget svært ved asynkron kommunikation. Det var virkelig frustrerende for mig, fordi vi arbejdede på afstand, og man skulle tro, at asynkron kommunikation netop er noget, der hjælper en med at samarbejde bedre, så man ikke behøver at deltage i regelmæssige møder.

Vi var nødt til at deltage i møder hele tiden for at få tingene til at bevæge sig fremad. Vi valgte også at bruge et system til backlogstyring. Jeg tror, det var Jira. I den slags systemer definerer man måske sine epics i et Confluence-dokument og sine historier med acceptkriterier.

Man ville forvente, at folk læste materialet og samarbejdede gennem kommentarerne på en eller anden asynkron måde. Men det fungerede bare ikke. Hver gang nogen sagde: Nå, det så jeg ikke, eller tog det op på et møde, tænkte jeg: Men alt det stod jo der.

Det var et kulturelt problem, som påvirkede, hvor nyttige vores produkter var for os. Nogle gange følte jeg, at jeg svømmede mod strømmen. Jeg måtte holde en hel session for at forklare, hvad asynkron kommunikation er, og hvorfor den er vigtig. Jeg kan ikke huske, om det overhovedet hjalp.

Det er det, jeg mener. Det er blot ét eksempel på, hvordan organisationen arbejder. Et værktøj kommer ikke nødvendigvis til at løse det. Et værktøj kan hjælpe med at gøre kommunikationen bedre, hvis man gør en indsats for faktisk at bruge det. Et værktøj kan hjælpe med at forbedre processerne, hvis det passer til den måde, organisationen arbejder på.

Normalt fungerer det ikke omvendt, selv om værktøjet godt kan være med til at ændre den måde, virksomheden arbejder på. Jeg ville dog først se på, hvilke kulturelle begrænsninger man har, og derefter tilpasse værktøjet til dem.

Hannah Clark: Det giver meget mere mening.

Lad os gå tilbage til funktionssammenligningerne, nu hvor vi har talt om noget af forarbejdet og nogle af de faktorer, man bør overveje, før man går helt ned i detaljerne om, hvad værktøjet tilbyder.

Mange teams går naturligvis direkte til sammenligning af funktioner og priser, når de vurderer værktøjer. Du nævnte det tidligere. Hvorfor kommer disse faktorer så sent i din evalueringsramme?

Moshe Mikanovsky: Primært fordi jeg ikke ønsker, at folk først ser på outputtet, altså hvad de kan gøre med det produkt, de bruger. Jeg vil hellere have, at de ser på de resultater, de forsøger at opnå.

Funktioner er sandsynligvis det letteste at sammenligne. Organisationerne vil fortælle, at de har denne og hin funktion. Men når man ser nærmere på detaljerne, som nogle gange er offentliggjort og andre gange ikke, opdager man, om det faktisk er de funktioner, man forventede.

Nogle gange bruger leverandørerne en anden terminologi. Nogle gange har de meget forskellige priser for forskellige tilgængelige funktioner. Det er alt sammen i orden, men det er som regel os som forbrugere, der skal gennemgå alle detaljerne for at finde det rigtige produkt til os.

Det vigtigste er dog, at vi vælger og implementerer værktøjer med fokus på de resultater, vi vil opnå, i stedet for blot på output. Jeg kan gøre dette, og jeg kan gøre hint, og derfor er dette værktøj bedre end det andet.

Hannah Clark: Jeg vil gerne tale om den måske mest frustrerende del af implementeringen af et nyt værktøj, nemlig at få alle til at tage det i brug og blive enige om, hvordan det skal anvendes i organisationen.

Især efter at man har gjort et omfattende arbejde for at finde det rigtige værktøj og tage alle disse hensyn for at sikre, at det er det rigtige værktøj, skal man stadig få folk til at bruge det og bruge det på samme måde. Hvad er nogle af de vigtigste strategier til at sikre en vellykket anvendelse i hele organisationen?

Moshe Mikanovsky: Den første er at vælge det rigtige værktøj eller i det mindste det mindst uegnede værktøj, man kan finde, for der vil altid være udfordringer. Den anden ting er selve udvælgelsesprocessen. Den er vanskelig. Det afhænger af, hvem der ejer den, og hvilken styring der gælder for ejerskabet og udvælgelsesprocessen.

Man kan også møde modstandere allerede på det tidspunkt. Jeg har ikke en specifik anbefaling lige nu. Det er noget, jeg overvejer, og jeg vil sikkert udvide rammen lidt i fremtiden, når jeg har fået flere oplysninger fra andre.

Hvis mange mennesker deltager i udvælgelsesprocessen, kan det for det første tage meget lang tid at vælge. For det andet: Har man samtykke, eller har man konsensus? Det er endnu et kulturelt spørgsmål i organisationen. Og hvem ejer så produktet – ikke bare set fra et udvælgelses- eller implementeringsperspektiv?

Historisk set har it-afdelingen ofte ejet produkter i organisationen, fordi det var software, der skulle installeres på en computer. Derfor ejede it-afdelingen det. Men de bekymrede sig måske ikke så meget om, hvorvidt produktet faktisk blev implementeret med succes. Derfor havde man brug for en anden person, der kunne være drivkraften bag implementeringen. Ejerskabet er også vigtigt.

I dag kan det være nemmere for nogle organisationer, hvis de har product operations, fordi jeg synes, det passer naturligt ind dér, især hvis man vil standardisere det på tværs af organisationen. Så kan de forstå alle de forskellige teams’ behov og forskellene mellem dem.

De kan også forstå, hvad der gør det vanskeligt at implementere og bruge værktøjerne i hvert team. Det kan skyldes personligheder, projektbegrænsninger eller mange andre ting.

Ligesom med ethvert andet produkt må nogle af os arbejde hårdt for at få vores produkt implementeret korrekt hos kunderne. Det her er et B2B-produkt. Alle de produkter, vi taler om, er B2B-produkter. Hvis du udvikler et B2B-produkt, ved du sikkert, hvad jeg taler om, og du har måske også større empati for det. Hvis du ikke bygger B2B-produkter, kan der være en afkobling. Det er ikke altid nemt.

Det afhænger af organisationens størrelse, hvor mange projekter og produkter man har, og mange andre ting. Overordnet vil jeg sige, at det handler om, hvem der træffer beslutningen, hvem der ejer det, hvilken styring man har, hvordan folk faktisk accepterer beslutningerne og fører dem videre, og også om at gennemføre iterationer, så man ikke behøver at implementere det hele med det samme.

Man kan afprøve forskellige ting og derefter iterere, ligesom man ville gøre med ethvert andet produkt.

Hannah Clark: Ja, det giver mening. Det er en fordel at have en onboardingproces, der er lidt mere gradvis. I denne situation har man i det mindste bedre adgang til sine brugere.

Moshe, mange tak, fordi du ville være med i dag. Det har været virkelig informativt. Jeg synes, det har været meget hjælpsomt, fordi vi alle på et eller andet tidspunkt skal vælge nye værktøjer, og hele implementeringsprocessen kan være lidt af en rejse. Vi sætter virkelig pris på din vejledning. Hvor kan folk lære mere om den ramme for produktvalg, du har udviklet, og komme i kontakt med dig online?

Moshe Mikanovsky: Det var en fornøjelse, og tak, fordi du inviterede mig. Alle kan komme i kontakt med mig på LinkedIn. Man kan finde mig ved at søge på mit efternavn, Mikanovsky, og mit websted er productsforgood.co. Jeg har lagt rammen ud som et Miroverse-board. Den er offentliggjort på Miroverse, og der er et link til den på mit websted under ressourcer.

Jeg deler den også med dig, så du kan lægge den i beskrivelsen af episoden. Jeg deler den meget gerne med alle. Man kan kopiere den og begynde at bruge den. Der er forklaringer, og der er mange ressourcer inde i rammen, blandt andet en Airtable-liste over produkter med en vis kategorisering.

Den er stadig under udvikling, fordi der hele tiden kommer nye produkter, og jeg finder altid nye produkter. Hvis der mangler noget, må du endelig kontakte mig på LinkedIn. Jeg vil meget gerne høre fra alle.

Hannah Clark: Ja, vi vil meget gerne dele den. Og mange tak for alle ressourcerne og for din tid.

Moshe Mikanovsky: Det var en fornøjelse. Mange tak, Hannah.

Hannah Clark: Tak, fordi du lyttede med. Hvis du vil have flere gode indsigter, vejledninger og anmeldelser af værktøjer, kan du abonnere på vores nyhedsbrev på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved at abonnere på The CPO Club, dér hvor du normalt får dine podcasts.