Hoe je tools kiest die je productteam daadwerkelijk zal gebruiken

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typfouten, want de bot is niet 100% van de tijd correct.

Hannah Clark: Kun je, zonder te tellen, snel zeggen hoeveel logins je momenteel wekelijks op je werk gebruikt? Als je het niet weet, druk dan op pauze en probeer ze te tellen. Ik wed dat het aantal schokkend is. Uit een rapport uit 2024 van CloudZero bleek zelfs dat de gemiddelde werknemer momenteel 36 cloudgebaseerde diensten per dag gebruikt, en engineeringteams gebruiken er twee keer zoveel.

Gek, toch? En hier is nog iets geks dat je waarschijnlijk niet zal verrassen. Volgens het onderzoek van CloudZero uit 2023 wordt meer dan 53% van de SaaS-licenties niet gebruikt. Met andere woorden: ondanks de voortdurende behoefte van onze organisaties aan tools ter ondersteuning van onze unieke bedrijfsvoering, verspillen we enorm veel geld aan tools die om de een of andere reden gewoon niet passen.

Mijn gast vandaag is Moshe Mikanovsky, oprichter en hoofdproductcoach bij Products for Good en medehost van de Product for Product-podcast. Moshe werkt sinds 1989 in productontwikkeling en software-engineering. Een belangrijk aandachtspunt van hem de afgelopen jaren is productteams helpen betere beslissingen te nemen over de tools die ze kiezen om te implementeren.

Moshe heeft een uitgebreid raamwerk ontwikkeld om organisaties te helpen de juiste tools voor hun behoeften te kiezen. Daarmee kunnen ze adoptie en productiviteit verhogen en tegelijk verspilling van uitgaven verminderen. We bespreken enkele hoogtepunten uit dit raamwerk die je vanaf vandaag kunnen helpen betere tools te kiezen. Laten we beginnen.

Welkom terug bij de The CPO Club-podcast. Vandaag ben ik hier met Moshe Mikanovsky. Hij is de oprichter en hoofdproductcoach bij Products for Good.

Moshe, heel erg bedankt dat je vandaag bij ons bent.

Moshe Mikanovsky: Bedankt dat je me hebt uitgenodigd, Hannah.

Hannah Clark: We beginnen zoals altijd. Kun je ons iets vertellen over je achtergrond en hoe je bent gekomen waar je nu bent?

Moshe Mikanovsky: Ja, ik ben vele jaren geleden begonnen als softwareontwikkelaar. De eerste twintig jaar van mijn loopbaan werkte ik aan de engineeringkant. Ik had het geluk bij kleine organisaties te werken. Of eigenlijk op locatie, waar ik rechtstreeks met klanten en gebruikers werkte. Ik denk dat ik daardoor een deel van mijn empathie voor gebruikers en hun behoeften heb ontwikkeld.

Destijds dus. Na twintig jaar besloot ik over te stappen naar productmanagement. Dat doe ik nu veertien à vijftien jaar. Ik vind het echt geweldig. Ik praat graag over productmanagement. Ik help andere mensen graag producten te bouwen. En ik kijk graag naar wat er beschikbaar is, wat werkt en wat niet werkt, en leer nieuwe methodologieën.

Alles wat met producten te maken heeft, maakt dus deel uit van wat mij 's ochtends wakker maakt.

Hannah Clark: Dan ben je hier in goed gezelschap.

Vandaag gaan we het hebben over iets dat volgens mij voor iedereen interessant is: tools. Hoe productteams betere beslissingen kunnen nemen bij het selecteren van tools voor hun organisaties. Een blijvende zorg. Dit is ook een belangrijk expertisegebied voor jou. Wat inspireerde je aanvankelijk om het productselectieraamwerk te creëren waar we het zo over gaan hebben?

Moshe Mikanovsky: Ja. Ik heb nu vier jaar lang een podcast die ik samen met mijn vriend Matt Green presenteer. Die heet The Product for Product.

