Produkt vs. prosjektledere: Marty Cagans tolv beste leksjoner for arbeid med produktgrupper

“Produktet er vanskelig.” Marty Cagan sier til et publikum av ivrige produktfolk på Appcues i Boston, Massachusetts og Pivotal Labs i New York City. “Og for produktledere som prøver å hjelpe selskaper overgang fra en tradisjonell prosjektleveringsorganisasjon til en moderne produktkultur; Når du jobber i visse typer organisasjoner (som tradisjonelle banker eller forsikringsselskaper), er det mange måter et produktteams formål kan misforstås og arbeid kan gå galt. "

Marty Cagan,
Grunnlegger & Partner, Silicon Valley Product Group

Marty er et husholdningsnavn i produktfellesskapet, når han reiser rundt i landet og verden, og hjelper de som prøver å navigere på sine respektive arbeidsplasser ved å diskutere hvorfor han tror ekte produktstyringsteknikker kan vinne i dagens selskaper.

Han mener også at når produkt- og prosjektledere lærer å skille mellom rollene og målene til produktstyring og prosjektleveranseteam, vil de lære hvordan du kan øke effektiviteten og bli vellykket å samarbeide. Her er de tolv beste karriertimene for produktledelse jeg har lært av Marty.

1. Forstå den smidige metoden

I det siste har det vært mye tilbakeslag mot teknikker som smidig, mager oppstart og designtenking, ifølge Marty. Han forsikrer at det absolutt ikke er noe galt med disse metodene, for de kan være svært nyttige når de brukes på riktige måter. Men når folk bruker smidige teknikker feil, oppstår forvirring. Mens han uttaler: "Det er grunnleggende ting som smidig utvikling prøver å oppnå, og det er de eneste tingene som smidige teknikker fungerer best for."

De fleste av fordelene som produkt- og prosjektgrupper får ved å bruke smidige teknikker er å lære å gjøre produktutgivelser minst annenhver uke (som på Zappos), i motsetning til hver tredje måned. Noen produktteam (som hos Amazon eller Etsy) slipper til og med en eller mange ganger om dagen.

"Vi trenger jevnlige, hyppige løslatebiler."

Men for å komme dit, forklarer Marty at produktteam forventes å gjennomgå et nivå av 'test og slipp automatisering' som han kaller det, og det endrer hele selskapets dynamikk. Endringene er aldri enkle, men nødvendige.

2. Funksjon som en mager oppstart

En av ideene bak mager oppstartsteknikk er å trenge å lære raskt for å innovere. For å innovere, må man utføre mange iterative tester, og mulighetene for iterasjon er begrenset ved oppstart. De fleste oppstart har bare 12–24 måneder før frøfinansieringen går ut, og større informasjonsteknologiorganisasjoner vil variere i antall forsøk de får innen en 12-måneders periode. Antall muligheter team i større selskaper får, avhenger i stor grad av mengden risiko prosjektledere er villige til å godta.

”Innovasjon er funksjonen til iterasjon. Det er en funksjon av å prøve ut ideer. Og vi må lære raskt for å innovere. ”

Selv om en typisk oppstart bare får tre til fire forsøk på iterasjon i løpet av fire til seks måneder, for eksempel, mener Marty at for å løse mest verdige problemer, bør startups skyve ut 50–100 forsøk.

"Jeg sier til grunnleggerne at hvis du vil ha noe håp om å løse problemer og bygge de riktige produktene, vil du trenge å ha minst 50 til 100 iterasjonsforsøk. Og det er bare ingen måte å gjøre det ved å bruke ingeniørene dine til å bygge fire måneders MVP-er. Hvis du har ingeniørene dine til å bygge en fire måneders MVP og distribuere den, og den faktisk ikke gjør som du vil, har du bare kastet bort fire måneder på en 18 måneders rullebane. "

3. Prosjektledede kontra produktledede selskaper

Mange organisasjoner ser i dag på informasjonsteknologiteamene som tjenere til virksomheten. I organisasjoner med et tankesett om produkt, er team der for å betjene kunder på måter som tilfredsstiller virksomhetens behov. Det er en tøff pille å svelge, men Marty innrømmer at realiteten er at en ekte produktsjef-rolle har mer relevans i organisasjoner som streber etter å være produktbedrifter.

Det som har en tendens til å skje hos organisasjoner som hevder å bruke smidige, men med et prosjektledet tankesett - de unnlater å styrke produktgruppene sine. Som Marty forklarer, "De ser ut til å glemme at grunnlaget for det smidige manifestet er å ta i bruk et produktinnstilte tankesett og la teamene eie problemløsningen."

