Как создать стартап

Занятие 2. Гипотезы

● 

Определение гипотезы

● 

Использование методологии SMART

● 

Циклы HADI как способ ускорения развития продукта

● 

Игра «HADI циклы»

Чему научитесь:

● 

Корректно ставить цели. Тестировать гипотезы. Ускорять развитие продукта.

Посетил 2ое занятие курса по продукт менеджменту. Тема: Гипотезы, HADI-циклы, SMART.

Пусть простит меня лектор, но вау-эффекта не было. Далее идет скучный разбор занятия на десяток абзацев и не говорите, что я вас не предупреждал.

Тема, на самом деле, огонь. Гипотезы – это самая мякотка работы продакта, исследование реального мира. От занятия я ждал магии, неожиданных и неочевидных открытий и не побоюсь этого слова, гроусхакинга.

Что же было рассказано.

Теория: цели должны быть SMART, т.е. определенными, измеримыми, достижимыми, релевантными (это самое важное – иметь смысл, отвечать на вопросы "зачем я это делаю", "чтобы что") и ограниченными по времени.

Гипотезы надо выдвигать как можно чаще через 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м случае юзеры отваливаются позже и проводят больше времени в сервисе и это типа хорошо. Хотя какая нам разница если доход не изменился, а скорее даже упал? Т.к. чем дальше клиент безуспешно прошел по воронке, тем больше ресурсов мы на него истратили. Если юзер ничего не купил, то лучше пусть он отвалится в начале и мы меньше ему примелькаемся и надоедим.

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

Конечно, если вы только что открывшийся стартап и не сделали ни одной продажи, то надо хоть кого-то провести через всю воронку и таки продать. Но для "нормального" бизнеса это правило, похоже, несет больше вреда, чем пользы.

Постулат 2: Сначала оптимизируй самую узкую часть воронки (см. Теория ограничений Голдратта (TOC)).

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

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

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

Х=100*0.3*0.2=6 чел.

Оптимизируем широкое место:

Х=100*0.6*0.1=6 чел.

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

С точки зрения математики имеет смысл расшивать узкое место т.к. поднять конверсию в 2 раза с 0.2 до 0.4 получится, а с 0.7 до 1.4 нет (КПД не может быть >100%). Но кто сказал, что первое сделать проще, чем второе? Можно стоит улучшать то, что получается, а не биться в стену?

Какие там конверсии при переходе по страницам эппл при покупке айфона? Да всем насрать. На каком бы этапе яблокофил не отвалился, он все равно придет и купит последний айфон иначе он нищеброд, который не достоин своим андроидом лайкать пост Кардашьян. Даже наоборот, на месте продакта сайта эппл я бы максимально затруднил покупку. Ну там, введите 100 текстовых полей с описанием о себе. Оставьте 5 емайлов, по которым вам можно написать и заблокированная галка о получении спама. Мелкая серая в цвет фона кнопка КУПИТЬ до которой нужно скроллировать 8 экранов вниз и 2 экрана вправо. Если продукт легко получить, он перестает быть элитным и желанным, впрочем, девушки этот момент понимают лучше:)

Вообще, оптимизации конверсии придается слишком большое значение. Был пример из презы про Аирбнб, которые тестят 700 гипотез в неделю. Это типа круто, т.к. типовой стартап тестит 1-2 гипотезы. Т.е. айрбнб 700 раз в неделю перекрашивает кнопку КУПИТЬ и через АБ тест смотрят где конверсия лучше? Сколько юзеров, которые увидели непривычную кнопку, переставленные местами блоки или изменившийся набор полей покинули сайт, сказав что опять у них сайт косячит?

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

Как пошутил лектор, его девушка сказала, что с ним невозможно поссориться, т.к. он перестал говорить утверждениями, а стал говорить предположениями. Вот что кастдев с людьми делает. Слово "кажется" рулит!

PS: публичная преза ФРИИ по юнит-экономике (гуглите в интернете, этого не было на занятии)

Идея выбрана: ЗаявкаНаПокупку (ZNP)