In de podcast behandelen we in feite tools die mensen in productteams gebruiken. Dat heeft ons allebei altijd geïnteresseerd, zij het vanuit verschillende invalshoeken. Voor Matt was dat toen hij overstapte naar productmanagement; voor mij kwam het voort uit het uitproberen van verschillende producten en het kiezen van producten omdat niemand anders ze voor mij koos en ik het werk moest doen.

Het is altijd erg interessant om te zien wat er allemaal beschikbaar is. Dat doen we dus in de podcast. Naar aanleiding daarvan besefte ik tijdens het opnemen van verschillende afleveringen over verschillende onderwerpen en thematische producten dat er overeenkomsten zijn in waarom mensen specifieke producten gebruiken, wat ze eraan waarderen en wat niet.

En dergelijke zaken. We interviewden altijd gebruikers van de producten, tenzij het om een start-up ging. Dan zijn er niet veel gebruikers, dus nodigen we de oprichter uit. Maar meestal interviewen we gebruikers. Zij beschikken al over inzicht en kennis in hoe het product wordt gebruikt, wat werkt en wat niet werkt. Daaruit heb ik veel van die redenen en aandachtspunten verzameld. Dat bracht me ertoe alles samen te brengen in één raamwerk dat ik graag met mensen deel.

Hannah Clark: Als we het willen hebben over enkele misstappen die mensen maken voordat we ingaan op de juiste aanpak of een raamwerk om dingen misschien op de best mogelijke manier voor je organisatie te doen: wat zijn enkele van de meest voorkomende fouten die productorganisaties maken bij het kiezen van nieuwe tools, en tot welke gevolgen leiden die fouten doorgaans?

Moshe Mikanovsky: Ja, ik denk dat het vooral gaat om de manier waarop ze tools kiezen en dat ze niet onderzoeken of de tool goed bij hun organisatie past. Dat is het eerste. Daarnaast begrijpen ze de tools vaak niet echt voordat ze ze kiezen. Dat komt vaak voor.

We zijn altijd erg enthousiast over een nieuwe tool. We zoeken ernaar. We zien de verschillende functies die de tool kan bieden. We hebben het gevoel, of denken, dat de tool aan onze behoeften zal voldoen, maar zodra we hem gaan implementeren, merken we misschien dat hij niet precies is wat we dachten. Of misschien keken we alleen naar de marketinginformatie op de website van de leverancier, en vertelt die ons niet het volledige verhaal.

Of de demo's vertelden ons niet het volledige verhaal, of er zijn verschillende addertjes onder het gras die we tijdens het proces ontdekken. Dat zie ik dus vaak: de tool past niet optimaal bij de organisatie en er is onvoldoende begrip van hoe het product daadwerkelijk voor hen zal werken.

Hannah Clark: Ja, dat is logisch.

Laten we je selectieproces doorlopen. Je raamwerk begint met het identificeren van problemen. Daarna volgen prioritering en het maken van een shortlist, en vervolgens het vergelijken van tools. Er is dus behoorlijk wat voorbereidend werk voordat je überhaupt aan het vergelijken begint.

Waarom is dit voorbereidende werk zo belangrijk voordat je daadwerkelijk functies gaat vergelijken?

Moshe Mikanovsky: Ik denk dat het net als bij elk ander product is. Omdat ik al zo veel jaren als productpersoon werk, probeer ik bijna alles wat ik doe als een product te benaderen. Dat deed ik hier dus ook mee. Begrijpen wat het echte probleem is dat we proberen op te lossen, is ontzettend belangrijk.

We willen geen functies bouwen voor een oplossing die niemand zal gebruiken. Op dezelfde manier hebben we geen specifieke functies nodig als er voor ons geen probleem is om op te lossen. Het feit dat iedereen iets doet, betekent niet dat jij het ook moet doen, of dat de manier waarop anderen het doen past bij de manier waarop jouw organisatie werkt.

Daarom bestaat het voorbereidende werk aan het begin, voordat je überhaupt naar alle functies kijkt, uit het begrijpen van de echte problemen die je probeert op te lossen. Je moet begrijpen wat het werk is, wat de te verrichten taak van je productteam is. Daarvoor moet je die tools kiezen. En vervolgens: wat zijn de prioriteiten tussen al deze zaken?

