Product versus projectmanagers: de twaalf beste lessen van Marty Cagan voor productteamwerk

“Product is hard.” Zegt Marty Cagan tegen een publiek van enthousiaste productmensen bij Appcues in Boston, Massachusetts en Pivotal Labs in New York City. “En voor productmanagers die bedrijven proberen te helpen bij de overgang van een traditionele organisatie voor projectlevering naar een moderne productcultuur; Bij het werken in bepaalde soorten organisaties (zoals traditionele banken of verzekeringsmaatschappijen), zijn er veel manieren waarop het doel van een productteam verkeerd kan worden begrepen en het werk fout kan gaan. "

Marty Cagan,
Oprichter & Partner, Silicon Valley Product Group

Marty is een begrip in de productgemeenschap, terwijl hij door het land en de wereld reist en diegenen helpt die proberen hun respectievelijke werkplekken te navigeren door te bespreken waarom hij gelooft dat echte productmanagementtechnieken kunnen winnen in de bedrijven van vandaag.

Hij gelooft ook dat wanneer product- en projectleiders leren onderscheid te maken tussen de rollen en doelstellingen van productmanagement en projectleveringsteams, ze zullen leren hoe ze hun effectiviteit kunnen vergroten en succesvol kunnen samenwerken. Hier zijn de twaalf beste loopbaanlessen voor productmanagement die ik van Marty heb geleerd.

1. Begrijp de Agile-methode

Onlangs is er volgens Marty veel terugslag geweest tegen technieken zoals agile, lean startup en design thinking. Hij verzekert dat er absoluut niets mis is met deze methoden, want ze kunnen erg nuttig zijn als ze op de juiste manier worden gebruikt. Wanneer mensen agile technieken echter verkeerd gebruiken, ontstaat verwarring. Zoals hij stelt: "Er zijn fundamentele dingen die agile ontwikkeling nastreeft en dat zijn de enige dingen waar agile technieken het beste voor werken."

De meeste voordelen die product- en projectteams halen uit het gebruik van agile technieken, zijn het leren van productreleases minstens om de twee weken (zoals bij Zappos), in tegenstelling tot om de drie maanden. Sommige productteams (zoals bij Amazon of Etsy) brengen zelfs één of meerdere keren per dag uit.

"We hebben consistente, frequent release-voertuigen nodig."

Maar om daar te komen, legt Marty uit dat van productteams wordt verwacht dat ze een niveau van ‘test- en release-automatisering’ ondergaan zoals hij het noemt, en dat verandert de dynamiek van het bedrijf. De veranderingen zijn nooit gemakkelijk, maar noodzakelijk.

2. Functie als een Lean Startup

Een van de ideeën achter lean startup technieken is dat je snel moet leren om te innoveren. Om te innoveren, moet men veel iteratieve tests uitvoeren en de mogelijkheden voor iteratie zijn beperkt bij startups. De meeste startups hebben slechts ongeveer 12-24 maanden voordat hun startfinanciering op is, en grotere informatietechnologieorganisaties zullen variëren in het aantal pogingen dat ze binnen een tijdsbestek van 12 maanden krijgen. Het aantal kansen dat teams bij grotere bedrijven krijgen, hangt grotendeels af van het aantal risicoprojectleiders dat bereid is te accepteren.

“Innovatie is een functie van iteratie. Het is een functie om ideeën uit te proberen. En we moeten snel leren om te innoveren. "

Hoewel een typische start-up slechts drie tot vier pogingen tot iteratie krijgt, bijvoorbeeld binnen vier tot zes maanden, is Marty van mening dat startups 50–100 pogingen moeten uitvoeren om de meest waardevolle problemen op te lossen.

"Ik vertel de oprichters dat als je hoop wilt hebben op het oplossen van problemen en het bouwen van de juiste producten, je minimaal 50 tot 100 iteratiepogingen moet hebben. En er is gewoon geen manier om dat te doen door uw technici te gebruiken om vier maanden durende MVP's te bouwen. Als je technici een MVP van vier maanden laten bouwen en implementeren, en het doet niet echt wat je wilt, dan heb je vier maanden verspild aan een start- en landingsbaan van 18 maanden. "

