Sådan bliver du en STOR produktchef

Oprindeligt offentliggjort på https://www.transformationlabs.io den 13. april 2019.

Jeg skrev oprindeligt følgende tilbage i sommeren 2007 (Ja 2007. Det er ikke en skrivefejl). Jeg var lige begyndt at blogge et par måneder tidligere. Det var et af de første blogindlæg, jeg skrev, der fik meget synlighed.

Dette indlæg blev oprindeligt skrevet i seks dele, men jeg tror, ​​det flyder godt som et enkelt længere blogindlæg. Rådgivning og observationer er alderen ret godt og tilbyder stadig nyttig indsigt. Så her er det, med et par mindre redigeringer sammenlignet med originalen. 2007 var for 12 år siden. Hvor længe siden var det? Slack, Uber & AirBnB var ikke engang blevet grundlagt. Twitter var knap et år gammel, og Facebook havde omkring 40 millioner brugere. Ja. det var så længe siden. :-).

Der er mange gode indlæg på nettet om at ansætte produktledere. En af de mest populære, jeg har set, har titlen "Sådan ansættes en produktadministrator". I det skriver Ken Norton, at ansættelse af ledere skal gøre eller se efter følgende:

  1. Ansæt alle de smarte mennesker
  2. Stærk teknisk baggrund
  3. "Spidey-sense" produktinstinkter og kreativitet
  4. Det er fortjent lederskab
  5. Mulighed for at kanalisere flere synspunkter
  6. Giv mig nogen, der er sendt noget

I resuméet skal ansættelse af ledere kigge efter smarte, tekniske og kreative mennesker med gode instinkter og lederegenskaber, der kan assimilere flere input og som ideelt set har været produktledere før.

For at sige det endnu mere kortfattet, hvis du ønsker at ansætte produktledere, skal du ansætte gode mennesker, der har været succesrige produktledere før.

OK, det kan være nødvendigt at give Ken noget slap, da han forklarer hvert af punkterne i detaljer og giver eksempler på spørgsmål til at stille potentielle kandidater. Ingen af ​​spørgsmålene er dog for hårde, hvis man antager, at kandidaten har et anstændigt kvalifikationssæt og gjort et rimeligt forberedelsesniveau.

Så det er sådan, du ansætter en god premierminister.

Men hvordan kan du være fantastisk PM?

For at besvare dette spørgsmål er følgende et sæt analoger til Ken's liste.

1. Må ikke bare lyde smart, handle smart og være smart

Langt de fleste produktledere er smarte og fokuserede. Eller for at sige det på en anden måde: kun et meget lille antal PM'er, jeg har stødt på, har været svimmel. Men så ærligt, i en gruppe er der altid et par, der ikke er der?

Generelt er der ingen mangel på hjernekraft i produktstyringssamfundet. Men det egentlige spørgsmål er ikke ren intellektuel hestekræft eller evnen til at formulere, hvad der skal gøres, men evnen til at omdanne alt dette potentiale til en kinetisk form, der gør det rigtige.

Intet makulerer en PM's troværdighed mere end opfattelsen - lad mig gentage - opfattelsen af, at han / hun snakker foredraget, men ikke kan gå.

Det betyder ikke noget, hvor meget af noget du gør. Hvis du ikke ses som nogen, der ruller ærmerne op og graver i detaljer, er du fodret til darttavlen.

Hvis en udviklingschef beder dig om at afklare et krav, og du ikke kan give et tilstrækkeligt svar, skal du ikke prøve at nynne og slå dig igennem det.

Fortæl dem, at du er nødt til at undersøge det spørgsmål lidt mere, så kom lige på det og kom tilbage med et klart og velbegrundet svar i kort rækkefølge.

Når det kommer til at give information, skal du vide, hvornår nok er nok. Der er ingen grund til at nedskrive et kæmpe sæt krav, når kun et par af disse krav på grund af udviklingsantal og tidsbegrænsninger har nogen chance for at komme ind i den næste udgivelse.

Hvem prøver du at imponere? Og hvis du ikke vidste, at kun et par krav kunne gøre det til den næste udgivelse, har du meget større problem at tackle.

2. Vær teknisk uden at blive teknolog