"Hvis selskapet ditt ikke bruker agile på en måte som styrker teamene dine, trenger du ikke produktledere; trenger du forretningsanalytikere eller prosjektledere, sier Marty. Og mens han hevder produktsjefrollen utviklet seg fra forretningsanalytikerrollen, basert på min egen erfaring, er årsakene til dette uklare. Hvis noe, får forretningsanalytikere i store selskaper tittelen "produktsjef" fordi det er mer moteriktig.

Som noen som har jobbet tett med forretningsanalytikere og produktledere i flere år, har jeg lært følgende distinksjoner:

Produktsjefer spesialiserer seg i å lære om områder der det eksisterer problemer for virksomheten via sine kunder; og bruke sine ferdigheter til å generere potensielle løsninger med bruk av prototyper, eksperimenter og iterasjon. Bedriftsanalytikere spesialiserer seg i å lære om forretningsproblemer, og bruker sine ferdigheter til å dokumentere krav til designere, ingeniører og interessenter.

Selv om disse rollene kan se ut til å være like ved første øyekast, er forskjellene klare: produktledere genererer verdi via kundeadvokat, prototyper, eksperimenter og innsikt, mens forretningsanalytikere genererer verdi gjennom å forstå virksomheten, generere dokumentasjon og leveranser.

"La team ta eierskap for å løse problemer."
Kilde: http://mecca11.com

4. Product Discovery vs Product Delivery

I følge Marty er de to essensielle problemene i byggevarer:

  • Hva bygger vi (produktfunn)
  • Hvordan bygger vi det (produktlevering)

"Vi må innse at fordi dette i hovedsak er to forskjellige spørsmål, og vi må tilnærme dem med to forskjellige strategier," anbefaler Marty. "Mange organisasjoner i dag anerkjenner fortsatt ikke produktoppdagelse og levering som to aktiviteter som må være separate. Mange selskaper prøver å utføre disse aktivitetene som en ved å bruke de samme verktøyene. ”

"Bygger vi riktig produkt, og bygger vi produktet riktig?"

Selv om hastighet til oppdagelse og hastighet til implementering er viktig, skaper det til slutt unødvendige mengder teknisk og UX-gjeld til å konfliktfylle de to strategiene. Produkt- og prosjektgrupper må forstå forskjellen mellom å oppdage en løsning og levere en løsning; fordi de ved å gjøre det kan samarbeide om å formulere strategier som kompletterer hverandre.

Jeg har vært vitne til at prosjektgrupper bruker prototypingverktøy for å dele wireframes og prototypes med interessenter, og på sin side bruker de samme resultatene for å kommunisere til ingeniører hva de skal implementere. Selv om jeg kan forstå hvorfor dette gjøres, er tilnærmingen ufullstendig. Prototyping-verktøy er laget for produktgrupper for raskt å generere og kommunisere ideer for eksperimentering, læring og foredling. Når ideene er validert raskt og tilsvarende, tar prosjektgruppene læring og prototyper for å lage krav, brukerhistorier, bruk av saker og konseptmodeller, som deretter dokumenteres for designere, ingeniører og interessenter. Selv om noen kan føle at det er bortkastet å lage kravsdokumentasjon, er det bare bortkastet hvis dokumentene ikke er nyttige. Trikset er å lage nok dokumentasjon som ingeniører kan bruke, fordi det beskytter alle mot juridisk ansvar.

Husk at dette er en konseptuell modell, det vil si at den er designet for å formidle ideen om at selv om du kanskje tror at du vil bygge en bil, handler Discovery om å lære om å bygge bilen er den rette ideen eller ikke. Mens i Delivery er målet ikke bare å bygge en bil, men også å bygge bilen i målestokk. Kilde: https://svpg.com
"Å oppdage en løsning er forskjellig fra å levere en løsning."

AirBnB har tenkt ut sine egne måter å skille mellom funn og levering. I følge Marty omtaler AirBnB oppdagelsen som 'byggeprodukter som ikke skalerer', og levering som 'byggeprodukter som skalerer.' Årsaken til dette er at de tidlig i livet som oppstart brukte for mye første gang bygge produkter som ville skalere før de visste hva som var gjennomførbart og verdifullt. Dette fikk virksomheten til å lide mye og tvang dem til å revurdere tilnærmingen.

5. Validering av produkter vs Discovering Solutions

