3 классных вывода из канала @productgames
У Кристины Гусевой (продуктолога из ВТБ) хороший аутентичный канал с интересными продуктовыми мыслями. Захотел поделиться со своими подписчиками:
1. Интуиция - это накопленный опыт. В случае с наймом - это опыт интерпретации вербальных и невербальных сигналов человека и построение на их основе его портрета. Ее можно «прокачать» насмотренностью, тренировками и другими подобными способами. Также ее можно, как минимум, принимать во внимание при принятии важных решений.
2. В качестве единственной целевой метрики MAU не очень хорош, так как стимулирует прибегать к методам, обеспечивающих рост в краткосроке. Дополнительно при оценке MAU стоит учитывать следующее:
-Сходимость экономики. Сам по себе высокий MAU ничего не говорит о финансовом успехе продукта. В продукте может быть большое количество активных пользователей, но экономически эффекта от этого не будет.
-Адекватность для сферы. Например, высокий MAU в страховом бизнесе может отражать проблемы в скоринге клиентов: у пользователей часто возникают страховые случаи. А вот для игры высокий MAU будет скорее отражать популярность среди игроков.
-Воздействие внешних факторов. Если в предыдущем месяце MAU был 100, а в текущем - 1000, то на рост могли повлиять внешние факторы, а не рост качества продукта.
3. За одним успехом стоит серия провалов. Поэтому если хочешь достичь цели не давай неудачам демотивировать себя - это контрпродуктивно. Не сработала гипотеза, не получилось попасть в музыку в танце - пробуй еще.
Подписывайтесь - https://news.1rj.ru/str/productgames
У Кристины Гусевой (продуктолога из ВТБ) хороший аутентичный канал с интересными продуктовыми мыслями. Захотел поделиться со своими подписчиками:
1. Интуиция - это накопленный опыт. В случае с наймом - это опыт интерпретации вербальных и невербальных сигналов человека и построение на их основе его портрета. Ее можно «прокачать» насмотренностью, тренировками и другими подобными способами. Также ее можно, как минимум, принимать во внимание при принятии важных решений.
2. В качестве единственной целевой метрики MAU не очень хорош, так как стимулирует прибегать к методам, обеспечивающих рост в краткосроке. Дополнительно при оценке MAU стоит учитывать следующее:
-Сходимость экономики. Сам по себе высокий MAU ничего не говорит о финансовом успехе продукта. В продукте может быть большое количество активных пользователей, но экономически эффекта от этого не будет.
-Адекватность для сферы. Например, высокий MAU в страховом бизнесе может отражать проблемы в скоринге клиентов: у пользователей часто возникают страховые случаи. А вот для игры высокий MAU будет скорее отражать популярность среди игроков.
-Воздействие внешних факторов. Если в предыдущем месяце MAU был 100, а в текущем - 1000, то на рост могли повлиять внешние факторы, а не рост качества продукта.
3. За одним успехом стоит серия провалов. Поэтому если хочешь достичь цели не давай неудачам демотивировать себя - это контрпродуктивно. Не сработала гипотеза, не получилось попасть в музыку в танце - пробуй еще.
Подписывайтесь - https://news.1rj.ru/str/productgames
Telegram
Product games с Кристиной Гусевой
Продакт-менеджер в New Yorker в Германии, ex-менеджер продукта в ВТБ ❤️
Рассказываю о карьере, делюсь, как строить продукты, которые пользователи полюбят
Сотрудничество - @KriGuseva
№ 4781101660
Рассказываю о карьере, делюсь, как строить продукты, которые пользователи полюбят
Сотрудничество - @KriGuseva
№ 4781101660
Про исследование рынка продакт-менеджеров
VK и Podlodka провели большое исследование рынка продакт-менеджеров, опросили 630 продактов и узнали много всего интересного: какие навыки им нужны для работы, какими сложными активностями они занимаются, какие книги читают, в каких компаниях хотели бы работать и кучу других вещей. Вот ключевые для меня пункты:
1. По каким критериям в вашей компании оценивается работа продакта?
-Конкретные выполненные задачи — 54,8%
-Конкретные продуктовые метрики — 41,9%
-OKR — 35,4%
-Прибыль — 31%
-Соблюдение сроков — 29,4%
-ROI — 8,3%
2. Работа в какой команде продакт-менеджеров кажется вам наиболее привлекательной?
-Miro
-Тинькофф
-Авито и вакансии тут.
-Skyeng
-Aviasales
-Сбер
-Ozon
3. Что характеризует лучшие продуктовые команды (Авито, Миро, Skyeng)?
⁃ нет стейкхолдеров, которые дают продакт-менеджерам задачи без обоснования на цифрах, просто «потому что надо». Только данные и пользователи диктуют команде, что делать.
⁃ Команды сами определяют, чем они должны заниматься, и формулируют это в виде OKR (Objective and Key Results).
⁃ продакт действует как предприниматель и занят только продуктовыми задачами.
4. Что из того, чем вы или ваши коллеги занимаетесь регулярно, кажется вам наиболее бесполезной активностью?
-Встречи и созвоны – 23,8%
-Согласования и политика – 6,4%
-Отчетность – 5,9%
-Работа с документами и подготовка презентаций – 5,6%
-Отсутствие фокусировки или смысла – 4,1%
А если хотите попробовать свои силы в крутой продуктовой среде, оценить свой опыт и скиллы, приходите, например, сюда https://product.avito.ru/
VK и Podlodka провели большое исследование рынка продакт-менеджеров, опросили 630 продактов и узнали много всего интересного: какие навыки им нужны для работы, какими сложными активностями они занимаются, какие книги читают, в каких компаниях хотели бы работать и кучу других вещей. Вот ключевые для меня пункты:
1. По каким критериям в вашей компании оценивается работа продакта?
-Конкретные выполненные задачи — 54,8%
-Конкретные продуктовые метрики — 41,9%
-OKR — 35,4%
-Прибыль — 31%
-Соблюдение сроков — 29,4%
-ROI — 8,3%
2. Работа в какой команде продакт-менеджеров кажется вам наиболее привлекательной?
-Miro
-Тинькофф
-Авито и вакансии тут.
-Skyeng
-Aviasales
-Сбер
-Ozon
3. Что характеризует лучшие продуктовые команды (Авито, Миро, Skyeng)?
⁃ нет стейкхолдеров, которые дают продакт-менеджерам задачи без обоснования на цифрах, просто «потому что надо». Только данные и пользователи диктуют команде, что делать.
⁃ Команды сами определяют, чем они должны заниматься, и формулируют это в виде OKR (Objective and Key Results).
⁃ продакт действует как предприниматель и занят только продуктовыми задачами.
4. Что из того, чем вы или ваши коллеги занимаетесь регулярно, кажется вам наиболее бесполезной активностью?
-Встречи и созвоны – 23,8%
-Согласования и политика – 6,4%
-Отчетность – 5,9%
-Работа с документами и подготовка презентаций – 5,6%
-Отсутствие фокусировки или смысла – 4,1%
А если хотите попробовать свои силы в крутой продуктовой среде, оценить свой опыт и скиллы, приходите, например, сюда https://product.avito.ru/
podlodka.io
Исследование российского рынка продакт-менеджеров, 2021 год
Организаторы конференции Podlodka Product Crew провели большой опрос российских продакт-менеджеров: навыки, рабочие обязанности, компании мечты и способы обучения
Почему компаниям нужны продуктовые аналитики?
Главная ценность — не собирать данные, а переводить их на язык бизнеса и давать четкие рекомендации продуктовой команде по дальнейшей работе, которая позволит приблизиться к намеченным целям.
Условно можно выделить 3 основные задачи продуктового аналитика:
1. Удержание пользователей: изучение поведения аудитории, ее проблемы и получаемые от продукта ценности. Чтобы понять, насколько эффективно компания удерживает клиентов, необходимо рассчитать два показателя. Это LTV – прибыль от клиента, CRR – коэффициент удержания покупателей. Что будет эффективней и лучше работать - работа с обратной связью, юзабилити и простота, работа над первым взаимодействием, уникализация продукта или онбординг и геймификация - должен подсказать аналитик.
2. Адаптация продукта под ожидания рынка (целевой аудитории): он может собрать данные о действиях лояльных клиентов и потерянных и сделать выводы о необходимых доработках.
Когда вы знаете, что важно для целевой аудитории, не сложно достичь соответствия ее ожиданиям. Например, в Airbnb раньше была проблема: рекламодатели уходили из сервиса, потому что не могли сдать жилье. А потребители не пользовались услугами из-за некачественных фото. В компании решили взять на себя обязанность по созданию крутых и привлекательных снимков, после чего популярность платформы начала стремительно расти, а прибыль увеличиваться.
В 2016 году компания провела анализ более 100 000 объявлений с профессиональными фото и обычными и пришла к выводу о необходимости запуска дополнительной услуги.
3. Улучшение пользовательского опыта. Без работы с данными любые изменения в продукте или добавление нового функционала, можно сказать, делается вслепую. Например, в приложении решили частично обновить интерфейс: разработали новую навигацию, изменили оформление кнопок и т.п. Пользователей стало больше и уменьшился процент отказов, но что именно повлияло на это сказать невозможно. Продуктовый аналитик способен ответить на этот вопрос, так как отслеживает поведение пользователей в режиме реального времени. Собирает данные, интерпретирует их и передает команде. Другие специалисты на основе полученной информации принимают объективные решения о разработке новых функций или изменениях старых.
Хотите развиваться в аналитике и помогать бизнесу? Уметь выстраивать аналитическую систему и использовать data‑driven подход.
Как устроена маркетинговая и продуктовая аналитика и как развиваться в этой сфере — разбирают в Нетологии.
На бесплатном курсе-симуляторе «Аналитика продукта: куда уходят деньги компании» вы попробуете себя в роли аналитика и пройдёте этапы маркетингового и продуктового анализа на примере реального кейса.
Начните свой путь в аналитике: https://netolo.gy/hdE
Главная ценность — не собирать данные, а переводить их на язык бизнеса и давать четкие рекомендации продуктовой команде по дальнейшей работе, которая позволит приблизиться к намеченным целям.
Условно можно выделить 3 основные задачи продуктового аналитика:
1. Удержание пользователей: изучение поведения аудитории, ее проблемы и получаемые от продукта ценности. Чтобы понять, насколько эффективно компания удерживает клиентов, необходимо рассчитать два показателя. Это LTV – прибыль от клиента, CRR – коэффициент удержания покупателей. Что будет эффективней и лучше работать - работа с обратной связью, юзабилити и простота, работа над первым взаимодействием, уникализация продукта или онбординг и геймификация - должен подсказать аналитик.
2. Адаптация продукта под ожидания рынка (целевой аудитории): он может собрать данные о действиях лояльных клиентов и потерянных и сделать выводы о необходимых доработках.
Когда вы знаете, что важно для целевой аудитории, не сложно достичь соответствия ее ожиданиям. Например, в Airbnb раньше была проблема: рекламодатели уходили из сервиса, потому что не могли сдать жилье. А потребители не пользовались услугами из-за некачественных фото. В компании решили взять на себя обязанность по созданию крутых и привлекательных снимков, после чего популярность платформы начала стремительно расти, а прибыль увеличиваться.
В 2016 году компания провела анализ более 100 000 объявлений с профессиональными фото и обычными и пришла к выводу о необходимости запуска дополнительной услуги.
3. Улучшение пользовательского опыта. Без работы с данными любые изменения в продукте или добавление нового функционала, можно сказать, делается вслепую. Например, в приложении решили частично обновить интерфейс: разработали новую навигацию, изменили оформление кнопок и т.п. Пользователей стало больше и уменьшился процент отказов, но что именно повлияло на это сказать невозможно. Продуктовый аналитик способен ответить на этот вопрос, так как отслеживает поведение пользователей в режиме реального времени. Собирает данные, интерпретирует их и передает команде. Другие специалисты на основе полученной информации принимают объективные решения о разработке новых функций или изменениях старых.
Хотите развиваться в аналитике и помогать бизнесу? Уметь выстраивать аналитическую систему и использовать data‑driven подход.
Как устроена маркетинговая и продуктовая аналитика и как развиваться в этой сфере — разбирают в Нетологии.
На бесплатном курсе-симуляторе «Аналитика продукта: куда уходят деньги компании» вы попробуете себя в роли аналитика и пройдёте этапы маркетингового и продуктового анализа на примере реального кейса.
Начните свой путь в аналитике: https://netolo.gy/hdE
netology.ru
Нетология — обучение современным профессиям онлайн
Нетология — один из лидеров на рынке онлайн-образования. Открытые занятия, интенсивы и интерактивные курсы для обучения.
Стратегия — это цепочка целей, с помощью которых вы собираетесь достичь vision
Стратегические цели нужно распределить по горизонтам планирования. Детальное планирование с конкретными задачами нужно только для того, чтобы достичь ближайшей цели. Когда вы декомпозируете стратегические цели и передадите в команды, спрашивайте о достижении конкретных задач с конкретных команд. Дизайнер не должен отвечать за конверсию в воронке, потому что на нее влияют множество факторов. Разработчики не отвечают за объём выручки. У каждого должны быть задачи, соответствующие его роли в компании.
Стратегия всегда контринтуитивна. Это значит, что очень редко vision можно достичь по принципу «написали и реализовали план». Иначе непонятно, почему это ещё никто не сделал (а если сделал — стратегия либо не нужна, либо она должна радикально отличаться от повторения предыдущих успешных действий).
В хорошей стратегии всегда есть место исследованиям, которые помогут понять новый пользовательский опыт, новые технологии и так далее. Это необходимо, чтобы обеспечить компании долгосрочный успех на рынке.
Хорошая стратегия включает в себя не только цепочку целей и краткосрочных задач, но и — на верхнем уровне — перечень направлений, по которым нужно провести исследования.
Как работать над стратегией
- Превратите работу над стратегией в ритмичную работу команды топ-менеджмента. Например, в компании Amazon 25 вертикально интегрированных холдингов, каждый не меньше «Сбербанка», обновляют свою стратегию раз в полгода.
- Регулярный процесс нельзя построить сразу. Сначала вы проводите несколько точечных стратегических сессий, пока команда не научится анализировать слабые сигналы рынка, формировать видение и управлять стратегическими горизонтами.
- На сессиях могут быть консультанты, но они не принимают решения за команду, а помогают организовать и ускорить процесс. Со временем вы выстроите процесс, расширите горизонт планирования. Глубина стратегических и эффективно-стратегических решений с каждой сессией начнёт увеличиваться. Хорошие консультанты после этого должны уйти.
Хотите разобраться в создании эффективных стратегий? Приходите к Диме Безуглому на курс по продуктовой стратегии https://master-strategy.ru/product-strategy-school и открытый вебинар 4 ноября в 10:00 https://master-strategy.ru/deep-dive-product-strategy
Стратегические цели нужно распределить по горизонтам планирования. Детальное планирование с конкретными задачами нужно только для того, чтобы достичь ближайшей цели. Когда вы декомпозируете стратегические цели и передадите в команды, спрашивайте о достижении конкретных задач с конкретных команд. Дизайнер не должен отвечать за конверсию в воронке, потому что на нее влияют множество факторов. Разработчики не отвечают за объём выручки. У каждого должны быть задачи, соответствующие его роли в компании.
Стратегия всегда контринтуитивна. Это значит, что очень редко vision можно достичь по принципу «написали и реализовали план». Иначе непонятно, почему это ещё никто не сделал (а если сделал — стратегия либо не нужна, либо она должна радикально отличаться от повторения предыдущих успешных действий).
В хорошей стратегии всегда есть место исследованиям, которые помогут понять новый пользовательский опыт, новые технологии и так далее. Это необходимо, чтобы обеспечить компании долгосрочный успех на рынке.
Хорошая стратегия включает в себя не только цепочку целей и краткосрочных задач, но и — на верхнем уровне — перечень направлений, по которым нужно провести исследования.
Как работать над стратегией
- Превратите работу над стратегией в ритмичную работу команды топ-менеджмента. Например, в компании Amazon 25 вертикально интегрированных холдингов, каждый не меньше «Сбербанка», обновляют свою стратегию раз в полгода.
- Регулярный процесс нельзя построить сразу. Сначала вы проводите несколько точечных стратегических сессий, пока команда не научится анализировать слабые сигналы рынка, формировать видение и управлять стратегическими горизонтами.
- На сессиях могут быть консультанты, но они не принимают решения за команду, а помогают организовать и ускорить процесс. Со временем вы выстроите процесс, расширите горизонт планирования. Глубина стратегических и эффективно-стратегических решений с каждой сессией начнёт увеличиваться. Хорошие консультанты после этого должны уйти.
Хотите разобраться в создании эффективных стратегий? Приходите к Диме Безуглому на курс по продуктовой стратегии https://master-strategy.ru/product-strategy-school и открытый вебинар 4 ноября в 10:00 https://master-strategy.ru/deep-dive-product-strategy
Что мешает большим компаниям создавать успешные продукты и как решать эти проблемы?
Ребята из Акселератора ФРИИ провели исследование «Как крупнейшие российские корпорации создают новые продукты и строят экосистемы», с которым я готов согласиться.
Барьеры для создания продуктов:
- Отсутствие измеримых целей и метрик по выручке от новых продуктов у руководителей направлений Действующие системы мотивации лидеров бизнес-стримов ориентированы прежде всего на количество релизов, пилотов, и запусков. В итоге «ванильные метрики» на бумаге достигаются, а реальные результаты по новым продуктовым инициативам выпадают из фокуса внимания руководителей.
-В ряде компаний недостаточное внимание уделяется ключевому этапу в создании новых продуктов — этапу проверки идеи (Discovery). В результате процесс замедляется и удорожается, а вероятность вывести на рынок конкурентоспособный востребованный продукт значительно снижается.
-К продуктам на ранней стадии предъявляются требования, аналогичные требованиям ко «взрослым» бизнес-юнитам (например, наличие P&L у продукта на ранней стадии).
-Вместо продуктового подхода используется проектноориентированный подход, в рамках которого отсутствует фокус на подтверждении ценности и тестировании гипотез.
-Сотрудникам, ответственным за разработку новых продуктов, не хватает компетенций и насмотренности.
Как полечить:
- Внедрение измеримых целей и мотивации руководителей бизнес-стримов по росту продуктовой выручки с дальнейшей декомпозицией на метрики продуктов
- Внедрение продуктового процесса с фокусом на этап проверки идей (Discovery), четкими метриками для продуктов на ранних стадиях и правилами перевода продуктов с одной стадии на другую;
- Внутренние и внешние эксперты и трекеры для внедрения методологии продуктовой работы (исследования, гипотезы, аналитика и т.д.);
- Запуск и использование сервисов для повышения результативности работы продуктовых команд (лаборатории по исследованию потребителей, UX, сервис-дизайну и т.д.);
- Менторство продуктологов силами бизнес-заказчиков и топ-менеджмента компании;
- Создание и развитие lean-отделений для пилотирования продуктов c облегченными процедурами запуска продуктов;
- Запуск и развитие продуктовых лабораторий и НИОКР-подразделений с собственными бюджетами на запуск продуктов и проверку гипотез;
- Использование накопленных данных о клиентах через data science-лабораторию при тестировании гипотез.
Хотите еще больше инсайтов - скачайте бесплатно полный отчет по ссылке с результатами исследования, чтобы узнать еще:
— Срок и стоимость создания MVP продукта, смертность продуктов
— Ключевые этапы процесса запуска и развития продукта и вариации в разных компаниях
— Типовые роли в продуктовой команде
— Препятствия для создания успешных продуктов и как их можно преодолеть
Ребята из Акселератора ФРИИ провели исследование «Как крупнейшие российские корпорации создают новые продукты и строят экосистемы», с которым я готов согласиться.
Барьеры для создания продуктов:
- Отсутствие измеримых целей и метрик по выручке от новых продуктов у руководителей направлений Действующие системы мотивации лидеров бизнес-стримов ориентированы прежде всего на количество релизов, пилотов, и запусков. В итоге «ванильные метрики» на бумаге достигаются, а реальные результаты по новым продуктовым инициативам выпадают из фокуса внимания руководителей.
-В ряде компаний недостаточное внимание уделяется ключевому этапу в создании новых продуктов — этапу проверки идеи (Discovery). В результате процесс замедляется и удорожается, а вероятность вывести на рынок конкурентоспособный востребованный продукт значительно снижается.
-К продуктам на ранней стадии предъявляются требования, аналогичные требованиям ко «взрослым» бизнес-юнитам (например, наличие P&L у продукта на ранней стадии).
-Вместо продуктового подхода используется проектноориентированный подход, в рамках которого отсутствует фокус на подтверждении ценности и тестировании гипотез.
-Сотрудникам, ответственным за разработку новых продуктов, не хватает компетенций и насмотренности.
Как полечить:
- Внедрение измеримых целей и мотивации руководителей бизнес-стримов по росту продуктовой выручки с дальнейшей декомпозицией на метрики продуктов
- Внедрение продуктового процесса с фокусом на этап проверки идей (Discovery), четкими метриками для продуктов на ранних стадиях и правилами перевода продуктов с одной стадии на другую;
- Внутренние и внешние эксперты и трекеры для внедрения методологии продуктовой работы (исследования, гипотезы, аналитика и т.д.);
- Запуск и использование сервисов для повышения результативности работы продуктовых команд (лаборатории по исследованию потребителей, UX, сервис-дизайну и т.д.);
- Менторство продуктологов силами бизнес-заказчиков и топ-менеджмента компании;
- Создание и развитие lean-отделений для пилотирования продуктов c облегченными процедурами запуска продуктов;
- Запуск и развитие продуктовых лабораторий и НИОКР-подразделений с собственными бюджетами на запуск продуктов и проверку гипотез;
- Использование накопленных данных о клиентах через data science-лабораторию при тестировании гипотез.
Хотите еще больше инсайтов - скачайте бесплатно полный отчет по ссылке с результатами исследования, чтобы узнать еще:
— Срок и стоимость создания MVP продукта, смертность продуктов
— Ключевые этапы процесса запуска и развития продукта и вариации в разных компаниях
— Типовые роли в продуктовой команде
— Препятствия для создания успешных продуктов и как их можно преодолеть
Канал для тех, кто в тренде
Каждое утро за кофе начинайте с рассказов о венчурном рынке, лайфхаках для предпринимателей, историях успеха и провалах с каналом https://news.1rj.ru/str/Theedinorogblog
1. Особенно рекомендую подборку “Правила стартапов” - https://news.1rj.ru/str/Theedinorogblog/2193 - и посты из нее:
6/ Как правильно описать «проблему»
7/ Найти правильное «Решение» для хорошей «Проблемы»
8/ Make Product! Great. Again
9/ Слайд «Почему сейчас?»
10/ Как правильно описать рынок
11/ Как описать бизнес-модель и юнит-экономику
12/ Как описать конкурентов
15/ Слайд «Стратегия»
2. Посты с содержательным мнением вроде Почему нужно посматривать на киберспорт - https://news.1rj.ru/str/Theedinorogblog/2922 : там все сложно и интересно. Многое зависит от индивидуальных действий, но супер важна и командная тактика. А еще нужно понимать, какого чемпиона взять, чтобы комфортно играть против соперника. А потом еще нужно по ходу игры решать, какие предметы нужно покупать для чемпиона, потому что это очень влияет на матч — усилить атаку или оборону, попробовать скомбинировать и так далее. И самое главное — турниры по киберспорту это всегда шоу. Очень крутое шоу в трансляциях.
3. Крутые мануалы вроде Как рассчитать финансовую модель для стартапа. Лекция Ани Магеры про финансовую модель для стартапа. Она очень подробно разбирает все по пунктам на примере шаблона. Аня крутой спец в стартаповских финансах, поэтому рекомендую посмотреть https://youtu.be/FpenkIew1sg . Оригинал - https://news.1rj.ru/str/Theedinorogblog/2921
4. Емкие выводы вроде “Причины венчурного безумия”
“Перевод статьи Vice про венчурное безумие. Объективно, за последние пару лет рынок очень изменился — единороги появляются чуть ли не каждый день, средний объем seed-раундов растет. И вот Vice рассказывает, почему это происходит и как существуют инвесторы в таких реалиях. А там, надо сказать, все довольно жестковато. Например, стартапы стали рассчитывать закрыть сделку через неделю после первого знакомства, а некоторые и вовсе требуют ответ сразу после 30-минутного звонка. А что инвесторы? А они заливают рынок деньгами, потому что боятся пропустить нового единорога.”
Подписывайтесь - https://news.1rj.ru/str/Theedinorogblog/
Каждое утро за кофе начинайте с рассказов о венчурном рынке, лайфхаках для предпринимателей, историях успеха и провалах с каналом https://news.1rj.ru/str/Theedinorogblog
1. Особенно рекомендую подборку “Правила стартапов” - https://news.1rj.ru/str/Theedinorogblog/2193 - и посты из нее:
6/ Как правильно описать «проблему»
7/ Найти правильное «Решение» для хорошей «Проблемы»
8/ Make Product! Great. Again
9/ Слайд «Почему сейчас?»
10/ Как правильно описать рынок
11/ Как описать бизнес-модель и юнит-экономику
12/ Как описать конкурентов
15/ Слайд «Стратегия»
2. Посты с содержательным мнением вроде Почему нужно посматривать на киберспорт - https://news.1rj.ru/str/Theedinorogblog/2922 : там все сложно и интересно. Многое зависит от индивидуальных действий, но супер важна и командная тактика. А еще нужно понимать, какого чемпиона взять, чтобы комфортно играть против соперника. А потом еще нужно по ходу игры решать, какие предметы нужно покупать для чемпиона, потому что это очень влияет на матч — усилить атаку или оборону, попробовать скомбинировать и так далее. И самое главное — турниры по киберспорту это всегда шоу. Очень крутое шоу в трансляциях.
3. Крутые мануалы вроде Как рассчитать финансовую модель для стартапа. Лекция Ани Магеры про финансовую модель для стартапа. Она очень подробно разбирает все по пунктам на примере шаблона. Аня крутой спец в стартаповских финансах, поэтому рекомендую посмотреть https://youtu.be/FpenkIew1sg . Оригинал - https://news.1rj.ru/str/Theedinorogblog/2921
4. Емкие выводы вроде “Причины венчурного безумия”
“Перевод статьи Vice про венчурное безумие. Объективно, за последние пару лет рынок очень изменился — единороги появляются чуть ли не каждый день, средний объем seed-раундов растет. И вот Vice рассказывает, почему это происходит и как существуют инвесторы в таких реалиях. А там, надо сказать, все довольно жестковато. Например, стартапы стали рассчитывать закрыть сделку через неделю после первого знакомства, а некоторые и вовсе требуют ответ сразу после 30-минутного звонка. А что инвесторы? А они заливают рынок деньгами, потому что боятся пропустить нового единорога.”
Подписывайтесь - https://news.1rj.ru/str/Theedinorogblog/
Telegram
The Edinorog 🦄
Тот самый канал про стартапы🤪
Автор - журналист Дмитрий Филонов
❗️Реклама на канале — https://teletype.in/@theedinorog/xASBsmc6JNE
Связь с автором - @TheEdinorog
РКН: https://clck.ru/3PUAPX
Автор - журналист Дмитрий Филонов
❗️Реклама на канале — https://teletype.in/@theedinorog/xASBsmc6JNE
Связь с автором - @TheEdinorog
РКН: https://clck.ru/3PUAPX
Golden Signals в мониторинге продукта
В книге Site Reliability Engineering есть полезная глава про мониторинг распределенных систем, где описан подход Google, основанный на отслеживании «четырех золотых сигналов» (Four Golden Signals).
1. Задержка (Latency) - сколько времени занимает обработка запроса? Определите ориентир для задержек, типичных для успешных запросов, и сравните его с задержками для неуспешных запросов. Отслеживание задержек, вызванных ошибками, позволяет решить любые вопросы, связанные со скоростью выявления инцидента и реакции на него.
2. Трафик (Traffic) - какое влияние на систему оказывает количество пользователей или число транзакций, проходящих через сервис? Отслеживая взаимодействие с реальными пользователями и трафик, можно лучше понять, как конечные пользователи воспринимают сервис, и получить представление о том, как системы ведут себя в условиях стресса.
3. Ошибки (Errors) - независимо от того, вызваны ли ошибки заданной вручную логикой или автономны (вроде неудавшегося HTTP-запроса), SRE-команды должны отслеживать их. Многие SRE-команды используют специальное ПО для управления инцидентами для оповещений о критических ошибках, поиска их причин и проведения работ по устранению последствий.
4. Насыщенность (Saturation) - важно задать метрику для насыщенности, которая бы означала, что сервис достиг максимума своих возможностей. Большинство сервисов начинают терять производительность еще до того, как загрузка достигнет 100%, поэтому понимание функциональности вашей собственной системы важно для определения ориентира насыщенности, который имеет смысл.
Собираются золотые сигналы по нескольким причинам:
• Оповещение - сигналы сообщают, когда что-то не так
• Устранение неполадок - сигналы помогают найти и устранить проблему
• Настройка и планирование мощностей - сигналы помогают улучшить ситуацию с течением времени
Производительность продукта влияет на продуктовые метрики. Интенсив от Слёрм поможет прокачать вашу команду в SRE практиках. Приходите на Четвертый интенсив от Слёрм по SRE: «SRE: внедряем DevOps от Google», 3-5 декабря 2021 года.
Концепция DevOps нацелена на внутреннее эффективное взаимодействие команд и стабильность разработки, а имплементация от Google - SRE обеспечивает надежность и счастье пользователя, создаёт продукт который работает, обновляется и приносит деньги компании, согласовывает метрики с бизнесом и следит за влиянием сервисов друг на друга.
Получить консультацию по курсу для команды https://slurm.club/3D1Ip1T
В книге Site Reliability Engineering есть полезная глава про мониторинг распределенных систем, где описан подход Google, основанный на отслеживании «четырех золотых сигналов» (Four Golden Signals).
1. Задержка (Latency) - сколько времени занимает обработка запроса? Определите ориентир для задержек, типичных для успешных запросов, и сравните его с задержками для неуспешных запросов. Отслеживание задержек, вызванных ошибками, позволяет решить любые вопросы, связанные со скоростью выявления инцидента и реакции на него.
2. Трафик (Traffic) - какое влияние на систему оказывает количество пользователей или число транзакций, проходящих через сервис? Отслеживая взаимодействие с реальными пользователями и трафик, можно лучше понять, как конечные пользователи воспринимают сервис, и получить представление о том, как системы ведут себя в условиях стресса.
3. Ошибки (Errors) - независимо от того, вызваны ли ошибки заданной вручную логикой или автономны (вроде неудавшегося HTTP-запроса), SRE-команды должны отслеживать их. Многие SRE-команды используют специальное ПО для управления инцидентами для оповещений о критических ошибках, поиска их причин и проведения работ по устранению последствий.
4. Насыщенность (Saturation) - важно задать метрику для насыщенности, которая бы означала, что сервис достиг максимума своих возможностей. Большинство сервисов начинают терять производительность еще до того, как загрузка достигнет 100%, поэтому понимание функциональности вашей собственной системы важно для определения ориентира насыщенности, который имеет смысл.
Собираются золотые сигналы по нескольким причинам:
• Оповещение - сигналы сообщают, когда что-то не так
• Устранение неполадок - сигналы помогают найти и устранить проблему
• Настройка и планирование мощностей - сигналы помогают улучшить ситуацию с течением времени
Производительность продукта влияет на продуктовые метрики. Интенсив от Слёрм поможет прокачать вашу команду в SRE практиках. Приходите на Четвертый интенсив от Слёрм по SRE: «SRE: внедряем DevOps от Google», 3-5 декабря 2021 года.
Концепция DevOps нацелена на внутреннее эффективное взаимодействие команд и стабильность разработки, а имплементация от Google - SRE обеспечивает надежность и счастье пользователя, создаёт продукт который работает, обновляется и приносит деньги компании, согласовывает метрики с бизнесом и следит за влиянием сервисов друг на друга.
Получить консультацию по курсу для команды https://slurm.club/3D1Ip1T
Как построить сильную продуктовую команду?
Своим опытом поделилась Ксения Михайлова, 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/