Grow Horse

Управление проектами

Grow Horse
Управление проектами
Подписаться
5.


Упрощайте до минимума, если без разработки не обойтись Худший способ проверить продуктовую гипотезу – реализовать 100% функционала и посмотреть, что получится. Вы потратите много времени, ресурсов и энергии команды на задачу, которая принесет ожидаемый результат с вероятностью 20-30%. Таковы средние показатели по проценту подтверждающихся гипотез роста.

Если разработки не избежать, как менеджер продукта, вы должны стремиться минимизировать ресурсы:


- выделите MVF (минимально жизнеспособную фичу), которая по аналогии с MVP позволит собрать достаточные данные, чтобы подтвердить или опровергнуть гипотезу;


- продумайте способ информирования о новом функционале и используйте фантомные кнопки, которые позволят измерить процент заинтересованных пользователей;


- смоделируйте ухудшающий тест, который путем отрицательных изменений, позволит установить влияние функций продукта на целевые метрики.

О важности проверки гипотез для достижения целей по росту знает каждый менеджер продукта. Но в России пока существует не так много компаний, в которых продакты занимаются этим системно.

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

Какие еще способы увеличить количество и качество проверяемых гипотез вы знаете и используете?

Grow Horse
Управление проектами
Подписаться
Как проверять больше продуктовых гипотез

Продолжаю поднимать старые посты из канала, которые считаю актуальными и интересными.

Несколько рекомендаций менеджерам продукта, отвечающим за рост важных метрик.


1. Выделите фиксированное время на работу с гипотезами

Отсутствие времени – главная причина, которая мешает добиваться результата. Продакт погрязает в операционной рутине, едва успевая выполнять текущие задачи.

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

Чтобы выстроить полноценную работу с экспериментами, нужно зафиксировать в календаре конкретный объем времени, который будет посвящен только гипотезам. Он варьируется в зависимости от ситуации, но должен занимать не меньше 20% от общего объема. Один полный день в неделю или два дня по четыре часа – стартовый минимум, который позволит сделать процесс системным и регулярным.


2. Заведите правила и единое пространство для записи гипотез

Многие менеджеры не видят смысла поддерживать порядок в работе с гипотезами, потому что относятся к ним, как к эфемерным идеям, большинство из которых не будет реализовано.

До тех пор, пока гипотеза не сформулирована достаточно четко, так и есть. Но как только вы заведете единые правила формулировки и выделите конкретный документ для записи, гипотезы обретут куда больший вес.

Есть разные способы формулирования гипотез. Например, шаблон: «если…, то...». В первой части вы пишите, что конкретно предполагаете сделать, во второй – к какому ожидаемому результату это приведет и на какую метрику повлияет.

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


3. Вовлекайте команду в работу с гипотезами

Генерация гипотез часто бывает индивидуальной работой продакт-менеджера. Это упущение, которое сильно мешает построить системный процесс.

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

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

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

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


4. Старайтесь проверять гипотезы без разработки

Многие гипотезы можно проверить, не меняя ничего в продукте. Вот несколько способов:


- Исследование имеющихся данных;

В основе гипотезы могут лежать причинно-следственные связи, существование которых можно доказать или опровергнуть, исследуя ретроспективные данные о продукте.


- Анализ поведения и разбор сессий;

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


- Интервью с пользователями;

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


- Эксперименты в каналах привлечения.

Если ваш продукт активно продвигается в платных каналах, часть гипотез вы можете проверить на уровне привлечения. Сформулируйте ценностное предложение под новую функцию и попросите маркетеров запустить небольшую кампанию с тестовым бюджетом. Показатели CTR в сравнении с уже работающими объявлениями покажут уровень интереса аудитории.

Grow Horse
Управление проектами
Подписаться
Три уровня развития команды роста

Не теряющий актуальности материал от одного из главных гуру growth-подхода – Casey Winters.

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

С момента создания команда роста проходит три уровня изменений в процессах работы и фокусировке.

1 уровень: стартовая команда

