“Wat is uw productstrategie? JE HEBT EEN STRATEGIE NODIG.”

wanneer ik deze scène in mijn hoofd speel, hoor ik de CTO heel hoorbaar schreeuwen (slash pleiten) met ons productteam. Hij was gespannen. We hadden twee maanden geëxperimenteerd naar een zeer concreet doel en hadden veel vooruitgang geboekt. We hadden zo veel geleerd over wat verhinderde dat gebruikers zich aanmelden op de site, en het was een stuk duidelijker welke richting we moeten gaan. Maar we moesten onze ideeën nog testen.

dit paste niet goed bij de CTO omdat hij in werkelijkheid geen strategie wilde, maar een plan. Hij wilde een lijst van wat we gingen bouwen, en wanneer we het gingen bouwen. Hij wilde zeker zijn over wat we aan het doen waren toen we morgen allemaal kwamen, zodat hij onze vooruitgang kon meten op basis van hoeveel we bouwden. Het is niet zijn schuld. Dit is de manier waarop we werden geleerd om na te denken over productstrategie.

De meeste bedrijven vallen in de val van het denken over productstrategie als een plan om bepaalde functies en mogelijkheden te bouwen. We zeggen vaak dat onze productstrategie dingen zijn als:

• ” om een platform te creëren waarmee muziekproducenten hun muziek kunnen uploaden en delen.”
• ” om een backend systeem te maken waarmee het sales team hun leads kan beheren.”
• ” om een front van de funnel-website te maken die onze doelgebruikers op de markt brengt en converteert.”

Dit is geen strategie, Dit is een plan. Het probleem is dat wanneer we een productstrategie als een plan behandelen, het bijna altijd zal mislukken. Plannen houden geen rekening met onzekerheid of verandering. Ze geven ons een vals gevoel van veiligheid. “Als we gewoon het plan volgen, zullen we slagen!”Helaas is er hier geen garantie voor succes. (Ik wou dat er was, onze banen zouden zo veel gemakkelijker!)

deze productinitiatieven zijn niet slecht, ze worden gewoon op het verkeerde moment en met de verkeerde bedoelingen gecommuniceerd. Wanneer we onszelf vastzetten in het plannen van een set van functies (ehem, Roadmaps) te bouwen, we zelden stoppen met de vraag of die functies zijn de juiste dingen om te bouwen om onze doelen te bereiken. We richten ons niet meer op de resultaten en beoordelen het succes van teams op basis van resultaten.

we moeten een plan hebben, maar het plan zou niet “build feature x” moeten zijn. ons plan zou moeten zijn om onze zakelijke doelen te bereiken. We moeten overschakelen van het denken over productstrategie als iets dat van boven naar beneden wordt gedicteerd, en in plaats daarvan iets dat wordt blootgelegd als we leren wat ons zal helpen onze doelstellingen te bereiken.

productstrategie is een systeem van haalbare doelen en visies die samenwerken om het team af te stemmen op wenselijke resultaten voor zowel het bedrijf als uw klanten.

productstrategie komt voort uit experimenten met het oog op een doel. Initiatieven rond functies, producten en platforms worden op deze manier bewezen. Die KPI ‘s, OKR’ s en andere statistieken die u voor uw teams instelt, maken deel uit van de productstrategie. Maar, ze kunnen niet een succesvolle strategie te creëren op hun eigen.

we hebben een paar kernpunten nodig om onze productstrategie succesvol te laten zijn:

visie

de visie is uw hoogste niveau, ultieme weergave van waar het bedrijf of de business line naar toe gaat. In grote bedrijven, u wilt dit te beperken tot de business line of customer journey. In kleinere bedrijven zal dit de algemene visie van uw bedrijf en product zijn. Denk hier op lange termijn, en houd het kwalitatief. Dit is een goede kans om te praten over concurrenten, hoe klanten je zullen zien, en ambities voor uitbreiding.

Challenge

de challenge is het eerste zakelijke doel dat u moet bereiken op weg naar uw langetermijnvisie. Welk deel van uw customer journey of trechter moet eerst worden geoptimaliseerd? Het is gecommuniceerd als een strategische doelstelling die helpt bij het afstemmen en richten van uw team rond een bepaald aspect van productontwikkeling. Dit kan kwalitatief of kwantitatief zijn. Probeer deze stil te houden in brede, hoge termen. Deze is het moeilijkst voor mij om persoonlijk mijn hoofd rond te wikkelen, maar bekijk het voorbeeld hieronder voor wat duidelijkheid.

Doelvoorwaarde

De doelvoorwaarde helpt de uitdaging af te breken. Uitdagingen bestaan uit kleinere problemen die je onderweg moet aanpakken. Deze worden vastgesteld in termen van haalbare, meetbare metrics. Als je een doelvoorwaarde stelt, moet je team niet precies weten hoe het morgen te bereiken. Ze moeten een goed idee hebben waar ze doorheen moeten kijken.

huidige toestand

Dit is wat de huidige realiteit is vergeleken met de Doelvoorwaarde. Het moet worden gemeten en gekwantificeerd voordat het werk begint om de eerste streefvoorwaarde te bereiken.

