Личный опыт Yuri Drogan
8 517

Запуск Growth Team в Movavi

Как в Movavi перестали делать функции в продукте, начали тестировать пять гипотез роста в неделю и увеличили выручку на $27 тысяч в месяц.

В закладки
Аудио

Для этого в Movavi пришлось поменять мышление, собрать Growth Team (команду роста), полностью изменить процессы, пересмотреть инструменты. В статье все подробности этих изменений: от теории до реальной истории внедрения.

Действующие лица

Movavi. Уверен, вы о ней хоть раз, но слышали. Компания-разработчик программного обеспечения для работы с видео, аудио и фото, которое продаётся в более чем 150 странах мира. Сейчас в Movavi работают более 300 сотрудников.

Growth Academy — первая компания в России, которая системно обучает, внедряет процессы Growth Hacking и запускает Growth Team (команды роста). Среди клиентов: «Райффайзенбанк», ФРИИ, Freemake, Timeweb, CS-Cart.

Я, Юрий Дроган, генеральный директор Growth Academy, внедрял Growth Hacking процессы в Movavi, о чём вам и хочу рассказать в подробностях.

Цель изменений

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

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

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

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

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

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

Галина Окунева
Growth Master в Movavi

Итак, передо мной стояла задача запустить Growth Team и тестировать минимум пять гипотез в неделю. Для этого я сначала провёл двухдневный обучающий курс в компании на 20 человек, чтобы все в компании получили одно и то же понимание и терминологию Growth Hacking. Затем выделили небольшую команду, встречи которой я помогал провести.

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

Сначала поговорим о теории и инструментах процессов Growth Hacking, затем я расскажу, как проходили четыре встречи команды, где мы приземляли эту теорию.

Теория

1. Что такое Growth Team

Что за зверь такой Growth Team (она же команда роста)? Вот лучшее определение.

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

Джош Шварцапель
сооснователь и генеральный директор Indie Money

Первой в истории командой роста считается та, что была организована в Facebook. Её возглавлял Чамат Палихапития. Именно его команда привела первые 500 млн пользователей в соцсеть. Был разработан простой фреймворк: привлечение — активация, вовлечение и виральность. Именно он обеспечивал прозрачность и логичность процессов и позволял легко и правильно приоритизировать внедрение гипотез, проводить эксперименты и создавать продукты.

Итак, Growth Team должна заниматься лишь одним делом — тестировать гипотезы роста. Она представляет собой кросс-функциональную группу людей для совместной работы сотрудников. Компетенции этих профессионалов лежат в областях аналитики, проектирования, управления продуктами и маркетинга.

2. Какие процессы мы использовали

Чтобы настроить непрерывный процесс тестирования гипотез в Growth Academy, разработан фреймворк — Growth Scrum. Он чётко детализирован, в отличии от HADI- и PDCA-циклов.

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

Growth Scrum

Growth Scrum предполагает тестирование гипотез в рамках одно- или двухнедельного спринта.

Growth Meeting

Ключевым событием в Growth Scrum является Growth Meeting, который проводится в одно и то же время в начале спринта и длится не более двух часов.

Growth Meeting обладает чёткой структурой:

  • обзор спринта;
  • ретроспектива спринта;
  • обсуждение гипотез;
  • приоритизация гипотез.

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

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

Эта часть обычно длится не более 30 минут.

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

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

Третий этап Growth Meeting — обсуждение идей из бэклога и превращения их в гипотезы. Здесь особенно важна работа Growth Master. Он следит за правильным формулированием гипотез с указанием ожидаемого эффекта, чтобы команда не сваливалась в бесконечное обсуждение гипотез. Важно отсекать гипотезы, если они не могут быть быстро «проданы» команде.

Приоритизация гипотез — это последний этап Growth Meeting. Он крайне важен, так как ценность и время исполнения у гипотез разная. Их приоритизация может осуществляться например по шаблону ICE Score.

Daily Meeting

