Как да валидирате SaaS идея, преди да напишете и един ред код

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

Виждал съм много умни хора да попадат в един и същ капан. Имат наистина добро наблюдение — реален дразнител в индустрия, която познават — и приемат, че разликата между наблюдението и продукта е просто разработка. Не е. Тази разлика е пълна с въпроси без отговор: чувства ли някой друг тази болка достатъчно силно, за да плати? Ще се откажат ли от това, което правят сега? Можете ли да ги достигнете, без да изгорите пари? На тези въпроси не се отговаря с писане на код. На тях се отговаря, като говорите с хора и наблюдавате какво всъщност правят.

Затова това е ръководството, което давам на основателите, преди да наемат когото и да било за каквото и да било. Не става дума за театъра на lean-стартъпа или за попълване на canvas. Става дума за шепа честни, евтини експерименти, които ви казват дали идеята ви има пулс — и за дисциплината да повярвате на резултатите, дори когато болят.

Защо разработката първо изглежда продуктивна — а обикновено не е

Разработката е съблазнителна, защото изглежда като видим напредък. В края на една сесия с код има екран, който работи, бутон, който прави нещо, нещо, което можете да покажете на партньора си. Разговорът с непознати за даден проблем не произвежда никакъв артефакт. Той е неудобен, бавен е и накрая нямате нищо освен бележки. Затова основателите посягат към клавиатурата, защото клавиатурата ги възнаграждава по-бързо.

Бедата е, че работещият екран не ви казва почти нищо за това дали идеята е правилна. Можете да изградите красив продукт без бъгове за проблем, който никой няма, и той ще е също толкова мъртъв, колкото и един грозен. Кодът е отговорът на „как доставяме това?“ — не на „иска ли изобщо някой това?“ Да прекарате месеци по първия въпрос, преди да сте отговорили на втория, е начинът, по който добрите инженери изграждат елегантни решения на въображаеми проблеми.

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

Намерете единственото допускане, което може да убие цялото нещо

Всяка SaaS идея стъпва върху купчина убеждения и те не са еднакво опасни. Някои са безопасни — „хората използват имейл“, „малките бизнеси не обичат документацията“. Други са залози, от които зависи цялото ви начинание, и ако са грешни, нищо друго няма значение. Задачата на валидирането не е да тества всичко. То е да намери най-рисковото допускане и да атакува първо именно него.

За да го намерите, напишете идеята си като едно изречение: „[тези хора] имат [този проблем] достатъчно зле, че да платят за [това решение] вместо [това, което правят сега].“ После се запитайте безпощадно: коя дума в това изречение, ако се окаже невярна, би потопила идеята? Обикновено не е решението. А дали проблемът е достатъчно болезнен, че да се плати за него, или дали изобщо можете да достигнете тези хора на достъпна цена.

Тази последователност е важна, защото цената на тестването нараства с всяка стъпка. Интервю за проблем е безплатно. Тест за готовност да се плати струва една landing страница. Тест за решение може да изисква кликаем прототип. Разработката е най-скъпият тест от всички. Искате да се провалите евтино и рано, не скъпо и късно — затова поставяте най-евтините, най-смъртоносните тестове отпред.

Говорете с хора — но го направете правилно

Най-полезното нещо, което можете да направите, е да говорите с хората, за които смятате, че имат проблема. Не с приятелите си, не с други основатели — с реалните хора, които биха използвали това. И ето уловката, която проваля повечето опити: хората са учтиви. Попитайте „бихте ли използвали инструмент, който прави X?“ и почти всеки казва да, защото да е безплатно и любезно. Това „да“ е безполезно. То е потопило повече стартъпи от всеки технически провал.

Лекът е да спрете да питате за бъдещето и да започнете да питате за миналото. Бъдещето е там, където хората лъжат, за да бъдат мили; миналото е там, където живее истината. Вместо „бихте ли използвали това?“, питайте „разкажете ми за последния път, когато се сблъскахте с този проблем.“ Какво направиха? Колко време отне? Колко им струваше? Потърсиха ли решение? Платиха ли за такова? Реалното поведение бие хипотетичния ентусиазъм всеки път.

Въпроси, които получават честни отговори

• „Преведете ме през последния път, когато това се случи.“ — изважда наяве реалния работен процес, не идеализиран.
• „Какво направихте по въпроса?“ — разкрива дали наистина им пука, или просто свиват рамене.
• „Колко време или пари ви струваше това?“ — превръща неясната болка в число.
• „Опитвали ли сте да го решите преди? Какво се случи?“ — казва ви дали има бюджет и намерение.
• „Кое друго в момента е по-дразнещо от това?“ — проверява дали проблемът ви изобщо влиза в петицата им.