Produktledere er nødt til at fokusere på "hvad" og ikke "hvordan". Når man arbejder med Engineering, skal en premierminister definere, hvad der skal gøres for at gøre produktet bedre, hurtigere, stærkere, billigere osv.

"Hvordan" ved at gøre disse ting overlades til Engineering at finde ud af. OK, det er ikke lige så enkelt. Nogle gange er Product Managers nødt til at bekymre sig om hvordan, men som regel i forbindelse med en implementeringsdiskussion med Engineering eller ressourcetildeling med Sr. Management.

Men at tænke på, hvordan i løbet af kravfasen kan være livsfarligt for produktledere. Gå ikke i den fælde at sætte dig selv i engineering's sko, indtil og medmindre det er absolut nødvendigt.

Jeg har set følgende ske med teknisk kyndige PM'er. De beslutter (for tidligt), at et krav ikke vil blive præsenteret på grund af en (opfattet) teknisk begrænsning i den aktuelle kodebase. Eller at under et kravgennemgang bliver et vigtigt krav mindre vigtigt, fordi tekniske indvendinger fremsættes af Engineering.

Mit spørgsmål er:

Hvorfor skulle du, Product Manager, endda bekymre dig om potentielle tekniske problemer, hvis kravet er tilstrækkeligt vigtigt?

Kravet skal være klart og overbevisende. Udford teknikerteamet til at komme med en løsning, eller arbejd med dem, hvis din vejledning er nødvendig, men lad være med bare på grund af tekniske grunde.

Markeds- og kundebehov, ikke tekniske begrænsninger, skal være drivkrav.

Men i betragtning af at mange produktledere selv er tidligere ingeniører eller kommer med meget teknisk baggrund, kan det være vanskeligt at stoppe fra at krydse grænsen til ”Implementeringszonen”. Når det først sker, hvis du ikke fanger dig selv, er du dømt, fordi det kan være vanskeligt at krydse tilbage.

Jeg arbejdede med en produktchef, temmelig ung og meget mere teknisk end mig, der ikke kun ville tale om kravene, men derefter diskutere mulige løsninger i et krav om gennemgangsmøde.

I betragtning af at han havde en teknisk baggrund og ikke har brugt meget tid på at tale med kunder / partnere / kundeemner osv., Hvad ellers kunne han give? Naturligvis var hans embedsperiode kortvarig.

Når det kommer til implementering, hvis et krav er vigtigt nok, men du står over for begrænsninger af ressourcer eller teknologi, vil de fleste rationelle organisationer finde ud af, hvordan man gør det rigtige, så længe du præsenterer sagen tilstrækkeligt.

Jeg siger “rationelle organisationer”, fordi ikke alle organisationer er rationelle; i det mindste ikke fra et forretningsmæssigt perspektiv og vil ikke nødvendigvis gøre det, der er rigtigt for markedet. Hvis det er tilfældet i din virksomhed, kan det være på tide at finde en anden arbejdsgiver, så det kan gå videre i din karriere, og dine energier og viden kan udnyttes godt.

3. “Spidey-sense” instinkter er gode, hårde data er langt bedre

For en sport kendt for sin statistik har baseball i ligaen altid været et spil, der styres af instinktet. Ledere så situationen, diskuterede strategi og foretog opkald om batting rækkefølge, pitching ændringer, fielding positioner og mere. Dette var normen, indtil Billy Beanebecame manager for Oakland Athletics i slutningen af ​​1990'erne og bogstaveligt ændrede grundlæggende antagelser om, hvordan hold skulle styres. Historien er beskrevet detaljeret i bogen.

Kort sagt begyndte Beane at bruge hårde målinger i stort set alle aspekter af at styre holdet, fra at spejde efter og rekruttere undervurderede spillere til at beslutte, hvad spillerne skal køre for en given situation i spillet.

Resultatet: en fantastisk vinderrekord med en af ​​de laveste lønningslister i baseball.

F.eks. Bundede Atletik i 2002 de mægtige Yankees til de fleste sejre i American League. Begge hold havde 103 sejre den sæson. Den højtflyvende Yankees havde en samlet lønningsliste på $ 126M det samme år. Atletik havde en lønningsliste på kun $ 41M. dvs. kun 1/3 af Yankees.

I dag har mange hold hentet Beanes succes og faktisk spreder teknikkerne, som Beane anvender i baseball, til andre professionelle sportsgrene.

