Switching 🔁

Есть один интересный подход к анализу того, почему пользователи уходят и как привлечь новых. Он основан на идее, что у людей уже «закрыты» все основные потребности, а конкуренция идёт между разными способами их удовлетворения.

Например, любителям готовить всегда нужны свежие продукты. Раньше эту потребность закрывали рынки, потом появились супермаркеты, а сейчас популярны сервисы доставки продуктов.

Чтобы привлечь новых пользователей, мы должны предложить им продукт, который более эффективным способом закрывает потребность.

В примере с продуктами: люди переходят от рынков к супермаркетам из-за лучшего сервиса, а от супермаркетов к сервисам доставки — из-за желания сэкономить время.

Как мы можно привлечь больше пользователей?

Возможно 4 точки приложения усилий:

1️⃣ Увеличить отталкивание, показать недостатки существующих решений. Например, если мы говорим о рынках, можно показать, насколько там может быть плохой сервис.

2️⃣ Увеличить привлекательность своего нового решения, активно продвигать преимущества нашего продукта. Подчеркнуть, как он решает проблемы пользователей. Например, возможность купить всё быстрее, в одном месте, без торговли и очередей.

3️⃣ Уменьшить страх и неопределённость изменений. Убедить пользователей, что переход на наш продукт будет быстрым и лёгким. Именно поэтому сервисы доставки так следят за простотой онбординга и понятностью интерфейса, а также предлагают хорошие скидки на первый заказ.

4️⃣ Снизить привязанность к текущему решению. Показать пользователям, что они могут потерять, продолжая использовать текущее решение.

Данный подход удобен тем, что позволяет сделать zoom out и посмотреть на картину с оттоком или привлечением пользователей комплексно 🔖

Что помогает менеджеру продукта быть эффективным ⭐️

Моя коллега Вера, CMO Яндекс Погоды, в своём канале Прыжок Веры (@teolog_marketolog_channel) анализирует практики личной эффективности, загляните к ней, если тема вам интересна. А сегодня хочу рассказать о своих прикладных методах личной эффективности на примере «фотографии дня», что делал в один из понедельников.

Итак, поехали:

👀 09:00 – 09:30. Обзор дня. Наливаю кофе, рефлексирую над своими записями с пятницы, думаю о том, что будет хорошим результатом по итогам дня.

👨‍💻 09:30 – 10:30. «Золотой час» на работу с проектами. Фокус – на качественной продуктовой проработке и постановке задач. Ценю это время за то, что никто не отвлекает и удаётся хорошо погрузиться, быть в потоке. Для меня это самая продуктивная часть дня.

🤔 10:30 – 11:00. Изучаю отчёты. Первый – ежемесячный отчёт от команды Поддержки, второй – исследование поведения клиентов в продукте. Хочу понять есть ли что-то новое, о чём стоить подумать или всё уже в проработке.

✅ 11:00 – 11:30. Подготовка ко встречам. Составляю список вопросов, которые важно задать и готовлю ответы, на те вопросы, которые нужны от меня.

🙌 11:30 – 12:00. Утренний стендап с командой разработки. Обсуждаем, как продвигаются проекты: кто и что сделал, кто и что будет делать, есть ли какие-то сложности. Обычно по завершению встречи у меня появляется несколько дел – уточнить описания задач, завести новые, донести недостающую информацию для разработчиков.

Я использую правило 2 минут: если что-то можно сделать быстро, я делаю это сразу. Если не могу выполнить задачу быстро, то откладываю её. Это правило помогает мне не загружать себя мелкими делами и не тратить время на планирование – это может занять столько же времени, сколько выполнение самой задачи.

✂️ 12:00 – 13:00. Груминг задач на дизайн. Обычно, список задач для груминга указываю прямо в описании встречи в Яндекс Календаре, а на самой встрече мы смотрим описание в тикете и если оно достаточное, то наш продуктовый дизайнер даёт оценку, если нет – уношу вопросы на продуктовую проработку.

🗣13:00 – 14:00. Грумминг задач для front-end-команды. Очень удобно, что с front-end разработчиками мы собираемся сразу после обсуждения с продуктовым дизайнером, это позволяет очень быстро получить комплексную оценку. Здесь также у меня заранее заготовлен список задач, фиксирую детально итоги обсуждения, так как оценок может быть несколько и важно понять, что «удешевляет задачу», а что – «удорожает».

🍽 14:00 – 15:00. Обед с коллегами и кофе после него. Обсуждаем у кого как прошли выходные: я наконец-то досмотрел серил Severance и дочитал книгу про связь почвы и вкуса вина, делаюсь впечатлениями.