3. Project-led versus product-led bedrijven

Veel organisaties zien hun informatietechnologieteams tegenwoordig als medewerkers van het bedrijf. In organisaties met een productmentaliteit zijn teams er om klanten te bedienen op manieren die voldoen aan de behoeften van het bedrijf. Het is een zware pil om te slikken, maar Marty geeft toe dat de realiteit is dat een echte rol als productmanager belangrijker is in organisaties die productbedrijven willen zijn.

Wat meestal gebeurt bij organisaties die beweren agile te gebruiken, maar met een projectgestuurde mentaliteit, verzuimen ze hun productteams te ondersteunen. Zoals Marty uitlegt: "Ze lijken te vergeten dat de basis van het agile manifest is om een ​​productmentaliteit te hanteren en teams in staat te stellen het probleemoplossend vermogen te bezitten."

“Als uw bedrijf geen agile gebruikt op een manier die uw teams machtigt, dan heeft u geen productmanagers nodig; u hebt bedrijfsanalisten of projectmanagers nodig ', zegt Marty. En hoewel hij beweert dat de rol van productmanager is geëvolueerd van de rol van bedrijfsanalist, op basis van mijn eigen ervaring, zijn de redenen hiervoor onduidelijk. Bedrijfsanalisten bij grote bedrijven krijgen in elk geval de titel ‘productmanager’ omdat deze modieuzer is.

Als iemand die al enkele jaren nauw samenwerkt met bedrijfsanalisten en productmanagers, heb ik het volgende onderscheid geleerd:

Productmanagers zijn gespecialiseerd in het leren over gebieden waar problemen voor het bedrijf bestaan ​​via haar klanten; en gebruiken hun vaardigheden om potentiële oplossingen te genereren met behulp van prototypes, experimenten en iteratie. Bedrijfsanalisten zijn gespecialiseerd in het leren over bedrijfsproblemen en gebruiken hun vaardigheden om vereisten voor ontwerpers, ingenieurs en belanghebbenden te documenteren.

Hoewel deze rollen op het eerste gezicht op elkaar lijken, zijn de verschillen duidelijk: productmanagers genereren waarde via klantbelangen, prototypes, experimenten en inzichten, terwijl bedrijfsanalisten waarde genereren via inzicht in de business, het genereren van documentatie en deliverables.

"Laat teams eigenaar worden van het oplossen van problemen."
Bron: http://mecca11.com

4. Productdetectie versus productlevering

Volgens Marty zijn de twee essentiële problemen bij het bouwen van producten:

  • Wat bouwen we (productdetectie)
  • Hoe bouwen we het (productlevering)

"We moeten ons realiseren dat dit in wezen twee verschillende vragen zijn en we moeten ze met twee verschillende strategieën benaderen", beveelt Marty aan. “Veel organisaties erkennen productontdekking en levering nog steeds niet als twee activiteiten die gescheiden moeten worden. Veel bedrijven proberen deze activiteiten als één uit te voeren, met dezelfde tools. ”

“Maken we het juiste product en bouwen we het product goed?”

Hoewel snelheid tot ontdekking en snelheid tot implementatie belangrijk zijn, creëert het samenvoegen van de twee strategieën uiteindelijk vermijdbare hoeveelheden technische en UX-schulden. Product- en projectteams moeten het verschil begrijpen tussen het vinden van een oplossing en het leveren van een oplossing; omdat ze hierdoor kunnen samenwerken om strategieën te formuleren die elkaar aanvullen.

Ik heb gezien dat projectteams prototypen gebruiken om draadframes en prototypen met belanghebbenden te delen en op hun beurt dezelfde resultaten gebruiken om aan ingenieurs te communiceren wat ze moeten implementeren. Hoewel ik kan begrijpen waarom dit wordt gedaan, is de aanpak onvolledig. Er worden prototyping-tools gemaakt waarmee productteams snel ideeën voor experimenten, leren en verfijning kunnen genereren en communiceren. Zodra de ideeën snel en dienovereenkomstig zijn gevalideerd, nemen projectteams de lessen en prototypes om vereisten, gebruikersverhalen, use cases en conceptmodellen te maken, die vervolgens worden gedocumenteerd voor ontwerpers, ingenieurs en belanghebbenden. Hoewel sommigen van mening kunnen zijn dat het opstellen van documentatie met vereisten een verspilling is, is het alleen zonde als de documenten niet nuttig zijn. De kunst is om voldoende documentatie te maken die ingenieurs kunnen gebruiken, omdat het iedereen beschermt tegen wettelijke aansprakelijkheid.