В начале пути команде лучше сосредоточиться на одной важной проблеме, решение которой может существенно отразиться на росте.

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

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

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

2 уровень: развивающаяся команда

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

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

Эксперименты с поиском и развитием Aha-moment могут помочь команде существенно улучшить показатели активации пользователей в продукте.

На новом уровне команде роста важно выстроить эффективное взаимодействие с командами продукта и маркетинга.

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

3 уровень: зрелая команда

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

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

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

Для перехода на уровень зрелости, команде необходимо сформулировать и утвердить North Star Metric – главную метрику роста, которая станет основным измерителем эффективности работы команды.

В разных проектах эволюция команды роста происходит по-разному.

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

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

Grow Horse
Управление проектами
Подписаться
Презентация книги в Санкт-Петербурге

В этот четверг (
22.07) совместно с Издательством «Альпина» проведем презентацию моей книги «Взлом роста».

На встрече обсудим:
- Что такое Growth Management, чем и кому он полезен?
- Зачем нужно что-то менять в бизнес-процессах, если они как-то работают?
- Что такое команда роста? Как ее собрать и вырастить?
- Какие инструменты помогут найти точки роста у вашего проекта?
- Как формировать и тестировать гипотезы?

Можно будет также задать мне вопросы по теме и подписать свой экземпляр.

Мероприятие пройдет в магазине «Буквоед»: Невский проспект 46, 3 этаж, новая сцена.

Начало в 19:
00.

Вход свободный, но количество мест ограничено из-за необходимости соблюдать социальную дистанцию.

Если решите прийти, напишите в комментариях к посту, чтобы я забронировал вам место.

Буду рад увидеться!

Grow Horse
Управление проектами
Подписаться
Рекомендации по настройкам Facebook Ads для тестов

В комментариях к предыдущему посту попросили рассказать, какие рекомендации я получил от экспертов по UA.

Решил выделить в отдельный пост:


1. Запускать сразу на iOS 14 и выше. В более ранних версиях нечего ловить.


2. Начинать с максимально широкого таргетинга. Максимум пол и широкий диапазон возраста. Если пытаться выставлять интересы, можно закопаться.


3. Оставлять все плейсменты. После первых запусков смотреть, какие лучше работают и отключать неэффективные.


4. Если аудитория англоязычная, то тесты начинать с US. Получится на US, получится все остальное. В обратном случае гарантии нет.


5. Пробовать Web to App. Там CPC получается заметно меньше. Если хорошая конверсия на лендинге, цена установки может быть ниже, чем в кампаниях на приложения.


6. Оптимизировать CR из перехода в стор в установку: название, скриншоты, рекламный текст, отзывы. В среднем должно получаться не меньше 30%. Если меньше, то есть какие-то проблемы, их надо фиксить в первую очередь.


7. Самое важное: решают креативы. Нужно тестить много баннеров и обязательно видео. Разница в CPI между креативами может быть кратной.

Grow Horse
Управление проектами
Подписаться
Статус по проверке гипотезы нового продукта

Продолжение серии постов (раз, два) про проверку гипотезы нового продукта мобильным приложением.

В конце июня я успешно выпустил MVP в App Store. Разработчики, которых я в итоге выбрал, следуя своему подходу, отработали отлично. Это было идеальное сотрудничество по цене, качеству и коммуникации.

Могу с уверенностью рекомендовать студию Neti всем, кто ищет надежного партнера на разработку мобильного приложения.

Трафик из Facebook Ads

Мой план после выхода приложения заключался в том, чтобы используя креативы и таргетинги, которые хорошо себя показали весной на тестовом прогоне, закупить когорту из 150-200 пользователей в App и собрать данные по воронке онбординга, конверсии в подписку и удержанию.

План, к сожалению, провалился.

Трафик на мобильное приложение оказался многократно дороже, чем я рассчитывал.

Первая кампания дала ужасающую стоимость установки в 18,5$. Пролив бюджет 200$ за несколько дней, я не увидел никакой динамики к снижению. Очень высокий CPM при в разы более низкой конверсии в клики, чем на тестах с лендингом.

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

