Grow Horse

2021-06-02 12:54:43 Репутация
Оптимально найти представителей заказчиков, кто уже работал с этим подрядчиком, связаться с ними и расспросить про опыт взаимодействия. Понятно, что сделать это не всегда реально, но по возможности стоит.

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

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

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

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

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

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

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

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

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

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

2021-06-02 12:54:27 Как найти и выбрать разработчиков на проект

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2021-05-11 12:38:10 Чеклист по проверке гипотезы о новом продукте платным трафиком

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2021-04-28 12:19:24 Принципы команды роста 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'ы на год и квартал для постановки больших целей и отслеживания прогресса. Общение с профессионалами из других компаний для более быстрого обучения. Регулярные личные встречи с руководителем и обратная связь от коллег для поиска точек профессионального роста. Выступления на конференциях и написание статей для структуриривания опыта.

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

2021-04-22 12:31:39 Выводы по итогам полуторалетнего родео:

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

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

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

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

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

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

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

2021-04-22 12:31:31 Как я проверял гипотезу о сервисе для управления гипотезами (часть третья)

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

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

Апрель 2019

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

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

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

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

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

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

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

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

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

Октябрь 2019

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

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

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

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

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

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

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

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

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

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

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

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

2021-04-19 11:51:04 ​​Как я проверял гипотезу о сервисе для управления гипотезами (часть вторая)

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

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

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

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

Декабрь 2018

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

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

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

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

Март 2019

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

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

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

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

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

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

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

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

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

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

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

2021-04-16 10:55:57 Как я проверял гипотезу о сервисе для управления гипотезами

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

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

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

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

Удобно настроить систему в Jira или Trello не получилось, в итоге все собиралось в большой Google-таблице с кучей строк и столбцов.

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

Но проблема ведь есть! Как минимум, у моей команды.

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

Май 2018

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

Затем, пошел к коллегам продактам, чтобы проверить, существует ли проблема у кого-то еще.

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

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

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

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

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

С этого момента появился данный канал, следом консалтинг и курс по Growth-менеджменту.

Дальше было два MVP и еще один, более масштабный, подход к интервью. Об этом расскажу в следующих постах. Открыть/Комментировать

2021-04-13 17:33:35 Курс по виральности стартует завтра

Восемь часов занятий и пять домашек в комфортном ритме за две неделю. Всё онлайн. Можно смотреть в записи. Можно взять участие с консультацией.

Кому и зачем:

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

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

Планировать рост никогда не рано. Но иногда поздно.

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

Бронь мест здесь: https://bit.ly/viral7lastcall Открыть/Комментировать

2021-04-08 09:14:10 Всё про виральность: седьмой поток

На следующей неделе стартует седьмой поток моего курса по виральности.

В программе:

— Знакомство со стратегией Product-Led Growth. Как модель монетизации влияет на виральность.
— Разница между виральностью продукта, вирусным маркетингом и сарафанным радио: примеры, цифры, графики.
— Виральные механики для SAAS, mobile, e-commerce, media, e-learning (семь типов виральности с примерами).
— Проектирование Viral Loop (этапы и метрики).
— Формула измерения коэффициента виральности (K-factor).
— Гипотезы, технические и аналитические инструменты, расчет ROI.

Объем: 4 вебинара, 8 часов занятий, 5 домашек, 50+ реальных примеров, 400+ слайдов презентации.

Все это за две недели с 14 по 24 апреля. Онлайн или в записи.

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

Подробности и регистрация: https://bit.ly/allviral7 Открыть/Комментировать