Houd in gedachten dat dit een conceptueel model is, d.w.z. het is ontworpen om het idee over te brengen dat hoewel je misschien denkt dat je een auto wilt bouwen, Discovery gaat over leren of het bouwen van de auto het juiste idee is. Terwijl bij Delivery het doel niet alleen is om een ​​auto te bouwen, maar ook om de auto op schaal te bouwen. Bron: https://svpg.com
"Een oplossing ontdekken is iets anders dan een oplossing leveren."

AirBnB heeft eigen manieren bedacht om onderscheid te maken tussen ontdekking en levering. Volgens Marty verwijst AirBnB naar ontdekking als 'bouwproducten die niet schalen' en levering als 'bouwproducten die wel schalen'. De reden hiervoor is dat ze in hun vroege leven als startup te veel initiële tijd hebben doorgebracht producten bouwen die opschalen voordat ze wisten wat haalbaar en waardevol was. Dit zorgde ervoor dat het bedrijf veel leed en dwong hen hun aanpak te heroverwegen.

5. Producten valideren versus oplossingen ontdekken

Bij het vinden van een oplossing bent u volgens Marty op zoek naar iets dat waardevol, bruikbaar, haalbaar en levensvatbaar is. Met andere woorden, de doelstellingen zijn om een ​​product te bouwen dat is:

  • Waardevol: iets dat mensen willen
  • Bruikbaar: iets wat mensen zullen begrijpen hoe te gebruiken
  • Uitvoerbaar: iets dat het bedrijf zich kan veroorloven om te bouwen, terwijl ontwerpers en ingenieurs het kunnen bouwen met de beschikbare tijd, technologie en middelen
  • Levensvatbaar: het bedrijf moet het kunnen verkopen en ervan kunnen profiteren

Daarom is het, als productmanager die met een projectteam werkt, om tijd toe te wijzen om te ontdekken wat klanten nodig hebben, met tijd om te bouwen wat werkt voor het bedrijf en de klanten.

“Prototypes worden gedaan in ontdekking. Producten worden afgeleverd. ”

Marty heeft, in zijn ervaring, opgemerkt dat teams bij startups de neiging hebben om producten te bouwen die naar marktvalidatie neigen, meer dan echt innovatieve oplossingen (Apple is waarschijnlijk een van de uitzonderingen, omdat ze echt innovatieve producten hebben gebouwd - zoals de personal computer , iPod en iPhone). Dit komt hoogstwaarschijnlijk omdat marktvalidatie meestal comfortabeler is voor startups, omdat u toegang kunt krijgen tot marktfeedback. Het probleem is echter zelden geworteld in de markt. Dit is vooral duidelijk wanneer er alternatieve producten op de markt zijn die mensen al gebruiken. Zoals Marty uitlegt:

“Als je product faalt, dan is dat niet omdat mensen hun probleem niet hoeven op te lossen. Het is omdat uw oplossing niet beter is dan de rest. Om succesvol te zijn, moet je product zelfs baanbrekend zijn en tien keer beter zijn dan de andere. ”

Dit is mogelijk de reden waarom de iPhone, Facebook en Instagram de concurrenten hebben overtroffen. Apple en Facebook bedachten oplossingen die niet werden aangedreven door markttrends, maar werden aangedreven door wat klanten in de eerste plaats leuk vonden aan deze producten: ze zijn eenvoudig, elegant, heerlijk, gemakkelijk te begrijpen en gewoon leuk om te gebruiken.

6. Minimum haalbare producten versus minimum haalbare prototypes

Er zijn veel verschillende technieken en processen die kunnen worden gebruikt bij het ontdekken. Een van Marty's favorieten is de ontwerpsprint. Evenzo zijn er veel technieken en processen die bij aflevering kunnen worden gebruikt. “Bij het doen van ontdekkingsiteraties bouw je geen dingen die schaalbaar zijn; u maakt een prototype. Ontdekking is geen levering, 'zegt Marty.

