Share
Før du kaster alle ressursene dine til å bygge en ny funksjon for produktet ditt, må du fastslå at du forfølger den riktige ideen.
Testing er ikke alltid det enkleste å gjøre - det er mange situasjoner hvor det kan virke lettere å bygge hvilken funksjon du har i tankene og bare se hva som faktisk skjer - men å skape en konsekvent teststrategi bidrar til å fastslå at du bruker din ressurser effektivt.
Enda bedre, den riktige tilnærmingen til testing kan gi deg raskere prosess med å arbeide gjennom produktkartplanen din. Avhengig av resultatene dine teller dukker opp, vil du oppdage nye muligheter for å legge til i prosessen.
Når du legger til nye funksjoner eller forbedringer av produktene dine, må du sørge for at du tilbyr dem på best mulig måte. Du må teste både etterspørsel og gjennomføring av hva du tilbyr til kundene dine. Det krever at du har noe å teste. MVP-modellen (minst levedyktig produkt) gir ofte den beste tilnærmingen til å skape noe som er verdt å teste.
Hvorvidt du allerede har et eksisterende produkt å jobbe med, eller ikke, tenk når det gjelder den minste endringen som gir deg verdifulle data. Hva vil tillate deg å få brukbar data uten å synke massevis av tid til en endring som kan vise seg å være ikke verdt din tid? Selvfølgelig kan en minimal funksjon fortsatt være massevis av arbeid, men målet er å ha så lite bortkastet arbeid som mulig samlet.
Siden du kan sannsynligvis gjette hva det vil ta å bygge produktet ditt, i hvert fall hvis du er erfaren i ditt felt, er det viktig å teste de tingene du ikke kan gjøre utdannede gjetninger om. Med mindre du har mind-reading ferdigheter, betyr det å forstå hvordan kundene dine svarer på det du bygger. Tinkering rundt med teknologier kan være morsomt, men det bør ikke være prioritet.
Du må tenke på hva som vil utgjøre en vellykket test.
Når du ser på et bestemt element på produktkartplanen, bør du vurdere hva kjerneelementene i funksjonen du vil legge til, er: Hva er de delene en kunde faktisk ser og samhandler med? Hvordan kan de skilles ut i betongstykker?
Hvis du for eksempel skaper en ny spade, samhandler kunden med håndtaket, skovlbladet og pinnen i mellom. Hvis du i stedet lager et nytt program, vil kundens samspill med det du har bygget, være langt mer begrenset.
Du må tenke på hva som vil utgjøre en vellykket test. Hvis du har kunder som allerede bruker et eksisterende produkt, vil få 50 prosent av dem til å prøve en ny funksjon være nok til å etablere et behov for neste funksjon du vil bygge? Trenger du dem til å fortsette å bruke funksjonen for å betrakte det til en vellykket test? Og hvis du er på utkikk etter nye brukere, hva slags retensjonsnivåer er nødvendige for å etablere gode data?
Kort sagt, du vil kunne se på dataene du har samlet på en bestemt dato, og vet automatisk om du skal gå videre med å bygge opp funksjonen helt, eller hvis du skal skrape ideen. Du bør vite hvilken suksess som ligner på forhånd.
Når du har brutt ned hva du kan sette foran en kunde, bør du vurdere den enkleste måten å bygge ut den samspillet, slik at du kan teste det. Hvis du trenger å bestille en liten serie av en testversjon av produktet, hva er den minste bestillingen du kan plassere? Er det muligens en måte å endre ditt eksisterende produkt for å legge til på en funksjon - selv om det selv er ikke skalerbart i det lange løp?
Selv om det å tilby en ny funksjon for en test, kommer ned til å ta en samtale fra hver enkelt kunde selv og deretter gå ut og endre sitt produkt for hånd, kan dette arbeidet være vel verdt tiden din. I det minste vil du sannsynligvis kunne håndtere minst noen slike bestillinger for mindre tid og penger enn du måtte investere for å bygge ut selv en minimal funksjon.
Jo mer realistiske tester, jo mer verdifulle finner du dataene du samler inn. Hvis du ikke kan ordne for samme type brukere som vil stole på produktet ditt når du slipper det, kan du ikke anta at dataene du får, reflekterer virkeligheten nøyaktig. Med det for øye, fokus på hvordan du kan samle mer informasjon spesifikt fra hvilke typer brukere du stoler på.
Selvfølgelig må du fokusere på å samle inn data som du faktisk skal bruke - å løpe hundrevis av kundeundersøkelser som du aldri ser på igjen, er sløsing med tid og penger. Ha en plan for å håndtere all informasjon du legger sammen, inkludert en måte å behandle biter og stykker inn i en sammenhengende analyse som du kan handle på.
Gjør et punkt for lading for din funksjon, selv om du ikke lader opp hele prisen du forventer å gå nedover linjen. Ellers vil du ikke få de høyeste kvalitetsdataene. Hvis du forventer at kundene dine til slutt betaler for funksjonen du vil bygge, må du vite om bare eksistensen av en prislapp endrer hvordan de bruker funksjonen. Det er umulig å teste hver eneste variabel der ute, men de store, som pris, må bygges inn i testene hver gang.
Lagre dataene dine på en slik måte at du kan henvise til den. Mens du vil gjøre en øvelse med å kjøre tester hver gang du vurderer en ny funksjon for ditt produkt, er det ikke nødvendig å gjenoppfinne hjulet hvis du jobber med noe lignende. Du kan kanskje finne et vell av ny informasjon i gamle data, da du finner nye spørsmål verdt å spørre.
Mens du forhåpentligvis har tester med en ide om svarene du trenger allerede i tankene, må du kunne handle på informasjonen du har samlet sammen.
Du må forplikte deg til å bygge opp funksjonen fullt ut hvis du får et visst nivå av positiv respons, men du vil skrape den hvis du ikke får nok god tilbakemelding. Dette er en klar linje i sanden du kan jobbe fra og måle om testen din er en suksess. Det handler om å sjekke om du har riktig responsnivå.
Dessverre, oftere enn du vil, vil du bevise at du ikke bør forfølge en funksjon som du er personlig forelsket i.
Det kan være noen problemer hvis du ser et sett svar som nesten oppfyller dine forventninger, men ikke slår helt merket. I slike situasjoner må du bestemme hvor mye wiggle room du er villig til å tillate dataene dine. Hvis du bare plukket nummeret du ønsket å komme ut av tynn luft, er det ikke en særlig stor sak enn å ikke slå helt.
Hvis du legger stor vekt på det nummeret - si, kanskje å beregne på hvilket tidspunkt å legge til en ny funksjon, er faktisk økonomisk levedyktig - enn du må holde fast i våpenene dine, selv om dataene er nært nok til den linjen for å gjøre deg omdøve justering av innledende tall. Det er poenget med en test. Dessverre, oftere enn du vil, vil du bevise at du ikke bør forfølge en funksjon som du er personlig forelsket i.
Etter at du har kjørt din første test, kan du oppdage at du må kjøre ytterligere tester for å avklare visse detaljer. Du bør fortsette å teste så lenge du får en klar fordel ved å gjøre det. Men det kommer et poeng hvor du ikke lenger vil ha nytte av å bygge minst levedyktige versjoner av produktet og løpende eksperimenter.
Hvis du har nådd et punkt der du kjører enda en testbringer, krever så mye innsats fra deg som å faktisk bygge et produkt, kan det være på tide å avslutte testsyklusen og faktisk begynne å bygge. Det er ingen harde og raske regler om slike situasjoner, men vær oppmerksom på den tiden du investerer i hvert trinn av å skape et nytt produkt.
Avhengig av virksomheten din, kan du få en liste over forbedringer du kanskje vil legge til på produktet en kilometer lang. Å bygge en sterk teststrategi kan hjelpe deg med å sortere gjennom de forskjellige banene du kan ta langt raskere, slik at du synker ressursene dine i alternativene som vil gjøre deg mest gode.
Denne strategien kan være en nøkkelfaktor i å skille deg fra konkurransen din. Hvis du alltid tester et nytt alternativ - og handler på dataene du samler inn gjennom testene dine, vil du bevege deg mye raskere enn noen som er iterating basert på anekdot informasjon, eller noen som ikke plager å vurdere forbedringer i det hele tatt. Du kan sørge for at du tilbyr den beste versjonen av produktet til kundene dine til enhver tid.
Grafisk kreditt: Idea designet av Waleed Al-Alami fra The Noun Project.
Accentsconagua