Millal peaksin oma käivitamisel arendaja palkama?

Üks kriipivaid hetki, mis mul varajaste ettevõtjate nõustamisel tekib, on see, kui nad ütlevad mulle, et neil on see suurepärane idee ja nad maksavad juba arendajale selle väljaehitamise eest.

Kutt.

Armastan agressiivset suhtumist ja tegemisvaimu. Kuid seal on nagu miljon asja, mida peate tegema enne, kui hakkate sellele vabakutselisele või offshore-meeskonnale raha kulutama.

Oota. Viis. Enne arendaja palkamist peate tegema viis asja. Mul on pettumuse korral pisut hüperboolia.

1. Koostage oma paberi MVP

Kui olete juba MVP-d ehitanud, liikuge 2. sammu juurde.

Eelmisel nädalal kirjutasin postituse minimaalse elujõulise toote ehitamisest. Idee on luua meie toote kiireim versioon, piirates funktsioonide komplekti ja loobudes suurema osa automatiseerimisest, et saaksime oma ideed tõestada.

Kas peaksite MVP-d ise kodeerima? Vaadake, mulle meeldib õppida koodi kodeerima, kuid lubage mul pakkuda väikest vastanõuannet: mitte ainult kodeerida, õppige koos hoopis hakatust. Nii ehitate paberi MVP, mis on nagu tavaline MVP, ainult seal on palju rohkem kanalilinti.

Seal on igasuguseid platvorme, mis suudavad jäljendada peaaegu kõiki tehnilisi funktsioone. Proovige Lambda abil AWS-i ja Serverless'i või kui see on liiga hirmuäratav, siis võib-olla WordPress, GSuite, Zapier ja Slack. Need võimaldavad teil vaid väikese koodiga veebirakenduste, andmebaaside ja API-de loomiseks oma asju lohistada - saate kogu asja sõna otseses mõttes võltsida.

Teie paberi MVP peaks tegema ühte ja hästi, asi, mis tõestab teie ideed. Kui teie idee on see, et inimesed maksavad interaktiivsete VR-kasside videote eest, siis teeb teie Paper MVP AINULT interaktiivseid VR-kasside videoid - sotsiaalvõrgustikus pole seda sisse ehitatud, puudub kassi järjestamise algoritm, läheduses asuvate kasside geograafiline asukoht puudub. Sest see viimane on super jube.

Kas peaksite nüüd laskma neil platvormidel välja reaalse reaalaine toote? Absoluutselt mitte. Kuid kui see paberi MVP töötab, olete 1. etapi lõpule viinud. Siis on veel neli käsku minna ja see on arendaja probleem.

2. Looge oma turustusmehhanism

Võimalik, et teil on juba viis oma toote turule toomiseks. Kui jah, siis jätkake 3. toiminguga.

Pole tähtis, kui suurepärane meie idee on ja kui hästi meie toode lõpuks töötab, ei tähenda see midagi, kui keegi selleni ei jõua.

Kui ehitame rakendust, oleme lukustatud rakenduste poodidesse. Mis tahes muud tüüpi traditsiooniline või veebipõhine tarkvara hakkab tehinguid tegema oma veebisaidi ja / või mingite agregaatide üle - heaks näiteks agregaadist on mängude Steam. Kui meie tootesse on kaasatud riistvara, ärge minge MVP-ga Amazoni, saate alglaadimise. Hoidke kinni Shopify või midagi sellist.

Nüüd on see ainult mehhanism, see ei hakka meie toodet poest läbi suruma. Kuid oma MVP jaoks pole meil vaja tohutut publikut. Me vajame vaid võimalust jälgida meie toote kasutamist, mis tuleb läbi nende mehhanismide kaudu, mille eest meie ettevõte otseselt ei vastuta. Peame teadma, kes need kasutajad on, kuidas nad meid leidsid ja miks nad tulid.

3. Pange inimesi oma toodet kasutama

Kui teil on inimesi, kes kasutavad teie MVP-d, jätkake 4. juhisega.

Kes siis meie toodet kasutama hakkab? Lihtne küsimus. Tõesti, väga raske vastata.