Softwareproduktstyring i dag er meget ligesom baseball var før Billy Beane. Selvom vi har evnen til at bruge målinger til at optimere resultaterne, indsamler vi sjældent, assimilerer og mine hårde analytiske data ved at træffe beslutninger om produktretning og funktionalitet.

Det er givetvis ikke altid nemt at få statistisk gyldige sæt af disse data. I en opstart eller i et lille firma med få kunder kan datasættets prøvestørrelse være for lille til at være meningsfuld.

Men det burde ikke stoppe os for at prøve, hvor det er muligt. I større virksomheder med større kundegrundlag og flere ressourcer bør brug af analytiske data til at understøtte og drive produktbeslutninger være normen. Men desværre er det ikke tilfældet.

Hvis produktstyring virkelig er så strategisk og vigtig, som vi hævder, er det, hvorfor overfører vi det således, at det ser adhoc og tilfældigt ud?

Jeg kan ikke fortælle dig, hvor mange gange jeg har set større produktbeslutninger taget baseret på empiri og personlige meninger. Udsagn som "Dette føles som den rigtige retning." Tales alt for ofte på strategiske planlægningsmøder.

Og lad os være meget tydelige, der er hårde omkostninger ved disse beslutninger med hensyn til ingeniørinvesteringer, marketingkampagner, salgsindsats, supportopkald osv. Dette inkluderer naturligvis ikke tabte eller i bedste fald forsinkede indtægter på grund af forkert prioritering af funktionalitet.

Hvorfor holder vi grupper som engineering, marketing og salg til en højere standard end vi selv holder?

Hvis udviklingshold planlagde deres tidsplan på instinkt, eller marketingteam styrede deres programmer på samme måde, eller salgsteam projicerede deres mål ved hjælp af mageføl, ville vi straks erstatte lederne af disse hold.

Men når det kommer til at tage produktbeslutninger, tages mange af dem uden nogen betydelig indsats for at indsamle og analysere hårde data. Der er mange undskyldninger, der gives for denne mangel på analytisk skarphed, men det faktum, at andre ikke beder dig eksplicit om hårde data, er ikke en undskyldning for ikke at få dem.

Opret en proces for at få de hårde data, der er nødvendige for at understøtte eller retfærdiggøre beslutninger. Ikke kun vil andre blive behageligt overrasket, men de vil også have svært ved at tilbagevise dine anbefalinger.

4. De fire cs for lederskab

Produktledere skal være ledere; en truisme uden tvivl. Men hvad betyder egentlig det at være en leder, og hvordan kan en produktchef være en stor leder? Lad os starte med at tale lidt om autoritet og ansvar. Begge er ord relateret til lederskab.

Ansvar: n. en form for pålidelighed; træk ved at være ansvarlig over for nogen for noget eller være ansvarlig for ens opførsel; for eksempel. ”Hun har et stort ansvar”.

Myndighed: n. magten eller retten til at give ordrer, tage handlinger eller træffe beslutninger; f.eks. "han har myndighed til at udstede warrants".

Ansvar er både en tillid og en pligt. Autoritet er noget, du får eller besidder i forbindelse med dit ansvar.

De to er klart indbyrdes relaterede. Hvis du har ansvaret for at gøre noget (f.eks. Opretholde loven), får du myndighed til at gøre de ting, der skal gøres for at levere dit ansvar (f.eks. Udstede warrants, foretage arrestationer osv.)

I tilfælde som retshåndhævelse er både ansvaret og myndigheden eksplicit defineret. I tilfælde af mange forretningsfunktioner, især matrixfunktioner såsom produktstyring, kan ansvaret være eksplicit, men myndigheden er implicit i rollen. Det er op til den enkelte produktchef at forstå det og ikke blive fanget af manglen på en hierarkisk rapporteringsstruktur med andre teams.

I et tidligt PM-job, efter et frustrerende produktstrategimøde med den øverste ledelse, lod en af ​​mine medproduktledere ud af den nu berømte linje:

"Produktstyring: Alt ansvar og ingen myndighed!"

Det var første gang, jeg nogensinde havde hørt den linje, og den eftermiddag kunne jeg ikke have været enig med ham mere. Jeg havde stået over for mine egne kampe med administrerende direktør i spørgsmål om produktretning.

