Как построить сильную продуктовую команду?
Своим опытом поделилась Ксения Михайлова, Head of product в Aitarget One.
Команде удалось за 2 года превратить MVP с одним окошком на сайте — в полноценную веб-платформу с автоматизацией. Этот AdTech-стартап растет х6 от года к году! И вот важные моменты, на мой взгляд, почему так получилось:
1. Всю работу они привязывают к бизнес-целям. Внутри команды продукта декомпозируют их по зонам ответственности. Для разработчиков — это скорость разработки, своевременность закрытия спринтов, количество ошибок, контрибьюшн в проекте, масштабируемость решения. Для продактов — динамика по ключевым метрикам (конверсии, churn rate, WAU, MAU) + количество проверяемых гипотез: “У нас общие цели по деньгам и клиентам на три отдела (маркетинг, продажи и продукт) — это позволяет нам двигаться в одном направлении и не конфликтовать, ведь у всех одинаковый критерий успеха.”
2. Трансформировали грумминги. Проводили сначала еженедельно. Груминг — это командная встреча для обсуждения («причесывания») бэклога и выяснения деталей по задачам. Нередко такие встречи превращаются в дискуссии без конкретных решений. Поэтому их стали проводить по потребности, а не потому, что в календаре стоит встреча.
3. Разделение зон ответственности, что позволяет тестировать больше гипотез за раз
4. Проводят персональные ротации новенького с каждым сотрудником, чтобы рассказать, кто чем занимается в команде. С одной стороны, это позволяет пообщаться лично, получше узнать друг друга, а с другой — помогает узнать про разные стороны продукта изнутри.
Ещё больше о том, как росла и развивалась команда и какие выводы ребята делали на разных этапах, — читайте в блоге Aitarget One.
Своим опытом поделилась Ксения Михайлова, Head of product в Aitarget One.
Команде удалось за 2 года превратить MVP с одним окошком на сайте — в полноценную веб-платформу с автоматизацией. Этот AdTech-стартап растет х6 от года к году! И вот важные моменты, на мой взгляд, почему так получилось:
1. Всю работу они привязывают к бизнес-целям. Внутри команды продукта декомпозируют их по зонам ответственности. Для разработчиков — это скорость разработки, своевременность закрытия спринтов, количество ошибок, контрибьюшн в проекте, масштабируемость решения. Для продактов — динамика по ключевым метрикам (конверсии, churn rate, WAU, MAU) + количество проверяемых гипотез: “У нас общие цели по деньгам и клиентам на три отдела (маркетинг, продажи и продукт) — это позволяет нам двигаться в одном направлении и не конфликтовать, ведь у всех одинаковый критерий успеха.”
2. Трансформировали грумминги. Проводили сначала еженедельно. Груминг — это командная встреча для обсуждения («причесывания») бэклога и выяснения деталей по задачам. Нередко такие встречи превращаются в дискуссии без конкретных решений. Поэтому их стали проводить по потребности, а не потому, что в календаре стоит встреча.
3. Разделение зон ответственности, что позволяет тестировать больше гипотез за раз
• Один продакт-менеджер отвечает за retention — делает все, чтобы продукт приносил максимум ценности и клиенты оставались с нами как можно дольше;• Другой продакт отвечает за acquisition — то есть за все, что происходит с пользователем до того, как он нам заплатил.• И Head of product отвечает также за стратегические проекты и разработку новых инструментов4. Проводят персональные ротации новенького с каждым сотрудником, чтобы рассказать, кто чем занимается в команде. С одной стороны, это позволяет пообщаться лично, получше узнать друг друга, а с другой — помогает узнать про разные стороны продукта изнутри.
Ещё больше о том, как росла и развивалась команда и какие выводы ребята делали на разных этапах, — читайте в блоге Aitarget One.
OneSpot
Как построить сильную продуктовую команду? Опыт Head of product Aitarget One — блог OneSpot
Как росла команда продукта и какие выводы мы делали на каждом этапе
Оценка архитектуры с помощью TARA
Каждый продукт начинается с платформенных метрик. После проверки результатов оценки по методике TARA можно фиксировать слабые места продукта и системы. Можно предположить, какой объем работы необходим для улучшения системы и каких технических знаний не хватает в команде разработчиков.
Основные шаги в TARA:
1. Контекстная диаграмма и требования
Сначала мы должны выяснить, в каком контексте живет система и какие требования качества должны быть удовлетворены. Нам также необходимо узнать какие ключевые функции доступны. Сложнее выявить требования к качеству, потому что в большинстве случаев команде не удается их четко сформулировать. Рекомендуется предлагать некоторые требования к качеству (нефункциональные требования), такие как производительность или масштабируемость, исходя из контекста приложения/системы.
2. Функциональные представления
После того как мы определили требования и контекст системы, можно приступать к рисованию функциональных структур (элементы рантайма) и структуры развертывания (среда, в которой развернуты элементы рантайма). В результате получается так называемый чертеж эскиза функционального представления.
3. Анализ кода
Базовый анализ кода охватывает следующую информацию для оценки:
- Структура модуля и зависимости
- Измерения, такие как строки кода (LOC), количество классов, тестовых классов или размер двоичных файлов
- Результаты статического анализа кода, такие как цикломатическая сложность, дублирование кода, соотношение комментариев к коду и стиль кода
- Покрытие тестов
Далее - оценка требований, определение и отчет о результатах, подготовка выводов для спонсора и предоставление выводов и рекомендаций.
Если вы как продуктолог видите проблемы в структурах бизнеса или хотите выйти на новый профессиональный уровень в построении модели управления, начните с фундаментального курса Архитектора предприятия. Начните осваивать необходимые навыки в OTUS уже 16 ноября в 19.00 с демо-занятия "Информационная архитектура компании"
На занятии рассмотрят, как информационная архитектура помогает выделять контексты на разных уровнях проектирования от программного до организационного, покажут слой информационной архитектуры и её место и взаимосвязи в модели BIAT (Business, Information, Application, Technology), а также основы концептуального моделирования.
Регистрируйтесь, чтобы принять участие https://otus.pw/B1Ek/
Каждый продукт начинается с платформенных метрик. После проверки результатов оценки по методике TARA можно фиксировать слабые места продукта и системы. Можно предположить, какой объем работы необходим для улучшения системы и каких технических знаний не хватает в команде разработчиков.
Основные шаги в TARA:
1. Контекстная диаграмма и требования
Сначала мы должны выяснить, в каком контексте живет система и какие требования качества должны быть удовлетворены. Нам также необходимо узнать какие ключевые функции доступны. Сложнее выявить требования к качеству, потому что в большинстве случаев команде не удается их четко сформулировать. Рекомендуется предлагать некоторые требования к качеству (нефункциональные требования), такие как производительность или масштабируемость, исходя из контекста приложения/системы.
2. Функциональные представления
После того как мы определили требования и контекст системы, можно приступать к рисованию функциональных структур (элементы рантайма) и структуры развертывания (среда, в которой развернуты элементы рантайма). В результате получается так называемый чертеж эскиза функционального представления.
3. Анализ кода
Базовый анализ кода охватывает следующую информацию для оценки:
- Структура модуля и зависимости
- Измерения, такие как строки кода (LOC), количество классов, тестовых классов или размер двоичных файлов
- Результаты статического анализа кода, такие как цикломатическая сложность, дублирование кода, соотношение комментариев к коду и стиль кода
- Покрытие тестов
Далее - оценка требований, определение и отчет о результатах, подготовка выводов для спонсора и предоставление выводов и рекомендаций.
Если вы как продуктолог видите проблемы в структурах бизнеса или хотите выйти на новый профессиональный уровень в построении модели управления, начните с фундаментального курса Архитектора предприятия. Начните осваивать необходимые навыки в OTUS уже 16 ноября в 19.00 с демо-занятия "Информационная архитектура компании"
На занятии рассмотрят, как информационная архитектура помогает выделять контексты на разных уровнях проектирования от программного до организационного, покажут слой информационной архитектуры и её место и взаимосвязи в модели BIAT (Business, Information, Application, Technology), а также основы концептуального моделирования.
Регистрируйтесь, чтобы принять участие https://otus.pw/B1Ek/
otus.ru
Курс Enterprise Architect: архитектор предприятия или корпоративный архитектор
Задачи Enterprise Architect — создавать, согласовывать и поддерживать целевое видение и траекторию развития компании, конкретизируя стратегию цифровизации и принимая обоснованные технологические решения на ее основе
Пост в помощь тем, кто ищет работу за рубежом
1. Про профайл
Как часто выглядит профайл среднего продакта из страны, где продуктовая культура появилась недавно (Россия, Европа в частности):
Как выглядит профайл среднего продакта из страны, где продуктовая культура появилась давно (США + страны, где представлены R&D-офисы американских компаний):
2. Продакты часто задумываются о продолжении карьеры в международной компании.
Для поиска могут быть полезны:
Книги про карьеру:
• How to make sense of any mess
• The power of moments
• The making of a manager
Каналы на Ютубе:
• Linda Rainier
• Webinar with Fernando Delgado (Google, Yahoo)
• Lewis C. Lin channel (the author of the book ‘The Product Manager Interview: 164 Actual Questions and Answers’)
3. А как все сделать правильно и получить работу за рубежом? Какие есть подводные камни, о которых не знают новички? 16 ноября в 19:00 в OTUS на бесплатном вебинаре "Старт карьеры за рубежом" постараются сделать этот самый старт максимально простым и гладким. Про что будем говорить:
– Как проходит найм в международные компании и в чем отличие от найма в России
– Есть ли разница в подходе к работе в России и по миру
– Что стоит узнать прежде, чем принять оффер иностранной компании
Спикер, Георгий Могелашвили, Lead Developer в Booking.com, поделится своим опытом и подробно расскажет про варианты старта карьеры в международной компании step by step.
Регистрируйтесь и готовьте вопросы: https://otus.pw/ICqv/
1. Про профайл
Как часто выглядит профайл среднего продакта из страны, где продуктовая культура появилась недавно (Россия, Европа в частности):
• образование: экономист/маркетолог/математик/инженер. Техническое образование приветствуется, но необязательно• опыт: пара лет работы продактом, а до этого может быть опыт работы проджектом/тестировщиком/саппортом/биздевом/дизайнером/аналитиком, реже — разработчиком.Как выглядит профайл среднего продакта из страны, где продуктовая культура появилась давно (США + страны, где представлены R&D-офисы американских компаний):
• образование: бакалавриат + магистратура в престижном вузе по Computer Science или Design; MBA очень приветствуется (а много где и обязательно)• опыт: не меньше 5 лет работы в продуктовой команде на позиции продакта, а также есть опыт разработчика/дизайнера/аналитика. • Если есть MBA, то могут взять на стажировку, а затем и на постоянную позицию.2. Продакты часто задумываются о продолжении карьеры в международной компании.
Для поиска могут быть полезны:
Книги про карьеру:
• How to make sense of any mess
• The power of moments
• The making of a manager
Каналы на Ютубе:
• Linda Rainier
• Webinar with Fernando Delgado (Google, Yahoo)
• Lewis C. Lin channel (the author of the book ‘The Product Manager Interview: 164 Actual Questions and Answers’)
3. А как все сделать правильно и получить работу за рубежом? Какие есть подводные камни, о которых не знают новички? 16 ноября в 19:00 в OTUS на бесплатном вебинаре "Старт карьеры за рубежом" постараются сделать этот самый старт максимально простым и гладким. Про что будем говорить:
– Как проходит найм в международные компании и в чем отличие от найма в России
– Есть ли разница в подходе к работе в России и по миру
– Что стоит узнать прежде, чем принять оффер иностранной компании
Спикер, Георгий Могелашвили, Lead Developer в Booking.com, поделится своим опытом и подробно расскажет про варианты старта карьеры в международной компании step by step.
Регистрируйтесь и готовьте вопросы: https://otus.pw/ICqv/
Про сплит-тесты со стороны аналитики
Когда точно можно проводить:
Если ваш объем конверсии меньше 1 000 в месяц — вы не готовы. Ваши результаты не будут статистически значимыми. Подождите, пока ваши конверсии превысят 1 000, а затем спокойно запускайте тесты.
Что делать, чтобы проведение тестов было эффективным:
Почему надо разобраться с статистической значимостью:
Она отражает уровень риска, связанного с внедряемым изменением. Она обеспечивает уверенность в выбранном варианте. Статистическая значимость — это способ математически доказать, что полученным результатам можно доверять. Когда вы принимаете решения на основе проводимых экспериментов, важно убедиться, что зависимости действительно существуют.
Для получения значимых результатов от значимых отношений между данными не прекращайте выполнение теста, пока не достигнете статистического значимости, равной 95-99%. Это будет означать, что вы на 95-99% уверены в верности результата.
Достижение статистической значимости не является единственным компонентом успешного сплит-теста. Объем выборки также сильно влияет на результаты.
Почему надо разобраться с размером выборки?
Если размер выборки слишком мал, риск погрешности будет увеличиваться. Надежным минимальным ориентиром будет диапазон 1 000 - 5000 (конверсий, клиентов, посетителей и т.д.).
Помните, что если вы используете А/Б-тест (то есть эксперимент с двумя вариантами), вы автоматически разделяете эту выборку пополам и показываете один вариант каждой половине. Понятно, что работа с группой меньше 500 человек не будет иметь смысла.
Если хотите лучше разобраться в продуктовом анализе, приходите на курс Продуктовая аналитика от Otus - https://otus.pw/Btv6.
На нем вы разберете основные задачи продуктовой аналитики и их последующее решение с помощью SQL и Python, навыки визуализации данных, понимание статистики для работы с А/В- тестами. Помимо этого вы прокачаете навыки работы в команде, получите карьерное консультирование и узнаете, как и куда развиваться в области продуктового анализа. Подробности - https://otus.pw/Btv6
Когда точно можно проводить:
Если ваш объем конверсии меньше 1 000 в месяц — вы не готовы. Ваши результаты не будут статистически значимыми. Подождите, пока ваши конверсии превысят 1 000, а затем спокойно запускайте тесты.
Что делать, чтобы проведение тестов было эффективным:
• Формируйте правильные гипотезы — никаких догадок или интуитивных решений.• Продолжайте тест, пока не достигнете статистической значимости в 95-99%.• Убедитесь, что размер выборки достаточно большой (не менее 1 000 конверсий).• Не останавливайте выполнение теста слишком рано. Нацельтесь на > 1-2 недели.Почему надо разобраться с статистической значимостью:
Она отражает уровень риска, связанного с внедряемым изменением. Она обеспечивает уверенность в выбранном варианте. Статистическая значимость — это способ математически доказать, что полученным результатам можно доверять. Когда вы принимаете решения на основе проводимых экспериментов, важно убедиться, что зависимости действительно существуют.
Для получения значимых результатов от значимых отношений между данными не прекращайте выполнение теста, пока не достигнете статистического значимости, равной 95-99%. Это будет означать, что вы на 95-99% уверены в верности результата.
Достижение статистической значимости не является единственным компонентом успешного сплит-теста. Объем выборки также сильно влияет на результаты.
Почему надо разобраться с размером выборки?
Если размер выборки слишком мал, риск погрешности будет увеличиваться. Надежным минимальным ориентиром будет диапазон 1 000 - 5000 (конверсий, клиентов, посетителей и т.д.).
Помните, что если вы используете А/Б-тест (то есть эксперимент с двумя вариантами), вы автоматически разделяете эту выборку пополам и показываете один вариант каждой половине. Понятно, что работа с группой меньше 500 человек не будет иметь смысла.
Если хотите лучше разобраться в продуктовом анализе, приходите на курс Продуктовая аналитика от Otus - https://otus.pw/Btv6.
На нем вы разберете основные задачи продуктовой аналитики и их последующее решение с помощью SQL и Python, навыки визуализации данных, понимание статистики для работы с А/В- тестами. Помимо этого вы прокачаете навыки работы в команде, получите карьерное консультирование и узнаете, как и куда развиваться в области продуктового анализа. Подробности - https://otus.pw/Btv6
Важные библиотеки на Python для быстрых самостоятельных проверок гипотез по данным
NumPy
NumPy позволяет очень эффективно обрабатывать многомерные массивы.
Также в ней есть несколько хорошо реализованных методов, например, функция random, которая гораздо качественнее модуля случайных чисел из стандартной библиотеки. Функция polyfit отлично подходит для простых задач по прогнозной аналитике, например, по линейной или полиномиальной регрессии.
pandas
Библиотека pandas позволяет работать с двухмерными таблицами на Python. Эта высокоуровневая библиотека позволяет строить сводные таблицы, выделять колонки, использовать фильтры по параметрам, выполнять группировку по параметрам, запускать функции (сложение, нахождение медианы, среднего, минимального, максимального значений), объединять таблицы и многое другое. В pandas можно создавать и многомерные таблицы.
Matplotlib
Визуализация данных позволяет представить их в наглядном виде, изучить более подробно, чем это можно сделать в обычном формате, и доступно изложить другим людям. Matplotlib — лучшая и самая популярная Python-библиотека для этой цели. Она не так проста в использовании, но с помощью 4-5 наиболее распространённых блоков кода для простых линейных диаграмм и точечных графиков можно научиться создавать их очень быстро.
scikit-learn
Содержит ряд методов, охватывающих всё, что может понадобиться в течение первых нескольких лет в карьере аналитика данных: алгоритмы классификации и регрессии, кластеризацию, валидацию и выбор моделей. Также её можно применять для уменьшения размерности данных и выделения признаков. Машинное обучение в scikit-learn заключается в том, чтобы импортировать правильные модули и запустить метод подбора модели. Сложнее вычистить, отформатировать и подготовить данные, а также подобрать оптимальные входные значения и модели.
SciPy
Включает средства для обработки числовых последовательностей, лежащих в основе моделей машинного обучения: интеграции, экстраполяции, оптимизации и других. Как и в случае с NumPy, чаще всего используется не сама SciPy, а упомянутая выше библиотека scikit-learn, которая во многом опирается на неё. SciPy полезно знать потому, что она содержит ключевые математические методы для выполнения сложных процессов машинного обучения в scikit-learn.
Решайте аналитические задачи быстро и эффективно с помощью Python! Как еще Python поможет менеджеру решать задачи аналитики? Расскажет на дне открытых дверей онлайн-курса «Python для аналитики» Алина Красавина, python-разработчик с 10-летним опытом.
Алина расскажет, кому будет полезен курс и что он даст, представит программу онлайн-курса, формат обучения в OTUS и проведет обзор рынка вакансий, где необходим язык программирования Python.
Зарегистрируйтесь, чтобы участвовать и задать свои вопросы эксперту, Demo Day 24.11: https://otus.pw/fy9A/
NumPy
NumPy позволяет очень эффективно обрабатывать многомерные массивы.
Также в ней есть несколько хорошо реализованных методов, например, функция random, которая гораздо качественнее модуля случайных чисел из стандартной библиотеки. Функция polyfit отлично подходит для простых задач по прогнозной аналитике, например, по линейной или полиномиальной регрессии.
pandas
Библиотека pandas позволяет работать с двухмерными таблицами на Python. Эта высокоуровневая библиотека позволяет строить сводные таблицы, выделять колонки, использовать фильтры по параметрам, выполнять группировку по параметрам, запускать функции (сложение, нахождение медианы, среднего, минимального, максимального значений), объединять таблицы и многое другое. В pandas можно создавать и многомерные таблицы.
Matplotlib
Визуализация данных позволяет представить их в наглядном виде, изучить более подробно, чем это можно сделать в обычном формате, и доступно изложить другим людям. Matplotlib — лучшая и самая популярная Python-библиотека для этой цели. Она не так проста в использовании, но с помощью 4-5 наиболее распространённых блоков кода для простых линейных диаграмм и точечных графиков можно научиться создавать их очень быстро.
scikit-learn
Содержит ряд методов, охватывающих всё, что может понадобиться в течение первых нескольких лет в карьере аналитика данных: алгоритмы классификации и регрессии, кластеризацию, валидацию и выбор моделей. Также её можно применять для уменьшения размерности данных и выделения признаков. Машинное обучение в scikit-learn заключается в том, чтобы импортировать правильные модули и запустить метод подбора модели. Сложнее вычистить, отформатировать и подготовить данные, а также подобрать оптимальные входные значения и модели.
SciPy
Включает средства для обработки числовых последовательностей, лежащих в основе моделей машинного обучения: интеграции, экстраполяции, оптимизации и других. Как и в случае с NumPy, чаще всего используется не сама SciPy, а упомянутая выше библиотека scikit-learn, которая во многом опирается на неё. SciPy полезно знать потому, что она содержит ключевые математические методы для выполнения сложных процессов машинного обучения в scikit-learn.
Решайте аналитические задачи быстро и эффективно с помощью Python! Как еще Python поможет менеджеру решать задачи аналитики? Расскажет на дне открытых дверей онлайн-курса «Python для аналитики» Алина Красавина, python-разработчик с 10-летним опытом.
Алина расскажет, кому будет полезен курс и что он даст, представит программу онлайн-курса, формат обучения в OTUS и проведет обзор рынка вакансий, где необходим язык программирования Python.
Зарегистрируйтесь, чтобы участвовать и задать свои вопросы эксперту, Demo Day 24.11: https://otus.pw/fy9A/
otus.ru
Python для аналитики
Разберем лучшие инструменты для аналитики, отчетности и построения дашбордов
HEART Framework - метрики счастья и удержания пользователей
HEART Framework фокусирует нас на то, что важно для пользовательского опыта. Это то, что влияет на отношение клиента к вашему сервису и к вашему бизнесу соответственно. Все перечисленные метрики у вас должны быть впорядке, и должны развиваться. В него входят:
Happiness (Счастье)- насколько счастливы ваши пользователи? Метрики «счастья» можно определить через проведение исследований и интервью. Что это может быть: выявление в интервью того, насколько удовлетворены потребности пользователей, насколько просто и удобно пользоваться продуктом, общая удовлетворенность от клиентского пути (Customer Journey и Net Promoter Score).
Engagement (Вовлечение) — это то, насколько полно и регулярно они пользуются продуктом. Примеры такой метрики: как часто и как долго пользователь взаимодействует с вашим продуктом или сервисом в течение определенного периода времени (например, заходит на сервис и делает определенные действия), как часто пользователь загружает контент, обновляет информацию и т.д. Как часто пользователь лайкает контент, комментирует, репостит внутри системы и в других системах. Все метрики зависят от бизнес-целей и возможностей.
Adoption (Принятие) — это метрика получения новых пользователей. То есть это то, как много людей «входит» в вашу систему в определенный период времени. Например: новые подписки на сервис покупки, совершенные новыми пользователями, обновления приложения / софта до новой версии, как много клиентов продолжает пользоваться продуктом после пробного периода.
Retention (Удержание) - как часто клиент «возвращается» и «удерживается в системе». Конкретными метриками здесь могут быть: как много пользователей продолжают пользоваться продуктом с течением времени, как быстро клиенты отписываются и бросают пользование продуктом, повторные покупки. В отличие от предыдущий метрики, здесь мы фокусируемся на том, чтобы у нас было не больше клиентов, а чтобы каждый клиент приносил больше денег.
Task Success — это то, насколько пользователи реально решают свои задачи в вашем сервисе / продукте. Насколько ваш сервис реально может решать их задачи. А также то, насколько эффективно (то есть быстро и качественно) эти задачи решаются.
Хотите узнать, как эти и другие метрики на практике качают продукты?
Приходите 25 ноября в 18:30 по московскому времени состоится продуктовый онлайн-митап от европейского финтех стартапа Vivid Money, где будут выступления на интересные темы:
• “Как мы растим инвестиционный продукт через контентную ленту” - Игорь Кузнецов, Head of Product - Vivid Money
• "Борьба с фродом в реферальной программе Тинькофф Инвестиций" - Артур Амиров, Product Manager - Тинькофф
• “Вовлечение пользователей с помощью геймифицированных элементов на примере Яндекс.Кью” - Владислав Чальцев, Product Manager - Яндекс.Кью
Регистрация по ссылке.
HEART Framework фокусирует нас на то, что важно для пользовательского опыта. Это то, что влияет на отношение клиента к вашему сервису и к вашему бизнесу соответственно. Все перечисленные метрики у вас должны быть впорядке, и должны развиваться. В него входят:
Happiness (Счастье)- насколько счастливы ваши пользователи? Метрики «счастья» можно определить через проведение исследований и интервью. Что это может быть: выявление в интервью того, насколько удовлетворены потребности пользователей, насколько просто и удобно пользоваться продуктом, общая удовлетворенность от клиентского пути (Customer Journey и Net Promoter Score).
Engagement (Вовлечение) — это то, насколько полно и регулярно они пользуются продуктом. Примеры такой метрики: как часто и как долго пользователь взаимодействует с вашим продуктом или сервисом в течение определенного периода времени (например, заходит на сервис и делает определенные действия), как часто пользователь загружает контент, обновляет информацию и т.д. Как часто пользователь лайкает контент, комментирует, репостит внутри системы и в других системах. Все метрики зависят от бизнес-целей и возможностей.
Adoption (Принятие) — это метрика получения новых пользователей. То есть это то, как много людей «входит» в вашу систему в определенный период времени. Например: новые подписки на сервис покупки, совершенные новыми пользователями, обновления приложения / софта до новой версии, как много клиентов продолжает пользоваться продуктом после пробного периода.
Retention (Удержание) - как часто клиент «возвращается» и «удерживается в системе». Конкретными метриками здесь могут быть: как много пользователей продолжают пользоваться продуктом с течением времени, как быстро клиенты отписываются и бросают пользование продуктом, повторные покупки. В отличие от предыдущий метрики, здесь мы фокусируемся на том, чтобы у нас было не больше клиентов, а чтобы каждый клиент приносил больше денег.
Task Success — это то, насколько пользователи реально решают свои задачи в вашем сервисе / продукте. Насколько ваш сервис реально может решать их задачи. А также то, насколько эффективно (то есть быстро и качественно) эти задачи решаются.
Хотите узнать, как эти и другие метрики на практике качают продукты?
Приходите 25 ноября в 18:30 по московскому времени состоится продуктовый онлайн-митап от европейского финтех стартапа Vivid Money, где будут выступления на интересные темы:
• “Как мы растим инвестиционный продукт через контентную ленту” - Игорь Кузнецов, Head of Product - Vivid Money
• "Борьба с фродом в реферальной программе Тинькофф Инвестиций" - Артур Амиров, Product Manager - Тинькофф
• “Вовлечение пользователей с помощью геймифицированных элементов на примере Яндекс.Кью” - Владислав Чальцев, Product Manager - Яндекс.Кью
Регистрация по ссылке.
Базовые стратегии поиска точек роста продукта
1. Оптимизируйте конверсию
Важно улучшать пользовательский опыт и внедрять любые изменения на сайте не хаотично или на основании догадок, а с опорой на исследования и тесты.
2. Рассматривайте конверсию через призму воронки продаж
Воронка продаж — предполагаемый путь пользователя к покупке. От входа на сайт до покупки посетители проходят несколько этапов. На каждом из них часть пользователей уходит, поэтому процесс напоминает воронку. Чем больше посетителей прошло через всю воронку, тем выше конверсия.
3. Описывайте этапы воронки с помощью CJM
Путь клиента может начаться с главной, каталога, карточки товара или товарного лендинга. Далее на пути к целевому действию возможны разные сценарии. Каждый из этапов, через который проходит пользователь, влияет на общую конверсию — негативно или позитивно.
4. Сделайте интерфейс максимально удобным
Конверсия интернет-магазина сильно зависит от того, насколько удобен для пользователя интерфейс и функционал разных этапов воронки сайта.
5. Реализуйте понятную структуру сайта
Понятная структура сайта помогает пользователям сориентироваться, что предлагает магазин, найти нужное и сделать покупку. От структуры сайта также зависит его видимость в поисковой выдаче, гибкость при масштабировании семантики и ассортимента.
6. Выбирайте подходящие стратегии ценообразования
Общий принцип ценообразования: розничная цена — это себестоимость плюс торговая наценка. Цена продажи — розничная цена минус скидка.
7. Правильно формируйте ассортимент
Правильно подобранный ассортимент интернет-магазина повышает вероятность покупки, а значит и конверсию. Но хороший ассортимент — не означает максимально широкий.
8. Повышайте средний чек
Используя техники cross-sell, up-sell, down-sell и bundle с умом, можно не только увеличить доход, но и улучшить поведенческие факторы, повысить лояльность пользователей.
9. Опирайтесь на законы психологии
Законы психологии, которые влияют на поведение человека, влияют и на пользовательский опыт, а значит на конверсию интернет-магазина. Опирайтесь на них для обеспечения хорошего UX.
10. Создайте ценностное предложение
Ценностное предложение — это ответ на вопрос, почему должны купить именно у вас. Самая распространенной формула: Ценность = Выгоды – Издержки. Чем больше воспринимаемых выгод и чем меньше воспринимаемых издержек вы обеспечите клиенту, тем выше ценность предложения и вероятность покупки.
11. Создавайте экспертный контент
Экспертный контент дает посетителям полезную информацию и за счет этого повышает их лояльность. Создание и распространение экспертного контента особенно актуально для продажи новых, сложных или необычных товаров — он раскрывает их преимущества и стимулирует покупку.
Работа данных историй наглядней на кейсах роста. Например, много таких кейсов вы можете найти в спецпроекте Product Analytics Champions: Лига Ставок от Adventum и Amplitude. По итогу, команды глубже анализируют данные, находят новые инсайты и эффективнее развивают продукт. Приходите за кейсами.
1. Оптимизируйте конверсию
Важно улучшать пользовательский опыт и внедрять любые изменения на сайте не хаотично или на основании догадок, а с опорой на исследования и тесты.
2. Рассматривайте конверсию через призму воронки продаж
Воронка продаж — предполагаемый путь пользователя к покупке. От входа на сайт до покупки посетители проходят несколько этапов. На каждом из них часть пользователей уходит, поэтому процесс напоминает воронку. Чем больше посетителей прошло через всю воронку, тем выше конверсия.
3. Описывайте этапы воронки с помощью CJM
Путь клиента может начаться с главной, каталога, карточки товара или товарного лендинга. Далее на пути к целевому действию возможны разные сценарии. Каждый из этапов, через который проходит пользователь, влияет на общую конверсию — негативно или позитивно.
4. Сделайте интерфейс максимально удобным
Конверсия интернет-магазина сильно зависит от того, насколько удобен для пользователя интерфейс и функционал разных этапов воронки сайта.
5. Реализуйте понятную структуру сайта
Понятная структура сайта помогает пользователям сориентироваться, что предлагает магазин, найти нужное и сделать покупку. От структуры сайта также зависит его видимость в поисковой выдаче, гибкость при масштабировании семантики и ассортимента.
6. Выбирайте подходящие стратегии ценообразования
Общий принцип ценообразования: розничная цена — это себестоимость плюс торговая наценка. Цена продажи — розничная цена минус скидка.
7. Правильно формируйте ассортимент
Правильно подобранный ассортимент интернет-магазина повышает вероятность покупки, а значит и конверсию. Но хороший ассортимент — не означает максимально широкий.
8. Повышайте средний чек
Используя техники cross-sell, up-sell, down-sell и bundle с умом, можно не только увеличить доход, но и улучшить поведенческие факторы, повысить лояльность пользователей.
9. Опирайтесь на законы психологии
Законы психологии, которые влияют на поведение человека, влияют и на пользовательский опыт, а значит на конверсию интернет-магазина. Опирайтесь на них для обеспечения хорошего UX.
10. Создайте ценностное предложение
Ценностное предложение — это ответ на вопрос, почему должны купить именно у вас. Самая распространенной формула: Ценность = Выгоды – Издержки. Чем больше воспринимаемых выгод и чем меньше воспринимаемых издержек вы обеспечите клиенту, тем выше ценность предложения и вероятность покупки.
11. Создавайте экспертный контент
Экспертный контент дает посетителям полезную информацию и за счет этого повышает их лояльность. Создание и распространение экспертного контента особенно актуально для продажи новых, сложных или необычных товаров — он раскрывает их преимущества и стимулирует покупку.
Работа данных историй наглядней на кейсах роста. Например, много таких кейсов вы можете найти в спецпроекте Product Analytics Champions: Лига Ставок от Adventum и Amplitude. По итогу, команды глубже анализируют данные, находят новые инсайты и эффективнее развивают продукт. Приходите за кейсами.
amplitude.adventum.ru
Спецпроект Product Analytics Champions: Лига Ставок от Adventum и Amplitude
Продуктовая аналитика позволяет собирать данные о поведении пользователей в продукте. Компании, которые умеют анализировать и использовать эти данные для улучшения продукта, зарабатывают в 2 раза больше. Такие компании мы называем «Чемпионами продуктовой…
👍1
В чём отличие автоматического и ручного распределения при A/B тестировании?
При классическом A/B-тестировании пользователей делят на группы, каждой показывается свой вариант. Спустя некоторое время результат оценивают по изначально выбранной метрике — например, по конверсии в покупку. Распределение трафика между вариантами не меняется на протяжении всего теста.
Алгоритм в основе автоматического распределения проводит эксперименты по-другому: трафик между вариантами распределяется динамически. Алгоритм постоянно анализирует эффективность вариантов по заданной метрике и перераспределяет пользователей между ними — больше трафика отдаётся более эффективным вариантам.
Например, вы тестируете экраны подписки в приложении. Ключевой метрикой выбрали конверсию в покупку. У вас 4 варианта пейволлов, все пользователи распределены поровну на 4 группы.
Спустя заданное время после запуска теста первый пейволл показывает лучшую конверсию из всех. Тогда алгоритм отдаст больше пользователей на этот пейволл, но продолжит анализировать метрики. Если в дальнейшем другой вариант начнёт показывать конверсию выше, трафик снова перераспределится.
Что важно учесть при автоматическом распределении?
1. Не торопитесь с выводами. Две недели — это минимальный срок для проведения А/B-тестирования, по истечении которого вы можете рассчитывать на статистически достоверные данные.
2. Самая распространенная ошибка — это когда тестирование проводится на разных аудиториях, с разными креативами и с разными посадочными страницами. Неизвестная должна быть только одна! Создайте абсолютно одинаковые условия в остальном: используйте одинаковые креативы в рекламных объявлениях, которые видит схожая аудитория, приходящая из одного рекламного источника.
3. Тестируйте несколько гипотез одновременно. Все привыкли тестировать только 2 варианта посадочной страницы, хотя в рамках одного тестирования вы можете добавить и 3, и 4 варианта, существенно сэкономив время.
4. Проводите тестирование на всей длине воронки. Что толку, если посадочная страница приносит конверсию в 3 раза больше обычной, но до продаж эти лиды не доходят?
Развитие мобильного приложения невозможно без постоянной проверки новых гипотез. Это конвейер — протестировали, измерили, приняли/отклонили. Любому product-менеджеру, разработчику, аналитику, маркетологу хочется ускорить этот процесс. На проверку каждой гипотезы уходит несколько дней (часто и недель), плюс нужно позаботиться о статзначимости результата.
Мои приятели запустили сервис proba.ai, который помогает мобильным продуктам автоматизировать этот процесс и проводить A/B-тесты быстрее и дешевле. Там алгоритмы автоматического распределения пользователей и оптимизации под выбранную целевую метрику. Помимо простой конверсии алгоритм может оптимизироваться на ARPU и количество совершённых событий. Уже в ходе эксперимента побеждающий вариант будет получать больше пользователей. Автоматическое распределение трафика работает на основе байесовской статистики.
Сервис можно попробовать бесплатно по ссылке.
По вопросам работы с сервисом пишите @annatch66.
А также приглашаем на бесплатный вебинар «А/B-тесты в мобайле: как проверять гипотезы быстро и дёшево», который пройдёт 1 декабря в 16:00 МСК. Регистрация доступна здесь.
При классическом A/B-тестировании пользователей делят на группы, каждой показывается свой вариант. Спустя некоторое время результат оценивают по изначально выбранной метрике — например, по конверсии в покупку. Распределение трафика между вариантами не меняется на протяжении всего теста.
Алгоритм в основе автоматического распределения проводит эксперименты по-другому: трафик между вариантами распределяется динамически. Алгоритм постоянно анализирует эффективность вариантов по заданной метрике и перераспределяет пользователей между ними — больше трафика отдаётся более эффективным вариантам.
Например, вы тестируете экраны подписки в приложении. Ключевой метрикой выбрали конверсию в покупку. У вас 4 варианта пейволлов, все пользователи распределены поровну на 4 группы.
Спустя заданное время после запуска теста первый пейволл показывает лучшую конверсию из всех. Тогда алгоритм отдаст больше пользователей на этот пейволл, но продолжит анализировать метрики. Если в дальнейшем другой вариант начнёт показывать конверсию выше, трафик снова перераспределится.
Что важно учесть при автоматическом распределении?
1. Не торопитесь с выводами. Две недели — это минимальный срок для проведения А/B-тестирования, по истечении которого вы можете рассчитывать на статистически достоверные данные.
2. Самая распространенная ошибка — это когда тестирование проводится на разных аудиториях, с разными креативами и с разными посадочными страницами. Неизвестная должна быть только одна! Создайте абсолютно одинаковые условия в остальном: используйте одинаковые креативы в рекламных объявлениях, которые видит схожая аудитория, приходящая из одного рекламного источника.
3. Тестируйте несколько гипотез одновременно. Все привыкли тестировать только 2 варианта посадочной страницы, хотя в рамках одного тестирования вы можете добавить и 3, и 4 варианта, существенно сэкономив время.
4. Проводите тестирование на всей длине воронки. Что толку, если посадочная страница приносит конверсию в 3 раза больше обычной, но до продаж эти лиды не доходят?
Развитие мобильного приложения невозможно без постоянной проверки новых гипотез. Это конвейер — протестировали, измерили, приняли/отклонили. Любому product-менеджеру, разработчику, аналитику, маркетологу хочется ускорить этот процесс. На проверку каждой гипотезы уходит несколько дней (часто и недель), плюс нужно позаботиться о статзначимости результата.
Мои приятели запустили сервис proba.ai, который помогает мобильным продуктам автоматизировать этот процесс и проводить A/B-тесты быстрее и дешевле. Там алгоритмы автоматического распределения пользователей и оптимизации под выбранную целевую метрику. Помимо простой конверсии алгоритм может оптимизироваться на ARPU и количество совершённых событий. Уже в ходе эксперимента побеждающий вариант будет получать больше пользователей. Автоматическое распределение трафика работает на основе байесовской статистики.
Сервис можно попробовать бесплатно по ссылке.
По вопросам работы с сервисом пишите @annatch66.
А также приглашаем на бесплатный вебинар «А/B-тесты в мобайле: как проверять гипотезы быстро и дёшево», который пройдёт 1 декабря в 16:00 МСК. Регистрация доступна здесь.
Hard skills проектного менеджера, которые полезны и продакт-менеджеру
Управление процессами - создание, запуск и развитие продукта — совокупность множества процессов (от планирования и бюджетирования до реализации и отчётности), за которыми нужно постоянно следить. Если, при прочих равных, будешь уметь не только управлять процессами, но и оптимизировать их (есть много методов и методик: от Lean до теории ограничений), цены не будет.
Управление задачами - работа над любым проектом — это череда задач разного масштаба, которые нужно сделать, чтобы достичь поставленных целей. Тебе нужно уметь грамотно ставить задачи и следить за их выполнением.
Знание методологий управления - хороший менеджер проекта должен знать хотя бы одну методологию по управлению (например, Agile и Waterfall)и уметь применять её в работе,знания методологий ещё и методики, типа Scrum, и различные методы управления проектами.
Управление командой - должен уметь объединять команду, чтобы проект двигался в едином направлении, распределять работы, анализировать результаты и управлять HR-процессами — нанимать и увольнять сотрудников. Без навыков управления командой менеджеру будет очень сложно скоординировать работу и довести проект до благополучного финала. Но управлять командой это не только давать всем указания, что делать, но и решать межличностные проблемы в коллективе. Менеджеру проекта важно создать комфортную рабочую атмосферу и не допускать внутренних конфликтов.
Техническая экспертность — умение не только управлять процессом, но и разбираться в самом продукте и всех аспектах его разработки (хотя бы частично), чтобы отслеживать эффективность развития продукта, уровень подготовки проекта и многое другое.
Планирование - создание стратегии присутствия проекта на рынке — определение бюджетов и необходимых ресурсов (в том числе временных и человеческих), распределение актуальных и важных задач. Кроме, собственно, создания плана, тебе нужно также следить за процессом и контролировать результаты.
Риск-менеджмент - должен предвидеть любые риски, уметь их избегать и брать на себя ответственность за ошибки. У каждого проекта есть бюджетные ограничения, в которые проджект-менеджер должен уметь укладываться без вреда рабочим процессам.
Если хотите быть будущим руководителем направления по продукту, приходите на курсы проектного менеджера. Например, присмотритесь к демоверсии курса «Project manager».
Вы разберётесь в основах работы проджекта, поймёте, как управлять рисками и качеством проекта. Узнаете о гибких методологиях управления, оцените свои навыки и составите личный план развития. На первом модуле вы будете учиться вместе с другими студентами, сможете оценить формат обучения и получите представление о профессии. Всё как на полноценном курсе, только бесплатно: https://netolo.gy/hjB
Управление процессами - создание, запуск и развитие продукта — совокупность множества процессов (от планирования и бюджетирования до реализации и отчётности), за которыми нужно постоянно следить. Если, при прочих равных, будешь уметь не только управлять процессами, но и оптимизировать их (есть много методов и методик: от Lean до теории ограничений), цены не будет.
Управление задачами - работа над любым проектом — это череда задач разного масштаба, которые нужно сделать, чтобы достичь поставленных целей. Тебе нужно уметь грамотно ставить задачи и следить за их выполнением.
Знание методологий управления - хороший менеджер проекта должен знать хотя бы одну методологию по управлению (например, Agile и Waterfall)и уметь применять её в работе,знания методологий ещё и методики, типа Scrum, и различные методы управления проектами.
Управление командой - должен уметь объединять команду, чтобы проект двигался в едином направлении, распределять работы, анализировать результаты и управлять HR-процессами — нанимать и увольнять сотрудников. Без навыков управления командой менеджеру будет очень сложно скоординировать работу и довести проект до благополучного финала. Но управлять командой это не только давать всем указания, что делать, но и решать межличностные проблемы в коллективе. Менеджеру проекта важно создать комфортную рабочую атмосферу и не допускать внутренних конфликтов.
Техническая экспертность — умение не только управлять процессом, но и разбираться в самом продукте и всех аспектах его разработки (хотя бы частично), чтобы отслеживать эффективность развития продукта, уровень подготовки проекта и многое другое.
Планирование - создание стратегии присутствия проекта на рынке — определение бюджетов и необходимых ресурсов (в том числе временных и человеческих), распределение актуальных и важных задач. Кроме, собственно, создания плана, тебе нужно также следить за процессом и контролировать результаты.
Риск-менеджмент - должен предвидеть любые риски, уметь их избегать и брать на себя ответственность за ошибки. У каждого проекта есть бюджетные ограничения, в которые проджект-менеджер должен уметь укладываться без вреда рабочим процессам.
Если хотите быть будущим руководителем направления по продукту, приходите на курсы проектного менеджера. Например, присмотритесь к демоверсии курса «Project manager».
Вы разберётесь в основах работы проджекта, поймёте, как управлять рисками и качеством проекта. Узнаете о гибких методологиях управления, оцените свои навыки и составите личный план развития. На первом модуле вы будете учиться вместе с другими студентами, сможете оценить формат обучения и получите представление о профессии. Всё как на полноценном курсе, только бесплатно: https://netolo.gy/hjB
Чек-лист правильных OKR-целей
1. OKR должны быть компактными. Не более страницы текста, в идеале полстраницы.
2. OKR это не to do-лист и не план работ. Если OKR выглядят таким образом, значит, их нужно переработать.
3. Хотя бы один OKR команды должен быть связан с глобальными целями компании. В противном случае непонятно, какое отношение команда имеет к бизнесу.
4. Приоритеты OKR внутри команды должны увеличивать вероятность достижения целей компании. Ключевая цель бизнеса не должна быть отражена в OKR команды последним пунктом.
5. Связанные инициативы должны быть согласованы. Разработка планирует выпустить продукт Z, а маркетинг обеспечить его продвижение. Если выпуск состоится в самом конце квартала, времени на его продвижение будет недостаточно.
6. Все глобальные обещания команды должны быть включены в ее OKR. Если другая команда предполагает, что отдел работает над целью X, а в действительности ничего такого не происходит — это проблема.
7. Цели не должны определять обычные и регулярные бизнес-задачи. Правда, Эффект Черной Королевы, когда нужно бежать чтобы оставаться на месте, никто не отменял. Если для сохранения достигнутых результатов требуется приложить экстраординарные усилия, в OKR отдела могут быть включены цели и по их штатной деятельности.
8. Достижение цели должно требовать усилий всего отдела или команды. В противном случае штат отдела раздут либо его сотрудники недостаточно мотивированы.
9. Достижение целей должно вести к существенной пользе бизнесу.
10. Определенные результаты должны быть достаточны для достижения цели. Если достижение цели определяется результатами недостаточными для признания ее успеха, это приведет как к реальным задержками в работе по причине отсутствия ресурсов в момент когда неучтенные требования проявятся, так и срыву планируемых сроков вследствие этого.
В чем разница в Проектном и продуктовом подходе? Что отличает продукт и как понять, что продукт получился (KPI, OKR и прочее)? Как менеджеру проекта поставить цели, эффективно управлять процессом и достичь целей в разработке любого IT-продукта?
Об этом и не только практический онлайн-курс «Agile Project Manager в IT» от Otus. И 30 ноября в 20:00 преподаватель курса в Otus и Agile Coach расскажет о ключевых навыках проектного менеджера в IT и проведет обзор рынка вакансий. Также вы познакомитесь с программой и форматом обучения на этом практическом онлайн-курсе. Оставьте заявку, чтобы посетить встречу и задать свои вопросы эксперту в прямом эфире https://otus.pw/
1. OKR должны быть компактными. Не более страницы текста, в идеале полстраницы.
2. OKR это не to do-лист и не план работ. Если OKR выглядят таким образом, значит, их нужно переработать.
3. Хотя бы один OKR команды должен быть связан с глобальными целями компании. В противном случае непонятно, какое отношение команда имеет к бизнесу.
4. Приоритеты OKR внутри команды должны увеличивать вероятность достижения целей компании. Ключевая цель бизнеса не должна быть отражена в OKR команды последним пунктом.
5. Связанные инициативы должны быть согласованы. Разработка планирует выпустить продукт Z, а маркетинг обеспечить его продвижение. Если выпуск состоится в самом конце квартала, времени на его продвижение будет недостаточно.
6. Все глобальные обещания команды должны быть включены в ее OKR. Если другая команда предполагает, что отдел работает над целью X, а в действительности ничего такого не происходит — это проблема.
7. Цели не должны определять обычные и регулярные бизнес-задачи. Правда, Эффект Черной Королевы, когда нужно бежать чтобы оставаться на месте, никто не отменял. Если для сохранения достигнутых результатов требуется приложить экстраординарные усилия, в OKR отдела могут быть включены цели и по их штатной деятельности.
8. Достижение цели должно требовать усилий всего отдела или команды. В противном случае штат отдела раздут либо его сотрудники недостаточно мотивированы.
9. Достижение целей должно вести к существенной пользе бизнесу.
10. Определенные результаты должны быть достаточны для достижения цели. Если достижение цели определяется результатами недостаточными для признания ее успеха, это приведет как к реальным задержками в работе по причине отсутствия ресурсов в момент когда неучтенные требования проявятся, так и срыву планируемых сроков вследствие этого.
В чем разница в Проектном и продуктовом подходе? Что отличает продукт и как понять, что продукт получился (KPI, OKR и прочее)? Как менеджеру проекта поставить цели, эффективно управлять процессом и достичь целей в разработке любого IT-продукта?
Об этом и не только практический онлайн-курс «Agile Project Manager в IT» от Otus. И 30 ноября в 20:00 преподаватель курса в Otus и Agile Coach расскажет о ключевых навыках проектного менеджера в IT и проведет обзор рынка вакансий. Также вы познакомитесь с программой и форматом обучения на этом практическом онлайн-курсе. Оставьте заявку, чтобы посетить встречу и задать свои вопросы эксперту в прямом эфире https://otus.pw/
otus.ru
Курс по ведению IT проектов в методике Agile. Научитесь Scrum и Kanban
Станьте профессионалом в ведении IT проекты самостоятельно в популярной методике Agile, Scrum и Kanban. Пройдите курс в Otus и прокачайте навыки Agile Project Manager
В2b и b2c продукты – в чем особенности разработки?
-Работа продуктовика над b2b-приложением предполагает фокус на макротренды и длинные истории, а не на микротренды, моду, покупку здесь и сейчас, как в b2c. Важно, что для трансформации конкретного продукта можно сменить не только его тип, но и сегмент ЦА, ценообразование и т. д.
-В b2b и до продажи, и во время, и после сохраняется более плотное общение с клиентом, хотя правильнее, если канал коммуникации меняется с продаж на customer success, которые в свою очередь могут вернуть существующего клиента сейлам, но уже для пролонгации или апгрейда. Не надо вести себя, как b2c: забывать про клиента, провоцировать на отток и надеяться на одни новые фичи.
-Для b2b-продукта уже недостаточно просто отгружать товар или лицензию. Этим ничего не заканчивается. Необходимо залезать внутрь текущей базы и предоставлять сервис, то есть убедиться в том, что есть ценность от внедряемых решений, что основной сценарий, который лежит в основе процессов, дает результат.
-В b2b-компаниях в целом не всегда есть понимание своего продукта. Когда продуктовик идет опрашивать коллег, он получает совершенно разные ответы на довольно простые вопросы: кто у нас клиент, что у него болит, что мы ему предлагаем?
Хотите узнать больше трендов и специфики работы с b2b-клиентом? Много полезного расскажут 30 ноября на первом онлайн-митапе для product owner (PO) & product manager (PM) от X5Tech. Там поговорят об отличиях продуктов b2b от b2c, обсудят различия PM & PO, рассмотрят best practice по управлению b2b продуктом на примере используемых фреймворков.
Регистрация по ссылке - https://x5-retail-group-event.timepad.ru/event/1846645/
-Работа продуктовика над b2b-приложением предполагает фокус на макротренды и длинные истории, а не на микротренды, моду, покупку здесь и сейчас, как в b2c. Важно, что для трансформации конкретного продукта можно сменить не только его тип, но и сегмент ЦА, ценообразование и т. д.
-В b2b и до продажи, и во время, и после сохраняется более плотное общение с клиентом, хотя правильнее, если канал коммуникации меняется с продаж на customer success, которые в свою очередь могут вернуть существующего клиента сейлам, но уже для пролонгации или апгрейда. Не надо вести себя, как b2c: забывать про клиента, провоцировать на отток и надеяться на одни новые фичи.
-Для b2b-продукта уже недостаточно просто отгружать товар или лицензию. Этим ничего не заканчивается. Необходимо залезать внутрь текущей базы и предоставлять сервис, то есть убедиться в том, что есть ценность от внедряемых решений, что основной сценарий, который лежит в основе процессов, дает результат.
-В b2b-компаниях в целом не всегда есть понимание своего продукта. Когда продуктовик идет опрашивать коллег, он получает совершенно разные ответы на довольно простые вопросы: кто у нас клиент, что у него болит, что мы ему предлагаем?
Хотите узнать больше трендов и специфики работы с b2b-клиентом? Много полезного расскажут 30 ноября на первом онлайн-митапе для product owner (PO) & product manager (PM) от X5Tech. Там поговорят об отличиях продуктов b2b от b2c, обсудят различия PM & PO, рассмотрят best practice по управлению b2b продуктом на примере используемых фреймворков.
Регистрация по ссылке - https://x5-retail-group-event.timepad.ru/event/1846645/
Частые ошибки при постановке стратегии
Ошибка №1: цели = стратегия
Стратегия — про то, как победить команде. Цели — про то, что такое победа. Например, у шахматиста есть подробный набор шагов (т.е. стратегия) для победы в матче (т.е. достижения цели).
Например, компания говорит: «Наша стратегия – увеличить доход на 20%». Но увеличение дохода – это цель, а не стратегия. Способов увеличения дохода может быть несколько – например, выйти в новый сегмент рынка или увеличить конверсию с бесплатного пробного продукта на платный продукт.
Ошибка №2: достижение целей = выполнение стратегии
Стек продуктовой стратегии помогает командам отслеживать, насколько работа продуктовой команды способствует выполнению задач компании. В большинстве компаний для оценки эффективности используют краткосрочные цели, просто потому что так проще. Но достижение цели не обязательно означает прогресс в реализации стратегии. Цели могли поставить в отрыве от стратегии или исходя из неверных предположений. Кроме того, стратегия зависит от внешних факторов, таких как конкурентные действия и рыночные условия.
Ошибка №3: стратегия продукта = стратегия компании
Это приводит к неправильной оценке той роли, которую играют продажи, маркетинг, поддержка и другие подразделения. Да, продукт важен, но он — не единственная движущая сила стратегии. Важно, чтобы движение было согласованным на всех этапах и уровнях компании.
Ошибка №4: сначала цель, потом план
План развития продукта – ключевое условие для достижения цели.
Многие компании считают, что команда должна сначала поставить цели, а затем прикинуть, как их достичь. Но по факту такой подход побуждает команду достигать краткосрочных целей любыми способами, часто в ущерб целенаправленному набору фич, понятному UX и стратегическому прогрессу в долгосрочной перспективе. Цели должны вытекать из плана развития, составленного таким образом, чтобы приносить пользу пользователям.
Ошибка №1: цели = стратегия
Стратегия — про то, как победить команде. Цели — про то, что такое победа. Например, у шахматиста есть подробный набор шагов (т.е. стратегия) для победы в матче (т.е. достижения цели).
Например, компания говорит: «Наша стратегия – увеличить доход на 20%». Но увеличение дохода – это цель, а не стратегия. Способов увеличения дохода может быть несколько – например, выйти в новый сегмент рынка или увеличить конверсию с бесплатного пробного продукта на платный продукт.
Ошибка №2: достижение целей = выполнение стратегии
Стек продуктовой стратегии помогает командам отслеживать, насколько работа продуктовой команды способствует выполнению задач компании. В большинстве компаний для оценки эффективности используют краткосрочные цели, просто потому что так проще. Но достижение цели не обязательно означает прогресс в реализации стратегии. Цели могли поставить в отрыве от стратегии или исходя из неверных предположений. Кроме того, стратегия зависит от внешних факторов, таких как конкурентные действия и рыночные условия.
Ошибка №3: стратегия продукта = стратегия компании
Это приводит к неправильной оценке той роли, которую играют продажи, маркетинг, поддержка и другие подразделения. Да, продукт важен, но он — не единственная движущая сила стратегии. Важно, чтобы движение было согласованным на всех этапах и уровнях компании.
Ошибка №4: сначала цель, потом план
План развития продукта – ключевое условие для достижения цели.
Многие компании считают, что команда должна сначала поставить цели, а затем прикинуть, как их достичь. Но по факту такой подход побуждает команду достигать краткосрочных целей любыми способами, часто в ущерб целенаправленному набору фич, понятному UX и стратегическому прогрессу в долгосрочной перспективе. Цели должны вытекать из плана развития, составленного таким образом, чтобы приносить пользу пользователям.
Состав иерархии метрик
Это инструмент, в котором метрики выстраиваются в пирамиду.
Строгой структуры у нее нет, так как все меняется и перестраивается в зависимости от целей организации и самого продукта.
Внешне пирамида метрик напоминает пирамиду потребностей Маслоу. Суть та же — чтобы достичь верхней точки, нужно пройти все ступени, начиная с нижней:
⁃ Внизу пирамиды находятся платформенные метрики — это про техническую надежность вашего продукта и его доступность.
⁃ Дальше идут интерфейсные метрики. Это про взаимодействие пользователя с приложением, метрики эффективности рекламы, конверсия форм и кнопок.
⁃ Следующая ступень — непосредственно продуктовые метрики. Это про пользовательские сценарии, проще говоря, поведение людей в продукте. Здесь же средний чек от одного пользователя, время взаимодействия, лояльность, регулярность использования и возвращаемость.
⁃ На верхних уровнях пирамиды метрик находятся бизнес–цели. Доходы инвестиции и все, что связано с экономикой проекта. Здесь используем метрики, которые описывают потоки благ: материальные (конечно, деньги) и нематериальные блага (интерес, польза для людей). Например, из нематериальных это могут быть: время ожидания услуги, взвешенная конверсия покупок.
⁃ И венчает пирамиду метрика Всевластия, роста и она же метрика полярной звезды North Star Metric (NSM). Это выходная метрика, то есть показывает результат от всех остальных действий. Про нее я писал ранее - https://news.1rj.ru/str/FreshProductGo/57
Хотите узнать больше прикладных инструментов по продуктовой аналитике и общаться с аналитиком на одном языке? Приходите на Demo day курса "Продуктовая аналитика", 7 декабря в 20:00. На дне открытых дверей Вы сможете задать интересующие Вас вопросы о продуктовой аналитике.
Готовьте вопросы, оставляйте заявку и присоединяйтесь! https://otus.pw/Eqiv
Это инструмент, в котором метрики выстраиваются в пирамиду.
Строгой структуры у нее нет, так как все меняется и перестраивается в зависимости от целей организации и самого продукта.
Внешне пирамида метрик напоминает пирамиду потребностей Маслоу. Суть та же — чтобы достичь верхней точки, нужно пройти все ступени, начиная с нижней:
⁃ Внизу пирамиды находятся платформенные метрики — это про техническую надежность вашего продукта и его доступность.
⁃ Дальше идут интерфейсные метрики. Это про взаимодействие пользователя с приложением, метрики эффективности рекламы, конверсия форм и кнопок.
⁃ Следующая ступень — непосредственно продуктовые метрики. Это про пользовательские сценарии, проще говоря, поведение людей в продукте. Здесь же средний чек от одного пользователя, время взаимодействия, лояльность, регулярность использования и возвращаемость.
⁃ На верхних уровнях пирамиды метрик находятся бизнес–цели. Доходы инвестиции и все, что связано с экономикой проекта. Здесь используем метрики, которые описывают потоки благ: материальные (конечно, деньги) и нематериальные блага (интерес, польза для людей). Например, из нематериальных это могут быть: время ожидания услуги, взвешенная конверсия покупок.
⁃ И венчает пирамиду метрика Всевластия, роста и она же метрика полярной звезды North Star Metric (NSM). Это выходная метрика, то есть показывает результат от всех остальных действий. Про нее я писал ранее - https://news.1rj.ru/str/FreshProductGo/57
Хотите узнать больше прикладных инструментов по продуктовой аналитике и общаться с аналитиком на одном языке? Приходите на Demo day курса "Продуктовая аналитика", 7 декабря в 20:00. На дне открытых дверей Вы сможете задать интересующие Вас вопросы о продуктовой аналитике.
Готовьте вопросы, оставляйте заявку и присоединяйтесь! https://otus.pw/Eqiv
Telegram
Fresh Product Manager
#фрикометрика #метрики_роста
У любого продукта для меня всегда есть единственная метрика, которая наилучшим образом отражает основную ценность, которую ваш продукт предоставляет клиентам. Их называют North Star, Growth metrics.
Чтобы раскрыть ее, нужно понимать…
У любого продукта для меня всегда есть единственная метрика, которая наилучшим образом отражает основную ценность, которую ваш продукт предоставляет клиентам. Их называют North Star, Growth metrics.
Чтобы раскрыть ее, нужно понимать…
Когда действительно нужен проджект-менеджер для вашего продукта
Вам стоит нанять PM, если:
⁃ у вас большой проект со стойкой иерархией, а распоряжения поступают сверху вниз
⁃ продукт, который вы разрабатываете, требует плановой, но несрочной доработки
⁃ у вас большая и разношерстная команда
⁃ вам необходим человек, который будет работать и с продуктом, и с командой, и с вами
Вам стоит нанять Scrum-мастера, если:
⁃ вы только начинаете внедрять метод Scrum, у вас первые итерации
⁃ ваш проект очень динамичный и требует постоянных изменений, а значит работа спринтами будет более эффективной
⁃ вам необходим человек, который адаптирует гибкие методологии под ваш проект
В чем сильная отсройка проджекта от Scrum Master?
⁃ Менеджер проекта создает, управляет и обновляет все формы документации (краткое описание проекта, PID, бюджет, риски, план проекта, диаграмма Ганта и т. д). Scrum Master не создает, не управляет и не обновляет документацию вообще.
⁃ Менеджер проекта распределяет работу среди членов команды, учитывая их загрузку и доступное время.
⁃ Менеджер проекта также управляет областью деятельности стейкхолдеров. Scrum Master не имеет никакого отношения к продукту, он отвечает только за процесс, результат которого — успешный продукт.
⁃ Роль менеджера проекта достаточно широкая. Она содержит много разных обязанностей, которые иногда не имеют закрепленных описаний. Роль Scrum-мастера более сфокусирована, так как определяется Scrum Framework.
⁃ Одна из причин, по которой многие реализации Scrum терпят неудачу, заключается в том, что необходимый набор ролей не до конца понят организацией. Менеджер проекта может переквалифицироваться как в scrum-мастера, так и в владельца продукта, но это не универсальное решение.
Проектный менеджер больше не нужен? Это бесполезная работа или основа успеха любого проекта? Что считать результатом работы менеджера проектов? Когда без него можно обойтись, а когда — совсем никак? Взвесим все за и против на бесплатной конференции OTUS MeetUp 2 декабря в 18:00!
Кто будет участвовать в дебатах?
1. Проектный менеджер Юлия Белозерова
2. Продуктовый менеджер в Biglion Влас Старцев
3. Agile coach в Почте России Дмитрий Емельянов
Записывайтесь на мероприятие, чтобы не пропустить битву экспертов: https://otus.pw/K775/
Вам стоит нанять PM, если:
⁃ у вас большой проект со стойкой иерархией, а распоряжения поступают сверху вниз
⁃ продукт, который вы разрабатываете, требует плановой, но несрочной доработки
⁃ у вас большая и разношерстная команда
⁃ вам необходим человек, который будет работать и с продуктом, и с командой, и с вами
Вам стоит нанять Scrum-мастера, если:
⁃ вы только начинаете внедрять метод Scrum, у вас первые итерации
⁃ ваш проект очень динамичный и требует постоянных изменений, а значит работа спринтами будет более эффективной
⁃ вам необходим человек, который адаптирует гибкие методологии под ваш проект
В чем сильная отсройка проджекта от Scrum Master?
⁃ Менеджер проекта создает, управляет и обновляет все формы документации (краткое описание проекта, PID, бюджет, риски, план проекта, диаграмма Ганта и т. д). Scrum Master не создает, не управляет и не обновляет документацию вообще.
⁃ Менеджер проекта распределяет работу среди членов команды, учитывая их загрузку и доступное время.
⁃ Менеджер проекта также управляет областью деятельности стейкхолдеров. Scrum Master не имеет никакого отношения к продукту, он отвечает только за процесс, результат которого — успешный продукт.
⁃ Роль менеджера проекта достаточно широкая. Она содержит много разных обязанностей, которые иногда не имеют закрепленных описаний. Роль Scrum-мастера более сфокусирована, так как определяется Scrum Framework.
⁃ Одна из причин, по которой многие реализации Scrum терпят неудачу, заключается в том, что необходимый набор ролей не до конца понят организацией. Менеджер проекта может переквалифицироваться как в scrum-мастера, так и в владельца продукта, но это не универсальное решение.
Проектный менеджер больше не нужен? Это бесполезная работа или основа успеха любого проекта? Что считать результатом работы менеджера проектов? Когда без него можно обойтись, а когда — совсем никак? Взвесим все за и против на бесплатной конференции OTUS MeetUp 2 декабря в 18:00!
Кто будет участвовать в дебатах?
1. Проектный менеджер Юлия Белозерова
2. Продуктовый менеджер в Biglion Влас Старцев
3. Agile coach в Почте России Дмитрий Емельянов
Записывайтесь на мероприятие, чтобы не пропустить битву экспертов: https://otus.pw/K775/
Базовые приемы и инструмент для успешного бизнес-нетворкинга
Очень рекомендую провести вечер пятницы с пользой для своего будущего и скачать прямо сейчас это мобильное приложение. Вперед: https://tenchat.app/
И, конечно, мой профиль там - https://tenchat.ru/SergeyKoloskov
• Нетворкинг строится на доверии и на осознании взаимной выгоды.• Необходимо определить цели в участии в целевых мероприятиях и выбрать группы, которые помогут получить необходимое. Некоторые встречи основаны больше на обучении, установлении контактов, а не на исключительно деловых связях.• Стоит посетить столько мероприятий, сколько возможно. Нужно обратить внимание на тон и отношение группы. Стремятся ли люди поддерживать друг друга? Является ли руководство компетентным? Многие группы придется посетить несколько раз, прежде чем станет понятно, подходят ли они.• На встречах следует задавать вопросы, предполагающие развернутый ответ. Такие вопросы приводят к началу дискуссии, и собеседник осознаёт заинтересованность.• Необходимо понять свою ценность в глазах других. Когда люди признают кого-то в качестве авторитета, то постоянно обращаются за советами, контактами людей и так далее. Это поможет всегда быть на виду.• Стоит сформировать четкое понимание того, в чём состоит деятельность, почему, для кого и что отличает от конкурентов.• Зачастую люди в разговоре спрашивают: «Чем я могу помочь?». Необходимо понять, в чём ценность других. Ответ приходит не сразу.• Обязательно прислушиваться к обратной связи и быстро реагировать на нее. Уважать такие отзывы, ведь они могут показать недостатки, которые стоит исправить.• Стоит определить тех, кому можно принести выгоду своей деятельностью, и связаться с ними, назначить встречу, на которой можно обсудить идеи.• Активно наращивать деловые связи для нетворкинга в соцсети TenChat (русский LinkedIn). В несколько свайпов можно познакомиться с топ-менеджерами крупнейших компаний и банков РФ, а ещё найти бизнес-партнёров для запуска собственного стартап-проекта или просто прокачать скиллы изучая кейсы роста коллег в Ленте новостей. Вместо сотен тысяч классических и ненужных сервисов, главный фокус на миниаппах для заработка (в стиле WeChat) и все это бесплатно! Очень рекомендую провести вечер пятницы с пользой для своего будущего и скачать прямо сейчас это мобильное приложение. Вперед: https://tenchat.app/
И, конечно, мой профиль там - https://tenchat.ru/SergeyKoloskov
tenchat.ru
TenChat – соцсеть для поиска клиентов, работы и нетворкинга
TenChat — деловая соцсеть для поиска клиентов, работы и деловых контактов. Профиль как визитка, CV и портфолио. AI-поиск, бизнес-сервисы и нетворкинг без барьеров
Блоги на английском языке для продактов
Синди Альварес - Блог рассказывает о приемах, помогающих предпринимателям не терять связь с реальностью даже на стадии научных исследований. Не стоит полагаться на рассказы потребителей о том, что они намерены делать в будущем. Стратегия Синди строится на их сегодняшнем поведении.
Hiten Shah blog - Блог от создателя трёх SaaS компаний: Crazy Egg, KISSmetrics, Quick Sprout. Делится подборкой интересных статей в еженедельных письмах.
Продуктовые процессы, практики, кейсы
Roman Pichler — эксперт в продуктовом менеджменте, специализирующийся на диджитал-продуктах. У него более 15 лет опыта в обучении продуктовых менеджеров и владельцев продуктов и в помощи компаниям в построении успешного продуктового менеджмента. Пишет на разные темы, в том числе про построение продуктов, Scrum и Agile.
Продуктовые процессы, практики, Scrum и Agile
David Skok - Отличная коллекция по SaaS в целом, метрикам, росту и масштабированию бизнеса. SaaS, рост, масштабирование бизнеса
Jason Fried - Блог генерального директора Basecamp, соавтора Getting Real, Remote, REWORK. Хорошая подборка эссе о No bullshit подходе к продукту и командной работе.
Лидерство, стартап-мышление, производительность, командная работа
Brian Balfour and Reforge - Отличные статьи о росте продукта от генерального директора Reforge и бывшего вице-президента по росту в Hubspot.
Marty Cagan an SVPG - Блог пионера продуктового управления в Силиконовой долине.
Стартапы, продуктовое мышление
Product talk - Тереза, автор Product Talk и тренер по поиску продуктов, помогает командам получать ценную информацию из клиентских интервью, проводить эффективные продуктовые эксперименты и управлять результатами, которые создают ценность для клиентов и бизнеса. Она учит команды связывать исследовательскую деятельность и продуктовые решения, внушая уверенность, что они на правильном пути. Среди последних клиентов: CarMax, Snagajob, Spotify и Tesco.
Управление продуктами, развитие клиентов
Ken Norton - Кен — старший операционный партнер в GV, он руководит инвестиционными операциями и оказывает продуктовую и техническую поддержку портфельным компаниям GV. Компания GV, созданная в 2009 году как Google Ventures, является венчурным подразделением Alphabet, Inc. Кен тесно сотрудничал с сотнями портфельных компаний GV, включая Uber, Nest, Slack, Stripe, Gusto, Foundation Medicine и Flatiron Health.
Andrew Chen - Подробные эссе о стартапах, росте, метриках и сетевых эффектах.
Nir Eyal - Понимание поведения клиентов, рассылка. Психология
Product coalition - Крупнейшее в мире бесплатное PdM сообщество. Более 250 000 читателей. 2000+ статей. 300+ авторов. 3000+ участников в Slack.
Хотите выучить язык быстро, без зубрежки и узнавать все новости, фишки конкурентов в области продакт-менеджеров и из блогов ТОПов?
Это можно сделать на бесплатном марафоне English O’Clock за 7 дней вы поймёте, где также можно
научиться думать на языке и получить возможность приобрести новый опыт в англоязычной деловой среде и узнать, как преодолеть языковой барьер и без проблем коммуницировать с партнерами из разных стран
Отсутствие навыков разговорного английского - не повод соглашаться на менее привлекательные перспективы в работе. Учиться без лишней теории и онлайн-тренажеров, с максимальной отработкой пройденного материала можно на курсах с авторской методикой Андрея Гуляева.
Протестировать эффективность вы можете на марафоне English O’Clock Зарегистрируйтесь сейчас и получите 15-минутный урок с преподавателем бонусом - https://clck.ru/Yvqhn
Синди Альварес - Блог рассказывает о приемах, помогающих предпринимателям не терять связь с реальностью даже на стадии научных исследований. Не стоит полагаться на рассказы потребителей о том, что они намерены делать в будущем. Стратегия Синди строится на их сегодняшнем поведении.
Hiten Shah blog - Блог от создателя трёх SaaS компаний: Crazy Egg, KISSmetrics, Quick Sprout. Делится подборкой интересных статей в еженедельных письмах.
Продуктовые процессы, практики, кейсы
Roman Pichler — эксперт в продуктовом менеджменте, специализирующийся на диджитал-продуктах. У него более 15 лет опыта в обучении продуктовых менеджеров и владельцев продуктов и в помощи компаниям в построении успешного продуктового менеджмента. Пишет на разные темы, в том числе про построение продуктов, Scrum и Agile.
Продуктовые процессы, практики, Scrum и Agile
David Skok - Отличная коллекция по SaaS в целом, метрикам, росту и масштабированию бизнеса. SaaS, рост, масштабирование бизнеса
Jason Fried - Блог генерального директора Basecamp, соавтора Getting Real, Remote, REWORK. Хорошая подборка эссе о No bullshit подходе к продукту и командной работе.
Лидерство, стартап-мышление, производительность, командная работа
Brian Balfour and Reforge - Отличные статьи о росте продукта от генерального директора Reforge и бывшего вице-президента по росту в Hubspot.
Marty Cagan an SVPG - Блог пионера продуктового управления в Силиконовой долине.
Стартапы, продуктовое мышление
Product talk - Тереза, автор Product Talk и тренер по поиску продуктов, помогает командам получать ценную информацию из клиентских интервью, проводить эффективные продуктовые эксперименты и управлять результатами, которые создают ценность для клиентов и бизнеса. Она учит команды связывать исследовательскую деятельность и продуктовые решения, внушая уверенность, что они на правильном пути. Среди последних клиентов: CarMax, Snagajob, Spotify и Tesco.
Управление продуктами, развитие клиентов
Ken Norton - Кен — старший операционный партнер в GV, он руководит инвестиционными операциями и оказывает продуктовую и техническую поддержку портфельным компаниям GV. Компания GV, созданная в 2009 году как Google Ventures, является венчурным подразделением Alphabet, Inc. Кен тесно сотрудничал с сотнями портфельных компаний GV, включая Uber, Nest, Slack, Stripe, Gusto, Foundation Medicine и Flatiron Health.
Andrew Chen - Подробные эссе о стартапах, росте, метриках и сетевых эффектах.
Nir Eyal - Понимание поведения клиентов, рассылка. Психология
Product coalition - Крупнейшее в мире бесплатное PdM сообщество. Более 250 000 читателей. 2000+ статей. 300+ авторов. 3000+ участников в Slack.
Хотите выучить язык быстро, без зубрежки и узнавать все новости, фишки конкурентов в области продакт-менеджеров и из блогов ТОПов?
Это можно сделать на бесплатном марафоне English O’Clock за 7 дней вы поймёте, где также можно
научиться думать на языке и получить возможность приобрести новый опыт в англоязычной деловой среде и узнать, как преодолеть языковой барьер и без проблем коммуницировать с партнерами из разных стран
Отсутствие навыков разговорного английского - не повод соглашаться на менее привлекательные перспективы в работе. Учиться без лишней теории и онлайн-тренажеров, с максимальной отработкой пройденного материала можно на курсах с авторской методикой Андрея Гуляева.
Протестировать эффективность вы можете на марафоне English O’Clock Зарегистрируйтесь сейчас и получите 15-минутный урок с преподавателем бонусом - https://clck.ru/Yvqhn
dont-speak.ru
Марафон English O'Clock
Бесплатный онлайн-курс для тех, кто хочет заговорить на английском
Chief Product Officer (CPO): цель, роль и ключевые обязанности
Цель CPO заключается в создании востребованного продукта, обеспечивающего устойчивую ценность для бизнеса и пользу для потребителя.
Основной задачей CPO является создание определенных рамок и принципов, благодаря которым другие смогут принимать грамотные продуктовые решения.
Роль CPO в компаниях различного типа
В стартапах численностью до 25 человек CPO может управлять 1-3 продуктовыми командами. Как правило, он является сооснователем компании, и его цель — создать продукт, который нужен рынку «здесь и сейчас».
В растущих компаниях, где численность сотрудников от 25 до 500 человек, в подчинении у CPO до 10 команд. Цель — совершенствование продукта.
В корпорациях, в которых работает свыше 500 человек, CPO руководит 10+ командами. Главная цель — инновации и создание новых продуктов.
Ключевые обязанности
⁃ Управление несколькими продуктами (пользователи продуктом - малый и средний бизнес) с целью увеличения доходности по их направлениям. Например: платежные системы, интеграция с банком, ЭДО, 1С
⁃ Анализ рынка, выявление потребности рынка (взаимодействие с отделом маркетинга)
⁃ Формирование продукта (взаимодействие с разработчиками, тестировщиками, бизнес-аналитиками)
⁃ Продвижение продукта на рынок среди клиентов (существующих, потенциальных)
Вы - СРО, Head of product, руководитель направления в крупной компании или CEO стартапа? Поделитесь своим опытом с Практикумом.
Сейчас коллеги проводят исследование аудитории, чтобы создать проект, который будет действительно полезен рынку. Это нужно, чтобы понять, как видят образование состоявшиеся специалисты, где они смотрят и читают материалы о профессиональной деятельности.
Если вы не против поделиться с нами информацией, пройдите опрос, перейдя по ссылке.
В благодарность мы поделимся с вами результатами исследования, и вышлем самый ранний анонс программы вам на почту.
Цель CPO заключается в создании востребованного продукта, обеспечивающего устойчивую ценность для бизнеса и пользу для потребителя.
Основной задачей CPO является создание определенных рамок и принципов, благодаря которым другие смогут принимать грамотные продуктовые решения.
Роль CPO в компаниях различного типа
В стартапах численностью до 25 человек CPO может управлять 1-3 продуктовыми командами. Как правило, он является сооснователем компании, и его цель — создать продукт, который нужен рынку «здесь и сейчас».
В растущих компаниях, где численность сотрудников от 25 до 500 человек, в подчинении у CPO до 10 команд. Цель — совершенствование продукта.
В корпорациях, в которых работает свыше 500 человек, CPO руководит 10+ командами. Главная цель — инновации и создание новых продуктов.
Ключевые обязанности
⁃ Управление несколькими продуктами (пользователи продуктом - малый и средний бизнес) с целью увеличения доходности по их направлениям. Например: платежные системы, интеграция с банком, ЭДО, 1С
⁃ Анализ рынка, выявление потребности рынка (взаимодействие с отделом маркетинга)
⁃ Формирование продукта (взаимодействие с разработчиками, тестировщиками, бизнес-аналитиками)
⁃ Продвижение продукта на рынок среди клиентов (существующих, потенциальных)
Вы - СРО, Head of product, руководитель направления в крупной компании или CEO стартапа? Поделитесь своим опытом с Практикумом.
Сейчас коллеги проводят исследование аудитории, чтобы создать проект, который будет действительно полезен рынку. Это нужно, чтобы понять, как видят образование состоявшиеся специалисты, где они смотрят и читают материалы о профессиональной деятельности.
Если вы не против поделиться с нами информацией, пройдите опрос, перейдя по ссылке.
В благодарность мы поделимся с вами результатами исследования, и вышлем самый ранний анонс программы вам на почту.
Тонкости подходов при управлении сроками релизов
1. Большие релизы или долгострои
Стабильность. Каждое обновление существующей функциональности — небольшое потрясение для обычных пользователей, большинство из которых не желает перемен. Для них проще пережить стресс пару раз в год, чем серию мелких изменений, происходящих постоянно.
Управляемость. У большого релиза есть запланированная дата, к которой он должен быть выпущен. Отставание от нее показывает, насколько плохо обстоят дела. При необходимости из большого релиза можно выкидывать отдельные функции, которые мешают его готовности, но в целом само наличие плановой даты дисциплинирует.
PR-эффект. Большое обновление — это событие и отличный инфоповод.
Задержки. На практике постоянно сталкиваются с тем, что реализация одной-двух сложных функций растягивалась на непредсказуемое время. Из-за этого приходится задерживать весь релиз, в котором могли быть десятки готовых опций и багфиксов.
Неконтролируемая сложность. Одновременный выпуск нескольких новых функций приводит к тому, что сразу после релиза можно получить большое количество сообщений об ошибках. Работа над ними останавливает нормальный процесс разработки на одну-две недели.
Медленная реакция. После выхода новой функции почти всегда получаем обратную связь — информацию о том, что нужно улучшить в реализации. В результате пользователи получают исправление только через пару месяцев.
2. Непрерывные релизы
Функции не ждут друг друга. Как только протестирован новый функционал, он попадает на продакшн. Ему не приходится ждать готовности управления правами пользователей и еще нескольких десятков изменений.
Оперативная реакция. Если мы выпускаем новую функцию и сразу понимаем, как ее нужно улучшить, изменения выходят на следующий день. Этот процесс намного лучше подходит для модели lean startup и концепции постоянных экспериментов с изменением продукта.
Обновления четко делятся на платформенные и функциональные. При платформенных изменениях, когда меняется какая-то технология или внутренняя архитектура, нужно откатиться к предыдущей версии, чтобы потом спокойно разобраться. При непрерывном выпуске обновлений у не возникает задачи сделать один релиз платформенным, а другой — с новыми функциями.
Больше ресурсов на тестирование и выпуск релизов. Вполне реально полностью протестировать продукт вручную два раза в год, но делать это каждый день уже невозможно. Решение уже давно найдено и отлично работает — это автоматические тесты.
Сползание графика. Теперь у релизов нет плановых дат, поскольку по факту нет и самих релизов. Вместо одного большого проекта «выпустить релиз к 25 мая», мы получаем сотню мини- и микропроектов в виде отдельных тикетов.
Главная боль в обоих подходах разработки остается ответ на вопрос «Когда будет готово?». Хотите прокачаться в этой дисциплине?
14 декабря в 20:00 пройдет вебинар «Как уточнять статусы задач и подружиться с соседями» с Юлией Белозеровой, Technical Program Manager. Юлия расскажет, как проактивно делиться новостями о проекте и задачах, чтобы всем было комфортно.
На открытом уроке мы разберем, как:
- Коммуницировать так, чтобы вас не переспрашивали, даже если вы не знаете, сколько времени займет задача
- Рассказывать о проектных проблемах, чтобы в вас не кидались помидорами
- Выстраивать и чинить отношения с соседними командами, если вы инженер
- Задавать вопрос: «Когда будет готово?», чтобы не злить команду
Вебинар пройдет в рамках онлайн-курса «Agile Project Manager» и будет полезен инженерам, тимлидам и проектным менеджерам. Чтобы попасть на мероприятие, нужно зарегистрироваться https://otus.pw/ylC9/
1. Большие релизы или долгострои
Стабильность. Каждое обновление существующей функциональности — небольшое потрясение для обычных пользователей, большинство из которых не желает перемен. Для них проще пережить стресс пару раз в год, чем серию мелких изменений, происходящих постоянно.
Управляемость. У большого релиза есть запланированная дата, к которой он должен быть выпущен. Отставание от нее показывает, насколько плохо обстоят дела. При необходимости из большого релиза можно выкидывать отдельные функции, которые мешают его готовности, но в целом само наличие плановой даты дисциплинирует.
PR-эффект. Большое обновление — это событие и отличный инфоповод.
Задержки. На практике постоянно сталкиваются с тем, что реализация одной-двух сложных функций растягивалась на непредсказуемое время. Из-за этого приходится задерживать весь релиз, в котором могли быть десятки готовых опций и багфиксов.
Неконтролируемая сложность. Одновременный выпуск нескольких новых функций приводит к тому, что сразу после релиза можно получить большое количество сообщений об ошибках. Работа над ними останавливает нормальный процесс разработки на одну-две недели.
Медленная реакция. После выхода новой функции почти всегда получаем обратную связь — информацию о том, что нужно улучшить в реализации. В результате пользователи получают исправление только через пару месяцев.
2. Непрерывные релизы
Функции не ждут друг друга. Как только протестирован новый функционал, он попадает на продакшн. Ему не приходится ждать готовности управления правами пользователей и еще нескольких десятков изменений.
Оперативная реакция. Если мы выпускаем новую функцию и сразу понимаем, как ее нужно улучшить, изменения выходят на следующий день. Этот процесс намного лучше подходит для модели lean startup и концепции постоянных экспериментов с изменением продукта.
Обновления четко делятся на платформенные и функциональные. При платформенных изменениях, когда меняется какая-то технология или внутренняя архитектура, нужно откатиться к предыдущей версии, чтобы потом спокойно разобраться. При непрерывном выпуске обновлений у не возникает задачи сделать один релиз платформенным, а другой — с новыми функциями.
Больше ресурсов на тестирование и выпуск релизов. Вполне реально полностью протестировать продукт вручную два раза в год, но делать это каждый день уже невозможно. Решение уже давно найдено и отлично работает — это автоматические тесты.
Сползание графика. Теперь у релизов нет плановых дат, поскольку по факту нет и самих релизов. Вместо одного большого проекта «выпустить релиз к 25 мая», мы получаем сотню мини- и микропроектов в виде отдельных тикетов.
Главная боль в обоих подходах разработки остается ответ на вопрос «Когда будет готово?». Хотите прокачаться в этой дисциплине?
14 декабря в 20:00 пройдет вебинар «Как уточнять статусы задач и подружиться с соседями» с Юлией Белозеровой, Technical Program Manager. Юлия расскажет, как проактивно делиться новостями о проекте и задачах, чтобы всем было комфортно.
На открытом уроке мы разберем, как:
- Коммуницировать так, чтобы вас не переспрашивали, даже если вы не знаете, сколько времени займет задача
- Рассказывать о проектных проблемах, чтобы в вас не кидались помидорами
- Выстраивать и чинить отношения с соседними командами, если вы инженер
- Задавать вопрос: «Когда будет готово?», чтобы не злить команду
Вебинар пройдет в рамках онлайн-курса «Agile Project Manager» и будет полезен инженерам, тимлидам и проектным менеджерам. Чтобы попасть на мероприятие, нужно зарегистрироваться https://otus.pw/ylC9/
Занимательные числа в работе продакт-менеджера
При поддержке канала Венчур в картинках - https://news.1rj.ru/str/ventureinpics
⁃ Разработчики тратят до 50% времени на переделывание проектов. Ключевая причина - изначально плохая продуктовая проработка.
⁃ 60% пользователей откажутся от любимого продукта, если 2-3 раза получат негативный опыт использования. 15% откажутся после одного случая.
⁃ 70% товаров остаются брошенными в корзинах пользователей. Лишь 7% из них могут быть выкуплены в течение полугода
⁃ Около 60% пользователей предпочитает мобильные приложения для первой и последующих покупок, а не сайт.
⁃ В течение первых трех дней после установки приложение для В2С клиентов теряет в среднем 75% пользователей. Через 30 дней оно теряет 90% пользователей, а через 90 дней — более 95%.
⁃ Привлечение 1% новых пользователей повысит доход лишь на 3%. Повышение ARPU на 1% в 4.3 раза более выгодно, а снижение оттока пользователей на 1% в 2.3 раза более выгодно.
⁃ Для среднего продукта с аудиторией от 200 000 в день, DAU/MAU — 10-20%, для высокоэффективных продуктов — 50%.
⁃ Вероятность, что пользователи iOS купят что-то в приложении выше на 50% по сравнению с пользователями Android.
⁃ Видео помогает убедить 70% пользователей купить продукт или услугу.
Цифры помогают продактам принимать решения. Рекомендую крутой источник - канал Венчур в картинках. Ныряйте в статистику - https://news.1rj.ru/str/ventureinpics
При поддержке канала Венчур в картинках - https://news.1rj.ru/str/ventureinpics
⁃ Разработчики тратят до 50% времени на переделывание проектов. Ключевая причина - изначально плохая продуктовая проработка.
⁃ 60% пользователей откажутся от любимого продукта, если 2-3 раза получат негативный опыт использования. 15% откажутся после одного случая.
⁃ 70% товаров остаются брошенными в корзинах пользователей. Лишь 7% из них могут быть выкуплены в течение полугода
⁃ Около 60% пользователей предпочитает мобильные приложения для первой и последующих покупок, а не сайт.
⁃ В течение первых трех дней после установки приложение для В2С клиентов теряет в среднем 75% пользователей. Через 30 дней оно теряет 90% пользователей, а через 90 дней — более 95%.
⁃ Привлечение 1% новых пользователей повысит доход лишь на 3%. Повышение ARPU на 1% в 4.3 раза более выгодно, а снижение оттока пользователей на 1% в 2.3 раза более выгодно.
⁃ Для среднего продукта с аудиторией от 200 000 в день, DAU/MAU — 10-20%, для высокоэффективных продуктов — 50%.
⁃ Вероятность, что пользователи iOS купят что-то в приложении выше на 50% по сравнению с пользователями Android.
⁃ Видео помогает убедить 70% пользователей купить продукт или услугу.
Цифры помогают продактам принимать решения. Рекомендую крутой источник - канал Венчур в картинках. Ныряйте в статистику - https://news.1rj.ru/str/ventureinpics
Telegram
Венчур в картинках
Инфографики о стартапах, инвестициях, венчурной экономике.
Для связи: @notaware
РКН: https://clck.ru/3JwfMf
Для связи: @notaware
РКН: https://clck.ru/3JwfMf
Какие когорты точно надо построить для роста метрик в продукте
-Продолжительность нахождения всей когорты на сайте.
-Количество достигнутых группой целей
-Доход, полученный от этой группы.
-Колебания численности посетителей на сайте за отрезок времени.
-Изменение числа просмотров страниц.
-Определение общего количества посещений, а также выделение в отдельную ячейку показателей динамики посещений одним клиентом.
-График, демонстрирующий транзакции посетителей.
-Выведение в отдельную ячейку среднего показателя времени пребывания на сайте одним пользователем.
-Средний показатель достижения цели одним посетителем.
-Средняя цифра дохода для одного клиента.
-Средний показатель, отражающий просмотры сайта одним клиентом.
-Средний показатель, отражающий нахождение на сайте одним посетителем.
-Средняя цифра совершенных операций одним человеком.
Сужение групп:
-С общей датой первого посещения.
-Общей датой оформления заявки.
-Общей датой первой оплаты.
-Сколько лет клиентам.
-Мужчины это или женщины.
-Где проживают.
-Кем работают.
-Откуда о вас узнали.
-На каком этапе сделки находятся.
-Имеют ли специальный купон или скидку.
-Почему не завершили сделку.
-Что стало причиной возврата.
Хотите научить эффективно применять когортный анализ? Приходите на Demo-урок "Когортный анализ и сегментация", 14 декабря в 20:00. На занятии вы узнаете о, пожалуй, основных рабочих инструментах аналитика - когортный анализ и сегментация. На примерах реальных компаний поймем почему и когда нужны эти виды анализа и к каким ошибкам может привести отсутствие практики их применения. По ходу занятия вы научитесь использовать эти аналитические подходы, а также будете знать какие самые распространенные варианты сегментов и когорт используются в продуктовой аналитике.
По ссылке - https://otus.pw/D5oM/
-Продолжительность нахождения всей когорты на сайте.
-Количество достигнутых группой целей
-Доход, полученный от этой группы.
-Колебания численности посетителей на сайте за отрезок времени.
-Изменение числа просмотров страниц.
-Определение общего количества посещений, а также выделение в отдельную ячейку показателей динамики посещений одним клиентом.
-График, демонстрирующий транзакции посетителей.
-Выведение в отдельную ячейку среднего показателя времени пребывания на сайте одним пользователем.
-Средний показатель достижения цели одним посетителем.
-Средняя цифра дохода для одного клиента.
-Средний показатель, отражающий просмотры сайта одним клиентом.
-Средний показатель, отражающий нахождение на сайте одним посетителем.
-Средняя цифра совершенных операций одним человеком.
Сужение групп:
-С общей датой первого посещения.
-Общей датой оформления заявки.
-Общей датой первой оплаты.
-Сколько лет клиентам.
-Мужчины это или женщины.
-Где проживают.
-Кем работают.
-Откуда о вас узнали.
-На каком этапе сделки находятся.
-Имеют ли специальный купон или скидку.
-Почему не завершили сделку.
-Что стало причиной возврата.
Хотите научить эффективно применять когортный анализ? Приходите на Demo-урок "Когортный анализ и сегментация", 14 декабря в 20:00. На занятии вы узнаете о, пожалуй, основных рабочих инструментах аналитика - когортный анализ и сегментация. На примерах реальных компаний поймем почему и когда нужны эти виды анализа и к каким ошибкам может привести отсутствие практики их применения. По ходу занятия вы научитесь использовать эти аналитические подходы, а также будете знать какие самые распространенные варианты сегментов и когорт используются в продуктовой аналитике.
По ссылке - https://otus.pw/D5oM/
otus.ru
Практический онлайн-курс продуктовая аналитика
Научитесь решать задачи продуктового анализа: работа с SQL и Python + AB-тестирование + визуализация данных и сделайте следующий шаг в своей карьере
3 критерия для быстрой оценки работы Скрам-мастера
Скрам-мастер не производит конечный продукт, но предоставляет услуги по организации процесса команде, Владельцу продукта и компании в целом. Поэтому оценивать его работу следует как сервис.
Для быстрой оценки можно исходить из следующих показателей:
1. Обратная связь от Владельца продукта и команды — основных «клиентов» Скрам-мастера. Как он помогает решать проблемы, возникающие у членов команды? Насколько им комфортно работать со Скрам-мастером. И главное — в чем они видят пользу от совместной работы?
Чтобы обратная связь получилась измеряемой, вы можете попросить коллег заполнить радарную диаграмму или опросник. Мы рекомендуем включить в него параметры по каждой из четырех ролей Скрам-мастера: фасилитатор, коуч, учитель, наставник.
2. Насколько Скрам-мастер является проводником Agile в команде.
Прямые обязанности Скрам-мастера — помогать команде и всем заинтересованным лицам понять теорию Scrum и наладить его правильное применение, способствовать внедрению Scrum в организации, поддерживать мотивацию людей. Поэтому проведение скрам-мастером митапов, внутреннего обучения и других активностей по привнесению новых знаний весьма показательно.
3. Насколько эффективно организован процесс в команде.
Проводятся все предусмотренные scrum-гайдом встречи — дейли, планирование, backlog refinement, демо, ретроспектива, — бэклог поддерживается в актуальном состоянии, размер спринта фиксирован и тд.
Основные моменты, на которые важно обратить внимание:
- Митинги проводятся эффективно: например, стендап укладывается в 15 минут и он действительно полезен всем участникам команды.
- Команда непрерывно улучшает свой процесс: выявляются и анализируются проблемы, находятся и внедряются их решения.
- Скорость команды стабильна или увеличивается. Объем ценности, который команда поставляет в конце спринта, постепенно растет.
На рынке труда нет однозначного ответа на вопрос, кто такой скрам-мастер, за что он отвечает и как стоит оценивать эффективность его работы. 23 декабря в 20:00 можно во всем разобраться! В OTUS пройдет вебинар «За что отвечает скрам-мастер и как померить его эффективность?».
На demo-занятии мы обсудим и постараемся прийти к общему знаменателю в вопросе о том, какие способы могут навредить при попытке оценить эффективность, а какие могут способствовать росту его как профессионала, его команды, продакта и организации в целом.
Проведет урок Дмитрий Емельянов, руководитель курса Agile Project Manager, первый в России Certified Team Coach (CTC by Scrum Alliance). Присоединяйтесь! https://otus.pw/WpCO/
Скрам-мастер не производит конечный продукт, но предоставляет услуги по организации процесса команде, Владельцу продукта и компании в целом. Поэтому оценивать его работу следует как сервис.
Для быстрой оценки можно исходить из следующих показателей:
1. Обратная связь от Владельца продукта и команды — основных «клиентов» Скрам-мастера. Как он помогает решать проблемы, возникающие у членов команды? Насколько им комфортно работать со Скрам-мастером. И главное — в чем они видят пользу от совместной работы?
Чтобы обратная связь получилась измеряемой, вы можете попросить коллег заполнить радарную диаграмму или опросник. Мы рекомендуем включить в него параметры по каждой из четырех ролей Скрам-мастера: фасилитатор, коуч, учитель, наставник.
2. Насколько Скрам-мастер является проводником Agile в команде.
Прямые обязанности Скрам-мастера — помогать команде и всем заинтересованным лицам понять теорию Scrum и наладить его правильное применение, способствовать внедрению Scrum в организации, поддерживать мотивацию людей. Поэтому проведение скрам-мастером митапов, внутреннего обучения и других активностей по привнесению новых знаний весьма показательно.
3. Насколько эффективно организован процесс в команде.
Проводятся все предусмотренные scrum-гайдом встречи — дейли, планирование, backlog refinement, демо, ретроспектива, — бэклог поддерживается в актуальном состоянии, размер спринта фиксирован и тд.
Основные моменты, на которые важно обратить внимание:
- Митинги проводятся эффективно: например, стендап укладывается в 15 минут и он действительно полезен всем участникам команды.
- Команда непрерывно улучшает свой процесс: выявляются и анализируются проблемы, находятся и внедряются их решения.
- Скорость команды стабильна или увеличивается. Объем ценности, который команда поставляет в конце спринта, постепенно растет.
На рынке труда нет однозначного ответа на вопрос, кто такой скрам-мастер, за что он отвечает и как стоит оценивать эффективность его работы. 23 декабря в 20:00 можно во всем разобраться! В OTUS пройдет вебинар «За что отвечает скрам-мастер и как померить его эффективность?».
На demo-занятии мы обсудим и постараемся прийти к общему знаменателю в вопросе о том, какие способы могут навредить при попытке оценить эффективность, а какие могут способствовать росту его как профессионала, его команды, продакта и организации в целом.
Проведет урок Дмитрий Емельянов, руководитель курса Agile Project Manager, первый в России Certified Team Coach (CTC by Scrum Alliance). Присоединяйтесь! https://otus.pw/WpCO/
otus.ru
Курс по ведению IT проектов в методике Agile. Научитесь Scrum и Kanban
Станьте профессионалом в ведении IT проекты самостоятельно в популярной методике Agile, Scrum и Kanban. Пройдите курс в Otus и прокачайте навыки Agile Project Manager