Насчет идей для разработки в процессе курса по продукт менеджменту. Шеф курса сказал, что обе идеи огонь (ЗаявкаНаПокупку (№49) и УберКодревью (№71), но лучше все-таки ЗаявкаНаПокупку (ZNP).

Я сделал презу для ZNP. Покритикуйте, плиз (донесение идеи, смысл, текст, картинки, шрифты и др)!

Ссылка на презу: https://docs.google.com/…/1LbMYxl2mI9LkGkmegmbNi20ou6…/edit…

Для каждого слайда внизу есть текст, как его буду озвучивать. Его тоже критикуйте

Ниже мнение шефа о предложенных идеях:

>>>

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

С точки зрения самих идей, кажется что они обе достаточно тяжелые с точки зрения бизнес-процессов.

Что в сервисе “ЗаявкаНаПокупку” надо сильно поменять привычный уклад вещей и по сути продавцу нанять нового человека для участия в таких аукционах.

Что в сервисе “Убер для техлидов” надо учесть массу нюансов с учетом разного стиля кода и т.д.

Абсолютно личное мнение, сервис “ЗаявкаНаПокупку” кажется мне более перспективным, но я не эксперт рынка ни там ни там, поэтому надо брать и проверять гипотезы в реальности.

Насчет идеи УберКодревью (№71)

Насчет идеи УберКодревью (№71). Покастдевил в одной дружественной ИТ-компании (скрины далее). Я думал, что B2B проще. Если зашел в одну компанию, считай, жизнь удалась. А с B2C сплошной геморрой. Только привлек клиента (физика), как он уже отвалился и не факт, что стоимость его привлечения будет больше выручки с него. По хорошему, должно быть больше раза в 3. Но как выяснилось, с B2B все не так просто. Проблемы с приватностью данных клиента и подрядчика и интеллектуальной собственностью, даже при подписанных NDA. Кодревью сплачивает команду и улучшает код и вряд ли хорошие компании захотят иметь внешний кодревью. Это увеличивает стоимость контракта для клиента. Проблема этического толка – кто гарантирует, что внешний ревьюер не обругает код команды и не перетянет проект в свою компанию? И прочая и прочая. В общем, выглядит круто, интересно, технологично, но если копать дальше, наверняка вылезут и другие проблемы. Хотя, конечно, все надо исследовать и проверять.

Занятие 3. Управления командой

● 

Идеальная команда для создания продукта

● 

AGILE методология

● 

Игра «Kanban pizza»

Чему научитесь:

● 

Научитесь подбирать оптимальную методологию под команду и продукт. Внедрять методологию в разработку.

Посетил 3-е занятие курса продакт менеджмента. Тема – команда, Скрам, Канбан. Тема важная, но для айтишников была не очень интересна, т.к. обсуждались очевидные для них вещи, а аджайлом сейчас разве что только домашних питомцев не называют. Плюс многие темы остались нераскрытыми, на уровне тизеров.

При этом для стартапа проблема #1 – создание команды. Найм через личную харизму, работа за доширак и будущую долю, денег нет но вы держитесь, вот это всё. Для продакта же в корпорации этой проблемы не существует, навыки работы с командой ему просто не нужны. Нанимает людей HR, проект организуется приказом руководства, люди подчиняются не продакту, а проджект менеджеру или вышестоящему лиду.

Но обо всем по порядку. У продакта, как и любого руководителя, могут быть подчиненные и разнообразные непересекающиеся активности. Он общается все с большим числом людей и в какой-то момент рвется на части и превращается в человека-снежинку. Еще один сгорел на работе, все вокруг некомпетентные козлы, увольняется и переходит к шагу 1 в другой компании. Чтобы не сгореть, надо держать фокус на основной цели и делегировать задачи.

Проблему обозначили, ОК. Но как ее решать так и не сказали. Здесь бы отлично зашли практики эффективного делегирования, GTD, метод пустого инбокса, метод критического пути, как правильно проводить совещания, ретроспективы, как писать минутки с митингов, фоллоуапы, использование планировщиков, как верифицировать эстимейты и скорость работы программистов (проговаривать задачи, промежуточные точки, создание общего видения). Как ничего не забывать и все успевать.

Было бы неплохо пригласить проджекта из топового диджитал агентства. Пусть он расскажет как выбивать ресурсы разработки и не порваться управляя 3-7 проектами одновременно и 20-40 чел в потенциальном подчинении (и никого в прямом из-за матричной иерархии). Про откаты по гос. тендерам тоже пусть расскажет, полезный навык для Москвы.

Что еще? Традиционно ругали водопадную модель разработки. Дохлого льва не пинает только ленивый. При том, что waterfall – прекрасная методология для проектов, где критически важно сделать "все или ничего". Вы же не захотите лететь в самолете, где не хватает маленькой такой кнопочки, из-за которой невозможно благополучное приземление? Я работал по водопаду в госконторе типа ОВИРа. И там да, никто в прод не запустит проект, который не будет поддерживать весь набор документов, который месяцами дотошно согласовывают юристы. Ну нельзя выдать паспорт человеку без фото, нельзя. А есть еще каскадный, итерационный RUP с CRами, где все становится совсем ОК, все же адекватные люди.

Была игра "канбан-пицца". Изготовление разных типов пицц из бумаги на время. Видимо, мы должны были организоваться, нарисовать канбан-доску и готовить по процессу. По факту был хаос, ор и я в спешке какой-то девушке ножницами чуть было не отрезал палец. Короче, мне не понравилось. Но тут, наверное, проблема во мне, а не в игре. Просто, не люблю суетиться. Еще в универе пока все резались в Starcraft и AgeOfEmpires мне больше были по нраву XCOM, HMM и прочие цифровые шахматы.

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

Но вуаля! Я наконец-то понял, что такое Канбан. Цель канбан – минимизировать WIP (work in progress), незавершенную работу. Чтобы в любой момент времени если процесс остановлен, было готово максимум завершенных задач.

А то кого не спрашивал, все хвалили канбан, мечтательно закатывали глаза, но что это, объяснить не могли. Обычно, говорили что-то вроде: "Канбан – это как Скрам, но без спринтов, ретро и продукт овнера. А вообще в канбане ничего этого нет, а нужно просто запланированную работу сделать в срок". Спасибо, блин, большое. Это как слепому объяснить: "Ну, слон это как зебра, но без полосок, с большими ушами и хоботом на морде".

ОК, я понял что такое канбан. И также понял, что он для ИТ совершенно бесполезен. Минимизировать WIP, вы серьезно? ОК, в одном проекте я управлял 3мя удаленными разрабами из Пензы. Если я видел, что у кого-то в прогрессе больше 1 задачи, то просил его немедленно это исправить, а если не помогало, то эскалировал вопрос его ПМу, чтобы тот починил процесс. Программист может кодить только одну задачу в один момент времени. Если в прогрессе >1 задачи, значит одну из них надо перевести в Hold. Если по ней что-то неясно, перевести в MoreInfoRequired на того, кто даст нужную инфу.

В канбане есть ограничение на максимальное число работ в каждой колонке. В теории, команда кросс функциональна и если, например, тестер не справляется, то все разработчики срочно переквалифицируются в тестеры. Ага, конечно. А если тормозит дизайнер, то все ставят себе фотошоп? Полный бред.

У меня есть предположение, почему такая отстойная вещь как канбан стала популярной в ИТ. Это кроме очевидной версии, что это мировой заговор и диверсия наших узкоглазых партнеров.

Перенесемся в начало 70х годов 20го века. СССР в застое и еле дышит от непомерных военных расходов. Китайцы забивают своих учителей мотыгами в рамках культурной революции. А как учителя закончились, переключаются на воробьев, т.к. великому Мао показалось, что они клюют слишком много зерна и на следующий год миллионы китайцев умирают от голода из-за расплодившихся насекомых.

А японская экономика с 50х годов на подъеме, демонстрируя уникальные 10% роста КАЖДЫЙ ГОД. Они уже 2ые в мире по ВВП и догонят США через десяток лет. На заводах Тойоты внедрена прогрессивная методика канбан, позволяющая выпускать точно в срок столько продукции, сколько запланировано. Япония крупнейший кредитор США, а их бытовая техника признак высокого статуса.

Но внезапно, все изменилось. Евреи раздали люлей своим соседям в Войне Судного дня. Те объявили нефтяное эмбарго. Нефть взлетела и спровоцировала кризис в развитых странах. В Японии случилась торговая война с США, которая закончилась ревальвацией иены и темпы роста упали с 8 до 2%. Южнокорейцы стали выпускать сравнимую по качеству продукцию, но в 2 раза дешевле. Китайцы взялись за ум, скупили или своровали патенты и стали производить товары ужасного качества, но в десять раз дешевле гигантскими объемами. И японское чудо кончилось.

НО БИЗНЕС-КОУЧЕЙ БЫЛО УЖЕ НЕ ОСТАНОВИТЬ. Инфоцыгане всех мастей продолжали по инерции расхвалить все японское по написанным 10 лет назад методичкам. Высокое качество – хотя это отстой, т.к. клиент выбирает по цене. Систему пожизненного найма – хотя это отстой, т.к. убивает креативность сотрудников, а если людей надо уволить, этого не делают и они висят на балансе компании. И, … тадам! КАНБАН.

При этом канбан был придуман для реального производства автомобилей, а не ИТ. Эта штука имеет смысл, если нужны готовые автомобили. Он радикально решил проблему перепроизводства, характерную для советской плановой экономики. Нельзя отделам завода ставить задачу "вкалывайте!" и в конце месяца иметь на складах 10 тысяч кузовов и 3 миллиона рулей. Как это относится к ИТ? Почему работать без спринтов плохо и надо просто фигачить без остановки? Канбан это просто "мы за все хорошее, против всего плохого" или это действительно СИСТЕМА разработки ПО? Много мы сейчас видим успешных транснациональных ИТ-корпораций из Японии, выпускающих массовый потребительский софт?

Свой единственный, к счастью, опыт работы по канбан вспоминаю с ужасом. Это была питерская ИТ-контора, связанная с немцами. Платили выше рынка, но там были ужасно тесные рабочие места, а мозг выносили в двойном объеме. Канбан, как его там понимали, означал, что в начале недели ПМ обещал клиенту поименный список фич, которые будут сделаны до следующего понедельника. При этом оценки команда не давала (в канбане нет такой бюрократии, как планнинг геймы!), задача оценивалась интуицией менеджера. И, собственно, все, крутись как можешь. Каждую пятницу до глубокой ночи и иногда по выходным народ допиливал код с ужасными костылями, лишь бы "сделать все по канбану". ПМ заказывал вечером в пятницу пиццу и считал, что все ОК – команда в едином порыве делает общее дело. Когда у меня стал дергаться глаз я оттуда свалил и жалел только о том, что не уволился в первые две недели, чтобы не испортить себе трудовую.

Фигня этот ваш канбан.

Занятие 4. Обзор задач и выбор проекта

● 

Обзор реальных продуктовых задач

● 

Презентация продуктов и текущих задач представителями компаний-партнеров

Чему научитесь:

● 

Познакомитесь с представителями нескольких компаний, которые представят свои продукты и текущие продуктовые задачи в качестве тем для курсовых работ

На 4м занятии курса были презентации кейсов вместо запланированной темы о методах генерации идей. Сказали, что идеи лучше генерить в конце курса, когда наберешься опыта в факапе идей, победивших на текущем занятии. Было 6 идей от участников курса, 1 от ФРИИ и 1 от внешней компании. До среды 03.07 люди записываются на кейс, в команде 2-5 человека, в каждой будет трекер от ФРИИ.

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

Знаю, что на евентах типа того же Slush в Хельсинки и в стартап-акселераторах основное внимание уделяется питчу идеи со сцены. Идея может быть отстой, но представить ее нужно с блеском. Она должна быть секси (хайповой, виральной, внезапной), должна решать реальную массовую проблему и должно быть понятно где там деньги.

Сравнил свое выступление с презой от ФРИИ и понял как много нужно еще работать. Преза – идеальный пример сторителлинга, это скорее постановка шоу, а не чтение бухгалтерского отчета перед советом директоров. Должно быть не скучно и захватывающе, как при просмотре блокбастера.

Уже после выступления придумал, как улучшить свою презу. У всех был слайд, каких результатов хотят добиться со своим кейсом через 2 месяца. Я написал:

1) проверенные гипотезы