Soms weten we dat we niet meteen alle producten kunnen kopen. Soms is zelfs het verkrijgen van budget voor één product al meer dan we kunnen krijgen. Daarom moet je prioriteren wat op dit moment echt het grootste probleem is. Dat is misschien niet altijd een probleem, maar iets waar we lang over doen, of waar veel rommel is die we moeten opruimen, of wat het ook maar is.

Op basis van dat grootste probleem geef je prioriteit aan wat je nodig hebt. Je zegt: oké, dit is echt het eerste waar we naar moeten zoeken. Daarna maak je bijna een routekaart voor het kiezen en uiteindelijk implementeren van je producten.

Hannah Clark: Oké, ik wil het met je hebben over iets interessants aan het proces dat je gebruikt om tools te vergelijken, namelijk de productfilosofie, het eerste criterium hier.

Allereerst: wat bedoel je met productfilosofie en waarom is dit belangrijk? Hoe zien de verschillen in filosofie er in de praktijk uit en hoe beïnvloeden ze de geschiktheid van tools voor een organisatie?

Moshe Mikanovsky: Een van de dingen die ik tijdens gesprekken met mensen heb opgemerkt — en het was ook mijn eigen ervaring en die van mijn cohost Matt — is dat we niet hetzelfde zijn in de manier waarop we graag werken, de manier waarop we graag communiceren en de zaken waarop we de nadruk leggen.

Dat is wat ik onder filosofie plaats. Sommigen van ons willen bijvoorbeeld echt één product dat alles oplost. Alle verschillende functies die we nodig hebben, moeten daarin zitten. We hoeven niets anders te implementeren. Maar we weten dat zulke producten vaak niet heel diep gaan in elk van die functies; ze gaan juist heel breed.

Bij anderen is de filosofie: ik wil het allerbeste voor elk specifiek probleem dat ik heb. Ik wil wel dat alles geïntegreerd is, zodat alles met elkaar communiceert, maar dat maakt de oplossing ook complexer. Dat is slechts één voorbeeld van een filosofie: wat zijn we eigenlijk als organisatie?

Soms is het moeilijk om dat te bepalen als je niet weet hoe je organisatie werkt en wie die beslissingen neemt. Toch is het belangrijk om deze informatie te onderzoeken, want ze helpt je een specifiek product te kiezen of je shortlist van producten samen te stellen. Een andere filosofie is de vraag of je wilt dat het product flexibel of bepalend is.

Sommige producten geven je de mogelijkheid om elke gewenste workflow te creëren, elk gewenst veld te definiëren en dergelijke. Dat is soms erg algemeen, maar wel flexibel — ik gebruik dat woord bewust. Elke organisatie zal het op een iets andere manier implementeren. Andere producten in dezelfde categorie kunnen juist heel bepalend zijn en zeggen: nee, je moet op deze manier werken.

We bouwen het alleen op die manier. Ik zeg niet dat het ene beter is dan het andere. Soms heeft het te maken met de fase waarin de organisatie zich bevindt. Niet zozeer met hoe vroeg ze zijn bij het bouwen van een product, maar meer met hun volwassenheid, met hoe volwassen ze zijn. Als ze bijvoorbeeld geen specifieke manier kennen om sprints uit te voeren, een backlog te verfijnen en al die andere zaken te doen, en ze een product krijgen dat daarin bepalend is, dan leert het product hun het proces.

Maar het leert hun het slechts op één manier, terwijl het ook op veel andere manieren kan. Misschien voelen ze zich, zodra ze volwassener zijn, prettiger bij het gebruik van een ander product dat daarvoor veel flexibeler is. Dat zijn enkele van de onderdelen waar ik in het raamwerk naar kijk, nog voordat je naar de functies kijkt: wat is je cultuur, welk type producten past beter bij jou, enzovoort.