Marty gelooft dat er verschillende soorten prototypes zijn waar productteams competent in moeten zijn. In zijn boek "INSPIRED" beschrijft hij ze als:

  • Prototypen van gebruikers
  • Haalbaarheid prototypes
  • Live-data prototypes
  • Hybride aka "Wizard of Oz" -prototypes

Elk soort prototype is ontworpen voor specifieke doelstellingen, die ook hun eigen fouten en risico's met zich meebrengen. En sommige prototypes zijn bedoeld om kwalitatief te worden getest, terwijl andere bedoeld zijn om kwantitatief te worden getest.

  • Kwantitatief testen: testen die ons vertellen wat er gebeurt of niet
  • Kwalitatief testen: testen die ons vertellen waarom dingen gebeuren, en als er een probleem is, kunnen we testen om een ​​oplossing te vinden

Prototyping in de ontdekkingsfase is belangrijk voor de leveringsfase, omdat ingenieurs de mogelijkheid krijgen om hun werk te optimaliseren op basis van wat ze van de prototypes hebben geleerd, en vervolgens hun werk met vertrouwen in te zetten.

Een ontwerper die prototyping doet, kan het zich veroorloven om prototypes met fouten te maken, omdat het doel is om snel te leren. In andere gevallen bouwen ingenieurs ook prototypes om specifieke redenen (bijvoorbeeld het bouwen van live-data prototypes om de gegevensbeheerprestaties te meten). Als ingenieurs echter producten met fouten op de markt brengen, kan dit hun reputatie schaden. Bevoegde ingenieurs zullen u vertellen dat als het op de levering van producten aankomt, het product goed moet presteren en betrouwbaar, schaalbaar, onderhoudbaar en zelfs geglobaliseerd en geïnternationaliseerd moet zijn als de eisen dit vereisen.

Omdat ontdekking geen levering is, is het een reden dat productmanagers en bedrijfsanalisten duidelijk moeten zijn over het doel van het vrijgeven van MVP's. Marty suggereert een manier om dit te verminderen door te articuleren wat ‘MVP’ in verschillende contexten betekent:

“De eenvoudigste manier om de verwarring bij het bouwen van een‘ Minimaal haalbaar product ’op te lossen, is als je gewoon communiceert in situaties waarin je ontdekt dat je een‘ Minimaal haalbaar prototype ’bouwt. Veel problemen zijn opgelost. Prototypes worden gedaan in ontdekking. Producten worden bij aflevering gedaan. ”

Er worden minimaal levensvatbare prototypes gemaakt om te kijken of er een betere manier is om uw ontwerpdoelen te bereiken. Op die momenten vinden productmanagers die ontwerpinput waardevol omdat het hun productbeslissingen informeert. Er worden ook minimaal levensvatbare prototypes gemaakt omdat u wilt dat uw technici u kunnen adviseren over de richting van het product; omdat u moet bepalen of het minimaal haalbare product technisch haalbaar is. Bedrijfsanalisten vinden die feedback waardevol omdat deze de productvereisten informeert.

7. Product op schaal: bouw producten die u kunt verkopen

In de commerciële of particuliere sector betekent iets 'verkopen' dat u klanten hebt overtuigd om uw product tegen een prijs te gebruiken. In de openbare sector of binnen een organisatie kan verkopen betekenen dat u belanghebbenden hebt overtuigd om uw product te gebruiken, omdat dit de productiviteit verhoogt en wrijving en kosten minimaliseert. Ongeacht de betekenis gaat het bouwen van producten op die schaal over het verbeteren van de kwaliteit van leven voor klanten.

Productmanagers hebben de neiging om na te denken over de snelste en goedkoopste manieren om ideeën te testen, wat onder andere aanleiding is om met klanten te praten om meer te weten te komen over de pijnpunten. Het zit in gesprekken en pijnpunten waar productmanagers met succes de beste ideeën kunnen ontdekken.