Рекомендации оказались очень ценными, с их помощью я перенастроил кампании и с теми же креативами смог снизить стоимость установки до 6,5$. Но для полноценного теста все еще дорого. Целевая для меня стоимость – 2-3$.

Всего за период тестов я привлек 40 пользователей из США при бюджете в 515$ и средней стоимости установки
12.9$.

Проблемы с аналитикой

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


1. Низкая точность атрибуции. Я не стал ставить трекеры вроде AppsFlyer или Adjust, потому что планировал использовать для привлечения только один канал и не ждал никакой органики. В итоге столкнулся с тем, что Facebook SDK видел только половину от тех установок, которые приходили по факту. На маленьких объемах это не большая проблема, кампании я запускал последовательно, поэтому просто собирал недостающие данные руками.


2. В Amplitude не отображается статистика пользователей, запретивших приложению собирать данные. Сейчас я вообще не вижу в аналитике часть пользователей, которые приходили с кампаний на iOS
14. Как результат – не могу построить нормальные воронки. Вероятно, проблема с настройками SDK, я пока точно не понял. Если вы работаете с Amplitude и можете что-то посоветовать, напишите мне @denisdizzy Буду благодарен.

Что дальше

Все мои изыскания показывают, что для получения адекватной стоимости установки нужно тщательно поработать с креативами. Готовлю бриф на основе ценностных предложений продукта и ищу людей, кто поможет сделать статичные баннеры и видео-ролики для новых тестов.

Хочу сделать 10 баннеров и 5 роликов и протестировать разные настройки кампаний:


- Автоматическая кампания на установки iOS 14+;


- Несколько кампаний со специфичными (но широкими) таргетингами, настроенными вручную;


- Web to App кампания с таргетингом на пользователей iOS 14+. WTA – это когда закупается реклама сайта, а не приложения, но задача сайта при этом сконвертить пользователей на переход в App Store и установку.

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

Я не буду развивать продукт пока нет уверенности, что можно привлекать в него пользователей по адекватной цене. Привлечение я считаю наиболее рискованным предположением, поэтому все силы сейчас на RAT (Riskiest Assumption Test).

Grow Horse
Управление проектами
Подписаться

​​Вышла моя книга «Взлом роста»

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

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

Материал основан на контенте курса Growth Manager, постах из канала и собственном опыте работы с различными командами.

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

Купить книгу можно в бумажном, электронном и аудио форматах. Вот ссылки:


- Бумага

- Электро

- Аудио

Буду благодарен, если после прочтения вы оставите отзыв на Озоне или Литресе.

Это поможет мне понять реальную ценность книги и положительно скажется на продвижении темы роста продуктов.

Grow Horse
Управление проектами
Подписаться
Новый Epic Growth Seasons Вышла первая серия нового сезона Epic Growth Seasons.

Ребята из Эпика, конечно, рассказывали мне, что готовят нечто крутое, но я не представлял насколько. Продакшн сериала теперь на таком уровене, что поначалу даже непривычно.

Качество картинки, постановка кадра, декорации, свет – это полноценное документальное кино, которое хочется смотреть целиком, не перематывая и не ускоряя.

В первой серии раскрывается тема продуктовой стратегии. Топы крупнейших российских компаний делятся мыслями и наработками из собственной практики.

Не буду много писать. Я впечатлен и воодушевлен, что контент такого качества стал появляться в нашей тематике.

Сериал доступен в подписке Epic Growth, там есть бесплатный пробный период, поэтому просто сходите и посмотрите сами.

Grow Horse
Управление проектами
Подписаться

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

Более простой способ – посмотреть на соц сети компании или человека. Сколько друзей/подписчиков, ведется ли активность на страницах.

Если вы нашли фрилансера, который адекватно общается, показывает крутое портфолио, но в Фейсбуке у него 100 друзей, а на аватаре супергерой из Марвела, то риски, что он просто решит пропасть в какой-то момент, весьма велики.