Hannah Clark: Oké. En nu we het toch over flexibiliteit hebben: er is nog een criterium waar ik je wat over wil bevragen, namelijk de factor van doorlopende engineering die nodig is. Dit is een interessante. Hoe kunnen teams de engineeringcapaciteit beoordelen die nodig is om verschillende tools te integreren, en hoe hangt dat samen met het langetermijnsucces van dat product?

Moshe Mikanovsky: Ja, dit heeft ook te maken met een bepaalde filosofie — mijn filosofie over het bouwen van producten in het algemeen, voor mijn eigen bedrijf waar ik werk of wanneer ik andere bedrijven adviseer. Onze engineers zouden zich echt moeten richten op de toegevoegde waarde die we creëren, en niet het wiel opnieuw uitvinden voor allerlei zaken die miljoenen andere ontwikkelaars al eerder hebben ontwikkeld.

Op dezelfde manier geldt dat wanneer ik functies toevoeg aan mijn product, zoals berichten in de app of productanalyses, die allemaal al in deze tools bestaan, om maar een voorbeeld te noemen, ik niet wil dat mijn ontwikkelaars zich daar zorgen over maken. Ik heb liever dat ze het één keer integreren met een zeer eenvoudige integratie en het daarna min of meer vergeten.

Vervolgens geven ze mij, de productmanager, of andere mensen buiten het engineeringteam de mogelijkheid om te definiëren wat we moeten definiëren om de meeste waarde uit dit product te halen. Sommige producten in dezelfde categorie, bijvoorbeeld voor berichten in de app en productanalyses, vereisen echter wel voortdurend engineers, omdat je soms gebeurtenissen moet definiëren die ze moeten registreren, of moet bepalen hoe je het uiterlijk en het gevoel van berichten in de app vastlegt, of wat het ook maar is.

Voor mij — en nogmaals, dit is persoonlijk, dus ik zeg niet dat het goed of fout is — is dat verspilling van de tijd van ontwikkelaars. Ik heb liever dat ze werken aan waarde die uniek is voor onze organisatie.

Hannah Clark: Oké. Nu we het hebben over bedrijfswaarden en enkele van die meer unieke zaken: je hebt ook genoemd dat culturele factoren, zoals bedrijfswaarden en communicatiestijlen, de toolselectie kunnen beïnvloeden. Dat vind ik erg interessant.

Ik hoor graag een verhaal over hoe dat in de praktijk werkt en hoe deze minder tastbare elementen kunnen beïnvloeden welke tools succesvol kunnen zijn in een organisatie.

Moshe Mikanovsky: Zeker. Ik kan een voorbeeld geven van een plek waar ik heb gewerkt en waar we het heel moeilijk hadden met asynchrone communicatie. Dat irriteerde me enorm, want we werkten op afstand en je zou denken dat asynchroon werken op afstand juist een van die dingen is die je helpen beter samen te werken, en dat je niet voortdurend in reguliere vergaderingen hoeft te zitten.

Toch moesten we voortdurend in reguliere vergaderingen zitten om zaken vooruit te krijgen. We kozen er ook voor om een soort backlogsysteem te gebruiken. Ik denk dat het Jira was, maar in al die systemen geldt dat wanneer je bijvoorbeeld je epics definieert in een Confluence-document en je stories met acceptatiecriteria beschrijft, je verwacht dat mensen dat doornemen, het lezen en op de een of andere manier asynchroon samenwerken via de opmerkingen.

Maar het werkte gewoon niet. En elke keer dat mensen tegen me zeiden: 'O, dat heb ik niet gezien', of wanneer ze het tijdens vergaderingen openden, dacht ik: maar we hadden dat allemaal daar staan.

Dat was een cultureel probleem dat invloed had op hoe nuttig het gebruik van onze producten was. Soms had ik het gevoel dat ik tegen de stroom in zwom. Ik moest een hele sessie houden om uit te leggen wat asynchrone communicatie is en waarom die belangrijk is. Ik weet niet meer of het uiteindelijk hielp.

Dat is wat ik bedoel. Dit is slechts één voorbeeld van de manier waarop je organisatie werkt. Een tool gaat dat niet noodzakelijkerwijs oplossen. Een tool kan je helpen je communicatie te verbeteren als je moeite doet om hem daadwerkelijk te gebruiken. Een tool kan je helpen je processen te verbeteren als hij past bij de manier waarop je organisatie werkt.