Колко разговора? По-малко, отколкото си мислите. Докато проведете десет честни, добре направени интервюта с правилните хора, моделът обикновено е очевиден. Или трима-четирима от тях светват и започват да описват болката в живи подробности — или всички са учтиво хладни и никаква хитра разработка няма да оправи това. Дванадесет до петнадесет са предостатъчно, за да вземете решение, на което можете да се доверите.

Евтини начини да тествате реалното търсене

Разговорите ви казват дали проблемът е реален. Следващият въпрос е дали хората ще действат — и единственият начин да разберете е да поискате малък ангажимент, преди продуктът да съществува. Тук валидирането става малко неудобно, а и честно. Думите са евтини; кликът, имейл адресът или депозитът — не.

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

1. 1
   Качете едностраничен пич

   Опишете проблема и решението си на прост език, с един ясен призив за действие. Една обикновена landing страница е достатъчна — все още без продукт зад нея.
2. 2
   Поискайте реален сигнал

   Не „харесване“. Помолете хората да се запишат в списък на чакащите с имейла си, да направят предварителна поръчка или да резервират разговор. Колкото повече им струва да кажат да, толкова повече значи това да.
3. 3
   Насочете малко честен трафик

   Споделете го там, където реалната ви аудитория вече е — релевантна общност, малка реклама, няколко директни съобщения. Искате непознати, не подкрепящата ви мрежа.
4. 4
   Четете конверсията, не комплиментите

   От всички, които наистина разбраха офертата, колцина предприеха действието? Шепа реални записвания от правилните хора бие хиляда неясни добри пожелания.

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

Продайте го, преди да го изградите

Има стъпка между „хората са заинтересовани“ и „хората ще плащат всеки месец“, която заслужава собствено внимание: да доставите стойността ръчно, преди да я автоматизирате. Ако идеята ви е инструмент, който, да речем, превръща разхвърляни имейли от доставчици в спретнат седмичен отчет, направете го на ръка за трима-четирима клиенти първо. Вие ставате софтуерът. Бавно е и не се мащабира, и точно това е смисълът — позволява ви да научите какво всъщност трябва да прави продуктът, преди да сте го заковали в код.

Това прави две неща наведнъж. Доказва, че хората ще плащат за резултата, а не само за идеята за него. И ви учи на реалния работен процес — крайните случаи, изключенията, частите, които интересуват клиентите и които никога не бихте отгатнали от интервю. Докато стигнете до разработката, не гадаете спецификацията. Кодирате процес, който вече сте изпълнили на ръка и за който са ви платили.

Да четете сигналите честно

Всичко това работи само ако сте готови да повярвате на резултатите — а това е по-трудно, отколкото звучи, защото вече сте привързани към идеята. Опасността не е лошите данни; а основателят, който тълкува всеки сигнал като насърчение. Хладкият интерес се запомня като ентусиазъм. Учтивото записване в списък на чакащите се превръща в „силно търсене“. Тук трябва да се борите със собствения си оптимизъм.

Помага да решите предварително как изглежда успешният резултат. Преди да проведете тест, запишете резултата, който би ви накарал да продължите, и резултата, който би ви накарал да спрете. „Ако по-малко от X от интервютата ми описват това като реален, повтарящ се проблем, го зарязвам.“ Да решите летвата, преди да видите данните, е единствената надеждна защита срещу това да си внушите разработка, която не бива да правите.

А понякога честният отговор е не. Това не е провал — това е системата, която работи. Процес на валидиране, който никога не може да върне „не градете това“, не е валидиране, а търсене на разрешение. Основателите, които печелят през цяла кариера, не са онези, които никога нямат лоши идеи. Те са онези, които убиват лошите идеи за три седмици и няколкостотин евро, вместо да ги отглеждат година.

Когато наистина сте готови да градите

Да кажем, че сигналите са добри. Проблемът е реален, хората го описаха с чувство, неколцина сложиха пари. Сега — и едва сега — разработката има смисъл. Но дори тук сдържаността се отплаща. Целта на първата ви версия не е да бъде продуктът, който си представяте. А да достави единствения основен резултат, за който вашите валидирани клиенти плащат, и нищо друго засега.

Тук валидирането тихо ви подарява нещо: остра, подкрепена с доказателства спецификация. Знаете за кого е, коя е основната задача, какво хората ще платят и кои функции изникваха отново и отново срещу тези, за които само на вас ви пукаше. Тази яснота струва повече от каквото и да е предварително проектиране. Това е разликата между изграждането на правилното малко нещо и изграждането на скъпо всичко.

Често задавани въпроси