Как правильно запускать стартап по Эрику Рису

Дочитал книгу создателя технологии бережливого стартапа - Эрика Риса. Книга утомительная, с точки зрения комфортного чтения. Вымотала так, что я её сильно растянул, хотя планировал потратить максимум дня 3-4.
Автор работал над до сих пор существующей игрой, похожей на Секондлайф - IMVU. Мутная херь, но людям нравится. Начиналась она как онлайн мессенджер с интерактивными аватарками. Рис много теорий напридумывал (или просто обдумал и приспособил) в процессе работы, от переосмысления конвейера до гибкой разработки. Это все околокорпоративные штуки и поэтому ужасно скучные, но смысл там есть:

Основная тема всей книги это обсасывание отношений с клиентами, то есть как круто постоянно быть с ними на связи. Если отбросить то, что применяется крупными игроками, можно отметить следующие темы:

  • Ставьте финансовые цели для стартапа, пусть даже цель будет 300$. Это поможет вам быть более приземленными и не летать в облаках своих фантазий. Например, если у вас нет конкретных цифр, позиция - "деньги сейчас не главное", то вы рассчитываете на завоевание мира. А когда вы поставили цель - заработать 300$, а заработали 100$, то это вернет вас на землю.
  • Одна из основополагающих тем, которая кочует по разным книгам о стартапах - не ориентируйтесь на то, что говорят клиенты в опросах - они сами не знают что им надо. Решение о выборе товара, или услуги принимается глубоко в подсознании и слабо поддается анализу.
  • Немного из другой книги, но тут в тему - не задавайте прямые вопросы о вашем потенциальном продукте, когда проводите предварительный анализ. Вам буду говорить всякую чушь, далекую от реальности. Спрашивайте только факты из жизни клиентов.
  • Предлагайте готовые варианты решения и наблюдайте за реакцией. Это отчасти касается рекомендации о создании MVP. 
  • Добавили опции, дали пользователям попробовать. Если эффект положительный, то двигайтесь в этом направлении.
  • Ещё одна важная тема, которая будет появляться не раз в этом блоге - выработайте привычку смотреть в будущее своего сервиса, либо бизнеса. Вы должны представить как все будет работать через месяц, год, пять лет. Что может случиться через данные промежутки времени, что конкретно вы будете делать, как будет работать созданный вами механизм, включая людей на позициях. Эта ключевая мысль также книги другого автора - Рея Далио.
  • После предоставления клиентам MVP проанализируйте - станут ли они рассказывать знакомым о сервисе. Так вы сформируете гипотезу роста стартапа.
  • Если гипотеза роста не оправдалась, то надо менять направление, а не застревать в неудачном решении. Смысл запуска - раскрутить механизм роста.
  • Все решения должны исходить из анализа действий клиентов. Если у вас нет даже MVP, ориентируйтесь на существующую практику в аналогичном сегменте, задавайте вопросы пользователям похожих продуктов.
  • Создайте архетип (профиль) вашего клиента. Это очень важно. Можно использовать подход дизайн-мышления. Но надо помнить о том, что архетип крайне приблизителен.
  • Постоянно разбавляйте теорию действием, не ограничивайтесь либо одним, либо другим.
  • Хорошо если во время привлечения первых клиентов вам попадутся так называемые ранние последователи - люди определенного склада характера, которые пробуют новые продукты и активно делятся результатами их применения.
  • Иногда клиенты считают, что MVP - продукт недостаточного качества. Если так, это нужно использовать для того, чтобы понять, какие опции важны для клиентов.
  • Важен баланс настойчивости и разумности при достижении целей стартапа. Если вы будете слишком увлечены целью достижения успеха, то не заметите что плывете не в том направлении.
  • Процент платных пользователей часто не зависит от самого продукта, а зависит от общей концепции. Если вы создаете ненужный продукт, его оптимизация, или маркетинг ни к чему не приведут.
  • Используйте когортный анализ. Не вводите сразу много улучшений в продукт. После введения каждого улучшения разделите пользователей на группы по какому-то признаку (например, времени посещения сайта) и проанализируйте реакцию каждой когорты на изменения. 
  • Для анализа функций можно использовать платные таргетированные объявления.
  • При сплит-тестировании уже существующим пользователям одновременно предлагаются разные версии продукта, та версия, что получила положительный отклик принимается в дальнейшую работу.
  • Пример анализа пользователей школы изучения языков Grockit - компания провела сплит-тестирование, которое включало функции самостоятельного изучения (без репетитора). Во время этого теста был замечен повышенный интерес к самостоятельному обучению. Далее, по этим результатам, компания ввела ещё и перекрестное обучение, когда студенты помогают друг другу учиться.
  • Ещё пример сплит-тестирования - насколько улучшает отклик пользователей ленивая регистрация. На тот момент, оказалось что эффект от регистрации, по сравнению с эффектом от непосредственно маркетинговых действий, практически отсутствует.
  • Если вы обнаружили, что глобальная стратегия, или концепция продукта неверна, то нужно совершить так называемый ВИРАЖ. А именно резкую смену направления с переосмыслением планов.
  • Например, когда при тестировании уровень рекомендаций пользователями вашего продукта, а также уровень удержания пользователей не превышает 5%, нужно задуматься о вираже.
  • График роста ключевых показателей проекта должен напоминать хоккейную клюшку. 
  • Как пример виража можно рассмотреть переориентирование сервиса социальной сети политических активистов Votizen в сервис подачи заявлений в политические структуры. У данного проекта ключевые показатели стали следующими: удержание - 21 %, а рекомендации - целых 54 %.
  • Ещё один пример виража - сервис для инвестиций отключил у себя возможность эмуляции реальных торгов и переориентировался на профессиональных инвесторов, тогда профессионалы более серьезно отнеслись к данной платформе.
  • Определите - какие ваши действия приводят к росту, а какие к потерям.
  • Есть три вида роста проектов: оплаченный (когда заработок успешно реинвестируется в привлечение); вирусный (пользователи сами распространяют информацию); липкий (например, сервис с ценной информацией, на который заходят каждый день).
  • Ещё пример липкого роста - зависимость от поставщиков технологий. Когда разработчики выбирают производителя баз данных, они как бы прилипают к нему.
  • У разных видов роста - разные техники и коэффициенты, и когда они уменьшаются надо начинать думать о вираже.
  • Например, пользователи не хотят делиться сервисом знакомств с друзьями потому, что в этом нет смысла. Следовательно, вариант вирусного роста сервисом знакомств не рассматривается.
  • Поток единичных изделий (небольших партий). Как вы думаете, если вам надо отправить много писем, то как эффективнее поступить - сначала надписать все конверты, разложить письма, потом заклеить? Или надписывать, раскладывать и заклеивать каждое письмо по очереди? Оказывается, провели исследования, и каждое письмо надо упаковывать и надписывать по очереди. 
  • Это связано с возможными ошибками конвейера, которые оказываются фатальными.
  • Toyota в свое время использовала данный механизм для большей кастомизации своих автомобилей.
  • В стартапе данная технология применяется в виде доступности новой функции относительно небольшому числу пользователей.
  • Уменьшая объемы изменений можно быстрее пройти цикл "создать-оценить-научиться".
  • Способность быстрее учиться у клиентов - важнейшее конкурентное преимущество, необходимое любому стартапу.
  • Современная система образования была разработана в эру массового производства и поэтому основана на подходе больших партий.
  • Если возникает серьезная проблема с качеством, то лучше остановить производство. Данное правило написано кровью многих предприятий.
  • Используйте метод пяти "почему?" для поиска причин образовавшейся проблемы. Задавайте вопрос "почему это произошло?" не менее 5 раз. В конечном итоге вы, скорее всего, столкнетесь с человеческим фактором.
  • Когда компания Риса начала нанимать на работу сотрудников, метод помог им понять, что проблемы замедления разработки продукта связан с отсутствием обучения.
  • Переходите от монолитных команд к гибким группам. Сокращайте время цикла разработки. Сразу получайте обратную связь от клиентов. Дайте группам полномочия принимать быстрые решения.
  • В старых командах время изменения способа работы может сильно затянуться.
    ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

Комментарии