Når du oppdager en løsning, leter du ifølge Marty etter noe som er verdifullt, brukbart, gjennomførbart og levedyktig. Med andre ord, målene er å bygge et produkt som er:

  • Verdifullt: noe som folk vil ha
  • Brukbar: noe folk vil forstå hvordan de bruker
  • Gjennomførbart: noe virksomheten har råd til å bygge, mens du husker at designere og ingeniører kan bygge den med tiden, teknologien og ressursene som er tilgjengelige
  • Levedyktig: Virksomheten må kunne selge den og tjene på den

Derfor, som en produktansvarlig som jobber med et prosjektgruppe, er balansegangen å fordele tid til å oppdage hva kundene trenger, med å sette av tid til å bygge det som fungerer for bedriften og kundene.

“Prototyper gjøres under oppdagelse. Produktene gjøres under levering. "

Marty har lagt merke til, fra sin erfaring, at team ved oppstart har en tendens til å bygge produkter som tverrer mot markedsvalidering, mer enn virkelig innovative løsninger (Apple er sannsynligvis et av unntakene, fordi de har bygget virkelig innovative produkter - som den personlige datamaskinen , iPod og iPhone). Dette er mest sannsynlig fordi markedsvalidering har en tendens til å være mer komfortabel for oppstart, fordi du kan få tilgang til tilbakemeldinger fra markedet. Imidlertid er problemet sjelden forankret i markedet. Dette er tydelig, spesielt når det er alternative produkter i markedet som folk allerede bruker. Som Marty forklarer:

"Hvis produktet mislykkes, er det ikke fordi folk ikke trenger problemet sitt løst. Det er fordi løsningen din ikke er posisjonert for å være bedre enn resten. Faktisk, for å lykkes, må produktet ditt være banebrytende og være ti ganger bedre enn de andre. ”

Dette er muligens grunnen til at iPhone, Facebook og Instagram overgikk konkurrentene. Apple og Facebook fant ut løsninger som ikke var drevet av markedstrender, men som ble drevet av hva kundene likte med disse produktene i utgangspunktet: de er enkle, elegante, herlige, enkle å forstå og bare morsomme å bruke.

6. Minimum levedyktige produkter vs Minimum levedyktige prototyper

Det er mange forskjellige teknikker og prosesser som kan brukes i oppdagelsen. En av Martys favoritter er designsprinten. Tilsvarende er det mange teknikker og prosesser som kan brukes i levering. "Når du gjør oppdagelses iterasjoner, bygger du ikke ting som skalerer; prototyper du. Oppdagelse er ikke levering, sier Marty.

Marty mener at det er forskjellige typer prototyper som produktgrupper trenger å være kompetente i. I sin bok "INSPIRERT" beskriver han dem som:

  • Brukerprototyper
  • Gjennomførbarhetsprototyper
  • Live-data prototyper
  • Hybrid aka "Wizard of Oz" -prototyper

Hver type prototype er designet for spesifikke mål, som også kommer med sine egne feil og risikoer. Og noen prototyper er ment å testes kvalitativt, mens andre er ment å testes kvantitativt.

  • Kvantitativ testing: Testing som forteller oss hva som skjer eller ikke
  • Kvalitativ testing: Testing som forteller oss hvorfor ting skjer, og hvis det er et problem, kan vi teste for å finne ut av en løsning

Prototyping i oppdagelsesstadiet er viktig for leveringstrinnet, fordi ingeniører får muligheten til å optimalisere arbeidet sitt basert på det de lærte av prototypene, og deretter distribuere arbeidet sitt med selvtillit.

En designer som gjør prototyping har råd til å lage prototyper med mangler, fordi formålet er å lære raskt. I andre tilfeller bygger ingeniører også prototyper, av spesifikke grunner (f.eks. Å lage live-data-prototyper for å måle resultatene for datastyring). Imidlertid, hvis ingeniører leverer produkter med mangler i markedet, kan det skade deres omdømme. Kompetente ingeniører vil fortelle deg at når det gjelder produktlevering, må produktet prestere godt og være pålitelig, skalerbart, vedlikeholdbart og til og med globalisert og internasjonalisert hvis kravene krever det.

Siden oppdagelse ikke er levering, er det en grunn til at produktansvarlige og forretningsanalytikere må være tydelig på formålet med å frigjøre MVPer. Marty foreslår en måte å dempe dette ved å formulere hva ‘MVP’ betyr i forskjellige sammenhenger:

"Den enkleste måten å løse forvirringen når det gjelder å bygge et 'minimalt levedyktig produkt' er hvis du bare kommuniserer i situasjoner når du oppdager at du bygger en 'minimum levedyktig prototype', mange problemer løses. Prototyper gjøres i oppdagelsen. Produktene gjøres under levering. "

Minimum levedyktige prototyper er laget for å se om det er en bedre måte å nå dine designmål. I de øyeblikkene synes produktledere at designinnspill er verdifulle fordi det informerer om deres beslutninger. Minimum levedyktige prototyper er også laget fordi du vil at ingeniørene dine skal kunne gi deg råd om produktets retning; fordi du må finne ut om det levedyktige produktet er teknisk mulig. Forretningsanalytikere synes at tilbakemeldingen er verdifull fordi den informerer om produktkravene.

7. Produkt på skala: Bygg produkter du kan selge

I kommersiell eller privat sektor betyr å "selge" noe at du har overbevist kunder om å bruke produktet til en pris. I offentlig sektor eller i en organisasjon kan salg bety at du har overbevist interessenter om å bruke produktet fordi det vil øke produktiviteten og samtidig redusere friksjonen og kostnadene. Uansett betydning, bygger produkter som skalerer handler om å forbedre livskvaliteten for kundene.

Produktsjefer har en tendens til å tenke på de raskeste og billigste måtene å teste ideer på, som blant annet driver behovet deres for å snakke med kundene for å lære om smertepunktene. Det er innenfor samtaler og smertepunkter produktledere kan oppdage de beste ideene med hell.

Forretningsanalytikere og prosjektledere har en tendens til å tenke på de raskeste og beste måtene å levere løsninger for kunden. Det er det som driver deres behov for å tilfredsstille virksomheten. Det er også i ideene og resultatene de finner suksess.

Med disse distinksjonene i bakhodet, er det en sjanse for teamet. Mens produktgrupper fokuserer på kundekomponenten, fokuserer prosjektgrupper på forretningskomponenten. Og når det oppdages innsikt eller avveininger som påvirker respektive komponenter, utveksles informasjon, blir avtaler laget, prototyper foredles og produkter til slutt blir bygget, solgt og levert.

Her er et triks som Marty antyder kan hjelpe deg med å selge produktet i skala. Produkt- og prosjektgrupper kan identifisere pilotbrukere eller 'referansekunder' som Marty kaller dem for å bruke prototypene og produktene. Hvis de liker det, vil de fortelle det til andre, noe som fører til større adopsjon.

8. Lag to veikart: Feature Driven & Outcome-Driven

Et av de vanlige antimønstrene som Marty ofte ser, er selskaper som fremdeles er avhengige av funksjonsdrevne veikart. ”Veikart er nesten alltid det samme; prioriterte lister over funksjoner og prosjekter, sier han. "Microsoft Bing-teamet tilsto nylig at bare rundt ti prosent av veikartideene faktisk ryker ut. Dessverre er denne trenden ganske konsistent på tvers av bransjer. ”

Jeg har vokst til å akseptere i min karriere at det er umulig å hindre prosjektgrupper og interessenter i å tenke når det gjelder tidslinjer og funksjonslister. Så som produktperson er det opp til deg å ikke bare være talsmann for å forstå situasjoner før du oppdager løsninger; er du også ansvarlig for å stille spørsmålet: "Hva vil vi se at skal skje som et resultat av å legge til denne funksjonen?" Med andre ord, "Hva er ønsket resultat?"

En måte å takle denne utfordringen er å lage et kompromiss, og lage to veikart fra to sammenhenger:

  • Feature Driven: En liste over ønsket innholdsområder og funksjoner, ordnet på en projisert tidslinje
  • Utfallsdrevet: En liste over ønskede virksomhets-, kunde- eller brukeraktiviteter og scenarier, også arrangert på en prosjektert tidslinje

Nå, med to veikart, har vi en annen tag-teamstrategi. Produktgrupper fokuserer på den resultatdrevne komponenten, prosjektgruppene fokuserer på den funksjonsdrevne komponenten. Og sørg for at begge lag har tilgang til begge veikartene for å sikre at minst tidslinjene er synkronisert. Når innsikt, avveininger og oppsigelser blir oppdaget, koordinerer du hverandre deretter.

9. Det er to slags A-B-testing

A-B-testing er noe av en gullstandard for teknikker for produktutvikling. Imidlertid kan noen mennesker bli forvirret fordi det faktisk er to forskjellige typer A-B-testing, som Marty forklarer:

“Det er oppdagelses A-B-testing og levering A-B-testing. De er begge det samme konseptet, men de brukes annerledes og av forskjellige grunner. Discovery A-B-testing er mye mer begrenset og er rettet mot å finne bevis. Linjen for resultater senkes, men testen er gjennomført mye raskere. Noen A-B-tester vil til og med være bare inviterte, spesielt hvis det er B2B, snarere enn B2C. Levering A-B-testing blir derimot vanligvis gjort for statistisk betydning. ”

En annen sak som Marty ofte ser er når selskaper bare optimaliserer og kjører A-B-tester, og deretter kaller den produktstyringen. Gitt at hvert produktfirma skal gjøre dette, men det er ikke det eneste de skal gjøre. "Produktsjefer skal visstnok skape verdier, ikke bare optimalisere og fange den," sier han.

10. Håndtere etiske risikoer

To flotte produktselskaper, Ebay og Facebook, hadde veldig forskjellige tilnærminger til etiske risikoer. Da Marty jobbet på Ebay tidlig, minnes han om at omdømmesystemet var en av de viktigste funksjonene for dem.

"Den største gruppen mennesker som jobbet på Ebay var Trust and Safety Team på den tiden, fordi de visste at for kundene var tillit alt."

For Facebook var tvert imot tillit tilsynelatende ikke alt. De nærmet seg ikke virksomheten med etiske risikoer i tankene. Og nå, spesielt i kjølvannet av avsløringene fra PRISM og Cambridge Analytica, har Facebook jobbet lidenskapelig for å dempe disse utfordringene.

Mens ledere vanligvis har skylden for etiske spørsmål, er det ofte produktledere og designere som innser disse problemene først. Ledere presenterer mål for teamet med liten eller ingen tanker om etiske risikoer, og det er når disse målene spiller ut at etiske spørsmål oppstår.

Når de oppstår, er det viktig at produktledere håndterer dem riktig og effektivt. I stedet for bare å ta opp saken til lederne, burde de komme til dem med løsninger. Produktsjefer kunne utforske ulike måter å dempe etiske risikoer ved å måle påvirkningen på kundene, og forretningsanalytikere kan undersøke markedslandskapet for å identifisere og støtte håndteringen av risikoer på vegne av virksomheten.

11. Kompetente produktledere

Marty definerer den kompetente produktsjefen som å ha fire ting:

Den første er en dyp kunnskap om brukere og kunder. Dette virker som en skremmende oppgave, men hvis en produktsjef bare kommer ut av kontoret og snakker med brukere og kunder, kan de lett tilegne seg denne dype kunnskapen.

Det neste en kompetent produktsjef trenger å ha er en dyp kunnskap om dataene som kundene genererer. For å oppnå dette må en produktsjef bruke ting som webanalyseverktøy, salgsanalyseverktøy og en eller annen form for datavarehusverktøy som viser hvordan dataene endres over tid. "De mest vellykkede produktsjefer begynner dagen med dedikert tid med verktøyene slik at de vet hvordan de kan svare på spørsmål som kan komme opp gjennom dagen," sier Marty.

Den neste, og muligens vanskeligste delen av å være en kompetent produktsjef er å ha en dyp kunnskap om virksomheten. Som Marty forklarer:

"En produktsjef må forstå hvordan produktet deres markedsføres, selges, betales for og tjene penger. De må forstå de juridiske, personvern-, partnerskap- og kontraktsbegrensningene. Den eneste andre jobben i et selskap som krever dette kunnskapsnivået, er administrerende direktør. ”

Endelig må en kompetent produktsjef ha en dyp kunnskap om bransjen. De trenger å forstå det konkurrerende landskapet, og kanskje viktigst, relevante markedstrender.

12. Produkt- og prosjektledere kan samarbeide

Basert på alt Marty forklarte, ble jeg nok en gang påminnet om følgende punkter alle produkt- og prosjektfolk trenger å forstå:

  • Prosjektleveranseteam bestemmer de beste måtene å fordele ressurser til å bygge og levere produkter til rett tid til interessenter og brukere.
  • Produktlederteam bestemmer de beste måtene å bygge produkter på mens de løser problemer for interessenter og brukere.

Og det eneste som gjenstår er at prosjektleveranser og produktteam skal samarbeide for å sikre at de lykkes i rollene sine, og til slutt sikre at produktene presterer godt i markedet.

Jeg håper at Marty Cagans tolv karriereundervisning kan gi deg verdi, for på slutten av dagen, hva produkt- og prosjektgrupper har til felles: begge blir holdt ansvarlige for produktsuksess.