Bedrijfsanalisten en projectmanagers denken vaak na over de snelste en beste manieren om oplossingen voor de klant te leveren. Het is wat hun behoefte drijft om het bedrijf tevreden te stellen. Het is ook in hun ideeën en resultaten dat ze succes vinden.

Met deze onderscheidingen in het achterhoofd is er een mogelijkheid voor een tagteam. Terwijl productteams zich richten op de klantcomponent, richten projectteams zich op de bedrijfscomponent. En wanneer inzichten of afwegingen worden ontdekt die van invloed zijn op respectieve componenten, wordt informatie uitgewisseld, worden afspraken gemaakt, prototypes worden verfijnd en worden producten uiteindelijk gebouwd, verkocht en afgeleverd.

Hier is een truc die volgens Marty je kan helpen je product op schaal te verkopen. Product- en projectteams kunnen pilotgebruikers of ‘referentieklanten’ identificeren, zoals Marty hen roept om de prototypes en producten te gebruiken. Als ze het leuk vinden, zullen ze het anderen vertellen, wat leidt tot een grotere acceptatie.

8. Maak twee routekaarten: functiegestuurd & resultaatgericht

Een van de meest voorkomende antipatronen die Marty vaak ziet, is dat bedrijven nog steeds verslaafd zijn aan functiegestuurde routekaarten. “Wegenkaarten zijn bijna altijd hetzelfde; geprioriteerde lijsten met functies en projecten ”, zegt hij. “Het Microsoft Bing-team heeft onlangs bekend dat slechts ongeveer tien procent van de wegenkaartideeën daadwerkelijk uitkomt. Helaas is deze trend vrij consistent in alle sectoren. ”

Ik ben in mijn carrière steeds meer gaan accepteren dat het onmogelijk is om te voorkomen dat projectteams en belanghebbenden denken in termen van tijdlijnen en functielijsten. Dus als productpersoon is het aan jou om niet alleen de pleitbezorger te zijn om situaties te begrijpen voordat je oplossingen ontdekt; je bent ook verantwoordelijk voor het stellen van de vraag: "Wat willen we zien gebeuren als gevolg van het toevoegen van deze functie?" Met andere woorden: "Wat is de gewenste uitkomst?"

Een manier om deze uitdaging aan te gaan, is een compromis te creëren en twee routekaarten te maken vanuit twee contexten:

  • Functiegedreven: een lijst met gewenste inhoudsgebieden en functies, gerangschikt op een geprojecteerde tijdlijn
  • Resultaatgestuurd: een lijst met gewenste bedrijfs-, klant- of gebruikersactiviteiten en scenario's, ook gerangschikt op een geprojecteerde tijdlijn

Nu hebben we met twee routekaarten een andere tag-teamstrategie. Productteams richten zich op de resultaatgerichte component, projectteams richten zich op de functiegestuurde component. En zorg ervoor dat beide teams toegang hebben tot beide routekaarten om ervoor te zorgen dat ten minste de tijdlijnen synchroon lopen. Wanneer inzichten, afwegingen en ontslagen worden ontdekt, coördineren dienovereenkomstig met elkaar.

9. Er zijn twee soorten A-B-tests

A-B-testen is enigszins een gouden standaard van technieken voor productontwikkeling. Sommige mensen kunnen echter in de war raken, omdat er eigenlijk twee verschillende soorten A-B-testen zijn, legt Marty uit:

“Er is A-B-ontdekkingstest en levering A-B-testen. Ze zijn beide hetzelfde concept, maar ze worden anders en om verschillende redenen gebruikt. Discovery A-B-testen zijn veel beperkter en gericht op het vinden van bewijs. De lat voor resultaten is verlaagd, maar de test is veel sneller voltooid. Sommige ontdekking-A-B-tests zijn zelfs alleen-uitnodigen, vooral als het B2B is in plaats van B2C. Aflevering A-B-testen worden daarentegen meestal gedaan voor statistische significantie. ”

Een ander probleem dat Marty vaak ziet, is wanneer bedrijven alleen A-B-tests optimaliseren en uitvoeren en dat productbeheer noemen. Toegegeven, elk productbedrijf zou dit moeten doen, maar het is niet het enige dat ze zouden moeten doen. "Productmanagers moeten waarde creëren, niet alleen optimaliseren en vastleggen," zegt hij.

