Forwarded from 100x | Денис Мартынцев
Как выбрать модель монетизации для SaaS-продукта
Результат бизнеса во многом зависит от правильного выбора модели монетизации. Важно уметь разбираться в моделях, понимать их отличия и особенности.
Первое, что влияет на выбор модели — стратегия роста. Для SaaS можно выделить две принципиально разные стратегии: Sales-Led и Product-Led.
Если вы придерживаетесь первой стратегии, то монетизация будет строиться на прямых продажах. В рамках этой модели менеджеры по продажам в личном общении выявляют задачи клиентов, которые может решить продукт, проводят демо функционала, обучают использованию.
Для Sales-Led компетенции в продажах — важнейший актив бизнеса. Модель характерна прежде всего для энтерпрайз продуктов с большим чеком.
Если вы выбрали стратегию Product-Led, то задачи по монетизации ложатся на сам продукт. Здесь есть разные модели.
Фримиум
Базовая часть функционала доступна пользователям бесплатно без ограничений по времени, но иногда с ограничением по объему. Когда пользователь достигает лимита или хочет воспользоваться функциями, не входящими в бесплатную версию, ему предлагают перейти на платный аккаунт.
Примеры: Miro, Slack, SurveyMonkey, Dropbox.
Когда применять:
1. На рынке много конкурентов или продуктов-заменителей.
2. Пользователи быстро получают ценность от базовых функций.
Триал
Пользоваться продуктом бесплатно можно ограниченное время, по истечению которого необходимо заплатить, оформить подписку.
Примеры: Netflix, Spotify, Photoshop, Salesforce.
Когда применять:
1. Продукт доминирует на рынке или не имеет аналогов.
2. Ценность от использования проявляется не сразу.
3. Пользователи сильно заинтересованы в продукте.
Смешанные
Существуют также смешанные модели, в которых одновременно используются элементы фримиума и триала.
Например, когда базовый функционал доступен бесплатно, а полный по подписке, предполагающей триальный период.
Или наоборот. Если пользователь не сконвертировался в платящего после триального периода, ему оставляют базовый набор функций в бессрочный доступ.
Product-Led стратегия не исключает наличие команды продаж и прямого общения с потенциальными клиентами. Но в с основном это касается только самых дорогих тарифов.
Определиться с выбором модели монетизации поможет MOAT-фреймворк, описанный в книге Product-Led Growth.
Делюсь локализованным шаблоном фреймворка, который вы можете использовать для выбора или проверки модели cвоего продукта.
Пройдтесь по каждой ячейке и отметьте, какие утверждения наиболее справедливы. Подсказка внизу поможет выбрать подходящую модель, исходя из отмеченных ячеек.
Важно понимать, что MOAT-фреймворк не является руководством к действию. Это бизнес-инструмент, который помогает принять более логичное решение, но ответственность за принятое решение остается на вас.
Если сделаете, напишите в комментариях, что получилось, и насколько вы доверяете подсказке фреймворка.
Результат бизнеса во многом зависит от правильного выбора модели монетизации. Важно уметь разбираться в моделях, понимать их отличия и особенности.
Первое, что влияет на выбор модели — стратегия роста. Для SaaS можно выделить две принципиально разные стратегии: Sales-Led и Product-Led.
Если вы придерживаетесь первой стратегии, то монетизация будет строиться на прямых продажах. В рамках этой модели менеджеры по продажам в личном общении выявляют задачи клиентов, которые может решить продукт, проводят демо функционала, обучают использованию.
Для Sales-Led компетенции в продажах — важнейший актив бизнеса. Модель характерна прежде всего для энтерпрайз продуктов с большим чеком.
Если вы выбрали стратегию Product-Led, то задачи по монетизации ложатся на сам продукт. Здесь есть разные модели.
Фримиум
Базовая часть функционала доступна пользователям бесплатно без ограничений по времени, но иногда с ограничением по объему. Когда пользователь достигает лимита или хочет воспользоваться функциями, не входящими в бесплатную версию, ему предлагают перейти на платный аккаунт.
Примеры: Miro, Slack, SurveyMonkey, Dropbox.
Когда применять:
1. На рынке много конкурентов или продуктов-заменителей.
2. Пользователи быстро получают ценность от базовых функций.
Триал
Пользоваться продуктом бесплатно можно ограниченное время, по истечению которого необходимо заплатить, оформить подписку.
Примеры: Netflix, Spotify, Photoshop, Salesforce.
Когда применять:
1. Продукт доминирует на рынке или не имеет аналогов.
2. Ценность от использования проявляется не сразу.
3. Пользователи сильно заинтересованы в продукте.
Смешанные
Существуют также смешанные модели, в которых одновременно используются элементы фримиума и триала.
Например, когда базовый функционал доступен бесплатно, а полный по подписке, предполагающей триальный период.
Или наоборот. Если пользователь не сконвертировался в платящего после триального периода, ему оставляют базовый набор функций в бессрочный доступ.
Product-Led стратегия не исключает наличие команды продаж и прямого общения с потенциальными клиентами. Но в с основном это касается только самых дорогих тарифов.
Определиться с выбором модели монетизации поможет MOAT-фреймворк, описанный в книге Product-Led Growth.
Делюсь локализованным шаблоном фреймворка, который вы можете использовать для выбора или проверки модели cвоего продукта.
Пройдтесь по каждой ячейке и отметьте, какие утверждения наиболее справедливы. Подсказка внизу поможет выбрать подходящую модель, исходя из отмеченных ячеек.
Важно понимать, что MOAT-фреймворк не является руководством к действию. Это бизнес-инструмент, который помогает принять более логичное решение, но ответственность за принятое решение остается на вас.
Если сделаете, напишите в комментариях, что получилось, и насколько вы доверяете подсказке фреймворка.
Google Docs
1. MOAT Framework
Payment Architecture https://youtu.be/1nz6muMNXF4
YouTube
How Spotify Payments Creates APIs to Manage Complexity
This is a session given by Horia Jurcut at Nordic APIs 2016 Platform Summit on October 25th, in Stockholm Sweden. This video also inspired a companion blog piece. Read "The Brilliance of Spotify Internal APIs to Mitigate Payments" for more: http://nordicapis.com/the…
Как Uber тестирует продуктовые гипотезы и проводит эксперименты https://eng.uber.com/xp/
Forwarded from Борода продакта
Небольшой пост о продуктовых образовательных играх. В декабре 2018 года я провел первый прогон стратегической бизнес-игры Game of PAF, целью которой является в форме симуляции рыночной ситуации показать ключевые концепции Product Architecture Framework, над которым я работаю больше шести лет. На текущий момент проведено более 30 таких мероприятий, которые посетили более 500 участников в России и Беларуси. А восторженные отзывы о ней можно найти по тегам #gameofpaf в Facebook и Instagram. Но я хотел бы познакомить вас еще с двумя такими играми.
Во-первых, это игра для руководителей и предпринимателей "Поймай волну" об управлении продуктами от Дмитрия Безуглого и Николая Фатеева (кстати, она будет проходить уже в эту субботу 11 декабря), которую коллеги разработали уже очень давно, но не сильно продвигали.
Во-вторых, это игры от Дениса Ялугина NotBad Company и UnitCraft (кстати, она будет проходить в следующую субботу 18 декабря). В которых фокус внимания нацелен на метрики продукта и экономику.
Вообще, всем, кто ищет новые интересные форматы обучения для себя или компании - обратите на них внимание. Это отличный способ получить эмоции, полезные знакомства, новые знания и рабочие инсайты (сужу непосредственно по фидбеку от участников игры Game of PAF). И это просто прекрасно.
"Лови волну" от Дмитрия Безуглого https://master-strategy.ru/catch-the-wave
NotBad Company от Дениса Ялугина https://notbadcompany.ru/
UnitCraft от Дениса Ялугина https://unitcraft.ru/
Game of PAF от Сергея Тихомирова https://productframework.ru/gameofpaf
P.S. Ах да! А еще я перенес на сайт фреймворка статью о том, как создавалась Game Of PAF, поэтому всем, кому будет интересно, добро пожаловать https://productframework.ru/articles/gameofpaf_history
P.P.S. Наверняка есть еще мероприятия в формате игр, о которых я не знаю. Если что - пишите, добавлю их в этот пост.
Во-первых, это игра для руководителей и предпринимателей "Поймай волну" об управлении продуктами от Дмитрия Безуглого и Николая Фатеева (кстати, она будет проходить уже в эту субботу 11 декабря), которую коллеги разработали уже очень давно, но не сильно продвигали.
Во-вторых, это игры от Дениса Ялугина NotBad Company и UnitCraft (кстати, она будет проходить в следующую субботу 18 декабря). В которых фокус внимания нацелен на метрики продукта и экономику.
Вообще, всем, кто ищет новые интересные форматы обучения для себя или компании - обратите на них внимание. Это отличный способ получить эмоции, полезные знакомства, новые знания и рабочие инсайты (сужу непосредственно по фидбеку от участников игры Game of PAF). И это просто прекрасно.
"Лови волну" от Дмитрия Безуглого https://master-strategy.ru/catch-the-wave
NotBad Company от Дениса Ялугина https://notbadcompany.ru/
UnitCraft от Дениса Ялугина https://unitcraft.ru/
Game of PAF от Сергея Тихомирова https://productframework.ru/gameofpaf
P.S. Ах да! А еще я перенес на сайт фреймворка статью о том, как создавалась Game Of PAF, поэтому всем, кому будет интересно, добро пожаловать https://productframework.ru/articles/gameofpaf_history
P.P.S. Наверняка есть еще мероприятия в формате игр, о которых я не знаю. Если что - пишите, добавлю их в этот пост.
master-strategy.ru
"Поймай волну!"-игра для руководителей
Поймай волну — бизнес-игра, основанная на реалистичных рыночных механиках и развивающая стратегическое мышление
Forwarded from Продакты не нужны
Что почитать
В какой-то момент Твиттер стал главным местом, где предприниматели, продакты и маркетологи выкладывают бриллиантовый контент. Они что-то поменяли в алгоритмах рекомендаций и полезные треды начали получать релевантный виральный охват. Если раньше я был ограничен там своим информационным пузырем, на 2/3 мертвым, то Твиттер мастерски вырвал меня из него и хочу поделиться с вами крутыми твитами.
Как продавать: https://twitter.com/wdmorrisjr/status/1480186297180319744
Как писать «холодные письма» https://twitter.com/SahilBloom/status/1452375554825486336
Как стать миллионером, если ты не ведешь телеграм канал про продакт менеджмент: https://twitter.com/GuillaumeMbh/status/1485188805867020288
Тред про опционы: https://twitter.com/susanfsu/status/1481332788859064322
Как лучше писать: https://twitter.com/Nicolascole77/status/1480604377073213445
Тред тредов (ха): https://twitter.com/heyeaslo/status/1483620687864422400
И напоследок навигатор по лучшим тредам по темам: https://twittrgems.careerleap.io/
В какой-то момент Твиттер стал главным местом, где предприниматели, продакты и маркетологи выкладывают бриллиантовый контент. Они что-то поменяли в алгоритмах рекомендаций и полезные треды начали получать релевантный виральный охват. Если раньше я был ограничен там своим информационным пузырем, на 2/3 мертвым, то Твиттер мастерски вырвал меня из него и хочу поделиться с вами крутыми твитами.
Как продавать: https://twitter.com/wdmorrisjr/status/1480186297180319744
Как писать «холодные письма» https://twitter.com/SahilBloom/status/1452375554825486336
Как стать миллионером, если ты не ведешь телеграм канал про продакт менеджмент: https://twitter.com/GuillaumeMbh/status/1485188805867020288
Тред про опционы: https://twitter.com/susanfsu/status/1481332788859064322
Как лучше писать: https://twitter.com/Nicolascole77/status/1480604377073213445
Тред тредов (ха): https://twitter.com/heyeaslo/status/1483620687864422400
И напоследок навигатор по лучшим тредам по темам: https://twittrgems.careerleap.io/
Forwarded from 100x | Денис Мартынцев
Как стартапу привлекать пользователей и расти
Нашел в закладках видео YC от 2018 года, в котором первый Growth Manager Airbnb рассказал о своем опыте работы и подходах, которые применял на ранних этапах роста.
Его команда изначально состояла из трех человек, но спустя несколько лет в ней работали десятки специалистов.
Законспектировал некоторые мысли. До сих пор актуально.
Про стартапы
1. Стартап — это постоянный рост. В стартапе, как нигде, нужна команда, которая будет заниматься поиском новых точек роста.
2. Не нужно строить команду роста, если стартап не прошел Product/Market Fit. Вы можете попасть в ловушку. Быстро расти на старте, но также быстро рухнуть в будущем.
3. Убедитесь, что продукт готов расти и для него есть достаточно масштабный рынок.
4. Определить наличие Product/Market Fit можно, исследуя процент удержания пользователей на длинном интервале.
5. Удержание — важнейшая метрика, которая определяет перспективы стартапа.
Про команду
1. Команды продукта и маркетинга должны работать над общими задачами и единой общей метрикой — North Star Metric.
2. Команды роста включают в себя программистов, аналитиков, дизайнеров, продакт-менеджеров, исследователей.
3. Если у вас небольшой стартап и вы не можете позволить себе выделенную команду, постарайтесь вовлечь в работу над ростом всех, кто занимается продуктом.
4. Приоритет команды должен отдаваться идеям, которые могут принести существенный результат и не требуют больших усилий для проверки.
Про воронку
Рассматривайте ваш продукт, как воронку из множества этапов. Кратно повысить конверсию на этапах воронки можно следующими способами:
1. Переводом продукта на другие языки.
2. Усовершенствованием авторизации и регистрации.
3. Усовершенствованием онбординга.
4. Усовершенствованием процесса оплаты.
Про драйверы роста
Главные драйверы роста продукта определяются поведением пользователей:
1. Если пользователям нужно ваше решение редко — поисковая оптимизация.
2. Если продукт используется для взаимодействия с другими людьми — реферальные программы.
3. Если ценность продукта повышается с ростом количества пользователей — виральность.
4. Если вы заранее знаете, кому нужен ваш продукт — прямые продажи.
5. Если у продукта высокой LTV — платное привлечение.
Про эксперименты
1. Эксперименты — самое важное в работе команды роста.
2. Если вы принимаете решения интуитивно, вы отдаете свой успех на волю случая.
3. Эксперименты и тесты должны предшествовать любому масштабированию.
4. Проверить результативность решения в продукте можно при помощи А/Б теста. Это поможет определить, действительно на результат повлияло ваше решение или это был один из многочисленных сторонних факторов.
5. Вы должны иметь отлаженные процессы по экспериментированию и организации А/Б тестов, чтобы добиваться успеха.
6. Проводите переоценку ваших экспериментов с командой роста каждые две-три недели. Это позволит настроить команду на более точное формулирование новых гипотез.
7. Лучше начать делать А/Б тесты рано, даже когда у вас мало трафика. Чем начать делать поздно, когда вы уже ничего не можете изменить.
Новых мыслей тут, конечно, нет. За прошедшие три года про все это говорили миллион раз. Я сам, в частности.
Но повторить и освежить в памяти идеи, ставшие постулатами, будет не лишним.
Нашел в закладках видео YC от 2018 года, в котором первый Growth Manager Airbnb рассказал о своем опыте работы и подходах, которые применял на ранних этапах роста.
Его команда изначально состояла из трех человек, но спустя несколько лет в ней работали десятки специалистов.
Законспектировал некоторые мысли. До сих пор актуально.
Про стартапы
1. Стартап — это постоянный рост. В стартапе, как нигде, нужна команда, которая будет заниматься поиском новых точек роста.
2. Не нужно строить команду роста, если стартап не прошел Product/Market Fit. Вы можете попасть в ловушку. Быстро расти на старте, но также быстро рухнуть в будущем.
3. Убедитесь, что продукт готов расти и для него есть достаточно масштабный рынок.
4. Определить наличие Product/Market Fit можно, исследуя процент удержания пользователей на длинном интервале.
5. Удержание — важнейшая метрика, которая определяет перспективы стартапа.
Про команду
1. Команды продукта и маркетинга должны работать над общими задачами и единой общей метрикой — North Star Metric.
2. Команды роста включают в себя программистов, аналитиков, дизайнеров, продакт-менеджеров, исследователей.
3. Если у вас небольшой стартап и вы не можете позволить себе выделенную команду, постарайтесь вовлечь в работу над ростом всех, кто занимается продуктом.
4. Приоритет команды должен отдаваться идеям, которые могут принести существенный результат и не требуют больших усилий для проверки.
Про воронку
Рассматривайте ваш продукт, как воронку из множества этапов. Кратно повысить конверсию на этапах воронки можно следующими способами:
1. Переводом продукта на другие языки.
2. Усовершенствованием авторизации и регистрации.
3. Усовершенствованием онбординга.
4. Усовершенствованием процесса оплаты.
Про драйверы роста
Главные драйверы роста продукта определяются поведением пользователей:
1. Если пользователям нужно ваше решение редко — поисковая оптимизация.
2. Если продукт используется для взаимодействия с другими людьми — реферальные программы.
3. Если ценность продукта повышается с ростом количества пользователей — виральность.
4. Если вы заранее знаете, кому нужен ваш продукт — прямые продажи.
5. Если у продукта высокой LTV — платное привлечение.
Про эксперименты
1. Эксперименты — самое важное в работе команды роста.
2. Если вы принимаете решения интуитивно, вы отдаете свой успех на волю случая.
3. Эксперименты и тесты должны предшествовать любому масштабированию.
4. Проверить результативность решения в продукте можно при помощи А/Б теста. Это поможет определить, действительно на результат повлияло ваше решение или это был один из многочисленных сторонних факторов.
5. Вы должны иметь отлаженные процессы по экспериментированию и организации А/Б тестов, чтобы добиваться успеха.
6. Проводите переоценку ваших экспериментов с командой роста каждые две-три недели. Это позволит настроить команду на более точное формулирование новых гипотез.
7. Лучше начать делать А/Б тесты рано, даже когда у вас мало трафика. Чем начать делать поздно, когда вы уже ничего не можете изменить.
Новых мыслей тут, конечно, нет. За прошедшие три года про все это говорили миллион раз. Я сам, в частности.
Но повторить и освежить в памяти идеи, ставшие постулатами, будет не лишним.
YouTube
Gustaf Alstromer - How to Get Users and Grow
YC Partner Gustaf Alströmer, who was most recently a growth expert at Airbnb describes strategies for scaling your user base. Startup School is YC's free online program for founders. Sign up to access the full curriculum and over $100k in deals! https://…
Forwarded from 100x | Денис Мартынцев
Виды стратегий роста
В предыдущем посте мы определились, что стратегия роста нужна в любое время. Кризисы – не исключение.
С помощью стратегии вы:
— Выделяете ключевые метрики измерения результата;
— Расставляете приоритеты в распределении ресурсов, найме, бюджетировании;
— Выдвигаете инициативы по развитию продукта и привлечению пользователей;
— Согласуете и приоритизируете гипотезы роста.
Без стратегии все вышеперечисленные задачи превращаются в хаос. Даже в небольшом стартапе никто толком не будет понимать, что делать. Компания либо утонет в бесконечных обсуждениях, либо зациклит принятие решений на одном человеке.
Наличие стратегии помогает фокусироваться на наиболее важных задачах, согласовывать действия между командами, двигаться сообща в одном направлении.
Для технологического бизнеса можно выделить четыре стратегии роста:
1. Product-Led Growth
Рост за счет продукта.
Драйверы: виральность, контент, поисковая оптимизация.
Характерна для продуктов с большим виральным потенциалом: социальные сети, мессенджеры, продукты для совместного использования. Незначительные издержки на одного пользователя делают возможным использование фримиум модели монетизации.
2. Marketing-Led Growth
Рост за счет платного привлечения.
Драйверы: наличие масштабируемых каналов, позитивная юнит-экономика.
Характерна для продуктов с хорошей монетизацией и высокими операционными издержками: доставка, такси, e-commerce, обучение. Пользователи начинают платить на раннем этапе использования продукта, что позволяет быстро сводить юнит-экономику или с достаточной точностью прогнозировать LTV.
3. Sales-Led Growth
Рост за счет прямых продаж.
Драйверы: отработанная механика продажи, узнаваемость бренда.
Характерна для продуктов, ориентированных на enterprise клиентов. Или продуктов с большим чеком. Стоимость одной сделки покрывает издержки длительного цикла продажи, позволяет выплачивать высокие проценты продавцам и партнерам.
4. Diversification
4.1. Рост за счет выхода на новые рынки.
Драйверы: воспроизводимая бизнес-модель.
Характерна для продуктов, оцифровывающих аналоговые решения на больших рынках. За счет преобладающей цифровой составляющей имеют умеренную стоимость локализации.
4.2. Рост за счет запуска новых продуктов.
Драйверы: незакрытые текущим продуктом потребности клиентов.
Характерна для продуктов, исчерпавших потенциал роста из-за высокой конкуренции или стагнации рынка.
Классификация основана на классическом инструменте стратегического менеджмента Ansoff Matrix. Мы с Викой Харламовой адаптировали его под реалии технологических продуктов для материалов нашего курса Grow Your Product.
Чтобы выбрать правильную стратегию, нужно ориентироваться не только и не столько на видение, сколько на достоверную информацию. Чтобы стратегия не стала бесполезной бумажкой в столе руководителя, нужно согласовать план конкретных действий по ее реализации.
На чем основывается хорошая стратегия роста, какие факторы нужно учитывать при ее составлении и как сопрягать стратегию с реальными действиями команды, поговорим в следующем посте.
В предыдущем посте мы определились, что стратегия роста нужна в любое время. Кризисы – не исключение.
С помощью стратегии вы:
— Выделяете ключевые метрики измерения результата;
— Расставляете приоритеты в распределении ресурсов, найме, бюджетировании;
— Выдвигаете инициативы по развитию продукта и привлечению пользователей;
— Согласуете и приоритизируете гипотезы роста.
Без стратегии все вышеперечисленные задачи превращаются в хаос. Даже в небольшом стартапе никто толком не будет понимать, что делать. Компания либо утонет в бесконечных обсуждениях, либо зациклит принятие решений на одном человеке.
Наличие стратегии помогает фокусироваться на наиболее важных задачах, согласовывать действия между командами, двигаться сообща в одном направлении.
Для технологического бизнеса можно выделить четыре стратегии роста:
1. Product-Led Growth
Рост за счет продукта.
Драйверы: виральность, контент, поисковая оптимизация.
Характерна для продуктов с большим виральным потенциалом: социальные сети, мессенджеры, продукты для совместного использования. Незначительные издержки на одного пользователя делают возможным использование фримиум модели монетизации.
2. Marketing-Led Growth
Рост за счет платного привлечения.
Драйверы: наличие масштабируемых каналов, позитивная юнит-экономика.
Характерна для продуктов с хорошей монетизацией и высокими операционными издержками: доставка, такси, e-commerce, обучение. Пользователи начинают платить на раннем этапе использования продукта, что позволяет быстро сводить юнит-экономику или с достаточной точностью прогнозировать LTV.
3. Sales-Led Growth
Рост за счет прямых продаж.
Драйверы: отработанная механика продажи, узнаваемость бренда.
Характерна для продуктов, ориентированных на enterprise клиентов. Или продуктов с большим чеком. Стоимость одной сделки покрывает издержки длительного цикла продажи, позволяет выплачивать высокие проценты продавцам и партнерам.
4. Diversification
4.1. Рост за счет выхода на новые рынки.
Драйверы: воспроизводимая бизнес-модель.
Характерна для продуктов, оцифровывающих аналоговые решения на больших рынках. За счет преобладающей цифровой составляющей имеют умеренную стоимость локализации.
4.2. Рост за счет запуска новых продуктов.
Драйверы: незакрытые текущим продуктом потребности клиентов.
Характерна для продуктов, исчерпавших потенциал роста из-за высокой конкуренции или стагнации рынка.
Классификация основана на классическом инструменте стратегического менеджмента Ansoff Matrix. Мы с Викой Харламовой адаптировали его под реалии технологических продуктов для материалов нашего курса Grow Your Product.
Чтобы выбрать правильную стратегию, нужно ориентироваться не только и не столько на видение, сколько на достоверную информацию. Чтобы стратегия не стала бесполезной бумажкой в столе руководителя, нужно согласовать план конкретных действий по ее реализации.
На чем основывается хорошая стратегия роста, какие факторы нужно учитывать при ее составлении и как сопрягать стратегию с реальными действиями команды, поговорим в следующем посте.
Forwarded from InsightStream
КАК ПРАВИЛЬНО ПОСТАВИТЬ ЗАДАЧУ ДЛЯ РАЗРАБОТКИ
💎
«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов.
В данной статье описывается опыт с упором на специфику работы компании (автора статьи) именно в их сфере – разработки мобильных приложений на заказ, но при этом у них есть несколько собственных продуктов в виде приложений. Если вы не увидите тут идеальных лично для вас процессов, то не переживайте, это вполне нормально, но в любом случае авторы считают, что описанное в той или иной мере может быть применимо в разных областях создания программного обеспечения.
Шаги описания задачи
⚡️ Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
⚡️ Подберите правильное название задачи.
⚡️ В самом начале описания задачи поясните разработчику ценность изменения.
⚡️ Добавьте путь до изменяемого экрана, если это не очевидно.
⚡️ Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
⚡️ Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
⚡️ Если предполагается переиспользование для реализации, явно укажите это.
⚡️ Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
⚡️ Если необходимо сохранение данных для будущего использования, укажите.
⚡️ Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
⚡️ Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
⚡️ Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
⚡️ Укажите прошлые локальные данные, если они используются.
⚡️ Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
⚡️ Укажите логику для пустых данных.
⚡️ Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
⚡️ Пропишите логику для обработки специальных ошибок.
⚡️ Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
⚡️ Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
⚡️ Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
⚡️ Дополните базовый чек-лист.
⚡️ Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
🏁 Перечитайте всю задачу от начала до конца!
Важно приучить себя мысленно продумывать все эти шаги, чтобы потом на автомате учитывать все потребности и возможности для облегчения разработки. Хорошо описанная задача экономит время всем: будет меньше вопросов, ускорится тестирование и т.д.
🍀 Source >>>
#case #development #efficiency #product #tools
💎
«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов.
В данной статье описывается опыт с упором на специфику работы компании (автора статьи) именно в их сфере – разработки мобильных приложений на заказ, но при этом у них есть несколько собственных продуктов в виде приложений. Если вы не увидите тут идеальных лично для вас процессов, то не переживайте, это вполне нормально, но в любом случае авторы считают, что описанное в той или иной мере может быть применимо в разных областях создания программного обеспечения.
Шаги описания задачи
⚡️ Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
⚡️ Подберите правильное название задачи.
⚡️ В самом начале описания задачи поясните разработчику ценность изменения.
⚡️ Добавьте путь до изменяемого экрана, если это не очевидно.
⚡️ Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
⚡️ Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
⚡️ Если предполагается переиспользование для реализации, явно укажите это.
⚡️ Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
⚡️ Если необходимо сохранение данных для будущего использования, укажите.
⚡️ Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
⚡️ Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
⚡️ Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
⚡️ Укажите прошлые локальные данные, если они используются.
⚡️ Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
⚡️ Укажите логику для пустых данных.
⚡️ Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
⚡️ Пропишите логику для обработки специальных ошибок.
⚡️ Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
⚡️ Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
⚡️ Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
⚡️ Дополните базовый чек-лист.
⚡️ Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
🏁 Перечитайте всю задачу от начала до конца!
Важно приучить себя мысленно продумывать все эти шаги, чтобы потом на автомате учитывать все потребности и возможности для облегчения разработки. Хорошо описанная задача экономит время всем: будет меньше вопросов, ускорится тестирование и т.д.
🍀 Source >>>
#case #development #efficiency #product #tools
Forwarded from 100x | Денис Мартынцев
Как смотреть географию установок и доходов конкурентных приложений
Анализ ниши через показатели конкурентов и аналогов – один из основных подходов к принятию решений о запуске или развитии mobile first/only продуктов.
Каждый, кто занимается приложениями, знает десяток сервисов, с помощью которых решается такая задача.
Но у всех этих сервисов есть общая проблема – возможности бесплатных версий сильно ограничены, а полноценные платные стоят, как крыло от Боинга в условиях санкций и параллельного импорта.
Недавно узнал крайне полезный хак, который позволяет бесплатно смотреть географию установок и доходов любого приложения.
Алгоритм такой:
1. Заходим на веб-версию https://app.sensortower.com
2. Вводим название приложения в поисковую строку
3. Выбираем нужный вариант в ниспадающем списке (учитывая платформу)
4. Нажимаем на иконку приложения (нужен бесплатный аккаунт)
5. Нажимаем правой кнопкой мыши на неактивную область и выбираем «Просмотр кода страницы»
6. В новой вкладке с кодом открываем поиск и вводим “breakdown”
7. Видим в коде строку с показателями "revenueBreakdown” и "downloadBreakdown”
8. Копируем себе показатели в формате "US":0.42,"IT":0.02,"BR":0.04,"EG":0.02,"IN":0.03…, где две буквы обозначают страну, а цифра после двоеточия – долю в установках или доходе приложения
9. Вставляем в Google Sheets, немного причесываем, строим круговые диаграммы и наглядно видим географическое распределение установок и покупок
10. Радуемся.
Данные обновляются каждый месяц. Можно копировать ручками или написать простенький парсер.
Понятно, что точность не стопроцентная. SensorTower использует косвенные данные и собственные алгоритмы для подсчета долей. Но общую картину и тенденции точно можно отследить.
Пользуйтесь на здоровье, только никому не говорите, что так можно. А то прикроют.
Анализ ниши через показатели конкурентов и аналогов – один из основных подходов к принятию решений о запуске или развитии mobile first/only продуктов.
Каждый, кто занимается приложениями, знает десяток сервисов, с помощью которых решается такая задача.
Но у всех этих сервисов есть общая проблема – возможности бесплатных версий сильно ограничены, а полноценные платные стоят, как крыло от Боинга в условиях санкций и параллельного импорта.
Недавно узнал крайне полезный хак, который позволяет бесплатно смотреть географию установок и доходов любого приложения.
Алгоритм такой:
1. Заходим на веб-версию https://app.sensortower.com
2. Вводим название приложения в поисковую строку
3. Выбираем нужный вариант в ниспадающем списке (учитывая платформу)
4. Нажимаем на иконку приложения (нужен бесплатный аккаунт)
5. Нажимаем правой кнопкой мыши на неактивную область и выбираем «Просмотр кода страницы»
6. В новой вкладке с кодом открываем поиск и вводим “breakdown”
7. Видим в коде строку с показателями "revenueBreakdown” и "downloadBreakdown”
8. Копируем себе показатели в формате "US":0.42,"IT":0.02,"BR":0.04,"EG":0.02,"IN":0.03…, где две буквы обозначают страну, а цифра после двоеточия – долю в установках или доходе приложения
9. Вставляем в Google Sheets, немного причесываем, строим круговые диаграммы и наглядно видим географическое распределение установок и покупок
10. Радуемся.
Данные обновляются каждый месяц. Можно копировать ручками или написать простенький парсер.
Понятно, что точность не стопроцентная. SensorTower использует косвенные данные и собственные алгоритмы для подсчета долей. Но общую картину и тенденции точно можно отследить.
Пользуйтесь на здоровье, только никому не говорите, что так можно. А то прикроют.
Sensor Tower
Sensor Tower - Market Intelligence for the Global Digital Economy
Understand your impact in the digital and mobile economy with Sensor Tower’s comprehensive highly accurate app store analytics and unique engagement insights
Forwarded from 100x | Денис Мартынцев
Freemium модель сложнее, чем кажется
Существует устойчивое мнение, что фримиум – это модель привлечения, а не монетизации, как принято считать.
Его активно продвигают Brian Balfour (основатель Reforge), Patrick Campbell (основатель ProfitWell), Wes Bush (основатель ProductLed). Авторитетные люди в индустрии.
Они приводят примеры успешных компаний, которые росли за счет фримиум-модели, и объясняют механизмы такого роста. Пара коротких видео для ознакомления: раз и два.
Суть идеи проста.
Активные пользователи, удовлетворенные бесплатной версией продукта, привлекают в продукт новых. То есть, работает виральность. Именно в этом и есть главный смысл держать большую массу неплатящих пользователей. Именно через призму привлечения нужно смотреть на фримиум-модель.
У меня эта мысль вызывает противоречие. Я с ней согласен и не согласен одновременно. Хочется ее приземлить и обсудить с вами.
То, что фримиум наиболее эффективная модель для продуктов, делающих ставку на виральность, как главный рычаг роста, сомнений не вызывает. Ее используют Slack, Dropbox, Spotify, Mailchimp, Notion, Figma, Miro и многие другие.
Качественный продукт + хорошая виральность + правильно задизайненный фримиум = устойчивый органический рост
Собственно, это и есть формула успешного Product-Led Growth бизнеса.
Стоит ли, исходя из этой формулы, отказываться от фримум-модели в пользу триала, если на виральность продукт расчитывать не может?
На мой взгляд, Balfour, Campbell и ребята из ProductLed слишком упрощают. Как бы пафосно это не звучало с моей стороны.
Они рассматривают преимущественно SaaS продукты и подводят к тому, что если нет виральности, нужно иметь другие каналы привлечения и использовать триал.
Но параллельно с SaaS существует гигантская игровая индустрия, для которой фримиум тоже устоявшаяся модель. Большинство фримиум-игр (например, мобильных) строят привлечение на платном маркетинге. Виральность, если и есть, то точно недостаточная, чтобы драйвить рост.
Зачем тогда играм фримиум-модель, если они не рассматривают ее, как модель привлечения? Потому что их устраивает фримиум, как модель монетизации.
Все дело в цикле вовлечения и периоде принятия решения о покупке. Люди играют в игры с разной интенсивностью. Могут начать платить, как на второй день, так и на сто второй. Гейм продюсеры это знают, поэтому создают длинные игровые сценарии с постепенным усложнением и калибруют монетизацию под них.
Пройти первые пять уровней без донатов может каждый. Но чтобы прокачать крутого персонажа и быть среди лидеров, нужно либо тратить на игру все свое время, либо платить за преимущества и ускорители. На поздних уровнях много платить.
Похожая логика применима к SaaS продуктам. Пользователь месяцами получал от продукта ценность (играл), привыкал к интерфейсу (обучался), накапливал контент (прокачивался) и вдруг столкнулся с ограничением. Закончилось место в облаке Dropbox или нужно создать еще одну доску в Miro.
Switching costs к этому моменту уже слишком большие, чтобы искать альтернативы. Приходится оформлять подписку.
Но как понять, что в долгосрочной перспективе лучше для конкретного продукта, не имеющего вирального потенциала, – фримиуим или триал? Сделать эксперимент со сравнением LTV когорт разных моделей.
Такой эксперимент может быть сложным, дорогим и очень долгим. Держать его прийдется, пока когорта с фримиумом не проживет существенное время. Месяцы или даже год.
Это, конечно, в том случае, если у продукта хорошее удержание на бесплатном тарифе. Если через месяц выжило 3% когорты, то пора сворачиваться и ставить триал. А лучше вернуться к поиску Product/Market fit.
Можно попытаться ускорить эксперимент за счет сбора качественных данных через интервью с пользователями. Увидеть сигналы в их опыте и восприятии продукта.
Ещё можно использовать фреймворки наподобие MOAT. Он помогает выбрать модель, исходя из характеристик продукта и состояния рынка. Основывается на эмпирических данных о сотнях продуктов, применяющих разные модели. Но отдавать такое важное решение на откуп шаблону, как-то ненадежно.
Существует устойчивое мнение, что фримиум – это модель привлечения, а не монетизации, как принято считать.
Его активно продвигают Brian Balfour (основатель Reforge), Patrick Campbell (основатель ProfitWell), Wes Bush (основатель ProductLed). Авторитетные люди в индустрии.
Они приводят примеры успешных компаний, которые росли за счет фримиум-модели, и объясняют механизмы такого роста. Пара коротких видео для ознакомления: раз и два.
Суть идеи проста.
Активные пользователи, удовлетворенные бесплатной версией продукта, привлекают в продукт новых. То есть, работает виральность. Именно в этом и есть главный смысл держать большую массу неплатящих пользователей. Именно через призму привлечения нужно смотреть на фримиум-модель.
У меня эта мысль вызывает противоречие. Я с ней согласен и не согласен одновременно. Хочется ее приземлить и обсудить с вами.
То, что фримиум наиболее эффективная модель для продуктов, делающих ставку на виральность, как главный рычаг роста, сомнений не вызывает. Ее используют Slack, Dropbox, Spotify, Mailchimp, Notion, Figma, Miro и многие другие.
Качественный продукт + хорошая виральность + правильно задизайненный фримиум = устойчивый органический рост
Собственно, это и есть формула успешного Product-Led Growth бизнеса.
Стоит ли, исходя из этой формулы, отказываться от фримум-модели в пользу триала, если на виральность продукт расчитывать не может?
На мой взгляд, Balfour, Campbell и ребята из ProductLed слишком упрощают. Как бы пафосно это не звучало с моей стороны.
Они рассматривают преимущественно SaaS продукты и подводят к тому, что если нет виральности, нужно иметь другие каналы привлечения и использовать триал.
Но параллельно с SaaS существует гигантская игровая индустрия, для которой фримиум тоже устоявшаяся модель. Большинство фримиум-игр (например, мобильных) строят привлечение на платном маркетинге. Виральность, если и есть, то точно недостаточная, чтобы драйвить рост.
Зачем тогда играм фримиум-модель, если они не рассматривают ее, как модель привлечения? Потому что их устраивает фримиум, как модель монетизации.
Все дело в цикле вовлечения и периоде принятия решения о покупке. Люди играют в игры с разной интенсивностью. Могут начать платить, как на второй день, так и на сто второй. Гейм продюсеры это знают, поэтому создают длинные игровые сценарии с постепенным усложнением и калибруют монетизацию под них.
Пройти первые пять уровней без донатов может каждый. Но чтобы прокачать крутого персонажа и быть среди лидеров, нужно либо тратить на игру все свое время, либо платить за преимущества и ускорители. На поздних уровнях много платить.
Похожая логика применима к SaaS продуктам. Пользователь месяцами получал от продукта ценность (играл), привыкал к интерфейсу (обучался), накапливал контент (прокачивался) и вдруг столкнулся с ограничением. Закончилось место в облаке Dropbox или нужно создать еще одну доску в Miro.
Switching costs к этому моменту уже слишком большие, чтобы искать альтернативы. Приходится оформлять подписку.
Но как понять, что в долгосрочной перспективе лучше для конкретного продукта, не имеющего вирального потенциала, – фримиуим или триал? Сделать эксперимент со сравнением LTV когорт разных моделей.
Такой эксперимент может быть сложным, дорогим и очень долгим. Держать его прийдется, пока когорта с фримиумом не проживет существенное время. Месяцы или даже год.
Это, конечно, в том случае, если у продукта хорошее удержание на бесплатном тарифе. Если через месяц выжило 3% когорты, то пора сворачиваться и ставить триал. А лучше вернуться к поиску Product/Market fit.
Можно попытаться ускорить эксперимент за счет сбора качественных данных через интервью с пользователями. Увидеть сигналы в их опыте и восприятии продукта.
Ещё можно использовать фреймворки наподобие MOAT. Он помогает выбрать модель, исходя из характеристик продукта и состояния рынка. Основывается на эмпирических данных о сотнях продуктов, применяющих разные модели. Но отдавать такое важное решение на откуп шаблону, как-то ненадежно.
YouTube
Freemium vs Free Trial - How Spotify Drives New Business Acquisition | Brian Balfour
Freemium is a way to lower friction and enable virality or some other form of acquisition model. Learn more here: https://goo.gl/guk1vm
10 day tech startup launch plan:
- Domain on GoDaddy (5 min)
- Logo ideas on Looka (5 min)
- Brand assets on Figma (30 min)
- Webpage on Webflow (5 hours)
- Backend data on Airtable (1 hour)
- Collect leads on Typeform (20 min)
- Customer CRM on Copper (1 hour)
- SEO optimization on Ahrefs (2 hours)
- Customer feedback on Canny (1 hour)
- Payment collection on Stripe (2 hours)
- Marketing designs on Canva (2 hours)
- Automation workflow on Zapier (1 hour)
- Newsletter each week on Substack (1 day)
- Landing page chatbot on Intercom (1 hour)
- Product roadmap & tasks on Trello (1 hour)
- Initial marketing on Product Hunt (3 hours)
- Step by step instructions on Notion (2 hours)
- Email marketing on Intuit Mailchimp (1 hour)
- Early MVP app on Bubble, Softr, Flutterflow (6 days)
Keep it simple:
1. Launch landing page
2. Get customers in
3. Provide value with MVP
4. Collect feedback
5. Repeat & improve
You don’t have to spend 3-6 months coding to launch.
Start in 10 days and less than $300.
- Domain on GoDaddy (5 min)
- Logo ideas on Looka (5 min)
- Brand assets on Figma (30 min)
- Webpage on Webflow (5 hours)
- Backend data on Airtable (1 hour)
- Collect leads on Typeform (20 min)
- Customer CRM on Copper (1 hour)
- SEO optimization on Ahrefs (2 hours)
- Customer feedback on Canny (1 hour)
- Payment collection on Stripe (2 hours)
- Marketing designs on Canva (2 hours)
- Automation workflow on Zapier (1 hour)
- Newsletter each week on Substack (1 day)
- Landing page chatbot on Intercom (1 hour)
- Product roadmap & tasks on Trello (1 hour)
- Initial marketing on Product Hunt (3 hours)
- Step by step instructions on Notion (2 hours)
- Email marketing on Intuit Mailchimp (1 hour)
- Early MVP app on Bubble, Softr, Flutterflow (6 days)
Keep it simple:
1. Launch landing page
2. Get customers in
3. Provide value with MVP
4. Collect feedback
5. Repeat & improve
You don’t have to spend 3-6 months coding to launch.
Start in 10 days and less than $300.
Forwarded from 100x | Денис Мартынцев
Как Customer Success помогает растить бизнес
Этот пост мы написали вместе с Олегом Красновым, ex-Head of Support Excellence в Miro.
Для подписочного SaaS продукта, как и для многих других, метрика удержания является ключевой. Retention показывает наличие или отсутствие Product/Market Fit и в целом демонстрирует здоровье бизнеса и потенциал для роста.
Принято считать, что удержание прежде всего зависит от повторяющейся ценности, получаемой пользователем. Во многом так и есть. Но когда дело касается крупных клиентов, покупающих десятки лицензий, на первый план могут выходить другие, менее очевидные факторы:
1. Несоответствие первоначальным ожиданиям. Менеджеры по продажам были красноречивы, но после покупки клиент не может в полной мере получить то, что ожидал.
2. Недостаточное проникновение лицензий. Клиент купил 100 лицензий для своих сотрудников, но активно используются только 50 из них.
3. Не хватает функциональности. Клиенту нужно решать специфические задачи, но продукт не позволяет этого делать.
4. Не исправляются баги. Пользователи со стороны клиента сталкиваются с багами в продукте, которые долго не решаются и вызывают раздражение.
Любая из этих проблем может стать причиной непродления подписки и ухода крупного клиента, который заберет с собой сразу несколько десятков (или даже сотен) пользователей и жирный кусок MRR.
Именно для того, чтобы избежать подобных серьезных последствий, существует дисциплина Customer Success.
В русскоязычной среде Customer Success часто путают с Customer Support.
Разница в том, что Support – это реактивная функция. То есть, ответ на запрос или жалобу клиента.
Success же – проактивная функция. Компания сама инициирует общение с клиентами. Делает это регулярно и методично, а не только в моменты, когда нужно изо всех сил спасать утекающую выручку.
Customer Success работает в тесной кооперации с продуктовой командой, чтобы обратная связь от крупных клиентов влияла на принятие решений о развитии продукта.
Но задача CS менеджера не в том, чтобы рассказать продактам про хотелки клиентов и настоять на их разработке. Успех достигается за счет синхронизации обратной связи с продуктовой стратегией. Главная цель – развитие продукта и улучшение пользовательского опыта для максимального числа клиентов в долгосрочной перспективе.
Правильно выстроенный Customer Success помогает не свалиться в заказную разработку под давлением крупного клиента. Для этого Success Manager с самого начала строит доверительные отношения и старается сделать так, чтобы клиент получил максимальную ценность от продукта.
Customer Success Manager обучает сотрудников клиента пользоваться продуктом, выясняет запросы и старается удовлетворить их в рамках текущего продукта, предоставляет регулярные обзоры активности в продукте и демонстрирует ROI клиента, своевременно оповещает о возможных сбоях и проблемах.
Один менеджер может вести от двух до десяти очень крупных клиентов или от 50 до 100 средних компаний при условии наличия автоматизации и аналитики.
Customer Success создает фундамент для роста бизнеса. Когда вы уверены в стабильности и постоянстве своих ключевых клиентов, вам гораздо проще экспериментировать, искать новые сегменты, пробовать новые бизнес-модели и тарифы.
Буквально на днях Олег начал вести свой канал, в котором планирует делиться профессиональным опытом и лайфхаками повышения продуктивности.
С Олегом мы знакомы много лет, я знаю его, как одного из лучших русскоязычных специалистов в Customer Success и просто интересного человека, поэтому с уверенностью рекомендую подписаться.
Этот пост мы написали вместе с Олегом Красновым, ex-Head of Support Excellence в Miro.
Для подписочного SaaS продукта, как и для многих других, метрика удержания является ключевой. Retention показывает наличие или отсутствие Product/Market Fit и в целом демонстрирует здоровье бизнеса и потенциал для роста.
Принято считать, что удержание прежде всего зависит от повторяющейся ценности, получаемой пользователем. Во многом так и есть. Но когда дело касается крупных клиентов, покупающих десятки лицензий, на первый план могут выходить другие, менее очевидные факторы:
1. Несоответствие первоначальным ожиданиям. Менеджеры по продажам были красноречивы, но после покупки клиент не может в полной мере получить то, что ожидал.
2. Недостаточное проникновение лицензий. Клиент купил 100 лицензий для своих сотрудников, но активно используются только 50 из них.
3. Не хватает функциональности. Клиенту нужно решать специфические задачи, но продукт не позволяет этого делать.
4. Не исправляются баги. Пользователи со стороны клиента сталкиваются с багами в продукте, которые долго не решаются и вызывают раздражение.
Любая из этих проблем может стать причиной непродления подписки и ухода крупного клиента, который заберет с собой сразу несколько десятков (или даже сотен) пользователей и жирный кусок MRR.
Именно для того, чтобы избежать подобных серьезных последствий, существует дисциплина Customer Success.
В русскоязычной среде Customer Success часто путают с Customer Support.
Разница в том, что Support – это реактивная функция. То есть, ответ на запрос или жалобу клиента.
Success же – проактивная функция. Компания сама инициирует общение с клиентами. Делает это регулярно и методично, а не только в моменты, когда нужно изо всех сил спасать утекающую выручку.
Customer Success работает в тесной кооперации с продуктовой командой, чтобы обратная связь от крупных клиентов влияла на принятие решений о развитии продукта.
Но задача CS менеджера не в том, чтобы рассказать продактам про хотелки клиентов и настоять на их разработке. Успех достигается за счет синхронизации обратной связи с продуктовой стратегией. Главная цель – развитие продукта и улучшение пользовательского опыта для максимального числа клиентов в долгосрочной перспективе.
Правильно выстроенный Customer Success помогает не свалиться в заказную разработку под давлением крупного клиента. Для этого Success Manager с самого начала строит доверительные отношения и старается сделать так, чтобы клиент получил максимальную ценность от продукта.
Customer Success Manager обучает сотрудников клиента пользоваться продуктом, выясняет запросы и старается удовлетворить их в рамках текущего продукта, предоставляет регулярные обзоры активности в продукте и демонстрирует ROI клиента, своевременно оповещает о возможных сбоях и проблемах.
Один менеджер может вести от двух до десяти очень крупных клиентов или от 50 до 100 средних компаний при условии наличия автоматизации и аналитики.
Customer Success создает фундамент для роста бизнеса. Когда вы уверены в стабильности и постоянстве своих ключевых клиентов, вам гораздо проще экспериментировать, искать новые сегменты, пробовать новые бизнес-модели и тарифы.
Буквально на днях Олег начал вести свой канал, в котором планирует делиться профессиональным опытом и лайфхаками повышения продуктивности.
С Олегом мы знакомы много лет, я знаю его, как одного из лучших русскоязычных специалистов в Customer Success и просто интересного человека, поэтому с уверенностью рекомендую подписаться.
Forwarded from Интернет-аналитика // Алексей Никушин (Alexey Nikushin)
Самостоятельно построить прогноз LTV пользователя мобильного приложения задача нетривиальная. Аналитики MyTracker написали целую книжку о том, с какой стороны к этому подойти. Гайд включает в себя сведения о том, как работать с сырыми данными, предобрабатывать их, представлять в виде пригодных данных для анализа.
И самое главное - для каждой модели есть руководство по тому, как оценить ее качество с помощью набора метрик. Рассматриваются модели на основе catboost, линейной регрессии, коэффициентная модель и модель на основе экстраполяции логарифмом.
Если есть базовые знания Python, то разобраться с материалом будет несложно и интересно - код предоставлен. Кроме этого, даже есть ссылка на датасет с сырыми данными о транзакциях устройств для большого приложения и файл с данными о кумулятивном (накопленном) LTV устройств.
Скачать книжку можно на лендинге
И самое главное - для каждой модели есть руководство по тому, как оценить ее качество с помощью набора метрик. Рассматриваются модели на основе catboost, линейной регрессии, коэффициентная модель и модель на основе экстраполяции логарифмом.
Если есть базовые знания Python, то разобраться с материалом будет несложно и интересно - код предоставлен. Кроме этого, даже есть ссылка на датасет с сырыми данными о транзакциях устройств для большого приложения и файл с данными о кумулятивном (накопленном) LTV устройств.
Скачать книжку можно на лендинге
🔸Что показывает метрика MRR, чем она отличается от Revenue и как на нее влиять.
Если ваш бизнес работает по модели SAAS вы точно должны знать такую метрику как MRR или Monthly Recurring Revenue. Итак MRR это ежемесячная регулярная сумма дохода от пользователя в SAAS бизнесе. Ключевое слово тут "регулярная", то есть если смотреть на доход от продажи - "Revenue" как разовую сделку по обмену определенной ценности за определенную цену, то MRR это сумма, которую вы получаете в месяц от пользователя в обмен на оказание определенного вида услуг или предоставление сервиса.
Это ключевое различие, когда деньги вы получаете вперед, а услугу должны оказывать еще продолжительное время, другими словами пользователю, который уже купил и пользуется сложно продать сервис повторно.
На скринах пример визуального отличия графика Revenue vs MRR, для простоты посчитал поделив годовую стоимость на 12, но правильнее считать стоимость дня и потом уже группировать помесячно.
Шаблон расчета
Если ваш бизнес работает по модели SAAS вы точно должны знать такую метрику как MRR или Monthly Recurring Revenue. Итак MRR это ежемесячная регулярная сумма дохода от пользователя в SAAS бизнесе. Ключевое слово тут "регулярная", то есть если смотреть на доход от продажи - "Revenue" как разовую сделку по обмену определенной ценности за определенную цену, то MRR это сумма, которую вы получаете в месяц от пользователя в обмен на оказание определенного вида услуг или предоставление сервиса.
Это ключевое различие, когда деньги вы получаете вперед, а услугу должны оказывать еще продолжительное время, другими словами пользователю, который уже купил и пользуется сложно продать сервис повторно.
На скринах пример визуального отличия графика Revenue vs MRR, для простоты посчитал поделив годовую стоимость на 12, но правильнее считать стоимость дня и потом уже группировать помесячно.
Шаблон расчета
🔸На что это влияет MRR?
- на подсчет экономической модели бизнеса
- на на оценку "здоровья" бизнеса
- на стратегию развития и прогнозирование будущего дохода
🔹Что нужно знать важного про MRR?
Посчитав MRR нужно обязательно детализировать метрику на составляющие: New MRR, Churn MRR, Contraction MRR, Expansion MRR, Regular MRR в этой детализации скрыты точки роста и проблемные зоны:
- NEW MRR покажет доход от новых пользователей с разбивкой по месяцам, удобно смотреть в связки с ARPU/ ARPPU для оценки маркетинговых инициатив
- Churn MRR покажет сколько денег вы теряете в результате отмены подписки, всегда отрицательное значение
- Contraction MRR - отрицательная сумма, полученная в результате понижения типа тарифного плана (с более дорогого на дешевый)
- Expansion MRR - апгрейд подписки с дешевой на более дорогой план. Косвенно показывает апсейл
- на подсчет экономической модели бизнеса
- на на оценку "здоровья" бизнеса
- на стратегию развития и прогнозирование будущего дохода
🔹Что нужно знать важного про MRR?
Посчитав MRR нужно обязательно детализировать метрику на составляющие: New MRR, Churn MRR, Contraction MRR, Expansion MRR, Regular MRR в этой детализации скрыты точки роста и проблемные зоны:
- NEW MRR покажет доход от новых пользователей с разбивкой по месяцам, удобно смотреть в связки с ARPU/ ARPPU для оценки маркетинговых инициатив
- Churn MRR покажет сколько денег вы теряете в результате отмены подписки, всегда отрицательное значение
- Contraction MRR - отрицательная сумма, полученная в результате понижения типа тарифного плана (с более дорогого на дешевый)
- Expansion MRR - апгрейд подписки с дешевой на более дорогой план. Косвенно показывает апсейл
🔸Система метрик AARRR, также называемая пиратскими метриками или воронкой AARRR, представляет собой набор метрик, используемых для отслеживания и влияния на критическое поведение пользователей, которое может привести к росту бизнеса.
Аббревиатура означает:
- acquisition или привлечение,
- activation или активацию,
- retention или удержание,
- referral - лояльный пользователь, готовый рекомендовать продукт друзьям
- revenue - получение дохода.
Стартапы используют данную структуру, чтобы узнать, находятся ли они на пути роста и какие конкретные этапы воронки нуждаются в оптимизации. AARRR была разработана инвестором и предпринимателем Dave McClure (основателем 500 Startups) из-за необходимости простого универсального решения, которое может использовать любой стартап.
Аббревиатура означает:
- acquisition или привлечение,
- activation или активацию,
- retention или удержание,
- referral - лояльный пользователь, готовый рекомендовать продукт друзьям
- revenue - получение дохода.
Стартапы используют данную структуру, чтобы узнать, находятся ли они на пути роста и какие конкретные этапы воронки нуждаются в оптимизации. AARRR была разработана инвестором и предпринимателем Dave McClure (основателем 500 Startups) из-за необходимости простого универсального решения, которое может использовать любой стартап.
🔹ACV или Annual Contract Value
Годовая стоимость контракта (ACV) — это средний годовой доход, полученный от каждого клиентского контракта, без учета комиссий. Если клиент подписывает 5-летний контракт на 50 000 долларов США, усреднение этого значения за год даст вам годовую стоимость контракта 10 000 долларов США.
Одна из причин, по которой ACV сбивает с толку основателей SaaS, заключается в том, что на первый взгляд он очень похож на ARR. Но в то время как ARR измеряет стоимость повторяющегося дохода от дополнительных продаж, продлений и других моментов в один момент времени, ACV нормализует этот общий доход за один или несколько лет.
Бизнес по подписке может быть успешным как с высоким, так и с низким ACV, а важность ACV как показателя определяется другими показателями, такими как уровень оттока и CAC (стоимость привлечения клиентов).
Годовая стоимость контракта (ACV) — это средний годовой доход, полученный от каждого клиентского контракта, без учета комиссий. Если клиент подписывает 5-летний контракт на 50 000 долларов США, усреднение этого значения за год даст вам годовую стоимость контракта 10 000 долларов США.
Одна из причин, по которой ACV сбивает с толку основателей SaaS, заключается в том, что на первый взгляд он очень похож на ARR. Но в то время как ARR измеряет стоимость повторяющегося дохода от дополнительных продаж, продлений и других моментов в один момент времени, ACV нормализует этот общий доход за один или несколько лет.
Бизнес по подписке может быть успешным как с высоким, так и с низким ACV, а важность ACV как показателя определяется другими показателями, такими как уровень оттока и CAC (стоимость привлечения клиентов).
👍1