Så validerar du en app-idé innan du bygger den

För att validera en app-idé tar du reda på om en specifik grupp människor har problemet, redan försöker lösa det och skulle ge upp något verkligt för din lösning, till exempel tid, en e-postadress eller pengar. Börja med samtal, gå sedan vidare till en landningssida eller väntelista, och behandla ett förköp eller en användare som kommer tillbaka som det starkaste beviset. Varje steg kostar lite mer och säger lite mer.

Validering bevisar inte att en idé kommer att lyckas. Den sänker oddsen för att lägga månader på något som ingen vill ha.

Vad du faktiskt testar

"Är det här en bra idé?" är för vagt för att testa. Dela upp det i frågor du kan besvara:

Den sista frågan hoppas man ofta över. Ett verkligt problem där du inte kan nå kunderna är fortfarande ett svårt företag.

Steg 1: Skriv ned ditt riskabelaste antagande

Innan någon research, skriv idén som en mening: "[Vem] kämpar med [problem] och skulle använda [lösning] eftersom [skäl]." Lista sedan vad som måste vara sant för att det ska fungera, och ring in det du är minst säker på. Det är det du testar först.

För en schemaläggningsapp för hundfrisörer är det riskabelaste antagandet kanske inte "frisörer behöver schemaläggning". Det behöver de uppenbart. Det riskabla är snarare att "frisörerna är tillräckligt missnöjda med sitt nuvarande verktyg för att byta".

Steg 2: Problemintervjuer

Intervjuer är den billigaste metoden med högst signalvärde, och den lättaste att göra illa. Målet är att lära sig om personens nuvarande beteende, inte att sälja.

Vem du ska prata med

Personer som passar din mening. Vänner och familj går bra för träning men kommer att vara snälla snarare än ärliga. Hitta verkliga kunder där de redan är: branschgrupper, subreddits, lokala näringslivsföreningar och ditt eget nätverk på LinkedIn.

Vad du ska fråga

Fråga om det förflutna, inte om hypotetiska framtider:

• "Berätta om senaste gången du hade med [problemet] att göra."
• "Vad gjorde du åt det? Vilka verktyg använde du?"
• "Vad var irriterande med det?"
• "Har du betalat för något för att lösa det? Varför eller varför inte?"
• "Vem mer är inblandad när det här händer?"

Vad du ska undvika

• "Skulle du använda en app som …?" Nästan alla säger ja för att vara artiga.
• Att visa din lösning för tidigt. När de väl sett den reagerar de på den i stället för att berätta om sitt problem.
• Att räkna komplimanger. "Det är en bra idé" är inte bevis. "Kan jag få testa när den är klar?" är lite. "Här är mitt kort" är mycket.

Anteckna, och skriv efteråt ned de tre saker du lärde dig. När flera personer beskriver samma smärta med liknande ord, skriv ned orden. De blir din landningssidas rubrik.

Steg 3: Kontrollera vad som redan finns

Sök på problemet, inte på din lösning. Titta på befintliga produkter, deras prissidor och deras publika recensioner. Konkurrens är oftast ett gott tecken: det betyder att folk betalar för att lösa problemet. Det du söker är en lucka, en grupp som befintliga verktyg betjänar dåligt, en prisnivå som ingen täcker, eller ett arbetsflöde som fortfarande görs i kalkylblad.

Om det inte finns något alls, ta reda på varför. Ibland är det en möjlighet. Ofta betyder det att problemet inte är tillräckligt smärtsamt för att man ska betala för det.

Steg 4: Smoke test med en landningssida

Ett smoke test är en sida som beskriver produkten som om den fanns, med en tydlig handling: gå med i väntelistan, begär åtkomst eller förbeställ. Du skickar sedan riktade personer dit och mäter hur många som utför handlingen.

Vad sidan behöver:

1. En rubrik som namnger problemet med dina intervjupersoners ord.
2. Tre eller fyra konkreta fördelar, det som förändras för användaren.
3. En uppmaning till handling.
4. En ärlig notis om att produkten är under utveckling, så att ingen känner sig lurad.