Administrerende direktør havde stoppet mig på det første lysbillede af min præsentation af produktkøreplanen. Jeg havde et tilbud fra en kendt industrianalytiker, hvis tjenester vores firma havde betalt for. Administrerende direktør sagde, at han var uenig i, at citatet kan kalde analytikeren "en idiot i en abedrakt". Jeg vidste med det samme, at det skulle blive et groft møde.

En anden administrerende direktør ville regelmæssigt spille et spil kaldet, som jeg kaldte "Hvis du kan gætte, hvilken beslutning jeg allerede har truffet om dit produkt, så er vi enige om det spørgsmål". I begge disse scenarier er det svært at føle sig bemyndiget.

Men i de mellemliggende år har jeg lært lidt om både ansvar og autoritet og er ikke enig i den linje mere. Faktum er, at uanset om du har en administrerende direktør (og / eller managementteam), der "får det" eller ej, har du et job at gøre.

Så hvad kan du gøre for at bruge den autoritet, du har, og være den leder, du skal være?

Husk de fire cs for lederskab.

Troværdighed

Lederskab begynder med troværdighed.

troværdighed: n. kvaliteten af ​​at være troværdig eller pålidelig.

Hvis folk ikke er villige til at tro på dig og stole på det, du siger, er der ingen måde, du får myndighed til at gøre noget markant.

Hvordan bliver du troværdig?

For en produktchef er den bedste måde at blive betragtet som at have den mest viden i din organisation om, hvad der er nødvendigt for at gøre dit produkt succesfuldt.

Det er, hvad alle forventer af dig (du er produktchef!), Og hvis du kan overgå disse forventninger, vil du have mere end nok troværdighed, når du taler med folk. Nogle ting at sætte på din "Hvordan får jeg troværdighed?" Checkliste er:

  1. Kend dit produkt så godt som dine brugere ved det
  2. Har dyb forståelse af kundebehov og markedsdynamik gennem løbende kommunikation, interaktion og forskning.
  3. Indsamle mere hårde data om kundebrug, problemer og mål end dine kolleger
  4. Forstå behovene og afhængigheden af ​​dine interne teams (salg, support, marketing, ingeniørarbejde) og faktor dem i dine beslutninger
  5. Hjælp de andre teams til at lykkes i deres bestræbelser på at gøre dit produkt vellykket

At få troværdighed tager tid. Du har lidt af en afleveringsperiode, når du starter en ny position, så brug denne periode til at komme op i hastighed. Fortsæt derefter med at arbejde på det og sikre dig, at når du først har troværdighed, ikke mister du det.

Forpligtelse

Den anden lederskab er engagement. Den definition, jeg kan lide, er:

engagement: n. handlingen med at binde sig selv (intellektuelt eller følelsesmæssigt) til et handlingsforløb

Se nøje på den definition. Ordene er meget specifikke: "Handlingen med at binde sig selv ..." vægt på "bindende". Det er et magtfuldt ord. Det er ikke en løs tilknytning til noget, men en tæt tilknytning til det.

Du skal demonstrere engagement i dit produkts succes. Har du bundet dig selv til succes med dit produkt i dit nuværende job som produktchef? Eller går du bare igennem bevægelserne og bare "gør jobbet"?

Folk vil se, at en produktchef virkelig interesserer sig for produktsucces og finde ud af, hvad der er rigtigt og bedst for dine produkter. Hvis de ikke ser denne forpligtelse til succes, mister du hurtigt troværdigheden.

Meddelelse

Den tredje lederskab er kommunikation.

kommunikation: n. kunsten og teknikken med at bruge ord effektivt til at formidle information eller ideer.

Ingen troværdighed kan opretholdes, hvis der findes kommunikationsbarrierer mellem en leder og hendes tilhængere. Ledere skal være i stand til at kommunikere deres tanker, ideer, visioner og strategier klart og kortfattet, og på en sådan måde, at de, der lytter, er inspireret til at være en del af de planer, lederen foreslår.

Bemærk, at kommunikation både er en kunst og en teknik. Det er ikke tilstrækkeligt at formidle information i dokumenter eller i rote-form til at blive betragtet som kommunikation.

Folk er nødt til at forstå, hvad du kommunikerer til dem, og indse, hvorfor det er vigtigt at lytte til dig.