Daily Meeting — это ежедневная встреча. Она нужна, чтобы команда не тестировала гипотезы в пятницу вечером и экспериментирование поддерживалось в течении недели. Daily Meeting проводится в одно и то же время, в течение 10–15 минут, как в скраме.

3. Какую доску взять

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

Чтобы поддерживать процесс и сохранять его подконтрольность, нужна доска с правильными этапами, где каждая гипотеза проходит путь от идеи до инсайта. Рекомендую доску, которую используют в 500 Startups, со следующими столбцами:

  • идеи;
  • приоритизация;
  • исполнение (или в работе);
  • измерение;
  • успех;
  • неуспех.

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

Growth Hacking Board Template

Вы можете скопировать её по этой ссылке: Growth Hacking Board Template.

Подробнее опишу каждый этап:

  • Идеи. Все идеи, которые появились во время Daily Meeting или в течение недели, записывайте в первый столбик в сыром виде — так, как они пришли в голову. Уже на еженедельном Growth Meeting на этапе обсуждения гипотез карточка с гипотезой переносится на следующий этап приоритизации.
  • Приоритизация. Во время Growth Meeting необходимо приоритизировать перешедшие на этот этап гипотезы, например, по методологии ICE Score. Переместите карточки «победивших» гипотез на следующий этап.
  • Исполнение (в работу). На этом этапе назначаются исполнители и ответственные за внедрение гипотез, комментируется прогресс реализации.
  • Измерение. Когда гипотеза запущена, карточка перемещается на этап измерений, пока данные по гипотезе не будут запущены. Тут гипотеза может находиться от нескольких дней или недель (если это гипотеза дохода, например). Когда данные собраны, обязательно поместите скриншот с результатами эксперимента из системы аналитики в карточку гипотезы.
  • Успех ил неуспех. Данные собраны? Ожидаемый эффект достигнут? Да? Помещаем карточку с гипотезой в «Успех». Нет — в «Неуспех». Так формируется база для будущих инсайтов и новых гипотез, которые приведут к кратному росту. Укажите результат эксперимента, суммировав ответы участников команды роста на вопрос: «Что стало понятно, что раньше было неочевидно?».

Практика

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

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

В Movavi Growth Team состояла из четырёх участников.

Growth Master: отвечает за процессы команды роста. Организовывает и ведёт события (Growth Meeting, Daily Meeting и так далее), сортировку гипотез, следит за правильной формулировкой гипотез, фасилитирует команду, актуализирует Experiment Board.

Product Owner: специализируется на генерации гипотез активации, дохода, ценности, метрике «полярной звезды», занимается проблемами онбординга и идентификацией aha-момента. Переносит гипотезу в бэклог разработки, отслеживает исполнение.

Growth-маркетолог: специализируется на гипотезах информирования (привлекает трафик и тестирует различные заголовки и каналы), гипотезах ценности, гипотезах привлечения (скачивание и установка).

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

И я, временный Growth Master, который должен настроить процессы и передать их Growth Master команды.

Первый Growth Meeting

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

  • Мало гипотез содержали ожидаемый эффект от внедрения. Например, «Поменяем шаг в онбординге» или «Сделать A/B-тест заголовка на сайте», однако какой ожидаемый эффект это принесёт, было очевидно далеко не всем. А если команда не понимает эффекта, то как ей голосовать за неё?

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

  • Как только представили ожидаемый эффект в показателях, у команды появились вопросы, на чём основан этот оптимизм. Автор гипотезы судорожно лез в аналитику, искал сколько отваливалось на этом этапе, сколько их всего — и так далее. Даже если он уже делал исследование, тяжело было рассказать это команде по памяти. Это крало много времени у всей команды, начинались споры, переписывались старые гипотезы, возникали новые, команда уставала, но так и не приближалась к запуску спринта.

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

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

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

  • Многие из них оказались ничейными. Команда когда-то придумала её в споре, записала, но что именно имелось в виду, каждый понимает по-своему.