Kirjeldage inimest, kes tõenäoliselt saab meie tootest kõige suurema väärtuse. Kitsendage seda määratlust ja võtke kõik suhted teiega - mitte oma sõprade, mitte oma tööstuse inimeste, mitte vasakukäeliste ega spordistatistikutega.

Jah, ma eeldan, et olete vasakukäeline spordistatistik, kellel on soovitav töö ja palju sõpru.

Kui olete oma kõige väärtuslikuma kasutaja väga täpselt määratlenud, leidke võimalikult palju inimesi, kes sarnanevad sellele määratlusele kõige paremini. Leidke neist tohutud rühmad. Seejärel müüge oma toode neile, andke neile ja jätke keset ööd ukse taha.

See, kuidas nad seda saavad, pole oluline, kuid see peaks olema järgmine: nad peaksid teadma, miks nad seda vajavad, peaksid teadma, mida see teeb, nad peaksid teadma, kuidas seda kasutada, ja nad peaksid teadma, kellele helistada, kui see ei lähe. t tööd.

Seejärel peate saama nendega ühendust võtta ja andma neile tagasiside andmise põhjuse. Sest nad ütlevad meile, millist toodet me tegelikult peame ehitama ja millisele turule me tegelikult müüma peame.

Võimalik, et see ei näe välja nagu see idee, mis meil selle postituse alguses oli. Nii et ma säästsin teile lihtsalt hunniku raha.

4. Pange kliendid teie toote eest maksma

Kui olete juba saanud inimesed oma toote eest maksma, peate palkama arendaja, eks? Eh, liikuge edasi 5. sammu juurde ja tehke oma valik.

Aga jah, alati on kõige parem, kui raha tuleb sisse enne, kui hakkate raha välja panema. Ma ei ütle, et neetud asi peab ise maksma, kuid kõige raskem on see, kui inimesed saavad oma rahakoti avada ja teile raha anda. Kui saate seda teha, on teil hea idee.

Hea uudis on see, et saame teha mõned arvamised selle kohta, kui palju toote valmistamine maksab ja kui palju selle eest tasu saame.

Võime nende arvamiste osas eksida, ainus ekslik, milleks me ei saa olla, on liiga vähe maksustamist. Sissejuhatava hinnakujunduse eesmärk on saada kliente areenile, kuid 100-dollarise toote müümine 1-dollarise hinnaga ei tõesta midagi. Ja nii saavad alguse ka Ponzi skeemid.

Viimane samm edasi minna.

5. Pange kliendid oma toote eest tasuma

Siit saab kana ja muna.

Ideaalis tahame, et kliendid tuleksid tagasi ja kulutaksid rohkem raha, olgu selleks siis kõrgem kasutusaste, versiooniuuendused, professionaalsed teenused, põrgu või isegi rakendusesisesed ostud. Olemasolevale kliendile on palju lihtsam ja odavam müüa kui täiesti uue kliendi leidmiseks.

Kuid kui meie toode on piiratud ja madala kvaliteediga, ei pruugi kliendid enam tulla. Pole tähtis, kui palju väärtust me esialgu pakume, tõusevad lõpuks ootused, et luua vajadus professionaalselt ehitatud toote järele.

Minu nõutakse usuhüpet.

Õnneks on seda hüpet andmetega palju lihtsam teha. Nüüdseks on meil võib-olla piisavalt teada oma 1. ja 2. etapi toote kohta ning piisavalt oma turu kohta 3. ja 4. etapil, et saaksime ühendada punkte, kust korduv tulu tuleb.

Mida me siis teeme? Palkame arendaja meie paberi MVP professionaalse versiooni loomiseks. Seejärel ehitame arendaja abiga järgmisele funktsioonikomplektile traditsioonilise MVP (st mitte Shit Hacked Together), mis on omadused, mida sammud 3–5 on meile öelnud, et meie kliendid soovivad. Seejärel käivitame sellel funktsioonikomplektil sammud 3–5, arendades välja selle, mis töötab, lammutades selle, mis mitte.

Sel hetkel on meil korratav tsükkel, mis võimaldab meil mitte ainult oma geniaalset ideed välja töötada, vaid ka jätkata ehitamist, kuni lööme mõnele teisele tootele, võib-olla isegi mõnele teisele ettevõttele, ja alustame protsessi uuesti.