Så väljer du verktyg som ditt produktteam faktiskt kommer att använda

Läs utskriften:

Vi testar att skriva ut våra poddavsnitt med hjälp av ett program. Ursäkta eventuella stavfel, eftersom boten inte har rätt 100 procent av tiden.

Hannah Clark: Snabb fråga: utan att räkna, kan du säga hur många inloggningar du använder på jobbet under en vanlig vecka? Om du inte vet, tryck på paus och försök räkna. Jag slår vad om att siffran är chockerande. En rapport från CloudZero från 2024 visade faktiskt att den genomsnittliga medarbetaren använder 36 molnbaserade tjänster per dag, och teknikteam använder dubbelt så många.

Helt galet, eller hur? Och här kommer en annan galen sak som förmodligen inte överraskar dig. Enligt CloudZeros studie från 2023 används över 53 procent av alla SaaS-licenser aldrig. Med andra ord: trots vår organisations ständiga behov av verktyg som stöder våra unika arbetssätt slösar vi enorma summor på verktyg som av någon anledning helt enkelt inte passar.

Min gäst i dag är Moshe Mikanovsky, grundare och ledande produktcoach på Products for Good och medvärd för podden Product for Product. Moshe har arbetat med produktutveckling och programvaruutveckling sedan 1989. Ett viktigt fokus för honom under de senaste åren har varit att hjälpa produktteam fatta bättre beslut kring vilka verktyg de ska införa.

Moshe har dessutom utvecklat ett omfattande ramverk som hjälper organisationer att välja rätt verktyg för sina behov. På så sätt kan de öka användningen och produktiviteten samtidigt som de minskar onödiga kostnader. Vi diskuterar några av ramverkets viktigaste delar, som kan hjälpa dig att välja bättre verktyg redan i dag. Då sätter vi i gång.

Välkommen tillbaka till podden CPO-klubben. I dag har jag Moshe Mikanovsky med mig. Han är grundare och ledande produktcoach på Products for Good.

Moshe, stort tack för att du är med oss i dag.

Moshe Mikanovsky: Tack för att jag fick komma, Hannah.

Hannah Clark: Vi börjar som vi alltid gör. Kan du berätta lite om din bakgrund och hur du hamnade där du är i dag?

Moshe Mikanovsky: Ja, jag började som programvaruutvecklare för många år sedan. Under de första 20 åren av min karriär arbetade jag på teknik- och utvecklingssidan. Jag hade turen att arbeta för små organisationer. Eller ute på fältet, faktiskt, där jag arbetade med kunder och användare. Jag tror att jag där utvecklade en del av min förståelse för användarna och deras behov.

Sedan, efter 20 år, bestämde jag mig för att gå över till produktledning. Det är det jag har arbetat med de senaste 14–15 åren. Jag älskar verkligen det. Jag tycker om att prata om produktledning. Jag tycker om att hjälpa andra att bygga produkter och att se vad som finns där ute, vad som fungerar och vad som inte fungerar, samt att lära mig nya metoder.

Så allt som rör produkter är en del av det som får mig att kliva upp på morgonen.

Hannah Clark: Då är du i gott sällskap här.

I dag ska vi prata om något som jag tror intresserar alla, nämligen verktyg. Hur produktteam kan fatta bättre beslut när de väljer verktyg för sina organisationer. Det är en ständig utmaning. Det här är också ett viktigt expertområde för dig. Vad var det ursprungligen som inspirerade dig att skapa det ramverk för produktval som vi snart ska prata om?

Moshe Mikanovsky: Ja. Jag har en podd som jag har varit med och lett i fyra år tillsammans med min vän Matt Green. Den heter Product for Product.

I podden går vi i princip igenom verktyg som produktpersoner använder. Det har alltid varit ett intresse för oss båda, fast från olika håll. För Matt började det när han gick över till produktledning. För mig handlade det om att prova olika produkter och välja produkter eftersom ingen annan valde dem åt mig och jag själv behövde göra jobbet.

Det är alltid väldigt intressant att se vad som finns där ute. Det är det vi gör i podden. Under inspelningen av olika avsnitt om olika ämnen och olika typer av produkter insåg jag att det finns vissa gemensamma nämnare kring varför människor använder specifika produkter, vad de tycker om med dem och vad de inte tycker om.