Решение: каждая гипотеза должна иметь автора, и он ответственен за правильную формулировку, что для неё создан скетч, прикреплены аналитические данные. Именно автор пытается продать гипотезу команде на Growth Meeting.

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

Итак, хорошая гипотеза отвечает на все четыре вопроса:

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

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

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

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

  • Участники команды роста всегда приходят на Growth Meeting с уже правильно сформулированными, подготовленными гипотезами.
  • Каждая гипотеза является результатом индивидуальной работы, а не порождением коллективного разума. Каждая гипотеза принадлежит определённому сотруднику. Именно в индивидуальной работе над гипотезами заключается главный секрет успеха любой команды роста.
  • Команда роста ни в коем случае не занимается коллективной генерацией гипотез во время Growth Meeting.
  • Автор гипотезы должен прикрепить подкрепляющую успех гипотезы аналитику и предоставить скетч, на котором будет наглядно продемонстрировано возможное изменение в продукте. Хотите добавить кнопку? Нарисуйте, чтобы всем было понятно, как это будет выглядеть, и не тратьте время на объяснения на пальцах.

Когда соблюдаются эти принципы, обсуждение гипотез не занимает много времени. Требуется максимум полчаса из двух отведённых на весь Growth Meeting.

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

Второй Growth Meeting

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

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

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

После обсуждения гипотез у нас осталось предостаточно времени на их приоритизацию. Команда голосовала за каждую по методологии ICE Score.

ICE Score предполагает оценку каждой из гипотез с использованием трёх коэффициентов:

  • Impact — влияние на метрику;
  • Confidence — степень уверенности оценивающего в успехе (обычно эта уверенность базируется на результатах уже проведённых похожих экспериментов);
  • Ease — лёгкость внедрения.

По каждому из критериев проставляется оценка от одного до десяти. Затем результаты по каждой гипотезе перемножаются в следующем порядке: Impact x Confidence x Easy = ICE Score.

После приоритизации шесть гипотез удалось запустить в работу. Гипотезы, которые обсуждали на втором Growth Meeting, распределились следующим образом:

  • три гипотезы активации пользователя;
  • две гипотезы информирования;
  • одна гипотеза привлечения на сайт (A/B-тест).

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

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

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

Качество гипотез — это качество топлива, на котором едет вся Growth Team.

Третий Growth Meeting

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

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

С одной стороны, увеличилось количество целевых действий пользователя — добавление видео. С другой — произведённое изменение отрицательно сказалось на доходе (revenue). А ведь раньше наблюдалась прямая зависимость: чем больше добавляют видео, тем больше платят.

Таким образом, мы сделали вывод, что между целевой метрикой и выручкой у нас есть «чёрный ящик», который надо открыть — найти все промежуточные метрики.

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

Обзор спринта прошёл быстро и плодотворно, поскольку аналитик заранее прикрепил скриншоты из аналитики с изменениями в метриках к каждой карточке с гипотезой. Так понять, чем закончился эксперимент и в какой из списков перенести карточку — в «Успех» или «Неуспех», — не составляло труда.

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

  1. Что стало понятно, что раньше было неочевидно? (После этого Growth Master заносил сумму ответов в карточку гипотезы.)
  2. Исходя из этого инсайда, какой шаг должен быть следующим? (Ответ на этот вопрос заносился в бэклог — список идей в Growth Hacking Board.)

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

Четвёртый Growth Meeting

На четвёртой встрече нам осталось добавить последний блок в наш Growth Meeting, чтобы завершить создание машины по перемалыванию гипотез. Этим блоком была «ретроспектива спринта», которая шла сразу после обзора гипотез.

Growth Master задавал участникам команды следующие вопросы:

  • Что шло хорошо в этом спринте?

  • Какие улучшения заметили по сравнению с предыдущим спринтом?

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

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

Итоги

Мы очень довольны тем, как быстро и с каким результатом был запущена Growth Team. Нужная скорость запуска достигнута — мы научились тестировать пять гипотез в неделю, а показатель успешных гипотез в 60% очень радует, хотя мы понимаем, что со временем он будет снижаться.

