Вашият MVP не е нито минимален, нито жизнеспособен, нито продукт – TechCrunch


Винаги, когато говоря за минимално жизнеспособни продукти с основатели на стартиращи компании, управлявани от продукти, често се озовавам в разочароващ разговор. Терминът MVP е толкова дълбоко погрешно наименование; добър MVP не е жизнеспособен и със сигурност не е продукт. Вероятно и то не е толкова минимално, колкото искате да бъде, като се замислите.

В света на стройните стартъпи основателите трябва да останат свръх фокусирани върху измислянето как да се провалят възможно най-бързо. В идеалния случай не успявате да се провалите, което означава, че в крайна сметка ще имате работещ бизнес. Много от подходите за „опит за провал“ включват разглеждане на вашите бизнес възможности и обмисляне къде бизнесът ви може да се провали в бъдеще. След това отидете и разберете тази част.

Не е добре да се изгражда най-добрата платформа в света за продажба на Beanie Babies, ако цялата клиентска база вече е доволна от използването на eBay и не би се отказала, дори ако продуктът ви е по-добър. Не е добре да създавате страхотна ключалка специално за скутери за rideshare, ако се окаже, че компаниите за скутери не се интересуват, ако скутерите бъдат откраднати. Би било чудесно, ако имаше начин да разберете дали някой ще купи вашия продукт, преди да напишете един ред код.

И така, къде идват MVP? Като стартъп имате хипотеза; MVP е най-малкото количество работа, което можете да извършите, за да потвърдите или разсеете вашата хипотеза. Ерик Райс – да, човекът, който написа “The Lean Startup” – използва известното MVP на Dropbox като пример. Това не беше напълно разработен продукт, пълен с функции. Това не беше продукт с много отстранени функции. Това беше видео, показващо как може да работи даден продукт. Отговорът на това видео беше потвърждението, от което компанията се нуждаеше: ако го изградят, те ще могат да намерят клиентска база за своя продукт, който все още не е създаден. И така те направиха: изградиха продукта и станаха огромен успех.

Проектиране на добър MVP

Проектирането на добър MVP означава да мислите извън кутията. Колко малко код можете да напишете? Можеш ли да се измъкнеш, като не правиш дизайн? Ако най-големият ви въпрос е дали можете да привлечете клиенти за цена за привличане на клиенти, която има смисъл, бихте ли могли да проведете само рекламна кампания и страница за плащане и след това просто да възстановите парите на всеки, който направи поръчка? Ако това звучи като забавно, но се притеснявате за риска на марката, бихте ли могли да създадете фалшива марка и да получите отговор за вашия продукт?

Номерът е да обмислите внимателно хипотезата – какво трябва да е вярно за вашия продукт, пазара, проблемното пространство, в което навлизате, клиентите, които се надявате да привлечете, и конкурентния пейзаж? Доколко сте сигурни, че вашите предположения са верни? Проектирането на добър MVP е изкуство, но започва с наистина добър въпрос. Ето няколко примера:

  • Възможно ли е да намалим четири часа ръчни счетоводни задачи до скрипт, който може да се изпълнява за три минути? Това е технически MVP – вероятно трябва да хакнете някакъв код, за да видите дали можете надеждно да автоматизирате ръчните задачи.
  • Можем ли да намерим някой, който е готов да плати, за да автоматизира тази задача? В някои случаи отговорът ще бъде „не“ – да, може да спестите известно време на младши счетоводител, но в някои индустрии хората просто не се интересуват от това колко време прекарват младши служители за извършване на ръчни задачи. В този случай трябва да определите дали можете да намерите 20-30 клиенти, които са готови да платят за това. Не забравяйте, че някой, който казва „о, това звучи като добра идея“ е различно от това да бръкне в джобовете си и всъщност да ти плаща пари.
  • Дизайнът има ли значение за този продукт? Много B2B софтуер е отвратително грозен. Не е защото не съществуват добри дизайнери, а защото просто не е приоритет; хората, които трябва да използват продукта, може да предпочетат по-добър дизайн или по-лесен UX, но на вземащите решения не им пука, а потребителите нямат думата. С други думи: Не харчете половината от бюджета си за разработка, за да направите нещо по-лесно за използване, ако не можете да намерите бизнес обосновка за това. Особено ако се окаже, че по невнимание разработите грешен набор от функции в процеса.
  • Ще ни копира ли и ще ни унищожи един титуляр? Ако имате няколко действащи лица във вашето пространство, направете проучване и вижте как те са реагирали на други стартиращи компании. Ако са склонни да ги придобият, чудесно. Ако са склонни да копират техните функции и иновации и след това да ги смачкат, по-малко страхотно. Малко търсене в Google (и, разбира се, четене на TechCrunch за вашата индустрия) може да ви спести много главоболия в бъдеще. Ако управляващите рутинно крадат иновации, инвестирайте повече в патенти и заделете малко пари за адвокати.
  • Има ли смисъл тази функция за нашите клиенти? Възможно е да получите много шумно малцинство от клиентите си, които искат същата функция, но няма да сте първата компания, която е пуснала нова функция с голяма фанфара, само за да бъде посрещната от колективно свиване на рамене. Шумните клиенти не говорят от името на цялата ви клиентска база, така че бъдете разумни в начина, по който поддържате изоставането си – ако дадена функция не добавя значителна стойност към общите бизнес цели на вашата компания, не я приоритизирайте пред тези, които го правят. Един от начините да проектирате MVP около това е просто да добавите бутон към потребителския си интерфейс и да проследите колко хора щракват върху него. Изпратете “скоро!” съобщение, когато се щракне, например. Да, това е досадно за потребителите, но е много „по-евтино“, отколкото да прекарате няколко цикъла на разработка за добавяне на функция, която почти никой няма да използва.

Накратко, ключът е да обмислите много внимателно какъв е въпросът и след това да измислите елегантни, леки начини да зададете този въпрос. Вместо код за доставка може ли проучване да работи? Може ли видео демонстрация да ви даде отговорите, от които се нуждаете? Можете ли да се обадите на 50 клиенти и да им зададете внимателни въпроси и да видите дали те предлагат функцията, за която мислите, като потенциално решение на проблема? Те могат да ви изненадат по два начина: Вашите клиенти може или силно да искат това, което предлагате (страхотно!), може да го мразят (също страхотно – това означава, че не е нужно да губите време и пари за разработване на нещо, което те не искат искат) или може да имат съвсем различен начин за решаване на проблема, който е в най-сладката точка, е по-евтин за разработване и им помага да се чувстват ангажирани с вашия процес.

Нямам предложение за по-добро име за MVP, просто не попадайте в капана да го мислите като продукт, жизнеспособен или непременно малък, прост или лесен. Някои MVP са сложни. Идеята обаче е да похарчите колкото се може по-малко от ценните си ресурси, за да получите отговор на въпросите си.