Och sådant. Vi intervjuade alltid användare av produkterna, såvida det inte rörde sig om ett nystartat företag. Då finns det inte så många användare, så vi tar in grundaren. Men i de flesta fall intervjuar vi användare. De har redan insikter och kunskap om hur produkten används, vad som fungerar och vad som inte fungerar. Utifrån det samlade jag många av dessa resonemang och saker man bör leta efter, vilket fick mig att samla allt i ett ramverk som jag gärna delar med andra.

Hannah Clark: Utifrån din erfarenhet: om vi vill prata om några av de misstag som människor gör innan vi går in på det rätta sättet att göra saker, eller ett ramverk för hur man gör det på bästa sätt för sin organisation, vilka är då några av de vanligaste misstagen som produktorganisationer gör när de väljer nya verktyg? Och vilka konsekvenser brukar de misstagen leda till?

Moshe Mikanovsky: Ja, jag tror främst att det handlar om hur de väljer verktygen och om att de inte undersöker vilket verktyg som passar deras organisation bäst. Det är den första saken. Men det handlar också om att de inte riktigt förstår verktygen innan de väljer dem. Det är vanligt.

Vi blir alltid väldigt entusiastiska över ett nytt verktyg. Vi letar efter det och ser vilka olika funktioner det kan erbjuda. Vi känner, eller tror, att det kommer att passa våra behov, men när vi börjar införa det kanske vi upptäcker att det inte riktigt är vad vi trodde. Eller så tittade vi kanske bara på marknadsföringsinformationen på leverantörens webbplats, och den berättade inte hela historien.

Demonstrationerna kanske inte heller berättade hela historien, eller så finns det olika fallgropar som vi upptäcker under arbetets gång. Det är alltså det jag ser många gånger: verktyget passar inte organisationen särskilt bra, och man har inte förstått tillräckligt hur produkten faktiskt kommer att fungera för organisationen.

Hannah Clark: Ja, det låter rimligt.

Okej. Då går vi igenom din urvalsprocess. Ditt ramverk börjar med att identifiera problem, därefter prioriterar och kortlistar man och sedan jämför man verktyg. Det är alltså ganska mycket förarbete innan man ens kommer till själva jämförelsen.

Varför är detta förarbete så viktigt innan man börjar jämföra funktioner?

Moshe Mikanovsky: Jag tror att det fungerar som med vilken annan produkt som helst. Eftersom jag har arbetat som produktperson i så många år försöker jag närma mig nästan allt jag gör som en produkt. Jag gjorde samma sak med detta. Det är verkligen viktigt att försöka förstå vilket det verkliga problemet är som vi försöker lösa.

Vi vill inte bygga funktioner för en lösning som ingen kommer att använda. På samma sätt behöver vi egentligen inte specifika funktioner om det inte finns något problem för oss att lösa. Att alla andra gör något betyder alltså inte att du måste göra det också, eller att det sätt som andra gör det på passar hur din organisation arbetar.

Det är därför det inledande förarbetet, innan man ens tittar på alla funktioner, handlar om att förstå vilka de verkliga problemen är som man försöker lösa. Man behöver förstå arbetet och vad produktteamets uppgift är, alltså varför man behöver välja de här verktygen. Därefter behöver man förstå prioriteringarna mellan allt detta.

Ibland vet vi att vi inte kan köpa alla produkter direkt. Ibland är det till och med svårt att få budget för en enda produkt. Därför behöver man prioritera det största problemet man har just nu. Det är kanske inte alltid ett problem, utan något som tar lång tid att göra, eller där det råder stor oordning och man behöver städa upp, eller vad det nu kan vara.

Utifrån det största problemet prioriterar man och säger: Okej, det här är verkligen det vi behöver leta efter först. Sedan skapar man nästan en färdplan för hur man väljer produkter och så småningom inför dem.

Hannah Clark: Okej, jag vill prata lite med dig om något intressant i den process du använder för att jämföra verktyg, nämligen produktfilosofi, som är det första kriteriet här.

För det första: vad menar du med produktfilosofi, och varför spelar det någon roll? Hur ser skillnader i filosofi egentligen ut, och hur påverkar de vilka verktyg som passar en organisation?

Moshe Mikanovsky: En sak som jag har lagt märke till genom samtal med människor, och som också bygger på mina egna erfarenheter och min medvärd Matts erfarenheter, är att vi inte är lika när det gäller hur vi vill arbeta, hur vi vill kommunicera eller vad vi lägger tonvikten på.