Meestal werkt het niet andersom, hoewel een tool wel kan helpen veranderen hoe bedrijven werken. Maar ik zou eerst kijken naar de culturele beperkingen die je hebt en vervolgens de tool daarop afstemmen.

Hannah Clark: Dat is veel logischer.

Laten we nu teruggaan naar het vergelijken van functies, nu we het hebben gehad over een deel van het voorbereidende werk en over enkele factoren waarmee je rekening moet houden voordat je echt ingaat op de details van wat de tool te bieden heeft.

Veel teams springen bij het beoordelen van tools natuurlijk meteen naar het vergelijken van functies en prijzen. Dat noemde je eerder. Waarom komen deze factoren zo laat in je evaluatieraamwerk aan bod?

Moshe Mikanovsky: Vooral omdat ik niet wil dat mensen eerst kijken naar de output die ze kunnen behalen met het product dat ze gebruiken, maar meer naar de resultaten die ze proberen te bereiken.

Functies zijn waarschijnlijk het gemakkelijkst te vergelijken. Organisaties zullen je ook vertellen dat ze deze en die functie hebben. Maar wanneer je in de details duikt — die soms wel en soms niet gepubliceerd zijn, zodat je ze zelf moet vinden — kom je erachter of het werkelijk de functies zijn die je verwachtte.

Soms gebruiken ze daarvoor andere terminologie. Soms hanteren ze heel andere prijzen voor verschillende beschikbare functies. Dat is allemaal prima, maar meestal is het aan ons als consumenten om door al die details heen te spitten en het juiste product voor ons te vinden.

Maar nogmaals, ik denk dat het belangrijkste is dat we tools selecteren en implementeren op basis van de gewenste resultaten, in plaats van alleen op basis van output. Ik kan dit en ik kan dat, en daarom is deze tool beter dan de andere.

Hannah Clark: Oké, ik wil het hebben over misschien wel het frustrerendste onderdeel van het implementeren van een nieuwe tool: iedereen zover krijgen dat ze hem gaan gebruiken en dat iedereen binnen de organisatie op dezelfde manier begrijpt hoe hij moet worden gebruikt.

Zeker nadat je zo uitgebreid hebt gewerkt aan het vinden van de juiste tool en allerlei aanpassingen en overwegingen hebt meegenomen om er zeker van te zijn dat de tool bij je past, moet je mensen er nog steeds toe krijgen hem te gebruiken en hem op dezelfde manier te gebruiken. Wat zijn enkele belangrijke strategieën om een succesvolle adoptie binnen een organisatie te garanderen?

Moshe Mikanovsky: Oké, de eerste is het selecteren van de juiste tool, of in elk geval de minst ongeschikte tool die je kunt vinden, want er zullen altijd bepaalde problemen zijn. Het tweede is het selectieproces. Dat is een lastige. Het hangt ervan af wie eigenaar is en hoe het bestuur rond eigenaarschap en het selectieproces wordt ingericht.

Je kunt zelfs op dat moment al tegenstanders hebben. Op dit moment heb ik geen specifieke aanbeveling. Ik denk erover na en zal het raamwerk in de toekomst waarschijnlijk wat uitbreiden, wanneer ik ook meer informatie van andere mensen heb gekregen. Want als je veel mensen bij het selectieproces betrekt, kan het ten eerste heel lang duren om een keuze te maken. Ten tweede: heb je instemming of consensus? Dat is opnieuw een cultureel aspect van de organisatie.

En dan: wie is eigenaar van het product? Niet alleen vanuit het perspectief van de selectie of de implementatie. Hoe vaak was IT in het verleden, historisch gezien, eigenaar van producten in de organisatie omdat het software was die je op een computer moest installeren? IT werd dan de eigenaar. Maar vervolgens bekommerden ze zich er niet echt om of het product succesvol was geïmplementeerd.