deze bijdragen allemaal aan iets dat “Unified Field Theory” wordt genoemd, wat hier heel mooi wordt uitgelegd door Bill Costantino en Mike Rother van Toyota Kata. Als we producten bouwen, hebben we een drempel van kennis. We kunnen niet beginnen op Dag 1 en precies plannen om onze visie te bereiken. Er zijn te veel onbekenden en variabelen. In plaats daarvan stellen we onderweg doelen en verwijderen we obstakels door te experimenteren totdat we onze visie bereiken.

Dit kan het best worden uitgelegd door middel van een voorbeeld, dus we gaan Uber gebruiken. Laten we doen alsof je een productmanager werkt op het platform waarmee chauffeurs zich kunnen aanmelden.de CEO heeft verklaard dat de visie van het bedrijf is om Uber het goedkope en efficiënte alternatief te maken voor zowel het bezit van een voertuig als het nemen van het openbaar vervoer. (Hij zei dit echt in een interview, maar alles daarna is hypothetisch).

Challenge
dus als we de visie goed begrijpen, wil Uber dat mensen ze gebruiken als hun enige bron van transport. Ze zouden eerst willen kijken naar waarom andere mensen nemen andere vervoersmethoden nu in plaats van Uber. Ze kunnen gaan en mensen interviewen en vinden dat in bepaalde steden waar Uber is niet zo populair, is er een zeer lange wachttijd om een auto te krijgen. Ze zouden dit vergelijken met andere problemen en bepalen hoe groot het is in vergelijking. Laten we zeggen dat het de grootste uitdaging is op dit moment.de eerste doelen die ze misschien willen aanpakken is het verkorten van de wachttijden in steden waar het extreem lang is. Laten we zeggen dat iets meer dan 10 minuten gemiddeld te lang is, en we willen dat verlagen tot 5 minuten of minder, omdat we hebben gezien in steden met die wachttijden, mensen hebben 80% meer kans om Uber te gebruiken.

Dit is nu onze uitdaging: verlaag wachttijden in steden waar het meer dan 10 minuten is tot minder dan 5 minuten tegen 30 januari 2018.

Doelvoorwaarde
als productmanager wilt u nu uitzoeken wat de oorzaak is van die lange wachttijd. Het probleem in dit geval zou kunnen zijn dat er niet genoeg Auto ‘ s om dat gebied te bedienen. Dus onze metric we geven nu om de overname van nieuwe chauffeurs.

ons doel voor ons team moet meetbaar en haalbaar zijn, zoiets als: we willen ten minste één chauffeur aan boord voor elke 50 mensen in elke stad tegen 30 januari 2017.

als productmanager verantwoordelijk voor het onboardingproces voor nieuwe stuurprogramma ‘ s wordt u belast met het bijdragen aan die acquisitie. Je zou eerst meten hoeveel bestuurders per persoon in elke stad die je momenteel hebt (huidige toestand), dan vinden de obstakels die voorkomen dat nieuwe bestuurders zich vandaag aanmelden. Vervolgens experimenteer je om elk obstakel te verwijderen totdat je je doel hebt bereikt. Het product Kata legt uit hoe dat te doen.

dus laten we een stap terug en neem een kijkje op al die:

(u kunt hier een lege kopie van het productstrategie-canvas downloaden.)

als productmanager hebt u geen controle over al deze getallen. De visie wordt bepaald door CEO ‘s, CPO’ s, besturen en andere C-level Executives. De uitdaging wordt bepaald door het volgende niveau van management (VP van Product voor elke reis of Business Line).

Direct Managers helpen hun teams effectieve Doelvoorwaarden te stellen. In het begin moeten deze wellicht van het management worden doorgegeven. Als teams wennen aan deze manier van werken, kunnen de managers en het team samenwerken om ze op te zetten.

zodra deze vier items zijn ingesteld en gecommuniceerd, kan het team beginnen met het toepassen van de Product Kata methode om erachter te komen hoe de doelen te bereiken. Het is de verantwoordelijkheid van de productmanager en hun team om de gebruikersproblemen en andere obstakels te bepalen die het bereiken van die Doelvoorwaarde in de weg staan. Dan experimenteren ze om ze op te lossen.

Dit brengt iedereen op één lijn rond een strategisch doel en visie. Elk niveau van de portefeuille heeft zijn doelstellingen. Teams worden verantwoordelijk gehouden voor hun vooruitgang naar het doel waar ze verantwoordelijk voor zijn.

nu heb je waarschijnlijk gekeken naar dit en zei: “Nou Dit is niet een product strategie, het is een business strategie.”Ja, dit ziet eruit als een heleboel zakelijke doelstellingen, maar is dat niet waarom we een product gebouwd? Om onze bedrijfsdoelstellingen te bereiken? Product Management is de kunst van het oplossen van problemen van uw klant om uw zakelijke doelstellingen te bereiken. Als je niet beide dingen te doen, uw product is gewoon een mooi stukje code voor de show.

de volgende post zal gaan over het formatteren van uw product Roadmaps rond deze strategieën, en hoe te communiceren met belanghebbenden om experimenten aan te moedigen.

Melissa Perri is een Product Management en UX leraar en coach. Je kunt haar volgen op twitter @lissijean. Abonneer je op haar blog op melissaperri.com om nooit een post te missen, en te horen over de lancering van haar online Product Management school.