Det är det jag placerar under filosofi. Vissa av oss vill till exempel verkligen ha en enda produkt som löser allt. Alla olika funktioner vi behöver ska finnas där, så att vi inte behöver införa något annat. Men vi vet att sådana produkter ofta inte går särskilt djupt i var och en av funktionerna, utan i stället täcker väldigt mycket på bredden.

För andra är filosofin: Jag vill ha det bästa av det bästa för varje specifikt problem jag har. Jag vill att allt ska vara integrerat så att allting kan kommunicera med varandra, men det ökar också lösningens komplexitet. Det är bara ett exempel på en filosofi: vilka är vi egentligen som organisation?

Ibland är det svårt att definiera om man inte vet hur organisationen arbetar eller vem som fattar besluten. Men det är viktigt att leta efter den här informationen, eftersom den hjälper dig att ringa in en specifik produkt eller kortlista dina produktalternativ. En annan sådan filosofisk fråga är om du vill att produkten ska vara flexibel eller styrd.

Vissa produkter ger dig möjlighet att skapa vilket arbetsflöde du vill, definiera vilka fält du vill och så vidare. Det blir ibland väldigt generellt, men flexibelt. Jag använder det ordet medvetet. Varje organisation kommer att införa produkten på ett lite annorlunda sätt. Andra produkter i samma kategori kan vara mycket mer styrda och säga: Nej, du måste arbeta på det här sättet. Vi har bara byggt det så.

Jag säger inte att det ena är bättre än det andra. Ibland handlar det om organisationens utvecklingsnivå, inte så mycket om hur tidigt i byggandet av en produkt man befinner sig, utan mer om organisationens mognad och hur mogen den är. Om man till exempel inte känner till något särskilt sätt att arbeta med sprintar, hantera en produktbacklogg eller göra allt sådant, och får en produkt som styr detta, kommer produkten att lära organisationen processen.

Men den lär bara ut processen på ett sätt, trots att det finns många andra sätt att göra det på. När organisationen sedan har blivit mer mogen kanske den känner sig bekvämare med att använda en annan produkt som är mycket mer flexibel. Det är några av de saker jag letar efter i ramverket, redan innan man tittar på själva funktionerna: vilken kultur har ni, och vilka typer av produkter passar er bäst, och så vidare.

Hannah Clark: Okej. På tal om flexibilitet finns det ett annat kriterium som jag vill pressa dig lite på, nämligen faktorn kring hur mycket löpande tekniskt arbete som krävs. Det här är intressant. Hur bör team utvärdera de tekniska resurser som behövs för att integrera olika verktyg, och hur kan det hänga samman med produktens långsiktiga framgång?

Moshe Mikanovsky: Ja, det här hänger också samman med en sorts filosofi, min filosofi kring att bygga produkter i allmänhet, både för mitt eget företag och när jag arbetar som rådgivare åt andra företag. Den är att våra utvecklare verkligen bör fokusera på det mervärde vi skapar och inte uppfinna hjulet på nytt när det gäller sådant som miljontals andra utvecklare redan har utvecklat.

På samma sätt vill jag, när jag lägger till funktioner i min produkt, till exempel meddelanden i appen eller produktanalys, som alla redan finns i de här verktygen som vi har i dag, inte att mina utvecklare ska behöva bekymra sig om sådant. Jag föredrar att de integrerar det en gång med en mycket enkel integration och sedan i princip glömmer bort det.

Därefter kan produktchefen, eller andra personer utanför utvecklingsteamet, få möjlighet att definiera det som behöver definieras för att få ut så mycket värde som möjligt av produkten. Men vissa produkter i samma kategori, både för meddelanden i appen och för produktanalys, kräver faktiskt utvecklare på löpande basis. Ibland måste man definiera händelser som ska utlösas eller bestämma hur meddelanden i appen ska se ut och kännas, eller vad det nu kan vara.

För mig, och återigen är detta en personlig uppfattning, säger jag inte att den är rätt eller fel, är det slöseri med utvecklarnas tid. Jag föredrar att de arbetar med värde som är unikt för vår organisation.

Hannah Clark: Okej. När vi ändå talar om företagsvärderingar och sådant som är mer unikt har du också nämnt att kulturella faktorer, som företagsvärderingar och kommunikationsstilar, kan påverka valet av verktyg. Det tycker jag är väldigt intressant.