Je had dus altijd een andere voorvechter nodig om het te implementeren. Eigenaarschap daarvan is dus ook belangrijk.

Tegenwoordig kan product operations het werk voor sommige organisaties eenvoudiger maken als ze over product operations beschikken, want ik zie dit heel goed binnen product operations passen, vooral als je het binnen de hele organisatie wilt standaardiseren. Dan kunnen zij alle behoeften van de verschillende teams begrijpen en ook begrijpen wat de verschillen tussen hen zijn.

Ze kunnen inzicht krijgen in de moeilijkheden bij de implementatie en bij het daadwerkelijke gebruik in elk team. Dat kan te maken hebben met persoonlijkheidskwesties, beperkingen van projecten of allerlei andere zaken. Net als bij elk ander product geldt dat sommigen van ons hard moeten werken om ervoor te zorgen dat ons product correct wordt geïmplementeerd bij onze klanten.

Dit is een B2B-product. Alle producten waar we het over hebben zijn B2B-producten. Als je een B2B-product ontwikkelt, weet je waarschijnlijk waar ik het over heb. Je hebt daar misschien ook meer empathie voor. Als je geen B2B-producten bouwt, kan daar een zekere kloof zitten. Het is soms niet gemakkelijk.

Het hangt af van de omvang van je organisatie, hoeveel projecten je hebt, hoeveel producten je hebt en allerlei andere factoren. Maar over het algemeen zou ik zeggen: wie neemt de beslissing, wie is de eigenaar, welk soort bestuur heb je, hoe accepteren mensen die beslissingen daadwerkelijk en hoe voeren ze ze vervolgens verder uit? Zelfs iteraties kun je toepassen, zodat je niet alles meteen hoeft te implementeren.

Je kunt verschillende dingen uitproberen en er vervolgens op itereren, zoals je dat met elk ander product zou doen.

Hannah Clark: Ja, dat is logisch. Een onboardingproces dat wat meer gefaseerd verloopt. Je hebt in deze situatie tenminste meer toegang tot je gebruikers. Dat is een voordeel.

Moshe, heel erg bedankt dat je vandaag bij ons was. Dit was zeer informatief. Ik denk dat het erg nuttig is geweest, want we komen allemaal op een bepaald moment voor de keuze van nieuwe tools te staan en het hele implementatieproces kan een behoorlijke reis zijn. We waarderen je begeleiding hierbij enorm. Waar kunnen mensen meer leren over dit productselectieraamwerk dat je hebt ontwikkeld en online contact met je opnemen?

Moshe Mikanovsky: Ja. Allereerst: graag gedaan en bedankt dat je me hebt uitgenodigd. Iedereen kan contact met me opnemen via LinkedIn. Je kunt me vinden op mijn achternaam, Mikanovsky, en mijn website is productsforgood.co. Ik heb het raamwerk als een Miroverse-bord. Het is gepubliceerd op Miroverse. Op mijn website staat onder 'resources' een link ernaartoe.

Maar ik deel het ook met jou, zodat je het in de beschrijving van de afleveringen kunt zetten. Ik deel het graag met iedereen. Je kunt het kopiëren en ermee aan de slag gaan. Er staan uitleg en veel bronnen in het raamwerk, zoals een Airtable-lijst met producten en enige categorisering.

Het is nog steeds werk in uitvoering, want er komen altijd nieuwe producten bij en ik ontdek steeds nieuwe producten. Als er iets ontbreekt, neem dan vooral contact met me op via LinkedIn. Ik hoor graag van iedereen.

Hannah Clark: Ja, we zouden het geweldig vinden om het te delen. En bedankt voor alle bronnen en voor je tijd.

Moshe Mikanovsky: Graag gedaan. Heel erg bedankt, Hannah.

Hannah Clark: Bedankt voor het luisteren. Abonneer je voor meer geweldige inzichten, handleidingen en toolbeoordelingen op onze nieuwsbrief via theproductmanager.com/subscribe. Je kunt meer gesprekken zoals dit beluisteren door je te abonneren op The CPO Club, waar je je podcasts ook maar beluistert.