Når skal jeg ansette en utvikler for oppstart?

Et av de skumleste øyeblikkene jeg får når jeg råder tidlige gründere, er når de forteller meg at de har denne gode ideen og allerede betaler en utvikler for å bygge den ut.

Dude.

Jeg elsker den aggressive holdningen og den kan-gjøre ånden. Men det er som en million ting du må gjøre før du begynner å bruke penger på det frilanseren eller offshore-teamet.

Vente. Fem. Det er faktisk fem ting du må gjøre før du ansetter en utvikler. Jeg blir litt hyperbolisk når jeg er frustrert.

1. Bygg papirmvp

Hvis du allerede har bygget en MVP, kan du gå videre til trinn 2.

Forrige uke skrev jeg et innlegg om å bygge et minimum levedyktig produkt. Konseptet er å lage den raskeste versjonen av vårt produkt, begrense funksjonssettet og falske det meste av automatisering, slik at vi kan bevise ideen vår.

Skal du kode MVP selv? Se, jeg elsker Learn To Code, men la meg tilby et lite motråd: I stedet for å lære å kode, lær å Hack Shit Together. Det er slik du bygger en Paper MVP, som er som en vanlig MVP, bare det er mye mer duct tape.

Det er alle slags plattformer som kan etterligne omtrent hvilken som helst teknisk funksjonalitet. Prøv AWS og Serverless med Lambdas, eller hvis det er for skremmende, så kanskje WordPress, GSuite, Zapier og Slack. Disse lar deg dra og slippe deg for å bygge webapper, databaser, APIer, uansett, med bare en liten kode - du kan bokstavelig talt falske hele saken.

Paper MVP-en din bør gjøre en ting og gjøre det godt, det som skal bevise ideen din. Hvis ideen din er at folk skal betale for interaktive VR-kattevideoer, gjør Paper MVP KUN interaktive VR-kattevideoer - det er ingen innebygde sosiale nettverk, det er ingen kattrangeringsalgoritme, det er ingen geolokalisering av nærliggende katter. Fordi den siste er super skummel.

Skal du nå lansere et ekte produkt fra disse plattformene? Absolutt ikke. Men hvis denne Paper MVP fungerer, har du fullført trinn 1. Fire til, og så er det utviklerens problem.

2. Lag din distribusjonsmekanisme

Du har kanskje allerede en måte å få produktet ut på markedet. Gå i så fall til trinn 3.

Uansett hvor flott ideen vår er og hvor bra produktet vårt etterhvert fungerer, betyr det ikke noe om ingen klarer å komme til den.

Hvis vi bygger en app, er vi slags låst inne i appbutikkene. Enhver annen form for tradisjonell eller nettbasert programvare kommer til å handle via sin egen webside og / eller en eller annen form for aggregat - et godt eksempel på et aggregat er Steam for games. Hvis maskinvare er involvert i vårt produkt, ikke gå til Amazon med en MVP, du får oppstart. Hold deg til Shopify eller noe lignende.

Nå, det er bare mekanismen, det kommer ikke til å skyve produktet vårt gjennom butikken. Men for vår MVP trenger vi ikke et stort publikum. Det vi trenger er muligheten til å spore all bruk av vårt produkt som kommer gjennom disse mekanismene som vårt selskap ikke er direkte ansvarlig for. Vi trenger å vite hvem de brukerne er, hvordan de fant oss og hvorfor de kom.

3. Få folk til å bruke produktet ditt

Hvis du har folk som bruker MVP-en din, kan du gå videre til trinn 4.

Så hvem skal bruke produktet vårt? Enkelt spørsmål. Skikkelig, veldig tøft å svare på.

Beskriv hvilken type person som mest sannsynlig vil få størst mulig utbytte av vårt produkt. Begrens denne definisjonen og ta ut et forhold til deg - ikke vennene dine, ikke folk i bransjen, ikke venstrehendte mennesker, ikke geeks til sportsstatistikker.

Ja, jeg antar at du er en venstrehendt idrettsstatistikk med en ønskelig jobb og massevis av venner.

Når du har en veldig stram definisjon av din mest verdifulle bruker, kan du finne så mange mennesker som du kan som ligner mest på denne definisjonen. Finn enorme grupper av dem. Så selg produktet til dem, gi det til dem, la det ligge på dørstokken midt på natten.

Hvordan de får det til spiller ingen rolle, men her er hva de skal ha: De skal vite hvorfor de trenger det, de skal vite hva det gjør, de skal vite hvordan de skal bruke det, og de skal vite hvem de skal ringe når det ikke gjør det. ' t arbeid.

Deretter må du kunne kontakte dem, og du må gi dem en grunn til å gi deg tilbakemelding. Fordi de kommer til å fortelle oss hva slags produkt vi faktisk trenger å bygge og hva slags marked vi faktisk trenger å selge inn.

Sjansen er stor for at det ikke kommer til å se ut som ideen vi hadde i begynnelsen av dette innlegget. Så jeg har bare spart deg en masse penger.

4. Få kunder til å betale for produktet ditt

Hvis du allerede har fått folk til å betale for produktet ditt, må du ansette en utvikler, ikke sant? Eh, bare gå videre til trinn 5 og ta ditt eget valg.

Men ja, det er alltid best å ha penger som kommer inn før du begynner å sette ut penger. Jeg sier ikke at den jævla tingen må betale for seg selv, men å få folk til å åpne lommebøkene og gi deg penger er det vanskeligste å gjøre. Hvis du kan gjøre dette, så har du en god idé.

Den gode nyheten er at vi kan komme med noen gjetninger om hvor mye det vil koste å lage produktet og hvor mye vi kan ta betalt for det.

Vi kan ta feil når det gjelder disse gjettene, det eneste galt vi ikke kan være å lade altfor lite. Innledende priser er ment å få kunder på arenaen, men å selge et produkt på $ 100 for $ 1 kommer ikke til å bevise noe. Og det er også slik Ponzi-ordningene starter.

Et siste skritt å gå.

5. Få kunder til å holde betaler for produktet ditt

Det er her det blir kylling og egg.

Ideelt sett ønsker vi å holde kundene tilbake og bruke mer penger, enten det er gjennom høyere nivåer av bruk, oppgraderinger, profesjonelle tjenester, helvete, til og med kjøp i appen. Det er mye enklere og billigere å selge til en eksisterende kunde enn det er å finne en helt ny kunde.

Men hvis vårt produkt er begrenset og lav kvalitet, kommer kanskje ikke kundene tilbake. Uansett hvor mye verdi vi opprinnelig gir, vil forventningene til slutt stige for å skape behov for et profesjonelt bygget produkt.

Det må kreves et sprang av tro.

Heldigvis er det mye lettere å ta det spranget med data. Nå vet vi kanskje nok om produktet vårt fra trinn 1 og 2, og nok om markedet vårt fra trinn 3 og 4, til å kunne koble prikkene der de gjentatte inntektene kommer fra.

Så hva gjør vi? Vi ansetter en utvikler for å bygge den profesjonelle versjonen av vår Paper MVP. Deretter bygger vi med utviklerens hjelp en tradisjonell MVP (dvs. ikke Shit Hacked Together) for det neste funksjonssettet, som er funksjonene som trinn 3 til 5 har fortalt oss om at kundene våre ønsker. Så kjører vi trinn 3 til 5 på det funksjonssettet, utvikler det som fungerer, skroter det som ikke gjør det.

På det tidspunktet har vi en repeterbar syklus som lar oss ikke bare bygge ut vår strålende idé, men fortsette å bygge til vi treffer på et annet produkt, kanskje til og med et annet selskap, og starte prosessen på nytt.