Sæt dig selv i deres position og tænk over, hvad de har brug for fra dig. Formidle oplysninger i formularer, som dem, der modtager den fra dig, finder værdifulde. Dette kan betyde lidt ekstra arbejde for dig oprindeligt - ikke alle har brug for (eller ønsker) at læse kravdokumenter - men når folk ser dig forstår deres referenceramme, vil de se værdien i at forstå din kommunikation.

Husk, at folk bombarderes med information dagligt, og de triager, hvad de læser, og hvad de lægger til side. Sørg for, at dine oplysninger får højeste prioritet ved at gøre det let for dem at forbruge.

Når du har troværdighed med dine kammerater, viser engagement i dit produkt og kommunikerer vision og detaljer klart, har du kendetegnene for at være en leder. Men hvad der virkelig kan skelne en god produktchef fra en stor, er modet.

Mod

Velkommen til den 4. og mest udfordrende af de 4 Cs.

Mod n. at handle i overensstemmelse med ens overbevisning, især på trods af kritik. at have modet til en overbevisning

Forskellen mellem en leder og en leder er lederens evne til at tage risici, blusse nye stier og få folk til at følge ham eller hende ned ad disse stier. Ledere kan blive rost, når de lykkes, men vil blive kritiseret rundt, når de ikke gør det.

Som produktchef er du en agent for positiv ændring i din virksomhed. Stå op for det, du mener er rigtigt, men gør først dit hjemmearbejde og være i stand til at støtte dine positioner med tillid. Ikke alle tager sig af dine anbefalinger eller initiativer, selvom du er rigtig. Men over tid kan der ske ændringer, selv i de mest konservative eller vanskelige miljøer.

I virksomheder, der er åbne for forandring, er det en kontinuerlig proces. I andre virksomheder kommer det i form af en revolution. Uanset hvilken type virksomhed, du arbejder i, hvis du vil rejse for at blive betragtet som en stor leder, så har modet til at tage, som Frost udtrykte det så godt, The Road Not Taken.

Den sidste strofe i Robert Frosts digt opsummerer ting pænt i mit sind.

Jeg skal fortælle dette med et suk
Et sted aldre og aldre derfra;
To veje divergerede i et træ og jeg-
Jeg tog den mindre rejste forbi,
Og det har gjort hele forskellen.

5. Vær en integrator, oversætter og kommunikator. Vær ikke en terminator

Jeg er sikker på, at du har hørt sætningen om, at produktadministratorer er "hjulets nav". Jeg kan virkelig ikke lide den linje. Hvem vil være navet i ethvert hjul? Det er som at sige, at nogen er hængslet på døren eller låsen på hætten. Boooring! Og ikke sandt.

Produktadministratorer er samlere, analysatorer og dispensere af information. De er routere til informationsstrøm. Og at være en fantastisk produktchef betyder at forstå, hvordan man optimerer informationsstrømmen, så andre teams i din virksomhed, der er direkte eller indirekte afhængige af dig for information, får den på en rettidig måde og i en form, de kan forstå og bruge.

Følgende billede er et groft eksempel på de største kommunikationsstier, der findes i en softwarevirksomhed. De blå er interne hold, og de røde er eksterne.

Jeg siger “groft eksempel”, fordi det virkelig kun repræsenterer et højt niveau af, hvordan information flyder. Det er beregnet til at repræsentere (ikke bogstaveligt defineret) større kommunikationsstrøm. Ikke alle links i diagrammet indeholder den samme mængde informationsstrøm; ikke alle knudepunkter bidrager med så meget information, som de modtager; og for at forhindre, at diagrammet bliver rodet, er et antal links, der med rette skal vises, ikke.

Jeg kalder disse kommunikationsveje for informationsforsyningskæden. Og som Product Manager er du direkte eller indirekte ansvarlig for en masse af de produktrelaterede oplysninger, der flyder gennem din organisation.

Hvor mange gange er du blevet spurgt, om der er en vis funktionalitet i en kommende version? Eller når en bestemt udgivelse kommer ud? Eller detaljerne i et betaprogram? Eller hvorvidt der foretages prisfastsættelse eller emballageændringer for at imødekomme markedets behov?