Jag skulle gärna höra en berättelse om hur det fungerar i praktiken, och hur de här mindre konkreta faktorerna kan påverka vilka verktyg som blir framgångsrika i en organisation.

Moshe Mikanovsky: Absolut. Jag kan ge dig ett exempel från en plats där jag arbetade och där vi hade väldigt svårt med asynkron kommunikation. Det var verkligen frustrerande för mig, eftersom vi arbetade på distans och man skulle kunna tro att asynkront arbete är en av de saker som hjälper en att samarbeta bättre på distans och att man inte behöver sitta i regelbundna möten.

Vi var tvungna att ha regelbundna möten hela tiden för att kunna föra arbetet framåt. Vi valde också att använda ett system för produktbackloggen. Jag tror att det var Jira, men i vilket sådant system som helst kan man definiera sina epikdelar i ett Confluence-dokument och sina berättelser med acceptanskriterier.

Man skulle förvänta sig att människor läste igenom detta och samarbetade genom kommentarer på något asynkront sätt. Men det fungerade helt enkelt inte. Varje gång någon sa till mig: Oj, det såg jag inte, eller tog upp det på ett möte, tänkte jag: Men allt det där fanns ju där.

Det var ett kulturellt problem som påverkade hur användbara våra produkter var för oss. Ibland kändes det som att jag simmade mot strömmen. Jag var tvungen att hålla ett helt utbildningstillfälle för att förklara vad asynkron kommunikation är och varför den är viktig. Jag minns inte ens om det hjälpte eller inte.

Det är det jag menar. Det här är bara ett exempel på hur organisationen arbetar. Ett verktyg kommer inte nödvändigtvis att lösa det. Ett verktyg kan hjälpa dig att förbättra kommunikationen om du faktiskt lägger ned arbetet på att använda det. Ett verktyg kan hjälpa dig att förbättra processerna om det passar hur organisationen arbetar.

Och vanligtvis är det inte tvärtom, även om verktyget skulle kunna bidra till att förändra hur företag arbetar. Jag skulle först titta på vilka kulturella begränsningar ni har och därefter anpassa verktyget efter dem.

Hannah Clark: Det låter mycket mer logiskt.

Låt oss gå tillbaka till funktionsjämförelser nu när vi har pratat om förarbetet och några av de faktorer man bör överväga innan man verkligen går in på detaljerna kring vad verktyget erbjuder.

Många team hoppar uppenbarligen direkt till funktionsjämförelser och priser när de utvärderar verktyg. Du nämnde det tidigare. Varför kommer de här faktorerna så sent i ditt utvärderingsramverk?

Moshe Mikanovsky: Främst för att jag inte vill att människor först ska titta på vad de kan göra med produkten, utan snarare på vilka resultat de försöker uppnå med den.

Funktioner är förmodligen det enklaste att jämföra. Organisationer kommer också att säga att de har den här funktionen och den där funktionen. Men när man tittar närmare på detaljerna, som ibland publiceras och ibland inte, måste man själv hitta informationen. Då upptäcker man om det verkligen är de funktioner man förväntade sig.

Ibland använder leverantörerna olika terminologi. Ibland har olika funktioner helt olika priser. Det är helt okej, men oftast är det vi konsumenter som måste gå igenom alla detaljer för att hitta rätt produkt för oss.

Men återigen tycker jag att det viktigaste är att välja och införa verktyg utifrån vilka resultat man vill uppnå, i stället för att bara fokusera på vad verktygen kan producera. Jag kan göra det här och jag kan göra det där, och därför är det här verktyget bättre än det andra.

Hannah Clark: Okej, jag vill komma in på den kanske mest frustrerande delen av att införa ett nytt verktyg: att få alla att börja använda det och att få alla att vara överens om hur det ska användas i organisationen.

Särskilt efter att man har gjort ett omfattande arbete för att hitta rätt verktyg, anpassa allt och ta hänsyn till alla dessa saker för att säkerställa att det är rätt verktyg, måste man fortfarande få människor att använda det och använda det på samma sätt. Vilka är några av de viktigaste strategierna för att säkerställa en framgångsrik användning i hela organisationen?

Moshe Mikanovsky: Okej, den första är att välja rätt verktyg, eller åtminstone det minst olämpliga verktyget man kan hitta, eftersom det alltid kommer att finnas saker som inte passar. Det andra är själva urvalsprocessen. Den är svår. Det beror på vem som äger processen och vilken styrning som gäller för ägandet och urvalet.

