Noot van de redactie: dit is het derde deel in een serie over het opschalen van productbeheer van serie B naar IPO. Lees het eerste en tweede deel hier en hier.

Een succesvolle organisatie - product en anderszins - is lasergericht op de klant. Wanneer deze focus verloren gaat, merk je problemen zoals het volgende op:

• Inconsistente productervaringen
• Lage NPS
• Afnemende UX, en
• Slecht gebruikers- en/of klantbehoud.

Als het gaat om opschalen van Series B naar IPO, lijkt klantgerichtheid het vaakst op het nastreven van de juiste problemen en projecten. Naarmate een bedrijf groeit en de inzet stijgt, is er minder ruimte voor fouten. Waar u uw R&D-tijd in investeert, is van belang - en u zult de investeringen willen kiezen met maximale impact. Het opzetten van een organisatie waarin de klant centraal staat, vergroot uw kansen op het maken van de juiste keuzes.

In mijn eigen ervaring als VP of Product Management bij SendGrid en CPO bij GitLab, heb ik uit de eerste hand gezien hoe het behouden van de focus op de klanten en gebruikers resulteert in een product dat bestand is tegen de druk van hypergroei. En waar klantgerichtheid echt op neerkomt, is:

a) weten voor wie je bouwt, en
b) dingen bouwen die hun problemen effectief oplossen.

Om beide goed te krijgen, moet u een probleem- en oplossingsvalidatiekader opstellen, klanten interviewen, voorkomen dat u uw organigram verzendt en validatiebevindingen gebruiken om met vertrouwen nee te zeggen.

1. Stel een probleem- en oplossingsvalidatiekader op

Bij zowel SendGrid als GitLab hebben we een duidelijk probleem- en oplossingsvalidatieproces opgezet dat leidde tot wat we bouwden - en wat niet. Pas toen we er zeker van waren dat een voorgestelde oplossing een acuut klantprobleem effectief zou oplossen, kon de ontwikkeling beginnen.

Als we dat vertrouwen niet hadden, moesten we doorgaan met het validatieproces of het idee schrappen.

Met name bij GitLab hebben we onze productontwikkelingsstroom opgesplitst in twee sporen: validatie en bouwen. Hoewel deze twee tracks onafhankelijk van elkaar bewegen, kan een groot project of functie pas in de build-track worden opgenomen nadat deze met succes door de validatie is gekomen. Volgens de GitLab-handboek, is het doel van het validatietraject:

• Begrijpen het gebruikersprobleem dat we proberen op te lossen
• Identificeren zakelijke doelen en belangrijke statistieken om succes te bepalen
• Genereer hypothesen en onderzoek/experiment/gebruikerstest
• Definiëren van het Minimum Viable Change (MVC) ontwerppatroon en mogelijke toekomstige iteraties
• Verkleinen risico's voor waarde, bruikbaarheid, haalbaarheid en zakelijke levensvatbaarheid met kwalitatieve en kwantitatieve analyse

Voor probleemgebieden die nieuw, groot of niet goed begrepen zijn, werken PM's samen met UXers om het probleem grondig te begrijpen. Deze fase bestaat doorgaans uit het houden van ten minste vijf probleeminterviews met de beoogde gebruikers en vervolgens het vastleggen van een samenvatting van één pagina van het project in een Kans canvas, die wordt beoordeeld met product- en ontwerpleiderschap. Goedgekeurde canvasbeoordelingen gaan door naar oplossingsvalidatie.

Bij oplossingsvalidatie nemen ontwerpers het voortouw door een prototype te maken dat de juiste betrouwbaarheid biedt om een ​​oplossing voor het probleem voor te stellen. Vervolgens houden ontwerpers en PM's nog minstens vijf interviews met beoogde gebruikers om te valideren dat het prototypeontwerp het probleem van de gebruiker voldoende oplost. Van daaruit komt het project in de Build Track.

2. Maak klantinterviews topprioriteit

In mijn eerste 18 maanden bij SendGrid heb ik ongeveer 100 klanten ontmoet. Voor mijn eerste twee kwartalen bij GitLab maakte ik het "aantal voltooide klantinterviews per PM" tot een van de OKR's van de productorganisatie. Dit gaf mij en de productorganisatie een solide basiskennis van wie onze klanten waren en wat ze wilden. Dit onderzoek informeerde onze ontwikkelingsprioriteiten op organisatieniveau, stelde ons in staat waardevolle inzichten tussen teams te delen en bouwde onze geloofwaardigheid op.