Folk stiller disse spørgsmål, fordi de træffer beslutninger og har brug for information for at beslutte klogt. Du kan have en betydelig positiv indflydelse på disse hold, hvis du forstår, hvilke informationsfolk har brug for, når de har brug for det, og i hvilken form de har brug for det? Hvis du kan gøre det for dem, vil de være i stand til at tage uddannede beslutninger før, strømline deres arbejde og være mere effektive. Lever små, sent eller vanskelige oplysninger, og det modsatte sker. Der er en reel topline-påvirkning af dårlig informationsstrøm i en virksomhed.

Hvis du virkelig ønsker at være analytisk omkring kortlægning af strømmen, kan du gøre det. Du skal se på alle stadier i produktudviklingscyklussen, fra undfangelse til færdiggørelse til lancering og videre og kortlægge, hvilke oplysninger forskellige grupper har brug for, og hvornår de har brug for det. En måde at repræsentere det på er via et varmekort, der kan ende med at se sådan ud.

De farvede celler repræsenterer områder, hvor kommunikationen sker under udviklingscyklussen. Jo dybere farve eller højere tal (fra 1-3 i dette tilfælde), desto mere aktivitet og informationsstrøm sker der.

Som du kan se, er Product Management dybt involveret i informationsstrømmen gennem alle faser i udviklingscyklussen, men mest kraftigt tidligt og i midten.

Marketing og salg for eksempel starter virkelig mod midten og har en tung informationsstrøm fra lanceringsfasen og fremefter.

Ved at forstå dette kan du bestemme, hvilke oplysninger du har brug for at producere og levere til disse grupper for at optimere deres aktiviteter og beslutninger. Husk, at dette ikke kun er en opgave for produktstyring. Ideelt set bruger alle grupper i virksomheden denne analyse til at optimere deres kommunikation. Men hvis du vil anvende en 80/20-regel (80% påvirkning for 20% indsats), skal hold som Product Management og Product Marketing være de første, der optimerer deres informationsstrøm til andre downstream-grupper.

Som teknologearbejdere findes vi i en informationsøkonomi. Og ligesom fremstillingsverdenen, hvor materialer, dele og lagerbehov optimeres for effektivitet og minimerer omkostningerne, kan informationsbehov forstås og leveringsprocesser optimeres for større effektivitet. Og på grund af vores rolle i at definere produktretning og kørselsstrategi, kan produktledere spille en nøglerolle i at optimere informationsforsyningskæden. Spørgsmålet er, er du op til opgaven?

6. Ej produktet fra undfangelse til færdiggørelse og videre

I mine tidlige job til produktstyring fokuserede jeg meget på processen med produktstyring. En administrerende direktør for en opstart, jeg arbejdede for, fortalte mig, at min tilgang til produktstyring var "meget akademisk".

Han så på sig selv som en "få det gjort på alle måder nødvendigt" iværksætter, mens jeg så på mig selv som en "få det gjort rigtigt" produktchef.

Opstart var et meget salgs- / dealdrevet firma, som mange startups har tendens til at være. At sætte produktstyring på plads i en sådan organisation er ikke let. Men at have en procesfokus er meget vigtig for en produktchef. Hver anden funktion, fra salg til marketing til udvikling til finansiering til HR implementering af processer.

Men da produktledere arbejder på tværs af disse funktionelle enheder, er de ikke klar over eller forstår, at selv i små virksomheder skal der være en gentagelig og skalerbar proces til:

vindende produkter!

Og selv om produktledere har et direkte ansvar inden for nogle af disse 10 forskellige områder og indirekte ansvar i andre, har PM'er absolut et hovedansvar for at føre tilsyn med og tilpasse aktiviteter fra andre teams i hele denne proces.

Jeg taler ikke om at styre disse mennesker direkte eller fortælle dem, hvad de skal gøre. Jeg antager, at folk ved, hvordan de udfører deres respektive job. Det, jeg siger, er, at hvis du ønsker at være en stor Product Manager, skal du overtage ejerskab (ikke nødvendigvis fuld kontrol) over processen og føre holdene i tilpasning gennem den.

Få tilpasning helt fra begyndelsen

Fra starten, mens du (og / eller dit PM-team) laver din research, skal du klart definere den kontekst og det ordforråd, der er nødvendigt for effektivt at formidle forskningsresultaterne til de tilsigtede målgrupper.

