Что я узнал о разработке продукта в стартапе:
1/ Опасайтесь хороших инженеров.
1/ Опасайтесь хороших инженеров.
2/ Пока у вас нет product-market fit, у разработки одна задача – проверка гипотез и быстрые итерации. Хорошие инженеры думают об инфраструктуре, тестах, процессах – это убивает скорость разработки.
3/ Фичи зло. Каждая фича – это время на разработку, неизбежные баги, усложнение продукта. Пока нет product-market fit вам нужна *одна* крутая идея, за которой придут пользователи. Дюжина "так себе" фич это не решит, только убьет скорость итераций.
4/ Лучший код – это код, которого нет. Почти всегда есть способ проверить идею без кода: интервью с пользователями, мок-ап, посадочная страница, рекламная кампания. Большинство идей здесь и умрет, и в разработку дойдут (в идеале) уже проверенные идеи.
5/ Если можно не нанимать, надо не нанимать. Ваше понимание продукта и пользователей меняется быстрее, чем вы успеваете объяснять это команде. Пока программист делает фичу, вы уже видите, что она не нужна. Фрустрация для всех.
6/ Все, что можно купить, надо покупать. Емейл рассылки, аналитика, у нас даже была подписка на сервис для загрузки файлов (@transloadit). Это позволяет не отвлекать ресурсы разработки, т.е. сохранять скорость итераций.
7/ Итерации надо делать после релиза, а не до. "Проверка" идей без живых пользователей это самообман.
8/ Everybody lies, включая пользователей. Пользователи говорят то, что по их мнению вы хотите услышать. Мне когда-то помогла эта книга:
momtestbook.com
momtestbook.com
9/ Еще лучше не спрашивать, а смотреть метрики и что пользователи реально делают в продукте. Это тема для отдельного поста.
10/ Когда я искал бизнес-модель Джинна, пользователи мне говорили, что готовы платить за отправленные сообщения и не хотят платить бонус, который привязан к зарплате. Все оказалось ровно наоборот.
11/ Для проверки гипотезы с оплатой бонуса я сделал поп-ап для некоторых профилей "начиная общение с этим кандидатом я соглашаюсь платить бонус $XXX по факту найма". Увидел результат и через неделю у Джинна была новая бизнес-модель.
12/ После нахождения product-market fit нужно разгребать технический долг. Приводить в порядок код, инвестировать в инфраструктуру и процессы. Теперь это важно и нужно, т.к. кривой код теперь будет вас тормозить по мере (неизбежного теперь) роста команды.
13/ Даже самый лучший продукт не взлетит, если о нем никто не знает. Дистрибуция (маркетинг) >> продукта, нельзя об этом забывать в "пылу" разработки.
14/ End. Предыдущая серия:
P.S.: очень очень хороший инженер, который способен думать о пользователях, а не TDD, подошёл бы, но: 1) стартапу он не по карману 2) для него нет задач / challenges. Только если это ко-фаундер.