Также радует, что по предварительным оценкам, внедрение успешных проверенных гипотез за этот период принесёт около $27 тысяч в месяц.

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

Галина Окунева
Growth Master в Movavi

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

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Yuri Drogan", "author_type": "self", "tags": [], "comments": 19, "likes": 39, "favorites": 128, "is_advertisement": false, "subsite_label": "life", "id": 57146, "is_wide": false, "is_ugc": true, "date": "Thu, 31 Jan 2019 09:58:28 +0300" }
{ "id": 57146, "author_id": 42987, "diff_limit": 1000, "urls": {"diff":"\/comments\/57146\/get","add":"\/comments\/57146\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/57146"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123 }

19 комментариев 19 комм.

Популярные

По порядку

Написать комментарий...
6

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

Из статьи сложилось впечатление, что "модель бизнеса" - это "ванна". С одной стороны в нее втекает вода (поток лидов), с другой - вытекает (отваливают, перестают пользоваться).
И вся работа была по факту была сосредоточена вокруг улучшения онбординга, чтобы повысить эффективность траты средств на привлечение. Это всё тоже достаточно "понятные вещи".

Гораздо интереснее вопрос поиска и создания ценности. Тут уж экспериментами с "цветом кнопки" не обойтись.
Если у вас был такой опыт и есть возможность озвучить детали - было бы интересно почитать.

Ответить
7

Статья только про процессы. Гипотезы были крутые, точно не про цвет кнопки, но статья не о том. В следующих статьях буду писать про поиск ценностей, это конечно отдельный мир в Growth Hacking. Не переключайтесь))

Ответить
5

Один из единственных бодрых материалов на тему продакт-менеджмента с начала 2019 года

Ответить
0

а какие вам запомнились в 2018?

Ответить
0

Замечательная статья! Похожий кейс построения Growth Team, но по другой методике мы обсуждали с Денисом Мартынцевом в эфире "Нормально делай, нормально будет".

Взяла в канал @normalno_delaj https://tgclick.ru/normalno_delaj/64

Ответить
1

Крутой канал! Но статья там так и не появилась)

Ответить
1

Спасибо) Скоро будет:))

Ответить
5

Спасибо за материал, интересно, но было бы хорошо увидеть больше примеров гипотез.

Ответить
3

$ 27 000 в месяц для компании в 300 людей? Он вообще это заметили?)

Ответить
1

Меня удивило наличие 300 человек :)

Ответить
0

Ну а как иначе? Там же не глупые люди работают. Ни разу не видел, чтобы в стабильном бизнесе сделали какую-то штуку и "бабах..+50% выручки". Мал-по-малу накапает.

Ответить
1

Юрий, а как вы сохраняете и систематизирует знания, полученные в ходе тестов?

В статья пишете, что из каждой гипотезы делаются все выводы и сохраняются в одной из двух колонок. Но я и будет через год работы (больше 1500 карточек)? А как вводить в курс новых людей?

Нет ли каких-то решений для систематизации этих знаний?

Ответить
1

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

Ответить
1

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

Ответить
1

Главное - умножать именно в этом порядке!
" Затем результаты по каждой гипотезе перемножаются в следующем порядке: Impact x Confidence x Easy = ICE Score."

Ответить
0

HADI вообще то в двух строках можно было описать.

Ответить
0

Спасибо за статью!

Юрий, скажите, а что случилось с hopox? Оказалось, что специализированный инструмент для работы с гипотезами по HADI циклам не нужен, и обычных канбан досок хватает?

P.S. В статье опечатка:
Impact x Confidence x Confidence = ICE Score

Ответить
0

Спасибо

Ответить
0

Может быть глупый вопрос, но вот как-то не понятно осталось. Параллельно с Growth Team в Movavi работали еще основные команды продукта, которые пилили больший блоки направленные на расширение функциональности продукта? или это Growth Team просто пределанная команда разработки?

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления
{ "page_type": "default" }