Формальности К формальностям я отношу все, что связано с юридичеcким оформлением работы: резидентство, наличие договора, условия договора, порядок оплаты, порядок отчетности.

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


4. Принять решение

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

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

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

Даже если возникнут сложности или продукт не полетит, это будет классный опыт, который не пропадет даром. Так я себя успокаиваю.

Напишите в комментариях, какие еще важные моменты про поиск и выбор разработчиков я не раскрыл? Что было бы интересно узнать детальнее? И стоит ли вообще писать про это в канале о growth-подходах?

Grow Horse
Управление проектами
Подписаться
Как найти и выбрать разработчиков на проект

В процессе проверки своих гипотез по новому продукту я пришел к выводу, что оптимальный вариант MVP – мобильное приложение.

С учетом того, что ресурсы сильно ограничены (я вкладываю собственные деньги), а неопределенность высокая (новый продукт в новом сегменте) – на разработку MVP адекватно выделить весьма скромный бюджет.

В таких условиях достаточно сложно искать разработчиков. Вы не хотите переплачивать, а разработчики не хотят работать за копейки.

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

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


0. Постараться обойтись без кода

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

Поисследовав no-code сервисы для создания мобильных приложений (Glide, Adalo, Bubble) и пообщавшись со знающими людьми, я пришел к выводу, что в моем случае это не будет оптимальным решением.

Причина простая. Логика приложения не вписывается в стандартные шаблоны, поэтому из коробки использовать сервисы не получится, нужно будет костылить.

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

В моем случае пришлось идти к программистам. Но в вашем все может быть иначе.


1. Тщательно подготовиться

Чтобы получить адекватную оценку проекта, вы уже на стадии обращения должны иметь: дизайн (в крайнем случае мокапы), общее описание требований к приложению (платформы, версии и тд), функциональное описание (основные функции, логика).

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


2. Обеспечить себя предложениями

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

Мне повезло, у меня есть несколько знакомых в теме разработки и достаточно много релевантных друзей в Фейсбуке. С одного поста и нескольких личных переписок я собрал 14 оценок в диапазоне от 50 000₽ до 990 000₽.


3. Определить критерии выбора

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

КоммуникацияВ процессе взаимодействия с разработчиками обязательно возникнут какие-нибудь сложности и недопонимая. Так бывает почти всегда.

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

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

Запрашивайте портфолио и не ленитесь его тщательно исследовать – смотреть рейтинги, читать отзывы, устанавливать и использовать приложения.

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

Grow Horse
Управление проектами
Подписаться
Чеклист по проверке гипотезы о новом продукте платным трафиком

Закупить рекламу на лендинг – один из самых популярных способов проверить гипотезу о новом продукте без разработки.

Я делал так дважды. Летом 2018 года для сервиса личных наставников. Тогда экономику свести не удалось, и от идеи я отказался. Весной этого года с мобильным приложением, которое сейчас в процессе разработки. На рекламные эксперименты я потратил в общей сложности около 1000$.

Делюсь своим чеклистом по этому подходу:


1. Определить критерии успеха

В первую очередь нужно понимать, какая стоимость привлечения и на каком объёме трафика вас устроит. Стоимость будет определяться гипотетической юнит-экономикой продукта, а объём должен быть достаточным, чтобы подтвердить стабильность результата.


2. Смоделировать воронку

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


3. Спланировать бюджет и сроки

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


4. Сформулировать ценностное предложение

Понимание ценности продукта – отправная точка для создания рекламных креативов. Я использую Value Proposition Canvas. С помощью VPC удобно описывать пользовательский сегмент и его потребности, что помогает сформулировать ценность. Многие сейчас используют для этой задачи фреймворк Jobs To Be Done.


5. Получить экспертизу в каналах привлечения

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


6. Обеспечить разнообразие креативов