Det kan finnas motståndare redan där. Just nu har jag ingen specifik rekommendation. Det är något jag funderar på och som jag förmodligen kommer att utveckla i ramverket framöver, när jag har fått mer information även från andra människor. Om många deltar i urvalsprocessen kan det för det första ta väldigt lång tid att välja, och för det andra: har ni samtycke eller konsensus? Det är ytterligare en kulturell fråga i organisationen.

Sedan handlar det om vem som äger produkten, inte bara ur perspektivet att välja eller införa den, utan också om hur det historiskt har sett ut. Många gånger har IT ägt produkterna i organisationen eftersom det är programvara som måste installeras på en dator. Då äger IT produkten. Men IT bryr sig kanske inte särskilt mycket om huruvida den faktiskt har införts framgångsrikt eller inte. Därför har man alltid behövt någon annan som driver införandet. Ägandet är alltså också viktigt.

I dag kan produktverksamhet göra det enklare för vissa organisationer om de har en sådan funktion, eftersom jag tycker att frågan passar ganska bra där, särskilt om man vill standardisera den i hela organisationen. Då kan produktverksamheten förstå alla olika teams behov och även förstå skillnaderna mellan dem.

Den kan förstå vilka svårigheter som finns med att införa verktygen och verkligen använda dem i varje team. Det kan handla om personligheter, begränsningar i projektet eller många andra saker. Precis som med vilken annan produkt som helst måste vissa av oss arbeta hårt för att vår produkt ska införas ordentligt hos våra kunder.

Det här är dessutom en B2B-produkt. Alla produkter vi pratar om är B2B-produkter. Om du utvecklar en B2B-produkt vet du förmodligen vad jag pratar om, och du kanske har större förståelse för det. Om du inte bygger B2B-produkter kanske du inte riktigt ser den kopplingen. Det är inte alltid enkelt.

Det beror på organisationens storlek, hur många projekt ni har, hur många produkter ni har och många andra saker. Men övergripande skulle jag säga att det handlar om vem som fattar beslutet, vem som äger produkten, vilken typ av styrning ni har, hur människor faktiskt accepterar besluten och sedan för arbetet framåt, även genom iterationer. Man behöver inte införa allt på en gång.

Man kan prova olika saker och sedan iterera, precis som man skulle göra med vilken annan produkt som helst.

Hannah Clark: Ja, det låter rimligt. Att ha en introduktionsprocess som är lite mer stegvis. Åtminstone har man bättre tillgång till användarna i den här situationen. Det är en fördel.

Moshe, stort tack för att du var med oss i dag. Det här har varit väldigt informativt. Jag tycker att det har varit till stor hjälp, eftersom vi alla förr eller senare behöver välja nya verktyg och hela processen med att införa dem kan bli en resa. Vi uppskattar verkligen din vägledning. Var kan människor lära sig mer om ramverket för produktval som du har utvecklat och komma i kontakt med dig på nätet?

Moshe Mikanovsky: Ja, först och främst: nöjet är på min sida, och tack för att jag fick komma. Alla kan kontakta mig på LinkedIn. Du hittar mig genom mitt efternamn, Mikanovsky, och min webbplats är productsforgood.co. Jag har ramverket som en Miroverse-tavla. Det är publicerat på Miroverse. På min webbplats finns en länk till det under resurser.

Jag kommer också att dela det med dig, så att du kan lägga det i avsnittsbeskrivningen. Jag delar det gärna med alla. Du kan kopiera det och börja använda det. Där finns förklaringar och många resurser inuti ramverket, till exempel en Airtable-lista över produkter med viss kategorisering.

Det är fortfarande ett pågående arbete, eftersom det alltid kommer nya produkter. Jag hittar hela tiden nya produkter. Om något saknas där får du gärna kontakta mig på LinkedIn. Jag vill gärna höra från alla.

Hannah Clark: Ja, vi ser verkligen fram emot att dela det. Och tack så mycket för alla resurser och för din tid.

Moshe Mikanovsky: Nöjet är på min sida. Tack så mycket, Hannah.

Hannah Clark: Tack för att du lyssnade. Prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe för fler fantastiska insikter, guider och recensioner av verktyg. Du kan höra fler samtal som detta genom att prenumerera på CPO-klubben där du brukar lyssna på poddar.