Mida asutajad MVP arendamisel valesti teevad (ja kuidas seda


Sissejuhatus
Kõik asutajad mõistavad, et tuleb kiiresti avada. Investorid tahavad tõmmet. Esimesed tarbijad soovivad midagi ehedat. Meeskonnad tahavad selgust. Siiski on enamikul idufirmadel raskusi MVP arendamisel, kuna algsed ootused on valed. See on algusfaas, kus hoog on kõige olulisem, kuid samas on see ka kõige kulukam faas, kus vigu teha. Suurim väärarusaam on, et MVP peab olema täielikult valmis, kui see turule tuuakse. Selline suhtumine viib asutajad ringi, paisutab eelarvet, mis pole vajalik, ja viib toote veelgi kaugemale sellest, mida kasutajad tegelikult soovivad. Keskendunud arendus annab asutajatele teadmised, mida nad vajavad, et tulevikus saada tõeliseks versiooniks. Allpool on loetletud kõige levinumad vead ja nende ennetamine, kasutades lihtsat MVP arendusprotsessi.
MVP-d on kõige kasulikumad, kui neid vaadelda eksperimentidena, mitte valmis toodetena.
Viga 1: Skaleeritavus enne nõudluse tõestamist
See probleem tekib, kui asutaja hakkab töötama ideaalse arhitektuuri, tegevuskava, täiustatud funktsioonide ja kogu kasutajate voo kallal. See tekitab pikalevenivaid tähtaegu ja tehnilisi võlgu enne, kui esimene kasutaja saab sisse logida.
Mida teha selle asemel
- Looge ainult seda, mis aitab teil testida ühte kindlat hüpoteesi
- Jätke tähelepanuta funktsioonid, mis võimaldavad pikaajalist mastaapsust, kuni idee on reaalses kasutuses tõestatud
- Viivitusi saab vältida, kasutades MVP arendusprotsessis lihtsaid ja usaldusväärseid tööriistu.
Lean MVP lähenemine põhineb optimeerimise asemel valideerimisel. Lisaks toote turule sobivusele peab olema tegelik mastaap, mitte eelnev.
Viga 2: Püüda investoritele muljet avaldada, selle asemel et
Teatud asutajad soovivad, et MVP oleks rahastamise saamiseks viimistletud. See sunnib meeskondi tavaliselt tegelema keerulise disaini, lisafunktsioonide ja kuluka arendustööga.
Alternatiiv
- Välja töövalmis versioon, kui see loob põhiväärtuse
- Lubage varajastel kasutajatel määrata, mis on oluline, selle asemel, et spekuleerida ettevõtte sees
- Rõhutage tagasisidet formaalsuse asemel
Investorid järgivad turul omandatud teadmisi, mitte vaakumis loodud prototüüpe.
Viga 3: Minimaalne ja vaevu toimiv on segamini
MVP ei tohi olla rikutud ega halvasti kokku pandud. See peab pakkuma kasutajale üht võimsat tulemust. Enamik meeskondi ehitab ja arendab midagi nii väikest, et see ei peegelda idee väärtust.
Mida teha selle asemel
- Leidke oma toote kõige olulisem ülesanne
- Koosta ainult nii palju samme, kui on vaja selle ülesande täitmiseks
- Puhasta tolm, aga ära lihvi samal ajal
MVP ei ole mahukas, kuid peaks siiski tegelema reaalse probleemiga.
Viga 4: Mitte-reaalne käitumine
Asutajad arvavad tavaliselt, et kasutajad avastavad kõik funktsioonid ise. Nad soovivad, et inimesed tunneksid toote kohe ära. Tegelikult on olukord teine. Kasutajad ei käitu nii, nagu nad peaksid käituma.
Alternatiivina sellele
- Vaadake kasutajate sessioone reaalajas
- jälgige, kuidas inimesed toodet kasutavad, selle asemel et teha oletusi
- Optimeerige järgmisi andmeid
Startup-ettevõtete MVP arendamine põhineb käitumisel, mitte teoorial.
Viga 5: Tagasiside ootamine on vabatahtlik
Mõned asutajad avaldavad MVP ja ootavad. Nad eeldavad, et tagasiside tuleb loomulikult. See juhtub harva. Meeskonnad jätkavad arendamist ilma ametliku sisendita, tuginedes sisemistele ideedele.
Alternatiivne käitumine
- Nõua kasutajatelt vastuste andmist pärast olulisi toiminguid
- Koguge kvalitatiivset ja kvantitatiivset teavet
- Leppige kokku kohtumised varajaste kasutuselevõtjatega
MVP eesmärk on õppida. Ilma töökohata ei ole haridust.
Oled valmis oma MVP-d õigesti ehitama?
Muutke oma idufirma idee valideeritud tooteks meie tõestatud lean-arenduse lähenemisviisi abil.
AlustamineKuidas teha MVP arendust õigesti
MVP ei ole protsess, mis nõuab pikki ajakavasid või ideaalset planeerimist. See sõltub selgusest. See sõltub kitsast ulatusest. See sõltub asutaja võimest suunata kogu energia ühele tegevusele, valideerimisele.
Õige strateegia on järgmine:
- Alustage üheainsa, lihtsa ja mõõdetava hüpoteesiga
- Looge ainult need funktsioonid, mis on vajalikud selle hüpoteesi testimiseks
- Mine turule varsti piiratud arvu tegelike kasutajatega
- Koguge nende kohta süstemaatilisi kommentaare
- Beat väikeste, oluliste sammude kaupa
- Echelon pärast väärtuste tuuma kehtestamist
See ongi lean MVP arenduse tegelik tähendus. See ei ole kiire sellepärast, et see on kiire. See on kiire, kuna varajane selgus säästab kuude jagu tarbetut tööd. MVP arendamisel distsipliini rakendades vähendavad asutajad riski, minimeerivad arenduskulusid ja loovad arengu hoogu, mis aitab saavutada varajast kasvu. Eesmärk ei ole ideaalne esimene versioon. Eesmärk on versioon, mis annab juhiseid selle kohta, mida järgmisena ehitada. See suhtumine on aluseks, mis peab olema igal edukal tootel, kui teie startup soovib lühikese aja jooksul oma väärtust tõestada, vähendada arendustöö raiskamist ja kindlalt turule tulla.
Tags
Sissejuhatus
Kõik asutajad mõistavad, et tuleb kiiresti avada. Investorid tahavad tõmmet. Esimesed tarbijad soovivad midagi ehedat. Meeskonnad tahavad selgust. Siiski on enamikul idufirmadel raskusi MVP arendamisel, kuna algsed ootused on valed. See on algusfaas, kus hoog on kõige olulisem, kuid samas on see ka kõige kulukam faas, kus vigu teha. Suurim väärarusaam on, et MVP peab olema täielikult valmis, kui see turule tuuakse. Selline suhtumine viib asutajad ringi, paisutab eelarvet, mis pole vajalik, ja viib toote veelgi kaugemale sellest, mida kasutajad tegelikult soovivad. Keskendunud arendus annab asutajatele teadmised, mida nad vajavad, et tulevikus saada tõeliseks versiooniks. Allpool on loetletud kõige levinumad vead ja nende ennetamine, kasutades lihtsat MVP arendusprotsessi.
MVP-d on kõige kasulikumad, kui neid vaadelda eksperimentidena, mitte valmis toodetena.
Viga 1: Skaleeritavus enne nõudluse tõestamist
See probleem tekib, kui asutaja hakkab töötama ideaalse arhitektuuri, tegevuskava, täiustatud funktsioonide ja kogu kasutajate voo kallal. See tekitab pikalevenivaid tähtaegu ja tehnilisi võlgu enne, kui esimene kasutaja saab sisse logida.
Mida teha selle asemel
- Looge ainult seda, mis aitab teil testida ühte kindlat hüpoteesi
- Jätke tähelepanuta funktsioonid, mis võimaldavad pikaajalist mastaapsust, kuni idee on reaalses kasutuses tõestatud
- Viivitusi saab vältida, kasutades MVP arendusprotsessis lihtsaid ja usaldusväärseid tööriistu.
Lean MVP lähenemine põhineb optimeerimise asemel valideerimisel. Lisaks toote turule sobivusele peab olema tegelik mastaap, mitte eelnev.
Viga 2: Püüda investoritele muljet avaldada, selle asemel et
Teatud asutajad soovivad, et MVP oleks rahastamise saamiseks viimistletud. See sunnib meeskondi tavaliselt tegelema keerulise disaini, lisafunktsioonide ja kuluka arendustööga.
Alternatiiv
- Välja töövalmis versioon, kui see loob põhiväärtuse
- Lubage varajastel kasutajatel määrata, mis on oluline, selle asemel, et spekuleerida ettevõtte sees
- Rõhutage tagasisidet formaalsuse asemel
Investorid järgivad turul omandatud teadmisi, mitte vaakumis loodud prototüüpe.
Viga 3: Minimaalne ja vaevu toimiv on segamini
MVP ei tohi olla rikutud ega halvasti kokku pandud. See peab pakkuma kasutajale üht võimsat tulemust. Enamik meeskondi ehitab ja arendab midagi nii väikest, et see ei peegelda idee väärtust.
Mida teha selle asemel
- Leidke oma toote kõige olulisem ülesanne
- Koosta ainult nii palju samme, kui on vaja selle ülesande täitmiseks
- Puhasta tolm, aga ära lihvi samal ajal
MVP ei ole mahukas, kuid peaks siiski tegelema reaalse probleemiga.
Viga 4: Mitte-reaalne käitumine
Asutajad arvavad tavaliselt, et kasutajad avastavad kõik funktsioonid ise. Nad soovivad, et inimesed tunneksid toote kohe ära. Tegelikult on olukord teine. Kasutajad ei käitu nii, nagu nad peaksid käituma.
Alternatiivina sellele
- Vaadake kasutajate sessioone reaalajas
- jälgige, kuidas inimesed toodet kasutavad, selle asemel et teha oletusi
- Optimeerige järgmisi andmeid
Startup-ettevõtete MVP arendamine põhineb käitumisel, mitte teoorial.
Viga 5: Tagasiside ootamine on vabatahtlik
Mõned asutajad avaldavad MVP ja ootavad. Nad eeldavad, et tagasiside tuleb loomulikult. See juhtub harva. Meeskonnad jätkavad arendamist ilma ametliku sisendita, tuginedes sisemistele ideedele.
Alternatiivne käitumine
- Nõua kasutajatelt vastuste andmist pärast olulisi toiminguid
- Koguge kvalitatiivset ja kvantitatiivset teavet
- Leppige kokku kohtumised varajaste kasutuselevõtjatega
MVP eesmärk on õppida. Ilma töökohata ei ole haridust.
Oled valmis oma MVP-d õigesti ehitama?
Muutke oma idufirma idee valideeritud tooteks meie tõestatud lean-arenduse lähenemisviisi abil.
AlustamineKuidas teha MVP arendust õigesti
MVP ei ole protsess, mis nõuab pikki ajakavasid või ideaalset planeerimist. See sõltub selgusest. See sõltub kitsast ulatusest. See sõltub asutaja võimest suunata kogu energia ühele tegevusele, valideerimisele.
Õige strateegia on järgmine:
- Alustage üheainsa, lihtsa ja mõõdetava hüpoteesiga
- Looge ainult need funktsioonid, mis on vajalikud selle hüpoteesi testimiseks
- Mine turule varsti piiratud arvu tegelike kasutajatega
- Koguge nende kohta süstemaatilisi kommentaare
- Beat väikeste, oluliste sammude kaupa
- Echelon pärast väärtuste tuuma kehtestamist
See ongi lean MVP arenduse tegelik tähendus. See ei ole kiire sellepärast, et see on kiire. See on kiire, kuna varajane selgus säästab kuude jagu tarbetut tööd. MVP arendamisel distsipliini rakendades vähendavad asutajad riski, minimeerivad arenduskulusid ja loovad arengu hoogu, mis aitab saavutada varajast kasvu. Eesmärk ei ole ideaalne esimene versioon. Eesmärk on versioon, mis annab juhiseid selle kohta, mida järgmisena ehitada. See suhtumine on aluseks, mis peab olema igal edukal tootel, kui teie startup soovib lühikese aja jooksul oma väärtust tõestada, vähendada arendustöö raiskamist ja kindlalt turule tulla.
Tags