2) выручку 1 млн руб

3) сделать мир лучше

Понял, что нужно было оставить только пункт 2. И отдельно добавить, что НЕВАЖНО, каким образом будет получена выручка. Будут ли это деньги клиентов. Или вместо себя проведем во ФРИИ стартаперов и они смогут пропитчить в лифте инвесторов если их там найдут. Или же зальем на порнхаб видео, как получивший инвестиции стартапер-резидент ФРИИ трахает единорога на первом этаже. Не важно, фокус на $$$.

Далее описание представленных идей и ссылки на их презы в конце поста если на это было получено разрешение (у всех свои заморочки насчет NDA). Хотя я считаю, что идеи не только стоят примерно ничего, но и скорее обладают отрицательной стоимостью т.к. их нужно еще проверять. А любую идею нужно разрабатывать зная, что как только вы проверите ее жизнеспособность, найдете большой денежный рынок, отладите экономику проекта, тут же этот же проект начнут делать Яндекс, МайлРу и тысячи компаний поменьше. В РФ не принято покупать проект, компаниям проще сделать копию идеи.

Представленные кейсы:

1) СЕО на месяц. Кейс ФРИИ.

Цель – продать консалтинг ФРИИ. Приходит компания, говорит нет продаж или покупатели отваливаются или не сходится экономика. ФРИИ выдает им чувака на месяц, который все это чинит. Кейс мне понравился. Понятен спрос (воронку ФРИИ каждый год проходят 3тыс стартапов из которых 100 берут на трек, а остальным можно продать консалтинг), понятно, что продавать (и это не придуманная хрень). Преза прочитана преподом курса, т.е. очень профессионально. Отдельно снимаю шляпу перед автором идеи сделать кейс учебным. Провести кастдев и биздев по выводу на рынок новой услуги ФРИИ не только бесплатно, но и студенты сами будут платить ФРИИ за работу над кейсом. Фришники, вы чертовы гении!