Houd er rekening mee dat de tijd die u besteedt aan het praten met klanten, tijdverspilling kan zijn als u niet opzettelijk bent over wat u moet leren, of als u de best practices voor kwalitatieve sollicitatiegesprekken niet volgt. Het afnemen van interviews van hoge kwaliteit is een essentiële PM-vaardigheid, dus bij SendGrid nam het hele team deel aan een kwalitatieve interviewtraining door Cooper Design, en bij GitLab volgde het grootste deel van het team een ​​uitstekende externe cursus genaamd Continu interviewen van Teresa Torres. Het hele team op een bekwaam niveau krijgen met klantinterviews heeft enorme voordelen opgeleverd, aangezien elk teamlid in staat was om de kwaliteit van inzichten uit kostbare klantinterviewtijd te maximaliseren.

Interviewen van best practice-suggesties

Ik bereidde me voor op deze interviews door een lijst met vragen op te stellen die ik met elke klant doornam. Door deze consistentie kon ik de inzichten van de geïnterviewden onderling controleren. Als meerdere mensen allemaal hetzelfde naar voren brengen, is dat een goede indicatie dat hun sentiment kan worden gedeeld door een veel groter klantensegment.

Andere best practice-suggesties zijn:

• Stel open vragen en vermijd ja/nee of suggestieve vragen
• Vraag hen om te beschrijven wat ze daadwerkelijk hebben gedaan, in plaats van wat ze van plan zijn te doen
• Voor probleemgesprekken vermijd om uw oplossing voor het probleem tot het einde toe te pitchen, of helemaal niet
• Voor oplossingsgesprekken, breng een interactief prototype mee en vraag hen om het beoogde probleem op te lossen met behulp van het prototype zonder enige begeleiding of aansporing, en praat hardop over hun gevoelens en reacties op de ervaring
• Stel geïnterviewden gerust dat negatieve of harde feedback OK is en maak je geen zorgen om je te beledigen

Het wegnemen van frictie in interviewlogistiek en planning

Een van de redenen waarom veel PM's niet genoeg interviews afnemen, is dat het logistiek moeilijk is om klantinterviews te identificeren, te vinden, te plannen en af ​​te nemen. Doe er als productleider alles aan om frictie voor teamleden uit het proces te halen. Bij SendGrid en GitLab kozen we ervoor om een ​​UX Coordinator in te huren, die hielp met het vinden en plannen van klanten voor interviews.

Als u geen toegewijde persoon kunt inhuren om te helpen, overweeg dan andere manieren om het proces te automatiseren of te vereenvoudigen, zoals het bijhouden van een database van klanten/prospects die bereid zijn om geïnterviewd te worden, zodat klanten zich rechtstreeks in het product kunnen aanmelden voor interviewslots, of het hebben van Sales/Customer Success line-up interviews voor het productteam.

3. Verzend uw organigram niet

Wanneer een bedrijf geen herhaalbaar validatieproces heeft, is het veel gemakkelijker om dingen te bouwen die er niet toe doen. Een ding dat ik vaak zie, is dat PM-teams hun organigram beginnen te verzenden. Hoe dat eruit ziet, is wanneer u een product bouwt dat is geoptimaliseerd voor welk gebied u ook bezit, zonder rekening te houden met de use case(s) van de klant.

Toen ik bij CA Technologies werkte als senior director productmanagement, maakte ik deel uit van een nieuwe business unit die ontstond uit de samensmelting van vier productgebieden. Ons doel was om klanten te helpen begrijpen waarom deze business unit bestond, en we wilden echt synergie stimuleren tussen deze vier productlijnen. We bedachten een idee waarvan we dachten dat het al onze problemen zou oplossen.

Het zag er geweldig uit op papier. Het legde duidelijk uit waarom de business unit bestond, en het leek iets dat interessant zou zijn voor een klant. Toen stelden we ons een productkenmerk voor dat alles bij elkaar bracht, en we gingen meteen aan de slag om het te bouwen.

De integratie leidde niet tot cross-sales zoals we hadden bedoeld. Niemand gebruikte het. Omdat het niemand iets kon schelen. Ze hebben nooit gevraagd hoe de vier producten samen zouden werken. Heeft het een echt probleem voor hen opgelost? Het antwoord was nee.

Focus op de use case, niet op uw interne structuur

Als je elke productmanager naar zijn eigen deel van het product laat kijken, beginnen er naden tussen teams te verschijnen. Als PM of ontwerper wordt u gestimuleerd om resultaten te behalen in het gebied waarvan u eigenaar bent - niet noodzakelijkerwijs een breder resultaat voor het product als geheel. Wanneer dit in productdivisies gebeurt, krijg je een productervaring die onsamenhangend aanvoelt.