Проверка гипотезы о новом продукте – это не A/B-тест. Не нужно тестировать одинаковые картинки с разным цветом фона. Вам нужны принципиально разные креативы (фотографии, графика, видео и тд), чтобы найти наиболее работающий формат. Вы также можете проверить разные ценности продукта в связке с креативами.


7. Описать сценарии дальнейших действий

Каким будет ваш следующий шаг, если экономика сошлась? А если немного не сошлась, но бюджет исчерпан? А если сильно не сошлась, есть бюджет, но все сроки прошли? Набросайте короткие сценарии под разные ситуации. Это сэкономит кучу энергии при принятии решений в будущем.

Тратить собственные деньги на эксперименты всегда больно. Вы не можете ожидать быстрого возврата средств и не знаете, какой результат вас ждет.

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

Grow Horse
Управление проектами
Подписаться
Принципы команды роста Miro

В Miro одна из самых прокаченных команд роста, о которых я знаю. Это даже не команда, а целый департамент, в котором работают больше 60 человек.

Вика Харламова (Growth Product Manager) рассказала в Epic Growth про основные принципы, которые помогают компании расти на 300% каждый год.


1. Делиться знаниями

Знания о пользователях, рынке, конкурентах должны распространяться по всей компании. В Miro есть Slack-канал Growth Insights, в котором команда делится подробными результатами экспериментов роста.


2. Поддерживать баланс между бизнес-результатом и ценностью для пользователей

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


3. Быть любопытными, изучать своих пользователей

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


4. Планы – ничто, планирование – всё

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


5. Видеть общую картину

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


6. Собирать базу знаний

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


7. Создавать синергию между командами

Команда роста активации запускает совместные эксперименты с командами привлечения, core-продукта, E-mail маркетинга. Результаты таких экспериментов могут давать синергетический эффект за счет более широкого разнообразия в опыте участников.


8. Отслеживать метрики и конкурентов

В Miro ключевые метрики отслеживаются регулярно с разной периодичностью. Монетизация ежемесячно на специальной встрече. Активация еженедельно в Metrics Journal в Confluence.

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


9. Работать быстро и веселиться

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

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


10. Расти самому быстрее, чем растет компания

Персональные OKR'ы на год и квартал для постановки больших целей и отслеживания прогресса. Общение с профессионалами из других компаний для более быстрого обучения. Регулярные личные встречи с руководителем и обратная связь от коллег для поиска точек профессионального роста. Выступления на конференциях и написание статей для структуриривания опыта.

Вика – блестящая. Посмотрите ее доклад и прочувствуйте настроение. Мало от кого еще можно услышать реальные практики работы в команде роста гиперрастущей компании.

Grow Horse
Управление проектами
Подписаться
Выводы по итогам полуторалетнего родео:


1. Фокус очень важен. Если вы хотите делать стартап и горите идеей, нужно уделить этому максимум своего времени и энергии.


2. Нельзя затягивать. Процесс проверки исходных гипотез должен проходить максимально интенсивно. Растянув его на месяцы и годы вы рискуете потерять интерес раньше, чем найдете подтверждение.


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

Я проверял свои гипотезы в параллели с основными задачами по консалтингу, сопровождению команд, обучению, что приводило к расфокусу и растягиванию сроков.

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

Но в итоге я даже рад, что перестал заниматься этим проектом. Если бы тогда я сделал прыжок веры, то мог стать заложником обязательств, которые бы меня тяготили.

А сейчас, используя полученный опыт, я делаю новый продукт, в который по-настоящему верю, и рассчитываю выпустить уже к июню.

Grow Horse
Управление проектами
Подписаться

Как я проверял гипотезу о сервисе для управления гипотезами (часть третья)

После исследования, которое мы провели с Сергеем и Иваном, энтузиазм немного поубавился. Процессы работы с гипотезами у разных команд сильно отличались, как и проблемы, с которыми они сталкивались.

Четкого видения, каким должно быть решение, не возникло, но мне все таки хотелось разобраться в вопросе тщательнее. К тому же, MVP на Airtable продолжали подключать все новые пользователи.

Апрель 2019