2) Аудиогид для автопутешествий

Интересный проект. Но смущает, что такие сервисы хорошо себя чувствуют только в США (где клиент привык за все платить), а в Европе и РФ не очень. Также непонятна "боль" – сильно ли расстроится турист если у него не будет такой штуки. Я, например, не люблю гиды, а люблю сам ногами ходить по незнакомому городу и все сам узнавать. Ну и роуминг за границей больная тема или же придется пару гигов себе заранее в тлф закачивать.

3) ZNP ЗаявкаНаПокупку (мой кейс)

Мне нравится

4) GipGip (купонатор скидок на ИТ-продукты)

Как я понял, у парней есть команда, они делали okogram, но что-то не взлетело и сейчас новая попытка исследовать рынок и заново запустить продажи. Плюс – экспертиза и имеющаяся база проекта.

5) Мониторинг строительного проекта

Возможно, это был самый сильный кейс, т.к. его выдвинул участник, долгое время работающий в строительной индустрии. Поэтому он явно понимает боли рынка, что там нужно улучшать и за что заплатят. К сожалению, автор не смог присутствовать на занятии и его кейс можно оценить только по презе, без заданных вопросов, что вероятно снизит привлекательность кейса. Что касается меня, то я ничего не понимаю в строительстве, поэтому вряд ли смогу сказать что-то полезное по теме.

6) Psycho (убер для психологов)

Хорошая денежная ниша, нервишки щас у всех пошаливают, телемедицина в тренде, но убийцы в белых халатах явно не моя тема.

7) Ремонтиста (убер для автосервисов, внешний кейс)

Как я понял, у компании была проблема с возвращаемостью клиентов в мобапп и они пофиксили это с помощью программы лояльности (оплата накопленными баллами за услуги). Сейчас видимо хотят, чтобы люди исследовали рынок как им еще вырасти.

8) Eevent (что-то для событий)

Не знаю, меня устраивает Timepad, но возможно придумали что-то новое.

Что скажете? Какие плюсы и минусы идей? Что взлетит?

Ссылка на презы: https://drive.google.com/…/1XtOnA2lZIE3aFBgVrxTPYtAKLMyfbWh…