Dette ordforråd, hvad enten det drejer sig om personer / roller, forretningsfunktioner, forbrugerbehov, produktarkitektur eller funktionalitet eller noget andet, vil blive nøglen til at bringe alle ind i den samme referenceramme.

Dette er vigtigt, fordi det hjælper med at minimere fejlagtolkninger og fejlkommunikation under produktudviklings- og lanceringsprocessen. Hvis folk ikke er på linje tidligt i processen, vil du sandsynligvis se forvirring eller konflikt senere, da krav implementeres forkert eller med uacceptable begrænsninger.

Et eksempel på manglende justering

Som et eksempel arbejdede jeg, før jeg blev produktchef, hos et firma, der udviklede en ret sofistikeret rapporterings- og visualiseringsramme for forretnings- og økonomiske data.

En af ingeniørerne fik til opgave at skabe et fleksibelt middel til at give brugerne mulighed for at formatere og vise numerisk og karaktertekst (inklusive tid, dato og flere internationale valutaværdier) dynamisk til visning i pop-up-bokse, når enheder på skærmen var kørte musen-over. Er du med mig?

Han gik af, gjorde noget research og implementerede funktionalitet uden meget intern diskussion til at imødekomme kravet. Jeg var ansvarlig for at dokumentere funktionaliteten. Da jeg så, hvad han havde udviklet, var jeg bedøvet. Han havde skabt et fleksibelt - men utroligt kompliceret - formateringsundersystem. Ja, det kunne gøre alt og mere i forhold til kravet, men jeg er sikker på, at kun ingeniøren og et par andre tekniske personer faktisk kunne bruge det.

Dokumentationen alene for denne funktionalitet tog 60 sider (ud af en 600 sider referencemanual). Da folk i virksomheden så, hvor kompliceret det var, blev funktionaliteten fjernet fra produktet.

Hvad gik galt? En række ting, inklusive mangel på intern kommunikation, manglende tilsyn og manglende involvering fra produktlederen.

Hvor var han under alt dette? Jeg kan ikke huske nøjagtigt, men jeg tror, ​​han var ude, arbejdede med salg og forsøgte at afslutte nogle aftaler. At hjælpe salg er godt - lad mig ikke tage fejl, men ikke når det kommer til bekostning af det produkt, der bygges.

Få dine hænder gode og beskidte

Under udviklingscyklussen skal du arbejde for at holde andre teams som marketing, produktmarketing, salg, salgskonsulent, support, kanaler, alliancer og professionelle tjenester informeret og uddannet om udviklingsstatus og produktfunktionalitet. For mindre forbrugerprodukter eller websteder er dette muligvis ikke en vanskelig opgave, men for større virksomheds- eller datacentersoftware kan dette være en skræmmende opgave.

For en større udgivelse af et stort produkt vil en udviklingscyklus vare 12 måneder eller mere. Der er mange beslutninger, der træffes i løbet af denne cyklus, som skal overføres til downstream-hold for at sikre, at de kan planlægge forud for virkningen af ​​den nye udgivelse.

Stop ikke, før vedtagelsen er klar

Når produktet er frigivet, skal du holde fokus på produktet. Du kan ikke slippe og bare gå i gang med at indsamle krav til den næste udgivelse. Bliv forlovet med tidlige kunder, partnere og de kunder, der står over for team, såsom salg og professionelle tjenester. Hvis de tidlige kunder opgraderer til den nye udgivelse fra en tidligere version, kan du spore disse opgraderinger og følge op med kunderne for at se, hvordan opgraderingen gik, og hvilke kommentarer de har om den nye udgivelse.

Deltag i salgsteamets medlemmer på kunde- og kundeopkald, og lyt til, hvordan de beskriver og sælger den nye udgivelse, og hvad reaktionen er fra publikum.

  • Har sælgerne besked?
  • Er salgskonsulenterne uddannet tilstrækkeligt?
  • Slår demoerne op på målet?
  • Er det markedsbehov, som du har undersøgt og identificeret (åh for længe siden), stadig så relevant og kritisk, som det var dengang?

Disse spørgsmål (såvel som andre) bør være i fokus hos produktledere (og produktmarkedsførere) efter produktlancering.