10. Beheer van ethische risico's

Twee grote productbedrijven, Ebay en Facebook, hadden zeer verschillende benaderingen van ethische risico's. Toen Marty in de begintijd bij Ebay werkte, herinnert hij zich dat het reputatiesysteem een ​​van de belangrijkste functies voor hen was.

"De grootste groep mensen die bij Ebay werkten, was op dat moment het team voor vertrouwen en veiligheid, omdat ze wisten dat vertrouwen voor hun klanten alles was."

Voor Facebook daarentegen was vertrouwen blijkbaar niet alles. Ze benaderden hun bedrijf niet met ethische risico's in het achterhoofd. En nu, vooral na de onthullingen van PRISM en Cambridge Analytica, heeft Facebook gepassioneerd gewerkt om deze uitdagingen aan te gaan.

Terwijl leiders meestal de schuld hebben van ethische kwesties, zijn de productmanagers en ontwerpers vaak degenen die zich deze problemen het eerst realiseren. Leiders presenteren doelen aan het team met weinig of geen aandacht voor ethische risico's, en het is wanneer deze doelen uitkomen dat ethische problemen rijzen.

Wanneer ze zich voordoen, is het belangrijk dat productmanagers ze correct en effectief behandelen. In plaats van de kwestie alleen aan de orde te stellen bij de leiders, zouden ze naar hen moeten komen met oplossingen. Productmanagers kunnen verschillende manieren onderzoeken om ethische risico's te beperken door de impact op klanten te meten, en bedrijfsanalisten kunnen het marktlandschap onderzoeken om het risicobeheer namens het bedrijf te identificeren en te ondersteunen.

11. Bevoegde productmanagers

Marty definieert de competente productmanager als vier dingen:

De eerste is een grondige kennis van de gebruikers en klanten. Dit lijkt een ontmoedigende taak, maar als een productmanager net het kantoor verlaat en met gebruikers en klanten praat, kunnen ze deze diepgaande kennis gemakkelijk opdoen.

Het volgende dat een competente productmanager moet hebben, is een grondige kennis van de gegevens die klanten genereren. Om dit te bereiken, moet een productmanager dingen gebruiken zoals webanalysetools, verkoopanalysetools en een vorm van datawarehouse-tool die laat zien hoe de gegevens in de loop van de tijd veranderen. "De meeste succesvolle productmanagers beginnen hun dag met toegewijde tijd met die tools, zodat ze weten hoe ze vragen moeten beantwoorden die de hele dag kunnen opkomen," zegt Marty.

Het volgende en mogelijk moeilijkste deel om een ​​competente productmanager te zijn, is diepgaande kennis van het bedrijf. Zoals Marty uitlegt:

“Een productmanager moet begrijpen hoe hun product op de markt wordt gebracht, verkocht, betaald en geld verdient. Ze moeten de wettelijke, privacy-, partnerschaps- en contractuele beperkingen begrijpen. De enige andere baan in een bedrijf die dit kennisniveau vereist, is CEO. ”

Ten slotte moet een competente productmanager een grondige kennis van de industrie hebben. Ze moeten het concurrentielandschap begrijpen, en misschien nog belangrijker, relevante markttendensen.

12. Product- en projectleiders kunnen samenwerken

Op basis van alles wat Marty uitlegde, werd ik opnieuw herinnerd aan de volgende punten die alle product- en projectmensen moeten begrijpen:

  • Projectleveringsteams bepalen de beste manieren om middelen toe te wijzen om producten op tijd te bouwen en te leveren aan belanghebbenden en gebruikers.
  • Productmanagementteams bepalen de beste manieren om producten te bouwen en tegelijkertijd problemen voor belanghebbenden en gebruikers op te lossen.

En het enige dat overblijft, is dat projectlevering en productteams samenwerken om ervoor te zorgen dat ze in hun rol slagen, en uiteindelijk ervoor zorgen dat producten goed presteren in de markt.

Ik hoop dat de twaalf carrière-lessen van Marty Cagan je waarde kunnen bieden, omdat uiteindelijk de product- en projectteams met elkaar gemeen hebben: beide worden verantwoordelijk gehouden voor productsucces.