Bij GitLab heette een van onze belangrijkste functies het samenvoegverzoek, en meerdere teams droegen eraan bij. Op een gegeven moment realiseerden we ons dat de prestaties van deze functie traag waren geworden en last hadden van een rommelige gebruikerservaring. We hebben een UX-onderzoeksteam de functie voor samenvoegverzoeken laten controleren met specifieke instructies om teamgrenzen te negeren en ons te concentreren op de use case.

Het team bouwde een user journey map die goede en slechte ervaringen binnen de user journey aantoonde. Vervolgens konden we de slechte ervaringsoplossingen uitbesteden aan de teams die er eigenaar van waren en na verloop van tijd die end-to-end-ervaring verbeteren door ons te concentreren op het use-case-niveau.

4. Gebruik het validatieproces om vol vertrouwen nee te zeggen

Bij SendGrid hadden we een strak schip. Het bedrijf schaalde razendsnel, waardoor het product miljarden e-mails per dag moest bezorgen. In die omgeving waar elk aspect van het systeem tot enorme niveaus moet worden opgeschaald, had engineering een mentaliteit van "twee keer meten en één keer knippen". Dat niveau van strengheid en controle betekende dat het ontwikkelingsproces tijd kostte en dat de productorganisatie zeer selectief moest zijn met betrekking tot wat we engineering vroegen te bouwen - dus hebben we dingen vroegtijdig weggegooid die anders veel tijd en energie van ons ontwikkelingsteam zouden hebben gekost . Wat het probleem betreft, slaagde slechts ongeveer de helft voor het validatieproces.

Een leidinggevende vroeg ons bijvoorbeeld om onze zelfbedieningsaankoopstromen te upgraden om meerdere valuta's te accepteren. Deze persoon had een soortgelijk project bij een vorig bedrijf geleid en zag veel succes. We begonnen het project te valideren en interviewden potentiële klanten in verschillende landen waar we dachten dat we lokale valuta zouden willen aanbieden. Wat we hebben geleerd, is dat betalen in Amerikaanse dollars geen acuut pijnpunt was. De meeste van onze klanten spraken vloeiend Engels en waren gewend dingen met creditcards in USD te kopen.

Natuurlijk, het zou een leuke functie zijn geweest om extra valuta's te accommoderen, maar we ontdekten dat de huidige opzet geen wezenlijke invloed had op de aankoopbeslissingen van mensen. Ze gingen gewoon het beste product kopen. De extra inkomsten uit het aanbieden van extra valuta's zouden het dure prijskaartje niet waard zijn geweest om te implementeren, dus zeiden we nee.

Belangrijkste punten voor productleiders en oprichters in een vroeg stadium

1. Besteed tijd aan het leren kennen van uw klanten. Als productleider zal een goed begrip van voor wie u bouwt en hun problemen niet alleen helpen bij het sturen van prioriteiten op directieniveau, maar het zal ook uw geloofwaardigheid binnen uw teams vergroten.
2. Voer grote projecten uit via een duidelijk probleem- en oplossingsvalidatieproces. Vooral op grote schaal heb je niet de tijd om iets te bouwen waar je klanten niet om geven, of om een ​​oplossing te lanceren die hun problemen niet adequaat aanpakt. Een validatiekader verankert klantgerichtheid in uw PM-organisatiecultuur.
3. Verzend uw organigram niet. In plaats van een product te bouwen dat is geoptimaliseerd voor welk gebied uw team ook bezit, richt u zich op de use case(s) van de klant, zelfs als daarvoor bijdragen van meerdere teams nodig zijn.
4. Gebruik uw validatieproces om vol vertrouwen nee te zeggen. Hoe meer aandacht u kunt besteden aan de projecten en functies die u nastreeft, hoe beter. Het hebben van een vastgesteld validatieproces om naar terug te verwijzen, kan u helpen uw besluitvorming aan andere teams te communiceren.

Houd de volgende aflevering van de Scaling Product Management-serie in de gaten. Abonneer u op de OpenView nieuwsbrief en maak contact met mij op LinkedIn om als eerste te weten!

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoAiStream. Web3 gegevensintelligentie. Kennis versterkt. Toegang hier.
• De toekomst slaan met Adryenn Ashley. Toegang hier.
• Koop en verkoop aandelen in PRE-IPO-bedrijven met PREIPO®. Toegang hier.
• Bron: https://openviewpartners.com/blog/scaling-product-management-part-3-establishing-a-customer-first-org/