Driv sedan trafik från de platser där din målgrupp finns. Ett litet betalt annonstest riktat mot en smal målgrupp kan fungera. Så kan också inlägg i communities göra, så länge du följer deras regler. Så bygger du en landningssida som konverterar går igenom struktur och text.

Att läsa resultaten

Det finns ingen universell "bra" konverteringsgrad, så jämför med dig själv: kör två rubriker eller två målgrupper och se vilken som går bäst. Det mest användbara resultatet är inte procenten, utan listan på personer som registrerat sig. Maila dem och be om ett samtal.

Steg 5: Bygg en väntelista, och använd den

En väntelista samlar e-postadresser från intresserade personer innan lansering. Den är användbar av två skäl: den ger dig personer att intervjua, och den ger dig en publik på lanseringsdagen.

Svagheten är att det nästan inte kostar något att registrera sig. Låt listan göra mer jobb:

• Ställ en fråga vid registreringen, till exempel "Vad använder du för det här idag?"
• Svara personligen på de första registreringarna och be om 15 minuter.
• Skicka en kort uppdatering med några veckors mellanrum så att listan inte kallnar.

Så bygger du en väntelistesida täcker byggandet, inklusive var e-postadresserna lagras.

Steg 6: Förförsälj eller ta en deposition

Den starkaste tidiga signalen är pengar. Erbjud tidig åtkomst till ett rabatterat pris, ett grundarmedlemspris eller en återbetalningsbar deposition, och se vem som betalar. Använd en betalningslänk från din betalningsleverantör. Du behöver inte en färdig produkt.

Var rak: säg när du räknar med att leverera, och återbetala alla som begär det. Ett förköp som ingen tar är också ett resultat. Det kan betyda att priset är fel, att målgruppen är fel eller att smärtan inte är lika skarp som den lät i intervjuerna.

Steg 7: Concierge- och Wizard-of-Oz-tester

Ibland är den snabbaste "produkten" du själv.

• Concierge-test: leverera resultatet för hand. Om appen skulle generera veckorapporter, gör dem själv i ett kalkylblad och maila dem. Du lär dig exakt vad användarna värdesätter innan du automatiserar det.
• Wizard-of-Oz-test: användarna ser ett enkelt gränssnitt, men bakom det gör du arbetet manuellt. Användaren upplever produkten, och du lär dig om de kommer tillbaka.

Båda är långsamma att skala, och det är poängen. Du automatiserar bara det som har visat sig vara värt att göra.

Steg 8: Bygg en liten MVP och observera beteendet

En minimal gångbar produkt (MVP) är den minsta versionen som gör det centrala jobbet. Med AI-appbyggare kan en fungerande MVP med databas och inloggning ta dagar i stället för månader, så det är numera rimligt att göra den till en del av valideringen. Se vad en MVP är.

Det avgörande måttet är inte registreringar utan återkommande användning. Kommer folk tillbaka en andra och tredje gång utan att du uppmanar dem? Bjuder de in en kollega? Klagar de när den går sönder? Det är tecken på att appen betyder något för dem.

Jämförelse av valideringsmetoder

När du ska sluta, ändra eller fortsätta

Sätt din tröskel innan du börjar, till exempel "tio intervjuer, tre personer säger att de skulle betala, ett förköp". Var sedan ärlig:

• Fortsätt om folk fortsätter beskriva samma smärta och några förbinder pengar eller tid.
• Ändra om smärtan är verklig men gäller en annan grupp, eller till ett annat pris, än du antagit. Det är vanligt och användbart.
• Sluta om ingen har försökt lösa problemet, ingen vill betala, och du inte kan nå dem som har det.

Att sluta tidigt är ett bra utfall. Det frigör dig för att testa nästa idé.

Validera med Mythex

Mythex passar de senare stegen i den här processen. Du kan beskriva en landningssida med ett väntelisteformulär och ha den live på en publik URL samma dag, med registreringar sparade i en databas, och sedan göra om samma projekt till en liten MVP när signalerna är goda. Det är gratis att börja, och genomgången av väntelistan i dokumentationen visar stegen. Om du väger budgeten jämför hur mycket det kostar att bygga en app alternativen.

Frågor