Alt for ofte har jeg set folk arbejde på en udgivelse, få den lanceret og derefter glemme det i det væsentlige, når de begynder at fokusere på den næste udgivelse. Stor fejltagelse. Hvis salget kæmper for at sælge produktet som Product Manager, skal du tage udfordringen og arbejde for at identificere og fjerne barrierer.

Se ikke på det som en andens job, fordi det ikke er tilfældet. Ville en administrerende direktør lade en kæmpende salgsdirektør flyve i et kvarter eller to? Absolut ikke. Som premierminister skal du tage dine signaler fra administrerende direktør, og inden for rimelighed gøre hvad en administrerende direktør ville gøre. Vent ikke på, at andre fortæller dig, hvad der skal gøres. Tag ansvaret for dit produkt, sørg for, at det er bygget rigtigt, og sørg derefter for, at det tronces konkurrencen.

Nogle sidste ord.

Der er sandsynligvis meget mere at skrive om at være en fantastisk produktchef. Bortset fra at rejse sig til udfordringen på egen hånd, kan der være organisatoriske, politiske eller forretningsmæssige hindringer, der hindrer din vej til succes. Rollen som en produktchef i et større firma er meget forskellig fra den samme rolle i en opstart.

Det kan være meget svært at fremstille et stort indtryk i en større virksomhed, hvor strategi og større produktorienteringsbeslutninger ofte træffes på øverste ledelsesniveau, hvor produktledere får til opgave at udføre disse beslutninger. I en opstart er du sandsynligvis underbemandet med mere at gøre end tid til at gøre det.

I begge tilfælde kan du stadig stige over støjen og være effektiv.

Fokuser på de vigtigste mål, du har brug for at levere, og sikre, at de bliver gjort rettidigt.

Vær ikke en "just-in-time" produktadministrator. Det efterlader dig ikke vingestue, hvis du møder uventede forsinkelser og gør folk afhængige af din temmelig nervøse.

Ud over de vigtigste mål, skal du holde øje med steder, hvor du kan hjælpe med at forbedre, hvordan organisationerne bygger, markedsfører, sælger og understøtter dine produkter. Hvis du bemærker, at evalueringsprocessen for din software er besværlig, og at dette påvirker salget, skal du hjælpe med at identificere og definere løsningen.

Hvis du ser, at salgskonsulenter ikke er uddannet tilstrækkeligt, skal du arbejde for at få dem den hjælp, de har brug for. Hvis du bemærker, at kunderne bliver frustrerede over supportkvaliteten (på trods af hvad resultatet af tredjeparts kundetilfredshedsundersøgelsen siger), skal du hæve det med Supportledelse eller andre ledere. Pointen her er, at ud over de (n) bogstavelige produkt (er), du administrerer, identificerer måder at gøre virksomheden bedre og være en del af løsningsteamet.

Vær på vagt over for interne magtstrukturer og politiske kredse. Det er alt for let at blive besat af virksomhedspolitik eller undertrykt af fjendtlige magtstrukturer. Dette er oftere tilfældet i større virksomheder, især dem, der er vokset hurtigt, og hvor mange af de originale eller tidlige medarbejdere er steget til lederstillinger.

Håndtering af og navigering i interne magtstrukturer kunne være genstand for en række blogindlæg (hmmmm), men alt hvad jeg vil sige for nu er at træde omhyggeligt og bevidst når du er i fjendens område.

I sidste ende er der ingen magisk opskrift for at sikre, at du er en succesrig produktchef. Det kræver en masse indsats, indsigt og tænkning. Men hvis du husker disse 6 regler og forsøger at anvende dem, hvor det er muligt, vil du helt sikkert øge dine chancer for succes.

Saeed

Lidt feedback tak

Da du har læst så langt, hvorfor ikke give mig en lille anonym feedback på artiklen. 3 korte spørgsmål, det vil kun tage et minut, og det vil sætte et smil på mit ansigt. Hvad kunne være bedre end det? Klik her.

Om forfatteren

Saeed Khan er grundlægger af Transformation Labs. Han er konsulent og hjælper virksomheder med at forbedre deres produkter og produktorganisationer med at fremskynde produktsucces. Han taler jævnligt ved brancher om produktstyring og produktledelse. Du kan kontakte ham via Twitter @saeedwkhan eller via siden Kontakt os på Transformation Labs websted.