Как да открием MVP за стартъпа ни?

Време: 3 месеца. 
Пари: -$5,000. 
Софтуер: почти готов. 
Потребители: nada.

Какъв е проблемът в този пример?

Докато парите може да ги преживеете, 3те месеца няма как да си ги върнете, колкото и $$$ да изкарате.

Време > пари
Време > всичко

Добре, че сте чували за Lean Startup и ще прочетете този пост.

Много ми хареса метафората от тази картинка:

(източник)

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

Слава богу, че може да правите къпкейкове!

Къпкейковете отнемат много по-малко време, струват по-малко за направа, а притежават същите качества като тортата: сладки са, вкусни са и стават за ядене. MVP-то на тортата е къпкейп.

Целта е да откриете:

Най-краткия път до активността, която генерира най-много познания за вас и най-много value за потребителя.

Това може да стане само като поставите дадения продукт в истински условия, с истинска потребителска употреба.

Как да откриете вашето MVP?

Предполагам няма да продавате торти, затова ще споделя една универсална формула, която бих приложил за откриване на MVP.

Да кажем, че искате да създате хипотетичен application, който да свързва собствениците на кучета с гледачи на кучета. Типичен marketplace бизнес модел.

Стъпка 1: Идентифицирайте коя е крайната полза за клиента

“High-level benefit” е това, което наричам крайната полза за клиента ви във веригата от ползи. За вашия кучешки ап това може да е например:

Този app има удобен interface -> Благодарение на удобния интерфейс в този app мога да намеря лесно кучегледачи -> Я, даже има опция за кучегледачи в моя квартал, които са сигурни -> Утре ще мога да оставя кучето си на гледач -> Ще бъда свободен цели 3 часа -> Ще имам повече свободно време със семейството ми.

Започвайки от features на продукта (interface-а), стигаме до ползи и набелязваме най-голямата (high level benefit) за собствениците на кучета: ще имат повече свободно време за семействата си.

Стъпка 2: Подредете рисковете на бизнес модела от най-голям до най-малък

Примерна таблица с рискове от The Entrepreneur’s Guide to Customer Development:

За нашият app аз идентифицирах следните рискове:

  • Development на аппа — ще мога ли да създам подобен апликейшън? Тип на риска: технологичен. Кой да тествам: freelance developers.
  • Demand от страна на собствениците на кучета — биха ли търсили подобна услуга собствениците на кучета и биха ли платили? Тип на риска: свързан с пазара. Кой да тествам: собствениците.
  • Demand от страна на гледачите на кучета — Ще се намерят ли достатъчно гледачи на кучета? Тип на риска: свързан с пазара. Кой да тествам: гледачите

Като най-голям от 3те риска за вашия application аз идентифицирам търсенето от страна на собствениците на кучета. И приоритетът за тестване би следвало да изглежда така (от най-приоритетен до най-малко приоритетен риск):

  1. Demand от страна на собствениците на кучета
  2. Demand от страна на гледачите на кучета
  3. Development на аппа

Стъпка 3: Открийте вашето MVP

Какво знаем досега?

  • Знаем, че най-голямата полза (high level benefit) за клиентите ви е, че ще имат повече свободно време да са със семействата си.
  • Знаем, че най-големият риск за този app е demand-а от страна на собствениците на кучета.

MVP подход 1:

Бърз (и сравнително бъгав) прототип на application, който позволява собственици на кучета и гледачи на кучета да се регистрират и свързват един с друг.

Време: 1–2 седмици (ако се отплеснете може да станат и месеци)

Benefit за клиента: малък. Като нов application-ът ви най-вероятно ще е пустинно празен. Едва ли ще бъде особено полезен за когото и да било.

Познания: почти никакви. Освен ако не сте си изкарали компютъра в кучешкия парк и не сте кодили оттам, едва ли сте натрупали много познания за пазара.

Тестване на най-големия риск: 2 седмици изгубено време и все още нито един собственик на куче не е зареждал пари в банковата ви сметка…

Защо този подход е грешен?

  1. Защото има много по-кратък път до активността, която генерира най-много познания за вас и най-много value за потребителя.
  2. Защото, както открихме в стъпка 1, application-ът сам по себе си е много назад във веригата ползи за потребителя.
  3. Sorry, но това дори не е MVP, а прототип.

На съвестта ви ще седнат стотици скучаещи у тях кучета…

Вместо да губите време в разработка на features, а не “high level benefits”, ето по-добър вариант за MVP:

MVP подход 2

10–15 телефонни обаждания и Facebook съобщения до приятели с кучета с въпроса: “Искаш ли да ти гледам кучето за X пари, когато си зает/а?”

Време: От 1–2 часа до 2–3 дни макс.

Benefit за клиентите: Pretty much веднагически, защото още днес могат да имат няколко часа повече свободно време със семействата си. Адресираме директно крайната полза за клиента, а не features.

Познания: След 15 разговора с потенциални клиенти се очавка да разберете много повече за пазара, отколкото след 15,000 реда код.

Тестване на най-големия риск До края на деня или а) ще имате повече пари в банковата ви сметка (дошли от собственици на кучета) или б) ще разберете, че собствениците на кучета не биха плащали за такава услуга. И в двата случая не губите.

Надявам се това постче да е хвърлило няколко идеи за валидацията на следващата ви бизнес идея.

Успех с намирането на вашия къпкейк!

Споделете вашите методи за създаване на MVP-та.

Like what you read? Give Kaloyan Yankulov a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.