Дали пишем код, тестваме, създаваме дизайн или сме мениджъри на софтуерен проект в стартъп или утвърдена компания, всички имаме една цел – да създадем продукт, който да се ползва от клиенти. Предполагам сте чували, чели или поне познавате някой, който е чувал за Lean startup. Но не съм сигурен, че всеки го разбира и най-важното имплементира в работата си правилно. Например аз, до скоро само си мислех, че го разбирам и практикувам.

Нека ви разкажа как започна и протече разработката на Office R&D.

Двама програмисти

Двама програмисти решават да създадат софтуерен продукт, смятайки че има нужда от него. Класика. Вечер след работа, сутрин преди работа, събота и неделя здраво кодене… И така няколко месеца. Измисляхме функционалност, имплементирахме, творихме, създавахме, мислехме сценарии. Питахме се и си отговаряхме сами – кой би бил потребителят, защо би ползвал продукта. Създавахме така наречените предположения (assumptions). Написахме доста код. След това написахме още повече код, но понеже сме Lean решихме, че е време да покажем продукта на света във възможно най-ранния момент. Пуснахме го. Вдигнахме малко шум в социалните мрежи. Дори написах статия за това в един от най-популярните блогове в долината… :) Всички приятели се регистрираха. Дадоха ни обратна връзка, ние ги слушахме, оправяхме бъгове, проблеми. Итерирахме.

Инвестиция

Записахме се на Startup Academy Sofia. Говорихме си отново за Lean Startup. И отново си мислех, че знам за какво става дума. По едно и също време два инвестиционни фонда ни поканиха да кандидатстваме – LAUNCHub, Sofia и PiLabs, London. Приеха ни и в двата. Не съм сигурен защо. Никой не разбираше много добре какво правим. Отново ми напомниха за Lean Startup, като дори мениджър от фонда ми прати книгата с молба да я прочета. Защо ли?!

LAUNCHub

Акселерация

Отидохме в Лондон, защото очевидно пазарът е по-голям и възможностите са по-добри. И се започна отново – имате продукт, а кой е клиентът? Защо ще ви ползва и защо ще си плаща? А ние отговаряхме наизуст с нашите предположения и сценариите, които ни изглеждаха супер логични. И така 2 месеца… Очевидно нещата не вървяха. Дори на нас започна да ни прави впечатление. Но продължавахме да си пишем код усърдно.

Толкова много пъти съм чувал фразата – ‘Излез от офиса‘ (Get out of the building…), но въпреки това ни отне доста време да разберем какво означава. Всъщност нещата са доста буквални. Започнахме да се срещаме с потенциални клиенти. Направихме срещи с десетки потенциални клиенти за много кратко време (Един от плюсовете да си в Лондонски акселератор). Започнахме да им задаваме въпроси. Повече да ги слушаме, по-малко да им ‘продаваме’ идеята си. И нещата започнаха да се наместват. Функционалността, в която виждахме толкова много смисъл, се оказа, че всъщност няма чак толкова много смисъл. Хората се интересуваха от други неща, имаха други проблеми. Започнахме да работим с определени клиенти. Да се виждаме всяка седмица. Да ги слушаме и да събираме обратната им връзка. Реално да пишем код, който решава техните проблеми, а не тези които ние си мислим, че те имат. Един вид излязохме от офиса. Даже започна да ни харесва, а и времето в Лондон не е толкова лошо, колкото разправят в прогнозата за времето… :)

На път към клиенти

Lean за програмисти

Оказа се, че не е лесно да си програмист и да си lean едновременно. Супер лесно е да се подхлъзнеш по анти-lean плоскостта и да твориш софтуер, от който никой няма нужда. Реално има логично обяснение за това. На нас ни е лесно да създаваме софтуер. Доста по-лесно ни е да стоим в офиса, да разсъждаваме и да програмираме това, което ни се струва най-логично. За съжаление този проблем съм го виждал хиляди пъти. Не само в стартъпи. Не само от програмисти. Много често се случва и продуктовите мениджъри да влизат в ролята на клиент, започвайки да разсъждават ‘от какво ли има нужда клиентът’… Няма лошо в това, стига след това да бъде валидирано с клиентите.

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

  1. Направи най-простото решение;
  2. Покажи го на клиенти;
  3. Вземи обратна връзка;
  4. Подобри решението в правилната посока;
  5. Итерирай, докато клиентът не е напълно доволен.

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

Пс. – Оказа се, че вече не правим това, което пише в книжката по-горе…