AI voor productdirecteuren: portfoliobeslissingen op je eigen productdata

De adoptie op de laatste release staat op 6% van de accounts in 30 dagen, en aan dat getal zie je niet of dat een trage start is of een dode feature. Wat het beslist is de trend, niet het niveau: ligt week 4 onder week 1, dan is het uitdoving en geen adoptie, en blijft er maar één segment hangen, dan heb je een vindbaarheidsprobleem en geen fitprobleem. Dat zijn tegengestelde besluiten. Het ene betekent de onboardingstap repareren waar mensen afhaken, het andere betekent stoppen met bouwen op deze lijn. Meestal moet je daartussen kiezen in een vergadering, met een percentage en zonder trend.

Elk kwartaal moet je dezelfde vertraging uitleggen, en de echte verklaring is politiek in plaats van technisch: de scope groeide halverwege het kwartaal door change-requests van sales, niet doordat engineering trager werd. Jij weet dat. Je kunt het in de kamer niet hard maken, dus het landt als een symptoom in plaats van als een besluit. PMI's Pulse of the Profession 2018 zette scope creep of ongecontroleerde wijzigingen op 52% van de projecten die in de twaalf maanden ervoor werden afgerond, tegen 43% vijf jaar eerder, en dat laat zien dat het structureel is en niet persoonlijk. Wat je in het MT nodig hebt is het wijzigingslog: welk item, welke datum, hoeveel scope erbij kwam, en wie erom vroeg.

"Ontbrekende functionaliteit" staat bij ruwweg 40% van de opzeggingen in het kwartaal, en de reflex die dat oproept kost een kwartaal bouwcapaciteit. Kruis die kolom met ARR en gebruiksdiepte en er blijft vaak weinig van over: kleine accounts die nooit onboardden, plus één groot verlies (Van Leeuwen) dat op prijs vertrok. Dezelfde kolom, de tegenovergestelde conclusie. Fix de onboarding, ga niet bouwen. Het ongemakkelijke is dat de verkeerde lezing de makkelijke is, want de reden-kolom staat al netjes geturfd en niemand heeft tijd om er vóór het roadmapoverleg mee in discussie te gaan.

Vraag of de laatste release is aangeslagen en je krijgt adoptie per segment met week 1 tegenover week 4, het ene segment dat bleef hangen, het cijfer van de vorige lancering ernaast, en de specifieke onboardingstap waar mensen afhaken. Dat is genoeg om vindbaarheid of fit hardop te zeggen en te verdedigen. Het oordeel blijft van jou. Wat verandert is dat je het neemt op de trend uit je eigen adoptie-export in plaats van op één percentage dat iemand voorlas.

Vraag waarom het initiatief opschoof en je krijgt de toegezegde items die verschoven, welk item twee keer schoof, hoeveel scope er bij elk halverwege het kwartaal bij kwam en de gedateerde verzoeken die dat veroorzaakten, gelezen uit het roadmapdeck en het wijzigingslog op je schijf. Daarmee wordt de vertraging geen bekentenis meer maar munitie: scope bevriezen op de toezegging, of de ruil openlijk accepteren. Je krijgt er ook de vooruitblik bij: welk kwartaal net zo gaat lopen tenzij er iets verandert, op een moment dat er nog tijd is om bij te sturen.

Vraag of ontbrekende functionaliteit echt de reden is dat klanten opzeggen en je krijgt de reden-kolom gekruist met ARR en gebruik, de accounts die nooit onboardden apart van dat ene grote verlies, en de nuchtere constatering dat de reden in de kolom en het bewijs elkaar tegenspreken. Waar het bestand het niet kan beslechten (geen gebruiksdiepte vastgelegd, geen exitgesprekken) zegt het dat, in plaats van het gat op te vullen. Dat is precies de bedoeling: het spreekt de gemakkelijke lezing tegen, en daarom kun je het veilig citeren in het roadmapoverleg.