Гипотезы надо выдвигать как можно чаще через HADI-цикл (гипотеза, действие, получение данных, инсайты).

Придумали гипотезу, поменяли бизнес-процесс (перекрасили кнопку на лендинге) поменялась конверсия, поняли ОК это или нет.

Классическое определение стартапа про временную организацию, организованную для поиска масштабируемой бизнес-модели.

Странный слайд про 4 вида организаций: простая, сложная, неопределенная и хаотическая. Тут я, каюсь, вспылил и спросил, что за хрень происходит и как слайд связан с темой занятия – гипотезами. Еще в презу добавить GTD и 7 навыков высокоэффективных людей и бинго! Отдаем Тони Роббинсу и он соберет с этой презой стадионы. Вырулили в итоге на то, что из 4х типов компаний HADI подходит только типу 3 "неопределенные" (с чего это вдруг?), а к ним относятся стартапы и значит HADI+startups=love

Далее практика в виде лендинга из 3х страниц в каждом 2-4 блока, которые нужно было менять (цвет и размер кнопок, промокод, зачеркнутая цена, число полей), чтобы добиться максимальной конверсии на каждом этапе и общего профита. Для знакомых с комбинаторикой было скучновато.

Из простого, но полезного – метод приоритезации гипотез ICE (ICE score = Impact * Confidence * Ease – влияние * уверенность * простота). Ставим баллы 1..5 каждому фактору и по общему баллу выбираем, что проверять. Ура! Я интуитивно сделал именно так при выборе идей для курса. Еще это отличный способ разрешения споров вместо голосования, которое входит в клинч при равенстве голосов и непонятках, чей голос весомее.

Самое сложное для меня на занятии были не показанные инструменты по сбору метрик, а необходимость убеждать людей и договариваться в процессе выбора гипотез. Я говорил, что не надо крутить все ручки одновременно, давайте менять элементы сайта по одному и замерять конверсию. Был неправ. Оказалось, можно менять несколько элементов если они находятся на разных этапах процесса со своей конверсией. Нужно быть готовым часто ошибаться, что бьет по самооценке. Для общения нужны софт скилы, а у меня с этим большие напряги.

ОК ставить чуть завышенные цели. OKR методика (Objectives key results), не помню про что это.

Что интересно, оба два основных постулата работы с воронкой, которые пропагандируются мастодонтами юнит экономики, легко опровергаются математикой и здравым смыслом если первой недостаточно.

Постулат 1: При прочих равных лучше оптимизировать начало воронки.

Опровержение: Пусть у нас 100 чел на входе воронки, а воронка состоит из 2х этапов с конверсией С1=20% и С2=20%.

На выходе воронки имеем: Х=100*0.2*0.2=4 чел.

Оптимизируем (в 2 раза поднимаем конверсию) начало воронки:

Х=100*0.4*0.2=8 чел.

Оптимизируем конец воронки:

Х=100*0.2*0.4=8 чел.

Вывод: ничего не изменилось.

В 1м случае юзеры отваливаются позже и проводят больше времени в сервисе и это типа хорошо. Хотя какая нам разница если доход не изменился, а скорее даже упал? Т.к. чем дальше клиент безуспешно прошел по воронке, тем больше ресурсов мы на него истратили. Если юзер ничего не купил, то лучше пусть он отвалится в начале и мы меньше ему примелькаемся и надоедим.

Я, например, очень злюсь на сервис, если долго выбираю товар, ввожу данные доставки, а на странице оплаты получаю сообщение "Товар закончился" или "Оплата налом" (а у меня с собой только карта), т.е. отваливаюсь в конце воронки. В этом случае я понимаю, что сайт делали мудаки, которые сожрали мое время и никогда больше не захожу к ним и другим не советую. Если клиент свалил в самом начале (на главном экране не заинтересовался списком продуктов) это ОК т.к. его заново можно активировать и привести на сайт через рекламу, у него нет отторжения к сервису из-за прошлого неудачного опыта.