Что значит быть крутым проект-менеджером
На английском (full version)
1. Главные обязанности ПМ: Стратегия. Менеджмент (время). Руководство (коммуникации).
2. 3 качества успешного ПМ-а: Любовь к знаниям, Широкий кругозор, Преодоление ограничений.
3. ПМ стоит на пересечении трех компетенций: Технологии (осуществимость), Бизнес, UX.
#product_dump @pm_dump
На английском (full version)
1. Главные обязанности ПМ: Стратегия. Менеджмент (время). Руководство (коммуникации).
2. 3 качества успешного ПМ-а: Любовь к знаниям, Широкий кругозор, Преодоление ограничений.
3. ПМ стоит на пересечении трех компетенций: Технологии (осуществимость), Бизнес, UX.
#product_dump @pm_dump
Короткая выжимка из выжимки Артёма Астапова про make sense Минск.
1. Dogfooding - пользуйтесь своим продуктом сами и по-настоящему.
2. Фреймворк Jobs To Be Done
3. Чтобы ввести продакта в курс дела максимально быстро и хардкорно, ему нужно поработать 2-3 дня в саппорте, провести 15 интервью, много следить за вебвизором, расписать краткосрочные и долгосрочные цели в продукте.
4. Чтобы потестить запрос фичи - можно сделать фейковые кнопки, по нажатию на которую будет предупреждение, что сейчас сервис недоступен, но с вами свяжется менеджер и поможет
5. Точность - стратегия микрониши. Нужно выбрать самые важные 10% функционала.
6. Для стартапа супер продакт: кодит продукт, сам общается с юзерами, думает о смысле и пользе, а не о инструментах.
7. В команде из 20 человек хороший продакт: мотивирует сотрудников, находит лучших специалистов, делегирует задачи.
8. В компании из 200 человек хороший СРО: создал корп культуру, написал миссию и принципы компании, инструменты - jira.
#product_dump @pm_dump
1. Dogfooding - пользуйтесь своим продуктом сами и по-настоящему.
2. Фреймворк Jobs To Be Done
3. Чтобы ввести продакта в курс дела максимально быстро и хардкорно, ему нужно поработать 2-3 дня в саппорте, провести 15 интервью, много следить за вебвизором, расписать краткосрочные и долгосрочные цели в продукте.
4. Чтобы потестить запрос фичи - можно сделать фейковые кнопки, по нажатию на которую будет предупреждение, что сейчас сервис недоступен, но с вами свяжется менеджер и поможет
5. Точность - стратегия микрониши. Нужно выбрать самые важные 10% функционала.
6. Для стартапа супер продакт: кодит продукт, сам общается с юзерами, думает о смысле и пользе, а не о инструментах.
7. В команде из 20 человек хороший продакт: мотивирует сотрудников, находит лучших специалистов, делегирует задачи.
8. В компании из 200 человек хороший СРО: создал корп культуру, написал миссию и принципы компании, инструменты - jira.
#product_dump @pm_dump
10 наиболее важных навыков хорошего проект-менеджера.
1. Знать, как проводить хорошие митинги. Оптимальное время - 30 минут.
2. Понимать код. Необязательно писать - надо понимать.Одна из основных проблем, с которой сталкивается ПМ — оценка времени на выполнение задач. Не понимая код, будет очень трудно поставить адекватные сроки.
3. Знать, как продавать свои идеи (разработчикам).Разработчики воплощают любую хорошую идею в жизнь. Они не просто «ресурс», они строители и хранители того, что придает жизнь проекту. “продажа идей команде” подробно прописана в предыдущей статье про приоритезацию.
4. Помогать другим. Четко понимай, что важно для компании. Хороший ПМ поддерживает и стимулирует сотрудников. Он не просто ставит задачи, а видит сильные стороны каждого человека и использует.
5. Четко понимать, о чем говорит статистика.
6. Часто контактировать с клиентами. Важно создать сильную клиентскую базу. Задача ПМ-а наладить тесную эмоциональную связь с клиентами. КастДев и всё такое. Регулярно общайся НЕ про продукт, а про жизнь. И никогда не спрашивай клиентов про будущее.
7. Уметь правильно подбирать слова.
8. Управлять своим временем. Пользуйтесь механизмами планирования времени.
9. Делегируй.
10. Не стесняться признаваться в том, что чего-то не знаете.
#project_dump @pm_dump
1. Знать, как проводить хорошие митинги. Оптимальное время - 30 минут.
2. Понимать код. Необязательно писать - надо понимать.Одна из основных проблем, с которой сталкивается ПМ — оценка времени на выполнение задач. Не понимая код, будет очень трудно поставить адекватные сроки.
3. Знать, как продавать свои идеи (разработчикам).Разработчики воплощают любую хорошую идею в жизнь. Они не просто «ресурс», они строители и хранители того, что придает жизнь проекту. “продажа идей команде” подробно прописана в предыдущей статье про приоритезацию.
4. Помогать другим. Четко понимай, что важно для компании. Хороший ПМ поддерживает и стимулирует сотрудников. Он не просто ставит задачи, а видит сильные стороны каждого человека и использует.
5. Четко понимать, о чем говорит статистика.
6. Часто контактировать с клиентами. Важно создать сильную клиентскую базу. Задача ПМ-а наладить тесную эмоциональную связь с клиентами. КастДев и всё такое. Регулярно общайся НЕ про продукт, а про жизнь. И никогда не спрашивай клиентов про будущее.
7. Уметь правильно подбирать слова.
8. Управлять своим временем. Пользуйтесь механизмами планирования времени.
9. Делегируй.
10. Не стесняться признаваться в том, что чего-то не знаете.
#project_dump @pm_dump
Как не сделать “какашку”? Личный опыт создания продукта.
Внутри подход Spotify по созданию продуктов: Think it, Build it, Ship it, Tweak it.
Think it - выясни, какой тип продукта мы разрабатываем и для чего.
Решаете нужен ли такой продукт. Вникаете в предметную область, определяете набор функционала для MVP и подготовите прототипы, проверите саму идею и находите первых бета-тестеров.
Результат этапа: Видение продукта, прототип.
Build it - создай минимально работоспособный продукт, готовый для реальных пользователей.
Переходим от бумажных прототипов в рабочим. Делаем только то, что поможет проверить гипотезы. Только те фичи, без которых не может существовать продукт.
Результат этапа: нарратив продукта (зачем и для кого он), MVP на реальных пользователей.
Ship It - постепенно предоставь 100% пользователей доступ к нему, измеряя параметры и улучшая продукт.
Постепенно расширяй аудиторию с 5-10% до 100% пользователей, улучшаясь итеративно.
Результат этапа: продукт выпущен на 100% пользователей и проверен.
Tweak it - Постоянно совершенствуй продукт. Это действительно окончательное состояние; продукт находится здесь, пока не будет закрыт или пересмотрен (= вернуться к Think It)
Результат этапа: продукт достиг локального максимума в выбранных метриках, выбрана новая цель для кратного улучшения (от think it и далее снова).
Теоретическая статья - обзор фреймворка.
#product_dump @pm_dump
Внутри подход Spotify по созданию продуктов: Think it, Build it, Ship it, Tweak it.
Think it - выясни, какой тип продукта мы разрабатываем и для чего.
Решаете нужен ли такой продукт. Вникаете в предметную область, определяете набор функционала для MVP и подготовите прототипы, проверите саму идею и находите первых бета-тестеров.
Результат этапа: Видение продукта, прототип.
Build it - создай минимально работоспособный продукт, готовый для реальных пользователей.
Переходим от бумажных прототипов в рабочим. Делаем только то, что поможет проверить гипотезы. Только те фичи, без которых не может существовать продукт.
Результат этапа: нарратив продукта (зачем и для кого он), MVP на реальных пользователей.
Ship It - постепенно предоставь 100% пользователей доступ к нему, измеряя параметры и улучшая продукт.
Постепенно расширяй аудиторию с 5-10% до 100% пользователей, улучшаясь итеративно.
Результат этапа: продукт выпущен на 100% пользователей и проверен.
Tweak it - Постоянно совершенствуй продукт. Это действительно окончательное состояние; продукт находится здесь, пока не будет закрыт или пересмотрен (= вернуться к Think It)
Результат этапа: продукт достиг локального максимума в выбранных метриках, выбрана новая цель для кратного улучшения (от think it и далее снова).
Теоретическая статья - обзор фреймворка.
#product_dump @pm_dump
Как перестать приоритизировать и начать жить. Эволюция продуктовых процессов
1. Что должен делать продакт-менеджер: тестировать продуктовые гипотезы, приоритизировать разработку, выпускать MVP на рынок как можно раньше, собирать фидбек, считать юнит-экономику, тестировать новые каналы и так далее.
2. В статье тестирование гипотез, канбан доски и выстроенные процессы. Очень полезно.
3. За рамками промо сервиса Kaiten описано как выстроить процесс от маленькой команды до большой компании, включая доски и подходы для real-time информирования акционеров по текущему прогрессу компании.
Summary: если правильно ограничить одновременное количество задач в работе, то высвободится время продакта на действительно важные процессы, способствующие кратному улучшению разрабатываемого продукта.
#product_dump @pm_dump
1. Что должен делать продакт-менеджер: тестировать продуктовые гипотезы, приоритизировать разработку, выпускать MVP на рынок как можно раньше, собирать фидбек, считать юнит-экономику, тестировать новые каналы и так далее.
2. В статье тестирование гипотез, канбан доски и выстроенные процессы. Очень полезно.
3. За рамками промо сервиса Kaiten описано как выстроить процесс от маленькой команды до большой компании, включая доски и подходы для real-time информирования акционеров по текущему прогрессу компании.
Summary: если правильно ограничить одновременное количество задач в работе, то высвободится время продакта на действительно важные процессы, способствующие кратному улучшению разрабатываемого продукта.
#product_dump @pm_dump
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