🎙15:00 – 16:00. Еженедельная большая встреча всей команды. Эта встреча – пространство для обсуждения важных вопросов, обычно есть и по части продуктов. Продажи, поддержка, редакция и коллеги из других направлений – это одни из моих стейкхолдеров, мне важно понимать и для них, как сделать продукт лучше.

💡16:00 – 17:00. Технический брейншторм по одному из проектов. Обсуждаем разные подходы, взвешиваем + и - каждого, стараемся найти сбалансированное решение. Фиксирую в тикете ход обсуждения и итоговые договорённости.

📄 17:00 – 18:30. Работа с задачами. За 4,5 часовой марафон из встреч накопилось много вещей, которые надо сделать. Последний рывок на сегодня.

Я придерживаюсь метода

Zero Inbox

, это позволяет снизить когнитивную нагрузку на мозг и отключиться от работы на остаток дня.

✅ 18:30 – 19:00. Подвожу итоги дня. Завершение работы над проектами плавно перетекает в подведение итогов дня, надо понять, как завтра простроить день с учётом встреч, за что нужно взяться завтра прямо с утра (в «золотой час»), кому про что напомнить, у кого спросить и прочее.

🔤🔤🔤🔤

Модель AIDA придумал специалист по рекламе Элиас Сент-Элмо Льюис в 1898 году. Она до сих пор актуальна и используется в учебниках по маркетингу и рекламе. Но сегодня мы поговорим, как эта модель может помочь менеджеру продукта в его работе.

Акроним AIDA расшифровывается как:
A – attention (внимание), иногда ещё пишут Awareness (осведомлённость)
I – interest (интерес)
D – desire (желание)
A – action (действие)

Исходно модель описывает процесс, который проходит пользователь, на пути к покупке: внимание → интерес → желание → действие.

1️⃣ Attention/Awareness

Чтобы человек стал потенциальным пользователем:
– он должен знать о существовании продукта и этот продукт должен быть одним из способов решения задачи пользователя;
– а мы должны знать, как «зацепить» внимание потенциального пользователя.

Ответственность менеджера продукта здесь:
– глубокое понимание своего целевого пользователя, с какими проблемами он сталкивается, где возникают точки неудовлетворённости в опыте;
– И умение понятными пользователю словами/смыслами/RTB объяснить, почему ваш продукт лучше остальных решить задачу.

2️⃣ Interest

Привлечь внимание не то же самое, что заинтересовать. Человек, который просто кликнул на баннер, может и не установить ваше приложение. Вы по-настоящему заинтересовали пользователя, когда он выдал вам «кредит доверия» и решил потратить время на ваш продукт, а не на продукт конкурентов.

Ответственность менеджера продукта здесь – это хорошо спроектированный пользовательский опыт первой сессии:
– продуманный, краткий, но ёмкий онбординг в продукте;
– минимальное Time to Value / время до A-ha moment.

3️⃣ Desire

Если вы всё сделали правильно на предыдущих шагах, то интерес пользователя конвертируется в желание решить свою задачу/проблему именно c помощью вашего продукта.

Ответственность менеджера здесь – подумать про switching costs и при необходимости выбрать оптимальный способ их снижения (trial-период, промо-код и пр.). Также важно транслировать образ будущего результата, а сам продукт должен работать, как понятная и предсказуемая для пользователя система.

4️⃣ Action

Ваш продукт должен хорошо решать задачу/проблему пользователя, причём «хорошо» именно по критериям пользователя – экономить время, деньги, быть более удобным, эстетически приятным и др.

После того как пользователь совершит целевое действие, следует:
– поблагодарить пользователя;
– убедиться, что он доволен результатом;
– подготовить почву для повторения сценария/возвращение в сценарий, например, предложение подписаться на push-уведомление, e-mail.

Ответственность менеджера продукта здесь – это обеспечить по-настоящему качественное решение задачи пользователя и не забыть про нюансы выше.
__

Понятно, что модель AIDA сильно упрощает процесс принятия решения о покупке (реальные пользователи действуют не линейно) и в него могут быть встроены дополнительные шаги (особенно это актуально для B2B), а для некоторых индустрий/продуктов она и вовсе может не подходить, но несмотря на все недостатки модель помогает структурировать работу над продуктом.

HADI-циклы 🔃

Работа с гипотезами — один из ключевых навыков, которыми должен обладать менеджер продукта. HADI-циклы — это метод, который помогает прокачивать данный навык. Он был создан в рамках методологии Agile.

Метод включает в себя 4 этапа: формулирование гипотезы → действие → сбор данных → выводы.

