MVP за 7 недель. Как это было
1. Мы «забили» на инфраструктуру. До поры до времени необязательно.
2. «Нафиг» — стало нашей любимой фразой.
3. Практический опыт пременения Бритвы Оккама для разработки продукта в сжатые сроки.
#product_dump @pm_dump
1. Мы «забили» на инфраструктуру. До поры до времени необязательно.
2. «Нафиг» — стало нашей любимой фразой.
3. Практический опыт пременения Бритвы Оккама для разработки продукта в сжатые сроки.
#product_dump @pm_dump
Сокровищница аналитика.
Набор полезных ссылок на курсы, инструменты и вот это всё.
От аналитикса и метрики до mySQL, Python и R.
#naked_links @pm_dump
Набор полезных ссылок на курсы, инструменты и вот это всё.
От аналитикса и метрики до mySQL, Python и R.
#naked_links @pm_dump
Toolmark
Сокровищница аналитика - Toolmark
Сокровищница аналитика
Сделай репост, чтобы не потерять
Строки отмеченные красным - обновления сокровищницы от 15.04.2020
Бесплатный курс "Анализ данных в google analytics" Андрея Осипова
Сделай репост, чтобы не потерять
Строки отмеченные красным - обновления сокровищницы от 15.04.2020
Бесплатный курс "Анализ данных в google analytics" Андрея Осипова
Как писать User Stories
User story - это то, как ваш пользователь должен взаимодействовать с вашим продуктом. Это не технические требования.
1. На выполнение истории не больше 1 итерации, иначе нужно разбить
2. Если какую-то из трех частей можно убрать, то она бесполезна:
- Актор (один) - сделать подгруппы и под них писать истории (персоны)
- Действие (одно) - писать нужно ЧТО делает пользователь, а не КАК. Это важно.
- Ценность (одна) - Не обязательно писать "чтобы". Можно сделать быстрее: щас 60 секунд, должно быть 15 секунд. Ценность должна линковаться с целью продукта. Используйте "Impact map".
3. Каждую юсторию можно оценить по критериям «INVEST»:
- Independent. Reduced dependencies = easier to plan;
- Negotiable. Details added via collaboration;
- Valuable.
- Estimable. Too big or too vague = not estimable;
- Small. Can be done in less than a week by the team;
- Testable. Good acceptance criteria;
4. Советы к написанию user stories:
- Лучше написать много историй поменьше, чем несколько громоздких.
- Каждая история в идеале должна быть написана избегая технического жаргона.
- Истории должны быть написаны таким образом, чтобы их можно было протестировать
- Тесты должны быть написаны до кода.
- Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
- Каждая история должна содержать оценку.
- История должна иметь концовку — т.е. приводить к конкретному результату.
- История должна помещаться в итерацию.
Summary: юстории помогут вам более чётко понимать зачем вы делаете ту или иную фичу, потому что ваш продукт должен решать пользовательскую задачу или проблему. Выработать US можно с помощью брейншторма или CJM.
#product_dump @pm_dump
User story - это то, как ваш пользователь должен взаимодействовать с вашим продуктом. Это не технические требования.
1. На выполнение истории не больше 1 итерации, иначе нужно разбить
2. Если какую-то из трех частей можно убрать, то она бесполезна:
- Актор (один) - сделать подгруппы и под них писать истории (персоны)
- Действие (одно) - писать нужно ЧТО делает пользователь, а не КАК. Это важно.
- Ценность (одна) - Не обязательно писать "чтобы". Можно сделать быстрее: щас 60 секунд, должно быть 15 секунд. Ценность должна линковаться с целью продукта. Используйте "Impact map".
3. Каждую юсторию можно оценить по критериям «INVEST»:
- Independent. Reduced dependencies = easier to plan;
- Negotiable. Details added via collaboration;
- Valuable.
- Estimable. Too big or too vague = not estimable;
- Small. Can be done in less than a week by the team;
- Testable. Good acceptance criteria;
4. Советы к написанию user stories:
- Лучше написать много историй поменьше, чем несколько громоздких.
- Каждая история в идеале должна быть написана избегая технического жаргона.
- Истории должны быть написаны таким образом, чтобы их можно было протестировать
- Тесты должны быть написаны до кода.
- Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
- Каждая история должна содержать оценку.
- История должна иметь концовку — т.е. приводить к конкретному результату.
- История должна помещаться в итерацию.
Summary: юстории помогут вам более чётко понимать зачем вы делаете ту или иную фичу, потому что ваш продукт должен решать пользовательскую задачу или проблему. Выработать US можно с помощью брейншторма или CJM.
#product_dump @pm_dump
Сеть оценок для планирования в Scrum.
Story points — это относительные оценки объёма работы в истории. Но SP всегда сравниваются с другими историями и существуют относительно друг друга - это проблема любой команды и PM, в частности. По ходу проекта забывается что такое один story point из-за регулярной переоценки задач.
Предлагается решение “оценочная сетка” - это таблица, где на одной линии стоят задачи одного размера. Для размера используются числа Фибоначчи (½, 1, 2, 3, 5 etc.)
Совет: добавляйте на такую таблицу только “типичные” повторяемые задачи. Исключительные и редкие задачи там не нужны. И заносите туда задачи только после реализации (по факту).
Правило: 5 - это интервал от 3 до 5, если задача чуть больше 3 или чуть меньше 5, то это 5. В каждой линии 2-5 карточек для простоты (много не надо).
Рекомендация: не делать доску больше 8, т.к. история должна помещаться в спринт.
#project_dump @pm_dump
Story points — это относительные оценки объёма работы в истории. Но SP всегда сравниваются с другими историями и существуют относительно друг друга - это проблема любой команды и PM, в частности. По ходу проекта забывается что такое один story point из-за регулярной переоценки задач.
Предлагается решение “оценочная сетка” - это таблица, где на одной линии стоят задачи одного размера. Для размера используются числа Фибоначчи (½, 1, 2, 3, 5 etc.)
Совет: добавляйте на такую таблицу только “типичные” повторяемые задачи. Исключительные и редкие задачи там не нужны. И заносите туда задачи только после реализации (по факту).
Правило: 5 - это интервал от 3 до 5, если задача чуть больше 3 или чуть меньше 5, то это 5. В каждой линии 2-5 карточек для простоты (много не надо).
Рекомендация: не делать доску больше 8, т.к. история должна помещаться в спринт.
#project_dump @pm_dump
Сила CJM в продукте (видео).
Откуда брать user stories? Один из вариантов - Customer Journey Map (Experience Map)
Цель любого продукта - принести ценность пользователю через взаимодействие с вашим продуктом.
CJM - это техника визуализации процесса взаимодействия пользователя с вашим продуктом и оценки «суммы всех впечатлений» (=ценности)
Точка взаимодействия с юзером - это зона пересечения круга потребностей юзера и потребностей бизнеса.
Внутри CJM (примеры в pdf):
1. Цели пользователя (чего хочет добиться);
2. Цели бизнеса;
3. Критерии успеха, ожидания;
4. Процесс и действия пользователя;
5. Каналы;
6. Проблемы и барьеры;
7. Моменты истины (MoT: Moments of Magic, Moments of Madness);
8. Эмоции, настроение, цитаты;
9. Степень критичности и приоритет;
10. Идеи и улучшения.
«Сила» Experience Map:
- Комплексный и непрерывный UX;
- Поиск проблемных точек взаимодействия;
- Лояльность пользователей;
- Ответственность и вовлеченность команды;
- Повышение качества разработки;
- Новое и уникальное взаимодействие.
Бонус трек:
1. Крутой сервис с шаблонами - UXPressia
2. PDF презентация
3. “Как использовать конкурента для экспоненциального роста” - видео, 11:25
#product_dump @pm_dump
Откуда брать user stories? Один из вариантов - Customer Journey Map (Experience Map)
Цель любого продукта - принести ценность пользователю через взаимодействие с вашим продуктом.
CJM - это техника визуализации процесса взаимодействия пользователя с вашим продуктом и оценки «суммы всех впечатлений» (=ценности)
Точка взаимодействия с юзером - это зона пересечения круга потребностей юзера и потребностей бизнеса.
Внутри CJM (примеры в pdf):
1. Цели пользователя (чего хочет добиться);
2. Цели бизнеса;
3. Критерии успеха, ожидания;
4. Процесс и действия пользователя;
5. Каналы;
6. Проблемы и барьеры;
7. Моменты истины (MoT: Moments of Magic, Moments of Madness);
8. Эмоции, настроение, цитаты;
9. Степень критичности и приоритет;
10. Идеи и улучшения.
«Сила» Experience Map:
- Комплексный и непрерывный UX;
- Поиск проблемных точек взаимодействия;
- Лояльность пользователей;
- Ответственность и вовлеченность команды;
- Повышение качества разработки;
- Новое и уникальное взаимодействие.
Бонус трек:
1. Крутой сервис с шаблонами - UXPressia
2. PDF презентация
3. “Как использовать конкурента для экспоненциального роста” - видео, 11:25
#product_dump @pm_dump
Retention rate. Как создавать продукты, формирующие привычки?
Retention rate — одна из ключевых метрик любого продукта, потому что именно она определяет потенциал роста вашего бизнеса, а также влияет на монетизационные метрики.
Пояснение: Если Retention вашего сервиса на день N составляет k%, то это означает, что если в день 0 к вам пришла группа новых пользователей, то k% из их воспользуются сервисом на день N.
Грубый ориентир хорошего Retention (для mobile app):
- R.1 дня ~50%
- R. 7 дня ~25-30%
- R. 30 дня ~10-15%
При важности ретеншена не стоит забывать, что ключевые метрики для большинства продуктов - это CAC (Стоимость привлечения клиента) и LTV (Доход с клиента за все время).
Retention - по сути привычка. А для привычки нужно действие, которое должно выполняться часто. Результат действия должен приносить удовлетворение (минус проблема/кайф).
Ниже фреймворк повышения Retention, который позволяет посмотреть на продукты в контексте их способности формировать привычки у людей. В этой модели привычка появляется после многократного прохождения шагов:
- Триггер (внешний/внутренний). Без внутреннего не будет привычки.
- Действие. Максимально облегчаем этот этап (вкл. онбординг).
- Награда. Значимые переменные награды работают лучше (мб азарт).
- Инвестиция
- Перезапуск цикла (важный этап).
Типы наград:
- Социальные (ты молодец)
- Трофеи (найден крутой пост в фб)
- Внутренние (пустой TODO лист напр.)
Типы инвестиций:
- Накапливаемая ценность. Dropbox - сохраненные файлы.
- Скилл. Разобрался и умеешь.
- Вложенные усилия.
Напоследок: это лишь фреймворк и любой элемент нужно тестировать на конкретном продукте. Не всё на 100% будет работать.
Бонус трек:
- Статья написана по книге Нира Эйаля «Hooked: How to Build Habit-Forming Products»
- В конце статьи вопросы, чтобы применить фреймворк к вашему продукту.
#product_dump @pm_dump
Retention rate — одна из ключевых метрик любого продукта, потому что именно она определяет потенциал роста вашего бизнеса, а также влияет на монетизационные метрики.
Пояснение: Если Retention вашего сервиса на день N составляет k%, то это означает, что если в день 0 к вам пришла группа новых пользователей, то k% из их воспользуются сервисом на день N.
Грубый ориентир хорошего Retention (для mobile app):
- R.1 дня ~50%
- R. 7 дня ~25-30%
- R. 30 дня ~10-15%
При важности ретеншена не стоит забывать, что ключевые метрики для большинства продуктов - это CAC (Стоимость привлечения клиента) и LTV (Доход с клиента за все время).
Retention - по сути привычка. А для привычки нужно действие, которое должно выполняться часто. Результат действия должен приносить удовлетворение (минус проблема/кайф).
Ниже фреймворк повышения Retention, который позволяет посмотреть на продукты в контексте их способности формировать привычки у людей. В этой модели привычка появляется после многократного прохождения шагов:
- Триггер (внешний/внутренний). Без внутреннего не будет привычки.
- Действие. Максимально облегчаем этот этап (вкл. онбординг).
- Награда. Значимые переменные награды работают лучше (мб азарт).
- Инвестиция
- Перезапуск цикла (важный этап).
Типы наград:
- Социальные (ты молодец)
- Трофеи (найден крутой пост в фб)
- Внутренние (пустой TODO лист напр.)
Типы инвестиций:
- Накапливаемая ценность. Dropbox - сохраненные файлы.
- Скилл. Разобрался и умеешь.
- Вложенные усилия.
Напоследок: это лишь фреймворк и любой элемент нужно тестировать на конкретном продукте. Не всё на 100% будет работать.
Бонус трек:
- Статья написана по книге Нира Эйаля «Hooked: How to Build Habit-Forming Products»
- В конце статьи вопросы, чтобы применить фреймворк к вашему продукту.
#product_dump @pm_dump
Как собрать отзывы о продукте на запуске. CustDev.
💀 Главная причина смерти стартапов (42%) — разработанный ими продукт или услуга оказываются не нужны потребителю. Надо говорить с потребителем.
🕵️ Продуктовое исследование начинается с одного из двух типов гипотез:
- Гипотеза проблемы. Ищем людей, у которых проблема есть (чего им еще не хватает и т.д).
- Гипотеза аудитории. Знаем аудиторию и ищем у нее проблемы.
⏰ Аудитория должна столкнуться с проблемой в период от 1-2 месяцев до 1 года в зависимости от глобальности или редкости проблемы.
💰Глубинное интервью (по мнению автора) длится не менее 1,5 часов. И платить за него нельзя.
📝 По новым продуктам спрашивайте по этим блокам:
- когда и почему возникает проблема/потребность;
- где ищут информацию/решения;
- как выбирают решение;
- сколько времени и денег тратят;
- опыт использования текущего решения (продукта/сервиса);
- люди, участвующие в процессе;
- артефакты (какие документы необходимы клиенту для решения его проблемы: чек, банковский договор, страховой полис и т. д.).
‼️Три правила:
- Только текущий или прошлый опыт. Не знакомых даже.
- Только открытые вопросы.
- Не думать решениями.
На один сегмент ЦА нужно не менее 5-8 интервью. Если кто-то сильно отличается от остальных, то это новый сегмент, ищите похожих.
Прекращайте брать интервью только если перестанете получать новую информацию - это самый верный признак.
🎁 Бонус трек:
- Подборка прощальных писем стартапов перед закрытием
- ТОП-20 причин провалов стартапов (CBInsights)
#product_dump @pm_dump
💀 Главная причина смерти стартапов (42%) — разработанный ими продукт или услуга оказываются не нужны потребителю. Надо говорить с потребителем.
🕵️ Продуктовое исследование начинается с одного из двух типов гипотез:
- Гипотеза проблемы. Ищем людей, у которых проблема есть (чего им еще не хватает и т.д).
- Гипотеза аудитории. Знаем аудиторию и ищем у нее проблемы.
⏰ Аудитория должна столкнуться с проблемой в период от 1-2 месяцев до 1 года в зависимости от глобальности или редкости проблемы.
💰Глубинное интервью (по мнению автора) длится не менее 1,5 часов. И платить за него нельзя.
📝 По новым продуктам спрашивайте по этим блокам:
- когда и почему возникает проблема/потребность;
- где ищут информацию/решения;
- как выбирают решение;
- сколько времени и денег тратят;
- опыт использования текущего решения (продукта/сервиса);
- люди, участвующие в процессе;
- артефакты (какие документы необходимы клиенту для решения его проблемы: чек, банковский договор, страховой полис и т. д.).
‼️Три правила:
- Только текущий или прошлый опыт. Не знакомых даже.
- Только открытые вопросы.
- Не думать решениями.
На один сегмент ЦА нужно не менее 5-8 интервью. Если кто-то сильно отличается от остальных, то это новый сегмент, ищите похожих.
Прекращайте брать интервью только если перестанете получать новую информацию - это самый верный признак.
🎁 Бонус трек:
- Подборка прощальных писем стартапов перед закрытием
- ТОП-20 причин провалов стартапов (CBInsights)
#product_dump @pm_dump
Стоимость привлечения клиента (перевод статьи Девида Скока)
🔷 В предыдущем посте было про №1 причину смерти стартапов.
// В целом самые важные факторы для продукта/бизнеса - это команда, продукт и рынок.
🔷 В этом будет про №2 - Стоимость привлечения клиентов оказывается выше, чем ожидалось, и превышает доход с клиента.
- CAC (Cost to Acquire Customers) - важно считать от всех затрат, включая зарплату, аренду офиса и разработку (опционально).
- LTV (Lifetime Value of a Customer) - надо считать через все выплаты вашего клиента, в том числе на поддержку, установку и обслуживание.
🔷 Правила для этих метрик:
1. LTV > 3* CAC (это для жизнеспособности компании, продающей ПО как сервис или работающей по любой другой модели с повторяющимися продажами. У большинства публичных компаний отношение LTV / CAC равно примерно 5)
2. Время до возврата CAC со ср.клиента должно составлять меньше 6 месяцев (Иначе ваш бизнес потребует больших вложений для роста)
3. Диаграмма про баланс LTV и CAC
🔷 Уровень конверсии всего потока в покупателей (платящий пользователь) имеет очень важную роль в формировании стоимости привлечения клиента. Замеряйте этот параметр, тестируйте и влияйте на него.
🔘 Summary: во множестве статей советуют на чём нужно сосредоточиться продукту и чаще всего это Market Fit.
На самом деле нужно смотреть на всю картину целиком и не забывать про баланс категорий в вашем P&L (бизнес-модели).
#product_dump @pm_dump
🔷 В предыдущем посте было про №1 причину смерти стартапов.
// В целом самые важные факторы для продукта/бизнеса - это команда, продукт и рынок.
🔷 В этом будет про №2 - Стоимость привлечения клиентов оказывается выше, чем ожидалось, и превышает доход с клиента.
- CAC (Cost to Acquire Customers) - важно считать от всех затрат, включая зарплату, аренду офиса и разработку (опционально).
- LTV (Lifetime Value of a Customer) - надо считать через все выплаты вашего клиента, в том числе на поддержку, установку и обслуживание.
🔷 Правила для этих метрик:
1. LTV > 3* CAC (это для жизнеспособности компании, продающей ПО как сервис или работающей по любой другой модели с повторяющимися продажами. У большинства публичных компаний отношение LTV / CAC равно примерно 5)
2. Время до возврата CAC со ср.клиента должно составлять меньше 6 месяцев (Иначе ваш бизнес потребует больших вложений для роста)
3. Диаграмма про баланс LTV и CAC
🔷 Уровень конверсии всего потока в покупателей (платящий пользователь) имеет очень важную роль в формировании стоимости привлечения клиента. Замеряйте этот параметр, тестируйте и влияйте на него.
🔘 Summary: во множестве статей советуют на чём нужно сосредоточиться продукту и чаще всего это Market Fit.
На самом деле нужно смотреть на всю картину целиком и не забывать про баланс категорий в вашем P&L (бизнес-модели).
#product_dump @pm_dump
Чем занимается продакт менеджер? Или “Про принятие продуктовых решений”
🔷 PdM должен гарантировать, что в команде принимаются лучшие на данный момент решения. Всё остальное лишь инструмент для достижения этой цели.
‼️это тактика на каждый день, а не стратегическая цель.
Решения принимает команда, но продакт ответственный. От этого три задачи:
1️⃣ Дизайн процессов и взаимосвязей. Обеспечивать центру экспертизы нужное кол-во информации (разработка, дизайн), обеспечивать движение к стратегическим целям.
2️⃣ Оценка степени важности принимаемых решений. От этого зависят ресурсы на сбор информации, а также инструменты для принятия решений.
3️⃣ Выделять ресурсы и использовать инструменты, исходя из степени важности.
Цель не “всегда принимать правильное решение”, а “инвестировать правильное количество времени в принятие решения относительно его важности”. Вы никогда не будете на 100% уверены, не тратьте деньги и время на избыточные исследования и анализ.
Джеф Безос: Если вы уверены более чем на 70%, значит, вы принимаете это решение слишком поздно // не воспринимать буквально
P.S. Профессии PdM в РФ всего лет 6-7. Стандарта нет и все заметки лишь мнения отдельных специалистов. В их контексте они правы, но в другой компании может и нет.
Бонус трек: Функционал PdM зависит от размера команды (№2)
#product_dump @pm_dump
🔷 PdM должен гарантировать, что в команде принимаются лучшие на данный момент решения. Всё остальное лишь инструмент для достижения этой цели.
‼️это тактика на каждый день, а не стратегическая цель.
Решения принимает команда, но продакт ответственный. От этого три задачи:
1️⃣ Дизайн процессов и взаимосвязей. Обеспечивать центру экспертизы нужное кол-во информации (разработка, дизайн), обеспечивать движение к стратегическим целям.
2️⃣ Оценка степени важности принимаемых решений. От этого зависят ресурсы на сбор информации, а также инструменты для принятия решений.
3️⃣ Выделять ресурсы и использовать инструменты, исходя из степени важности.
Цель не “всегда принимать правильное решение”, а “инвестировать правильное количество времени в принятие решения относительно его важности”. Вы никогда не будете на 100% уверены, не тратьте деньги и время на избыточные исследования и анализ.
Джеф Безос: Если вы уверены более чем на 70%, значит, вы принимаете это решение слишком поздно // не воспринимать буквально
P.S. Профессии PdM в РФ всего лет 6-7. Стандарта нет и все заметки лишь мнения отдельных специалистов. В их контексте они правы, но в другой компании может и нет.
Бонус трек: Функционал PdM зависит от размера команды (№2)
#product_dump @pm_dump
Какими навыками должен обладать менеджер продукта?
🔷 Спойлер: никто не знает / везде по-разному
🔷 Если ещё не работаешь на позиции PdM, но активно лежишь в этом направлении, то нужно понимать, в каком направление развиваться и в какой системе координат.
Данная таблица - попытка составить для себя карту компетенций на основе открытых источников.
🙏 Карта составлена составлена без участия, но благодаря Юре Агееву (@wert1go, Конференция MakeSense), Валерии Коваленко, Нетологии, ВШБИ (ВШЭ), Product Star. Вакансии сознательно не анализировались.
📥 Обратная связь по таблице горячо приветствуется. Контакты cверху.
🔷 Summary:
Продакт работает на пересечении четырех сфер -> Команда, Бизнес, UX, Технологии
1️⃣ Команда - коммуникация и управление коллективом
2️⃣ Бизнес - прибыль, стратегия, миссия
3️⃣ UX - доставленная ценность, полноценность
4️⃣ Технологии - средство донесения ценности, каркас продукта, осуществимость
P.S. Карта компетенций будет дополняться по мере появления новой информации.
🔷 Бонус трек:
- Крутой PM в трех пунктах
- Чем занимается продакт? Мнение
- 10 важных навыков хорошего PM
- Функционал PdM в компаниях разного размера (п.6-8)
#product_dump @pm_dump
🔷 Спойлер: никто не знает / везде по-разному
🔷 Если ещё не работаешь на позиции PdM, но активно лежишь в этом направлении, то нужно понимать, в каком направление развиваться и в какой системе координат.
Данная таблица - попытка составить для себя карту компетенций на основе открытых источников.
🙏 Карта составлена составлена без участия, но благодаря Юре Агееву (@wert1go, Конференция MakeSense), Валерии Коваленко, Нетологии, ВШБИ (ВШЭ), Product Star. Вакансии сознательно не анализировались.
📥 Обратная связь по таблице горячо приветствуется. Контакты cверху.
🔷 Summary:
Продакт работает на пересечении четырех сфер -> Команда, Бизнес, UX, Технологии
1️⃣ Команда - коммуникация и управление коллективом
2️⃣ Бизнес - прибыль, стратегия, миссия
3️⃣ UX - доставленная ценность, полноценность
4️⃣ Технологии - средство донесения ценности, каркас продукта, осуществимость
P.S. Карта компетенций будет дополняться по мере появления новой информации.
🔷 Бонус трек:
- Крутой PM в трех пунктах
- Чем занимается продакт? Мнение
- 10 важных навыков хорошего PM
- Функционал PdM в компаниях разного размера (п.6-8)
#product_dump @pm_dump
Онбординг цифровых продуктов. Что это?
🔷 Onboarding – это процесс обучения пользователя, встроенный в продукт.
🔷 Задача онбординга: улучшить первый опыт взаимодействия пользователя с продуктом.
Виды онбординга:
1️⃣ Обучающие экраны
“С порога” рассказываем о ценности, но тут всё без разбора, да и еще и ставим барьер между продуктом и пользователем.
Реко: Коротко и не более 5 экранов. Пропускаемый.
2️⃣ Сегментированный онбординг
Персонализированный подход, но затратный. Можно облажаться с сегментированием - будет фиаско.
3️⃣ Welcome письма
Дешево и гибко, но низкое вовлечение и информативность.
Реко: Это доп.инструмент к онбордингу, где возможна крутая сегментация и сценарии.
4️⃣ Обучающие видео
Высокое вовлечение, но затратно.
Реко: Не более 2х минут, субтитры, (!) только суть.
5️⃣ Контекстные подсказки
Обучение в контексте, которое поможет продвинуть пользователей дальше по сценарию (узкие места). Нужно потратить много сил на изучение сценариев, но отрисовать будет просто.
6️⃣ Пустые экраны
Не перекрывают контекст (в отличии от п.5). Делаем коротко, по делу, не забываем про call to action.
7️⃣ Демосущности
Наглядно показывает результат, но требует много ресурсов на анализ.
8️⃣ Геймификация
Юзеры сильно вовлекаются и “инвестируют” в продукт, но сложно прорабатывается.
9️⃣ Немодальные подсказки
Отдельные интерактивные элементы интерфейса, которые обучают пользователей и не прерывают сценарии. Нажал и сразу понятно как это работает.
🔷 Summary: в онбординге есть две сущности - “рассказ” и “пример”. Добавляем к ним сценарии / сегментации ЦА и получаем подходящий онбординг для вашего продукта. Всё это при постоянном тестировании и улучшении, конечно.
#product_dump @pm_dump
🔷 Onboarding – это процесс обучения пользователя, встроенный в продукт.
🔷 Задача онбординга: улучшить первый опыт взаимодействия пользователя с продуктом.
Виды онбординга:
1️⃣ Обучающие экраны
“С порога” рассказываем о ценности, но тут всё без разбора, да и еще и ставим барьер между продуктом и пользователем.
Реко: Коротко и не более 5 экранов. Пропускаемый.
2️⃣ Сегментированный онбординг
Персонализированный подход, но затратный. Можно облажаться с сегментированием - будет фиаско.
3️⃣ Welcome письма
Дешево и гибко, но низкое вовлечение и информативность.
Реко: Это доп.инструмент к онбордингу, где возможна крутая сегментация и сценарии.
4️⃣ Обучающие видео
Высокое вовлечение, но затратно.
Реко: Не более 2х минут, субтитры, (!) только суть.
5️⃣ Контекстные подсказки
Обучение в контексте, которое поможет продвинуть пользователей дальше по сценарию (узкие места). Нужно потратить много сил на изучение сценариев, но отрисовать будет просто.
6️⃣ Пустые экраны
Не перекрывают контекст (в отличии от п.5). Делаем коротко, по делу, не забываем про call to action.
7️⃣ Демосущности
Наглядно показывает результат, но требует много ресурсов на анализ.
8️⃣ Геймификация
Юзеры сильно вовлекаются и “инвестируют” в продукт, но сложно прорабатывается.
9️⃣ Немодальные подсказки
Отдельные интерактивные элементы интерфейса, которые обучают пользователей и не прерывают сценарии. Нажал и сразу понятно как это работает.
🔷 Summary: в онбординге есть две сущности - “рассказ” и “пример”. Добавляем к ним сценарии / сегментации ЦА и получаем подходящий онбординг для вашего продукта. Всё это при постоянном тестировании и улучшении, конечно.
#product_dump @pm_dump
Свалка продакта
Короткая выжимка из выжимки Артёма Астапова про make sense Минск. 1. Dogfooding - пользуйтесь своим продуктом сами и по-настоящему. 2. Фреймворк Jobs To Be Done 3. Чтобы ввести продакта в курс дела максимально быстро и хардкорно, ему нужно поработать 2-3 дня…
Продолжение выжимок с конференции "Product Sense" В Минске'18
1️⃣ Михаила Трутнева, Chief Operation Officer в Ultimate Guitar
О своих ошибках управления командами
2️⃣ Анны Бояркиной, Head of Product в RealtimeBoard
Про стратегию развития продуктовой компании и о формировании культуры.
3️⃣ Дмитрия Твердохлебова, Head of Mobile Product в SaveForm
Об онбординг процессе и специфике разных стран (USA & UK, Spain & Italy, Mexica & Australia, India, Germany, China).
4️⃣ Игоря Соколова, Product Manager в Grammarly
Про Frictionless - как основу продуктовой стратегии.
5️⃣ Светланы Аюповой, Product Manager из Netology
О том, как классному продукту расти, если клиенты не могут осознать его ценность.
❗️ Руслан Дороничев очень кратко и по делу резюмировал доклады. П - польза!
#product_dump @pm_dump
1️⃣ Михаила Трутнева, Chief Operation Officer в Ultimate Guitar
О своих ошибках управления командами
2️⃣ Анны Бояркиной, Head of Product в RealtimeBoard
Про стратегию развития продуктовой компании и о формировании культуры.
3️⃣ Дмитрия Твердохлебова, Head of Mobile Product в SaveForm
Об онбординг процессе и специфике разных стран (USA & UK, Spain & Italy, Mexica & Australia, India, Germany, China).
4️⃣ Игоря Соколова, Product Manager в Grammarly
Про Frictionless - как основу продуктовой стратегии.
5️⃣ Светланы Аюповой, Product Manager из Netology
О том, как классному продукту расти, если клиенты не могут осознать его ценность.
❗️ Руслан Дороничев очень кратко и по делу резюмировал доклады. П - польза!
#product_dump @pm_dump
Новая рубрика: "Чистим закладки"
🔘 UX Project Checklist - Чеклист забрал себе в программу Харвард!
🔘 Animista - Шаблоны CSS анимаций
🔘 Readability - Проверка читабельности текста (UX же)
🔘 Pttrns - Огромная библиотека для проектирования mobile
🔘 UX Crash Course - Ускоренный курс UX, посвященный психологии пользователя
🎁 Бонус трек:
История всех продуктов акселератора YCombinator - будто учебник истории прочитать. Источник
#naked_links @pm_dump
про дизайн🔘 Laws of UX - Ресурс посвящён десяти законам UX-дизайна
🔘 UX Project Checklist - Чеклист забрал себе в программу Харвард!
🔘 Animista - Шаблоны CSS анимаций
🔘 Readability - Проверка читабельности текста (UX же)
🔘 Pttrns - Огромная библиотека для проектирования mobile
🔘 UX Crash Course - Ускоренный курс UX, посвященный психологии пользователя
🎁 Бонус трек:
История всех продуктов акселератора YCombinator - будто учебник истории прочитать. Источник
#naked_links @pm_dump
Когортный анализ. Метрики продукта vs метрики роста
🔷 Метрики роста: DAU, MAU, доход, общее количество регистраций etc.
- За ними полезно следить для общего понимания ситуации, но в работе над продуктом они бесполезны
- Невозможно отличить влияние изменений в продукте и маркетинга на эти метрики.
🔷Идея когортного анализа состоит в том, чтобы разделить пользователей на группы по определенным признакам, и отслеживать поведение этих групп во времени
И в ней всё хорошо, кроме того, что она очень высокоуровневая. Из-за этого влиять на нее сложно, потому что непонятно как.
- активация в приложении
- активность использования
- долгосрочный retention (месяц, два и далее)
🔷 Пример метрик монетизации:
- активация в приложении
- увидел продающий экран
- совершил 1 покупку (вторую, N-ную и ср. количество повторных покупок)
📝 Summary: Сравниваем CAC и LTV как метрику успешности и прибыльности продукта. Влияем на это соотношение через метрики, полученные после декомпозиции LTV (напр., успешный онбординг)
🎁 Бонус трек:
- Для когортного анализа в моб.приложениях идеально подходят - Mixpanel и Localytics
#product_dump @pm_dump
🔷 Метрики роста: DAU, MAU, доход, общее количество регистраций etc.
- За ними полезно следить для общего понимания ситуации, но в работе над продуктом они бесполезны
- Невозможно отличить влияние изменений в продукте и маркетинга на эти метрики.
🔷Идея когортного анализа состоит в том, чтобы разделить пользователей на группы по определенным признакам, и отслеживать поведение этих групп во времени
Ведь вашим продуктом в конкретный день пользуются новые, вернувшиеся и очень давние пользователи🔷 LTV - ключевая метрика для PdM, отражающая ценность продукта для потребителей.
И в ней всё хорошо, кроме того, что она очень высокоуровневая. Из-за этого влиять на нее сложно, потому что непонятно как.
Декомпозируем LTV на важные для продукта метрики (ниже примеры, это метрики продукта) и влияем через них.🔷 Пример метрик вовлеченности:
- активация в приложении
- активность использования
- долгосрочный retention (месяц, два и далее)
🔷 Пример метрик монетизации:
- активация в приложении
- увидел продающий экран
- совершил 1 покупку (вторую, N-ную и ср. количество повторных покупок)
📝 Summary: Сравниваем CAC и LTV как метрику успешности и прибыльности продукта. Влияем на это соотношение через метрики, полученные после декомпозиции LTV (напр., успешный онбординг)
🎁 Бонус трек:
- Для когортного анализа в моб.приложениях идеально подходят - Mixpanel и Localytics
#product_dump @pm_dump
“Пример как выглядит когортный анализ”
Две итерации по улучшению % прохождения туториала помогло сравнять CAC и LTV.
Две итерации по улучшению % прохождения туториала помогло сравнять CAC и LTV.
На CAC влияла команда по привлечению трафика#product_dump @pm_dump
Как выбрать правильные метрики для продукта ч.1 (HEART)
🔷 В Google Ventures для оценки UX используют следующие фреймворки:
- HEART для качества user experience
- Цели-Сигналы-Метрики для целей продукта или проекта (ч.2)
🔷 Помните про data-informed design — это когда “рулит” все еще дизайнер, а не данные (=data-driven).
- Всё ДО использования продукта - это сфера продуктового маркетинга. Это про эмоции, бренд и историю
- ВО ВРЕМЯ использования продукта - это сам продукт. Это про ценность, пользу
- Гипотеза внутри продукта - это проект (~фича)
🔷 H - Happiness
Это отношение user’а к продукту, которое часто замеряется через опросы. Но в продуктах концепт “счастья” часто бесполезен, лучше заменить его на пользовательскую ценность. Про донесение ценности при первом визите в посте про онбординг.
Это метрика успешности проекта. Ответ на вопрос “продолжают ли пользователи получать ценность?”
🔷 A - Adoption
Это метрика на стыке маркетинга и продукта, т.к. говорит о количестве новых пользователей/регистраций и т.д.
🔷 R - retention (большой пост про retention)
Это одна из важнейших продуктовых метрик❗️ По опыту автора именно retention + engagement определяли успех продукта или фичи.
🔷 T - Task success
Это метрики в части продукта, где работа идёт на выполнения конкретной пользовательской задачи (поиск или загрузка). Лучше относить эти метрики к части “здоровья продукта” и считать их техническими, нежеле продуктовыми (автор).
🔷 Примеры:
Happiness - удовлетворение, воспринимаемая легкость использования и NPS
Engagement - частота, интенсивность и глубина взаимодействия за период
Adoption - количество аккаунтов, созданных за последние 7 дней, или процент пользователей Gmail, которые используют лейблы
Retention - процент пользователей, возвращающихся в продукт в момент времени
Task Success - оперативность (пример — время на выполнение задания), эффективность (процент выполненных заданий) и процент ошибок
🔷 Необязательно создавать метрики во всех из этих категорий — вы можете выбрать только те, которые наиболее важны для вашего проекта. Фреймворк HEART может помочь вам решить, какая из категорий вам нужна.
🎁 Бонус трек (aka. “Чистим закладки”):
- Stack Share - Стэк ПО топовых компаний и сравнение инструментов
- Догадливый интерфейс - Готовые приёмы, инструменты и наборы данных для автозаполнения данных о пользователе
- Кто такой продакт менеджер? Чем он отличается от проджекта и продакт оунера? (презентация + пост с картой компетенций)
#product_dump @pm_dump
🔷 В Google Ventures для оценки UX используют следующие фреймворки:
- HEART для качества user experience
- Цели-Сигналы-Метрики для целей продукта или проекта (ч.2)
🔷 Помните про data-informed design — это когда “рулит” все еще дизайнер, а не данные (=data-driven).
Сначала стратегия и цели, затем метрики. Сначала гипотеза и цели, затем эксперимент.🔷 В данной статье принимаются следующие тезисы:
- Всё ДО использования продукта - это сфера продуктового маркетинга. Это про эмоции, бренд и историю
- ВО ВРЕМЯ использования продукта - это сам продукт. Это про ценность, пользу
- Гипотеза внутри продукта - это проект (~фича)
🔷 H - Happiness
Это отношение user’а к продукту, которое часто замеряется через опросы. Но в продуктах концепт “счастья” часто бесполезен, лучше заменить его на пользовательскую ценность. Про донесение ценности при первом визите в посте про онбординг.
❗️ Как определить ценность? Идите от обратного: спросите себя — если мы представим идеального пользователя, который получает максимальную пользу от продукта, что он делает? И получите ответ.🔷 E - Engagement
Это метрика успешности проекта. Ответ на вопрос “продолжают ли пользователи получать ценность?”
🔷 A - Adoption
Это метрика на стыке маркетинга и продукта, т.к. говорит о количестве новых пользователей/регистраций и т.д.
🔷 R - retention (большой пост про retention)
Это одна из важнейших продуктовых метрик❗️ По опыту автора именно retention + engagement определяли успех продукта или фичи.
🔷 T - Task success
Это метрики в части продукта, где работа идёт на выполнения конкретной пользовательской задачи (поиск или загрузка). Лучше относить эти метрики к части “здоровья продукта” и считать их техническими, нежеле продуктовыми (автор).
🔷 Примеры:
Happiness - удовлетворение, воспринимаемая легкость использования и NPS
Engagement - частота, интенсивность и глубина взаимодействия за период
Adoption - количество аккаунтов, созданных за последние 7 дней, или процент пользователей Gmail, которые используют лейблы
Retention - процент пользователей, возвращающихся в продукт в момент времени
Task Success - оперативность (пример — время на выполнение задания), эффективность (процент выполненных заданий) и процент ошибок
🔷 Необязательно создавать метрики во всех из этих категорий — вы можете выбрать только те, которые наиболее важны для вашего проекта. Фреймворк HEART может помочь вам решить, какая из категорий вам нужна.
🎁 Бонус трек (aka. “Чистим закладки”):
- Stack Share - Стэк ПО топовых компаний и сравнение инструментов
- Догадливый интерфейс - Готовые приёмы, инструменты и наборы данных для автозаполнения данных о пользователе
- Кто такой продакт менеджер? Чем он отличается от проджекта и продакт оунера? (презентация + пост с картой компетенций)
#product_dump @pm_dump
Как выбрать правильные метрики для продукта ч.2 (Цели-Сигналы-Метрики)
🔷 Сейчас поговорим как прийти от категорий HEART к конкретным метрикам.
🔷 Цели
Сначала определяем цели, а метрики уже должны говорить о прогрессе по достижению этих целей
Если определить цели трудно, обращаемся к категориям HEART.
🔷 Сигналы
Привязываем цели к более низкоуровневым сигналам. Они должны говорить об успехе или провале цели.
- Пример: провал в Task Success может быть поисковый запрос без единого клика на результат.
- Требования: сигналы протестированы, легко/возможно измерять, сигналы чувствительны к изменениям.
🔷 Метрики
Уточняем сигналы и превращаем в метрики. Всех кандидатов на метрики анализируем и отбираем самые “говорящие и полезные”.
- Пример: сигнал (как долго юзеры смотрят видео на YT) -> метрика (ср. кол-во минут на просмотр видео у ср. пользователя в день).
🔷 Summary
Весь процесс Ц-С-М должен привести к приоритезации метрик. Не засоряйте дашборд лишним, помните про цели продукта.
🎁 Бонус трек:
- Cute Isometric Objects For Your Design
- Appfollow Benchmark - срез рынка моб. приложений по конверсии из показа/просмотра в установку
#product_dump @pm_dump
🔷 Сейчас поговорим как прийти от категорий HEART к конкретным метрикам.
🔷 Цели
Сначала определяем цели, а метрики уже должны говорить о прогрессе по достижению этих целей
(вспоминаем data-informed design).Если определить цели трудно, обращаемся к категориям HEART.
🔷 Сигналы
Привязываем цели к более низкоуровневым сигналам. Они должны говорить об успехе или провале цели.
- Пример: провал в Task Success может быть поисковый запрос без единого клика на результат.
- Требования: сигналы протестированы, легко/возможно измерять, сигналы чувствительны к изменениям.
🔷 Метрики
Уточняем сигналы и превращаем в метрики. Всех кандидатов на метрики анализируем и отбираем самые “говорящие и полезные”.
- Пример: сигнал (как долго юзеры смотрят видео на YT) -> метрика (ср. кол-во минут на просмотр видео у ср. пользователя в день).
🔷 Summary
Весь процесс Ц-С-М должен привести к приоритезации метрик. Не засоряйте дашборд лишним, помните про цели продукта.
🎁 Бонус трек:
- Cute Isometric Objects For Your Design
- Appfollow Benchmark - срез рынка моб. приложений по конверсии из показа/просмотра в установку
#product_dump @pm_dump