Slik validerer du en appidé før du bygger den
For å validere en appidé må du finne ut om en bestemt gruppe mennesker har problemet, allerede prøver å løse det, og ville gitt fra seg noe reelt for løsningen din: tid, en e-postadresse eller penger. Start med samtaler, gå over til en landingsside eller venteliste, og se på et forhåndssalg eller en bruker som kommer tilbake som det sterkeste beviset. Hvert steg koster litt mer og forteller deg litt mer.
Validering beviser ikke at en idé vil lykkes. Den reduserer sjansen for å bruke måneder på noe ingen vil ha.
Hva du faktisk tester
«Er dette en god idé?» er for vagt til å teste. Del det opp i spørsmål du kan svare på:
| Spørsmål | Hva et «ja» ser ut som |
|---|---|
| Finnes problemet? | Folk beskriver det uten at du spør, med egne ord |
| Er det smertefullt nok? | De har prøvd omveier, regneark eller andre verktøy |
| Hvem har det mest? | Én gruppe dukker stadig opp: en rolle, bransje eller situasjon |
| Vil de betale? | De bruker allerede penger eller tid på det, eller de forhåndsbestiller |
| Kan du nå dem? | Du vet hvor de samles: et forum, en bransjeorganisasjon eller et nyhetsbrev |
Det siste punktet hoppes ofte over. Et ekte problem du ikke kan nå kundene til, er fortsatt en vanskelig virksomhet.
Steg 1: Skriv ned den riskableste antakelsen din
Før all research skriver du ideen som én setning: «[Hvem] sliter med [problem] og ville brukt [løsning] fordi [grunn].» List deretter opp det som må være sant for at den skal fungere, og sett en ring rundt det du er minst sikker på. Det tester du først.
For en timeplanleggingsapp for hundefrisører er den riskabelste antakelsen kanskje ikke «frisører trenger timeplanlegging». Det gjør de helt sikkert. Det risikable er «frisører er misfornøyde nok med verktøyet sitt til å bytte».
Steg 2: Problemintervjuer
Intervjuer er den billigste metoden med mest signal, og den enkleste å gjøre dårlig. Målet er å lære om personens nåværende atferd, ikke å selge.
Hvem du skal snakke med
Personer som passer til den ene setningen din. Venner og familie er fint til øving, men de vil være snille fremfor ærlige. Finn reelle potensielle kunder der de allerede er: bransjegrupper, subreddits, lokale næringsforeninger, og ditt eget nettverk på LinkedIn.
Hva du skal spørre om
Spør om fortiden, ikke hypotetiske fremtider:
- «Fortell meg om sist du hadde med [problemet] å gjøre.»
- «Hva gjorde du med det? Hvilke verktøy brukte du?»
- «Hva var irriterende med det?»
- «Har du betalt for noe for å fikse det? Hvorfor eller hvorfor ikke?»
- «Hvem andre er involvert når dette skjer?»
Hva du bør unngå
- «Ville du brukt en app som …?» Nesten alle sier ja for å være høflige.
- Å vise løsningen din for tidlig. Når de først har sett den, reagerer de på den i stedet for å fortelle deg om problemet sitt.
- Å telle komplimenter. «Det er en flott idé» er ikke bevis. «Kan jeg prøve den når den er klar?» er litt. «Her er kortet mitt» er mye.
Ta notater, og skriv etterpå ned de tre tingene du lærte. Når flere beskriver den samme smerten med lignende ord, skriv ned de ordene. De blir overskriften på landingssiden din.
Steg 3: Sjekk hva som allerede finnes
Søk etter problemet, ikke løsningen din. Se på eksisterende produkter, prissidene deres og offentlige anmeldelser. Konkurranse er vanligvis et godt tegn: det betyr at folk betaler for å løse problemet. Det du leter etter er et gap, altså en gruppe de eksisterende verktøyene betjener dårlig, et prisnivå ingen dekker, eller en arbeidsflyt som fortsatt gjøres i regneark.
Finnes det ingenting i det hele tatt, må du finne ut hvorfor. Noen ganger er det en mulighet. Ofte betyr det at problemet ikke er smertefullt nok til at noen betaler for å løse det.
Steg 4: Smoke test med en landingsside
En smoke test er en side som beskriver produktet som om det finnes, med en tydelig handling: bli med på ventelisten, be om tilgang eller forhåndsbestill. Deretter sender du målrettede personer dit og måler hvor mange som gjør handlingen.
Det siden trenger:
- En overskrift som navngir problemet med intervjuobjektenes egne ord.
- Tre eller fire konkrete fordeler: hva som endrer seg for brukeren.
- Én handling.
- En ærlig notis om at produktet er under utvikling, slik at ingen føler seg lurt.
Deretter driver du trafikk fra stedene målgruppen din er. En liten betalt annonsetest rettet mot en smal målgruppe kan fungere. Det samme gjelder å legge ut i fellesskap, så lenge du følger reglene deres. Slik bygger du en landingsside som konverterer dekker struktur og tekst.
Å lese resultatene
Det finnes ingen universell «god» konverteringsrate, så sammenlign med deg selv: kjør to overskrifter eller to målgrupper og se hvilken som gjør det best. Det mest nyttige resultatet er ikke prosenten, men listen over folk som registrerte seg. Send dem en e-post og be om en samtale.
Steg 5: Bygg en venteliste, og bruk den
En venteliste samler e-postadresser fra interesserte personer før lansering. Den er nyttig av to grunner: den gir deg folk å intervjue, og den gir deg et publikum på lanseringsdagen.
Svakheten er at det nesten er gratis å registrere seg. Få listen til å gjøre mer arbeid:
- Still ett spørsmål ved registrering, for eksempel «Hva bruker du til dette i dag?»
- Svar tidlige registrerte personlig, og be om 15 minutter.
- Send en kort oppdatering hver andre uke, slik at listen ikke blir kald.
Slik bygger du en venteliste-side dekker bygging, inkludert hvor e-postene lagres.
Steg 6: Forhåndssalg eller forskudd
Det sterkeste tidlige signalet er penger. Tilby tidlig tilgang til en rabatt, en pris for grunnleggere eller et tilbakebetalbart forskudd, og se hvem som betaler. Bruk en betalingslenke fra betalingsleverandøren din. Du trenger ikke et ferdig produkt.
Vær rett på sak: si når du forventer å levere, og refunder alle som ber om det. Et forhåndssalg ingen tar, er også et resultat. Det kan bety at prisen er feil, at målgruppen er feil, eller at smerten ikke er like skarp som den virket i intervjuene.
Steg 7: Konsierge- og Wizard-of-Oz-tester
Noen ganger er det raskeste «produktet» deg selv.
- Konsierge-test: lever resultatet for hånd. Hvis appen skulle generere ukentlige rapporter, lag dem selv i et regneark og send dem på e-post. Du lærer nøyaktig hva brukerne verdsetter, før du automatiserer det.
- Wizard-of-Oz-test: brukerne ser et enkelt grensesnitt, men bak det gjør du arbeidet manuelt. Brukeren opplever produktet, og du lærer om de kommer tilbake.
Begge er trege å skalere, og det er poenget. Du automatiserer bare det som har vist seg å være verdt å gjøre.
Steg 8: Bygg en liten MVP og følg med på atferden
En minimum viable product (MVP) er den minste versjonen som gjør den ene kjernejobben. Med KI-appbyggere kan en fungerende MVP med database og innlogging ta dager i stedet for måneder, så det er nå rimelig å gjøre den til en del av valideringen. Se hva en MVP er.
Det viktigste målet er ikke registreringer, men gjentatt bruk. Kommer folk tilbake en andre og tredje gang uten at du dytter dem? Inviterer de en kollega? Klager de når den går i stykker? Det er tegn på at appen betyr noe for dem.
Sammenligning av valideringsmetoder
| Metode | Kostnad | Tid | Hva den beviser | Hvor den misleder |
|---|---|---|---|---|
| Problemintervjuer | Gratis | Dager | At problemet er reelt, og hvordan folk beskriver det | Høflighet; å snakke med feil personer |
| Konkurranseanalyse | Gratis | Timer | At folk allerede betaler for å løse det | Å anta at et gap finnes uten å sjekke hvorfor |
| Smoke test med landingsside | Lav | Dager | At budskapet trekker klikk | Klikk er ikke forpliktelse |
| Venteliste | Lav | Uker | Vedvarende interesse; et lanseringspublikum | E-poster er billige å gi bort |
| Forhåndssalg / forskudd | Lav | Dager til uker | Betalingsvilje | Tidlige brukere kan avvike fra det brede markedet |
| Konsierge-test | Din tid | Uker | At resultatet verdsettes | Vanskelig å skille deg fra produktet |
| MVP | Lav til middels | Dager til uker | Reell bruk og retensjon | Lav bruk kan skyldes et produktproblem, ikke ideen |
Når du skal stoppe, endre eller fortsette
Sett terskelen din før du starter, for eksempel «ti intervjuer, tre sier at de ville betalt, ett forhåndssalg». Vær deretter ærlig:
- Fortsett hvis folk stadig beskriver den samme smerten, og noen forplikter penger eller tid.
- Endre hvis smerten er reell, men for en annen gruppe, eller til en annen pris enn du antok. Det er vanlig og nyttig.
- Stopp hvis ingen har forsøkt å løse problemet, ingen vil betale, og du ikke kan nå dem som har det.
Å stoppe tidlig er et godt resultat. Det frigjør deg til å teste neste idé.
Validering med Mythex
Mythex passer til de senere stegene i denne prosessen. Du kan beskrive en landingsside med et venteliste-skjema og få den live på en offentlig nettadresse samme dag, med registreringer lagret i en database. Deretter kan du gjøre samme prosjekt om til en liten MVP når signalene er gode. Det er gratis å starte, og venteliste-gjennomgangen i dokumentasjonen viser stegene. Hvis du vurderer budsjett, sammenligner hva det koster å bygge en app alternativene.
Spørsmål
Hva er den raskeste måten å validere en appidé på?
Snakk med fem til ti personer som har problemet, og spør hva de gjør i dag, i stedet for å presentere ideen din. Hvis de beskriver problemet tydelig, har forsøkt å løse det og bruker tid eller penger på det, har du et signal som er verdt å teste videre med en landingsside eller et forhåndssalg.
Er en venteliste nok til å validere en idé?
Ikke alene. Å registrere seg med en e-postadresse koster folk nesten ingenting, så en venteliste viser interesse, ikke betalingsvilje. Behandle den som en liste over folk du skal intervjue og selge til, og se etter sterkere signaler som forhåndsbestillinger eller forskudd.
Hvor mange kundeintervjuer trenger jeg?
Det finnes ikke noe magisk tall. Fortsett til svarene slutter å overraske deg. For en smal målgruppe kan det skje etter noen få samtaler. Hvis hvert intervju forteller en ny historie, er målgruppen sannsynligvis for bred.
Bør jeg bygge en MVP for å validere, eller validere før jeg bygger?
Gjør de billige sjekkene først: intervjuer og en landingsside koster dager, ikke uker. Med KI-appbyggere er en liten MVP nå også billig, så å bygge en kan være en del av valideringen, så lenge du raskt setter den foran ekte brukere og måler om de kommer tilbake.