Lære å sykle og bygge programvare

BikeArbeid har vært en skikkelig utfordring den siste tiden. Å være produktsjef er en fascinerende jobb - når du faktisk kommer til å gjøre den jobben. Jeg vet at det er en flippant ting å si, men du er virkelig det sentrale knutepunktet i en pågående slepekrig med salg, utvikling, kundeservice og ledelse i selskapet.

Noen mennesker mister siden det faktum at målet ikke er å bygge flere funksjoner eller det neste kule Web 2.0-programmet, men målet er å gi folk muligheten til å gjøre jobben sin mer effektivt og mer effektivt. Hver dag blir jeg spurt: "Hvilke funksjoner er det i neste utgivelse?"

Jeg svarer sjelden på spørsmålet fordi fokuset mitt ikke er på funksjoner i det hele tatt, mitt fokus er å bygge en løsning som gjør det mulig for markedsførere å gjøre jobben sin mer effektivt og mer effektivt. Å styrke kundene dine er hva det handler om. Hvis du fokuserer på store og skinnende ting, vil du ha store og skinnende ting uten kunder som bruker det.

Google bygget et imperium som starter med en enkelt tekstboks. Jeg har lest noen artikler der Yahoo! har faktisk kritisert Google for deres brukervennlighet. Hva er bedre brukervennlighet enn en tekstboks? Ikke misforstå meg, Yahoo! bygger noen fantastiske funksjoner i applikasjonene sine. Jeg elsker absolutt brukergrensesnittkomponentene deres, jeg bruker bare ikke programmene deres.

Google utdanner folk hvordan de skal sykle, og deretter fortsetter de å forbedre sykkelen. Ved å bygge mer effektive søk fra en enkelt tekstboks ga Google hundrevis av millioner mennesker muligheten til å gjøre jobbene sine bedre. Det fungerte, og det er derfor alle bruker det. Det var ikke pent, det hadde ikke en glamorøs hjemmeside, men det ga brukerne mulighet til å jobbe effektivt og effektivt.

Kan du forestille deg å sette deg 4 år på en 15-trinns terrengsykkel med bakspeil, signaler, vannkanne osv? Det ville du ikke. Så hvorfor vil du bygge et program som har 15 hastigheter, speil, signaler og en vannkanne? Du burde ikke gjøre det. Målet er å få dem til å lære å sykle slik at de kan komme fra punkt A til punkt B. Når punkt A til punkt B vokser i kompleksitet, trenger du en sykkel med ny funksjonalitet som støtter den. Men bare når brukeren faktisk kan ri på den!

Det betyr at treningshjul er bra (vi ser disse i form av trollmenn). Når en bruker faktisk kan sykle, kan du fjerne treningshjulene. Når brukeren blir flott på å sykle og trenger å sykle den raskere, så sett noen gir på den. Når brukeren trenger å løpe off-road, må du sette dem opp med en terrengsykkel. Når brukeren skal treffe trafikk, kast inn et speil. Og for de lange turene, kast inn vannkannen.

Google gjør dette med de progressive utgivelsene og kontinuerlige forbedringer i programvaren. Jeg elsker det faktum at de hekter meg med noe enkelt, og så fortsetter de å legge til det. De startet med en tekstboks, så la de til andre ting som bildesøk, bloggsøk, kodesøk, Googles startside, Google-dokumenter, Google-regneark ... Etter hvert som jeg har vant meg til å bruke programvaren deres, har de fortsatt å forbedre det for å støtte flere prosesser som får meg til å gjøre jobben min mer effektivt og mer effektivt.

Sykkelen er det som får personen fra punkt A til punkt B. Bygg en flott sykkel som er lett å sykle først. Når de lærer å sykle, så bekymre deg for hvordan du kan støtte flere prosesser ved å bygge ut ny funksjonalitet i applikasjonen din.

Husk - Google startet med en enkel tekstboks. Jeg vil utfordre deg til å se på de raskest voksende applikasjonene og vellykkede virksomhetene på nettet, og du vil finne en unik egenskap for dem alle ... de er enkle å bruke.

Avgårde til jobb…

3 Kommentarer

  1. 1

    Fantastisk innlegg! Likte spesielt analogien.

    Jeg tror at det som produktledere har problemer med i dag, er å definere nøyaktig når det er riktig tidspunkt for ekstra "sykkel"-funksjoner og hvordan de skal kobles til de allerede eksisterende funksjonene som brukerne deres har blitt vant til.

  2. 2

    Flott innlegg Doug. Så mange ting som virker så kult gjør egentlig bare jobben vanskeligere. Har du sett boken "Why Software Sucks" eller "Dreaming in Code"?

    Begge snakker om hvordan programvare blir ødelagt ved å prøve å være kul eller superfleksibel kontra bare å få jobben gjort enkelt.

Hva tror du?

Dette nettstedet bruker Akismet for å redusere spam. Lær hvordan kommentaren din behandles.