Таким образом, мы проверяем гипотезу через действие, чтобы получить данные и сделать вывод.

Предполагается, что цикл бесконечен, т.е. после того, как вы проверили один гипотезу и получили выводы, вы формулируете новую уточнённую гипотезу.

Давайте детально рассмотрим каждый этап 🔬

💡 H – Hypothesis. Гипотеза, сформулированная по правилу:

– Если мы сделаем это,
– то для определённого сегмента,
– это приведёт к такому изменению метрики,
– потому что у нас есть такие аргументы/вера

Обычно идея гипотезы появляется из-за проблем в продукте, неудачного опыта пользователей, поиска новых точек роста и т. д. HADI-циклы особенно полезны для стартапов и MVP, но вы также можете проверять гипотезы для отдельных функций зрелого продукта, изучения рынка, спроса на него, каналов продвижения и др. Критически важно, чтобы гипотеза была сформулирована конкретно, а не верхнеуровнево.

💬 A – Action. Действие, проверка гипотезы выбранным способом (например, с помощью A/B-тестов, Fake Door Test, RITE, 5 Second Test и др.). Важно сделать это быстро, именно за счёт скорости проверки вы быстрее отберёте перспективные гипотезы.

📈 D – Data. Сбор данных, которые подтверждают/опровергают гипотезу. Здесь важно не забывать о репрезентативности выборки и стат. значимости данных, чтобы не спутать закономерности с «шумом».

👀 I – Insight. Анализ данных и выводы/инсайты из них. Здесь важно сделать финальное заключение – подтвердилась ли гипотеза. И сформулировать что делаем дальше – масштабируем гипотезу, или переходим к тестированию следующей, уточнённой гипотезы. Не стоит бояться, что гипотеза не подтвердится, ведь задача HADI — находить не только успешные, но и неудачные гипотезы, чтобы не тратить на них ресурсы.

На что обратить внимание в цикле HADI:

1️⃣ В первую очередь тестируйте те гипотезы, которые могут сильно повлиять на целевую метрику и при этом просты в реализации и при этом есть уверенность в валидности гипотезы. Например, используйте подход RICE, чтобы приоритизировать гипотезы.

2️⃣ Не запускайте несколько HADI-циклов сразу, если они направлены на одну и ту же метрику. Если хотите проверить несколько идей, пусть они будут направлены на разные показатели.

3️⃣ Затраты на проверку гипотезы должны быть соизмеримы с потенциальными выгодами.

4️⃣ Проверяйте только те гипотезы, в которых не уверены. Не тратьте время на проверку того, что и так работает, отличайте факты от гипотез.

5️⃣ Иногда стоит возвращаться к проверке гипотез, потому что технологии и тренды меняются и поведение пользователей может стать другим. Так вы поймёте, гипотеза не подтверждается вообще или только в определённых условиях.

Как тренировать насмотренность? 👀

Ранее я уже писал о том, почему менеджеру продукта полезно тренировать насмотренность.

Важно понимать, что тренировка насмотренности — это не просто просмотр большого количества материалов, а вдумчивое чтение с задаванием себе вопросов:

1️⃣ Почему автор выбрал именно этот способ? Какую проблему он хотел решить?
2️⃣ Получилось ли у него это сделать? Почему?
3️⃣ Как я могу использовать это в своей работе?

Именно такой осознанный, вдумчивый подход поможет вам тренировать свою насмотренность.

🤩🤩🤩 18 ноября приглашаем на лекцию «Как масштабировать продукт». Вы поймете, что готов ли ваш продукт к масштабированию, что нужно учесть, чтобы не потратить зря время, деньги и силы команды. Спикер расскажет, о чём важно подумать — от анализа ценности продукта до выбора способов его продвижения и расчёта unit-экономики.

Ключевые темы

✔️ Ценность продукта и критерии Product/Market Fit
✔️ Критерии выбора каналов продвижения и расчёт unit-экономики
✔️ Виральности и «крючки» в продукте
✔️ Чек-лист с критериями готовности продукта к масштабированию

Спикер — Иван Меркурьев, Senior Product Manager в Яндекс, ментор в GoPractice, эксперт в Эйч, автор телеграм-канала Ordinary PM, 10+ лет опыта в создании и развитии цифровых продуктов в ведущих ИТ-компаниях.

Подробности и регистрация — на сайте.

❗️Мероприятие пройдет в офлайн-формате. Количество мест ограничено, ведется премодерация для комфортного проведения мероприятия. Пожалуйста, дождитесь письма с подтверждением регистрации.