К апрелю базу (так в Airtable называется проект) подключили уже больше 700 человек.

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

Я вручную собрал все емейлы в таблицу, загрузил в Mailchimp и сделал рассылку с темой «Что улучшить в Growth Team фреймворке?».

В письме я попросил уделить 15-20 минут на созвон для сбора обратной связи и уточнил, что интересен любой опыт, даже если фреймворк по факту не использовался.

Откликнулось чуть больше двадцати человек, с большинством из которых мне удалось договориться на звонок.

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

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

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

Я ушел думать дальше.

Октябрь 2019

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

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

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

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

Не без сложностей, но к концу месяца бот был готов. Расходы мы разделили на троих с Сергеем и Иваном.

Сначала я раздал ссылку на бота директно командам, с которыми работал или много общался. Это позволило выявить основные замечания, пофиксить проблемные места, улучшить логику.

Затем распространил ссылку на бота по группам и стал наблюдать за статистикой.

В первый же день в бот добавилось более 100 проектов с общим количеством участников под 200 человек. Снова явный сигнал наличия спроса.

Но уже через неделю стало понятно, что никто не внедрил бота в рабочий процесс и не использует его на регулярной основе.

Как обычно, я пошел собирать обратную связь, созвонился с несколькими пользователями и выяснил, что причины быстрого отвала очень разнородные. Просили сделать бота для Slack, добавить экспорт бэклога в Jira, добавить другие фреймворки приоритизации и много всего другого.

К этому моменту энергии развивать решение уже не осталось, хотя и прослеживался потенциал.

Здесь в истории с проверкой гипотезы о сервисе для управления гипотезами можно поставить точку.

Grow Horse
Управление проектами
Подписаться

​​Как я проверял гипотезу о сервисе для управления гипотезами (часть вторая)

Спустя уже пару месяцев работы с командами роста проблема управления гипотезами вернулась снова.

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

Я сделал еще один поход к исследованию существующих решений, но остановился на том, что нужно делать свое.

Разрабатывать сервис с нуля было бы слишком долго и дорого, а коммерческий потенциал вызывал большие сомнения. Лучшим вариантом было сделать MVP на базе существующей платформы.

Декабрь 2018

К началу декабря мой фреймворк управления гипотезами, собранный на Airtable, был готов и протестирован в работе.

Я опубликовал посты в Facebook и в канале, в которых расписал возможности фреймворка и предложил подключить его бесплатно.

Интерес к решению предвосхитил ожидания. За первый месяц фреймворк подключили больше 500 человек. Забегая вперед скажу, что на текущий момент количество подключений перевалило за
1000.

Спрос на инструмент управления гипотезами подтверждался, но его фактическая ценность вызывала сомнения.

Март 2019

В конце февраля мы списались с Сергеем Тихомировым (канал @productclub) и договорились созвониться, обсудить тему проверки гипотез в командах.

В процессе разговора выяснилось, что Сергей вместе с Иваном Серебренниковым (канал @uxboost) тоже прорабатывают идею создания сервиса для управления гипотезами, что у них тоже возникала аналогичная моей проблема.

Мы решили объединить усилия. Два опытных продакта и мощный UX-дизайнер – хорошая заявка на успех.

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

Наша доска в Miro (скрин внизу) обросла огромным количеством артефактов, мы обладали четким видением и были во всеоружии, чтобы приступить непосредственно к общению с респондентами.

За две недели мы провели порядка 35 интервью с продаками из самых разных компаний, от небольших стартапов до крупнейших банков. Раскопали всю подноготную процесса проверки гипотез, вскрыли самые разные типы проблем.

Главный вывод, который мы сделали: проблем много, но ключевые из них – организационные. И решаются организационно, а не за счет софта.

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

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

Но у меня оставалась одна зацепка – пообщаться с теми, кто подключил мой фреймворк и выяснить, для каких задач его используют.

Про результаты этих интервью, MVP в виде чат-бота и итоговые выводы расскажу в следующем, заключительном посте.

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...