Нормально делай, нормально будет / Саша Клименко

2022-12-30 13:15:02 Хочу под новый год сделать подарок себе и немного вам.

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

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

2022-12-29 11:10:31 Ребята подвели итоги ежегодного опроса продактов. Там интересно!

Вычитала немного полезного для себя любимой edtech в сфере коммуникаций:

Топ самых сложных для продактов вещей снова так или иначе связан с коммуникациями: от изменения процессов до взаимодействия со стейкхолдерами.

Встречи и общение, налаживание процессов и согласование — в топе того, что съедало больше всего времени на работе. Правильно, снова коммуникация!

И мое любимое: в топ-3 самых важных навыка для продакта — входят #2коммуникации и #3лидерство, ноо… в списке того, что необходимо прокачать, эти навыки даже не в пятерке: на 8 и 9 месте — снова!

Ну в целом, понятно над чем работать в новом году

Другие интересные факты про средний уровень английского «по больнице», географию продактов и распределение по компаниям читать тут:) Открыть/Комментировать

2022-12-26 12:12:48 #эксперименты #развитие_продукта #процессы
К 2021 году конверсия в первую покупку у Skyeng перестала кратно расти по всем направлениям (ну когда-то же должно было случиться). Стали искать новые точки роста в данных, но их безумно много: ~47 млн профилей, в разных базах, с дубликатами и не сегментирована. Из-за этого на проверку одной гипотезы уходило 1,5-2 месяца.

Решили внедрять CDP — платформу для управления клиентскими данными. Позволяет собрать полную инфу о пользователях (каналы, транзакции, поведение) и найти новые точки роста в монетизации. Стоит около 500к в месяц, плюс надо перестраивать процессы, а к этому не все готовы.

Пилотный запуск провели втроём за 3 месяца в вертикали B2B — там сильнее всего было желание получить скорость в работе и возможность изучения новой платформы. Привлекли вендора с оплатой 40 часов для помощи во внедрении и изучении системы. Затем подтянулась команда роста, а потом и остальные, когда увидели на внутреннем демо результаты команд коллег, и понадобилось еще 20 часов на ответы на вопросы остальных команд.

Что успели сделать за год:

Сегментировали данные. Собрали профили из 20 разных баз, дедуплицировали и настроили сегменты по множеству критериев.
Теперь бизнес-вертикали знают своих клиентов, видят систематическое поведение (например, интерес к продукту есть, но почтой не пользуется — нужны другие каналы коммуникации) и лучше планируют стратегию коммуникации.

Настроили инструмент для фронтальных инструментов. Стало возможным разбивать пользователей на группы в зависимости от глубины скролла на сайте или ответов в квизе, и для сегмента настраивать поп-апы, менять блок страницы или отправлять сообщение. Раньше потребовалось бы писать отдельный модуль для каждого такого эксперимента, а теперь настройка эксперимента занимает от 30-ти минут.
Создали единый профиль с информацией из многих систем: свойства, события, покупки и настроили цепочки коммуникации для них. Это помогло найти узкие места и ошибки системы.

Например, оказалось что 50% (!) пользователей по каким-то причинам не видят онбординг. Техническую проблему решают, а пока этой когорте отправляют оффер по смс, и CR у него в районе 30-40%.

А в B2B оказалось, что если пользователь уже существует (но забыл об этом и заново регистрируется), то их заявки не регистрируются и с ними никак не коммуницируют на странице сайта (менеджер позже звонит, но не до всех дозванивается).
Настроили новый баннер (пишут, что за счет CDP ушел всего час) с информацией и ссылкой на ЛК. Конверсия из баннеров в покупку — 19-20%, доля продаж с помощью этого сценария — 27% от общего числа продаж в когорте.

Так как понять, окупится ли недешевая платформа?
Говорят, посчитать ROI для нее невозможно: зависит от того, насколько хорошо внедрили инструмент, сколько данных туда загрузили, научили ли бизнес этим пользоваться. Только запускать пилоты и надеяться, что команды найдут ценность для себя самостоятельно, а другие будут готовы тратить силы и время на внедрение у себя.

Кстати, Женя Писаревская, продакт-евангелист CDP в Skyeng, согласилась поотвечать на наши вопросы. Поэтому если вам что-то оказалось непонятным, или интересны подробности — давайте обсудим в комментариях!

Источник: пост (~7 минут) в блоге Epic Growth Открыть/Комментировать

2022-12-21 15:12:29 Спасибо Насте и каналу «Кнопка хорошо» за классный кейс, вам за участие и активность! Открыть/Комментировать

2022-12-21 15:12:28 Но когда подумала, вспомнила, что у меня был и такой, и такой вариант. Мы всегда смещались к тому, чтобы обсуждать всей командой — но это когда дизайнер был уже глубоко посвящен в проблему, вся команда доверяла его компетенциям и он это знал, и отвечать на любые вопросы не составляло труда.
Так что временно оградить дизайнера и давать ему первые комментарии самостоятельно, чтобы к команде приходил уже более проработанный вариант — согласна, хорошая часть решения.

Что еще добавить?
Разумеется, тут опять речь будет про эмоции. Я просто приведу кусочек из комментария, который прекрасен, и коротко объясню принципы, которые тут отлично вписались:

Разговор с дизайнером:

«Понимаю, что кажется, будто разработчики сомневаются в твоей компетентности, поэтому задают кучу вопросов. Я бы тоже обиделась и разозлилась на такое. Думаю, большое количество вопросов связано с тем, что судя по твоему дизайну нужно менять логику работы приложения. Мы такие изменения не планировали, поэтом все были удивлены, увидев новые макеты. Давай вместе разберём комментарии ребят? Там точно были дельные вещи»

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

Смотрим на реакцию дизайнера — либо он сам признает, что что-то пошло не так, либо стоит ему еще раз это озвучить.
Например:
«Вася, мне очень важно уважение и доверие между членами команды. Когда ты говоришь, что раз ты дизайнер, тебе виднее — у ребят возникает ощущение, что они не имеют права задавать вопросы. Это их обижает и на мой взгляд нарушает доверие. Я прошу тебя в следующей ситуации, если ты видишь, что обсуждение идет не по плану, ты его останавливаешь, прежде чем оно становится неприятным для кого-то из присутствующих. Можешь звать меня, чтобы я помогла разобраться, если какие-то вещи объяснить не получается.»

Дальше можно делать структурные изменения, которые вы предложили: плотнее работать с дизайнером, пока он не погрузится больше в продукт, внимательно наблюдать, как идет дальнейшее взаимодействие, или полностью перестроить работу — это уже как у вас получится. Открыть/Комментировать

2022-12-21 15:12:28 Разбор кейса. Как закончилась история, можно увидеть в посте Насти.

Люблю смотреть на ситуацию вашими глазами! Когда вам не хватает контекста, когда уверены в своем решении, когда накладываете призму предыдущего опыта — все круто

Сначала, традиционно, что мне кажется ошибочным или рискованным:

Дизайнер и правда знает лучше, надо попросить команду не заваливать вопросами.
Любой имеет право на защиту своей позиции, вопрос — какими способами (явно не токсичными комментариями). Даже если команда была не права и залезала в сферу чужих компетенций, важно это показать корректно и экологично, что явно не удалось. Если не решить проблему коммуникации, взаимодействие дизайнера и команды не будет эффективным.

Дизайнер — токсик, надо увольнять / дать по шапке и если повторится — увольнять.
Другая крайность. Токсичность — не лучший, но часто попросту защитный инструмент неуверенного человека. Это же первое взаимодействие с дизайнером, а вся команда стала пытать в чате нового человека вопросами «зачем это здесь?» «почему именно так?» и т.п. Правда могло восприняться, как «все на одного».
Если вы, когда человек защищается, ему в резкой форме скажете, что так здесь не принято — отношения с новичком наладить будет горааздо сложнее.
И да — если вы решили заранее, что дизайнер токсик, то это будет чувствоваться, какие бы слова вы ни выбрали.

Поговорить с дизайнером и объяснить, что нарисованное кому-то нужно делать, и этот кто-то лучше знает, что можно, а что нельзя/дорого.
Действительно, есть проблема выхода за скоуп/зону ответственности. Но с нее не стоит начинать. У нас уже образовался конфликт в команде из-за вопросов и из-за ответов на них дизайнера. Решить процессную проблему врядли получится, пока есть коммуникационная: дизайнер вас сейчас не услышит, он в позиции «к бою готов» в защиту своей работы и своих компетенций.

А вот эти идеи мне кажутся полезными:

Разговор тет-а-тет с дизайнером «помоги мне понять, почему так будет лучше»
Если дизайнер новый в команде, защищать работу перед одним человеком — легче, чем перед всей командой, которая забросает глубокими вопросами так, что уйдешь в оборонительную позицию. Проблема коммуникационная остается, так как конфликт с командой уже есть, но в этой ситуации к ней проще перейти.

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

В обоих вариантах хочется добавить отдельным пунктом разговор о том, как надо и не надо защищать свою позицию. Например, если дизайнера забросали вопросами — он имеет право попросить паузу, сказать, что вопросов слишком много и ему сложно на все ответить, и предложить очную встречу; если вопросы переходят (вполне возможно) какие-то границы, то он имеет право сказать и об этом — может, там и намеки на некомпетентность дизайнера проскальзывали, за всем можно и не уследить.

Очень хороший управленческий инструмент — разделение по времени на «что делаем сейчас» и «что делаем в будущем». Действительно, чтобы не повторять неприятную ситуацию, нужно:
1. решить текущую, уже существующую проблему
2. поменять что-то в работе, чтобы подобных проблем больше не возникало (или возникало меньше)

Был вариант — пусть дизайн не сразу представляется всей команде, а проходит итерацию у продакта.
Я сначала ответила уверенно, что не стоит менять так процесс, поскольку тогда появляется лишняя итерация обсуждения: тратятся силы продакта и увеличивается рассинхрон из-за дополнительной итерации согласования. Открыть/Комментировать

2022-12-20 13:07:46 Новый кейс #нормальные_коммуникации_нормальный_продукт!
На этот раз — опыт Насти Борисюк, продакта и автора канала «Кнопка «Хорошо».
Вот вам первая часть истории Насти. Что бы вы делали на ее месте?

Кейс: конфликт в чатике

Ситуация

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

После первого обсуждения “что делаем” дизайнер подготовил макеты. Во время близкого изучения макетов нашли, что сценарий работы пользователя изменился. В планы и цели команды не входило изменять опыт пользователя и делать доработки функционала.

В специальном чате, где обсуждался дизайн, завязывается обсуждение в духе “а зачем это”, “вот так не можем сделать”, “а давайте так?”. Дизайнер участвует в дискуссии, но чем больше команда сыплет вопросами, тем больше накаляется ситуация. В итоге дизайнер токсичит и в конце концов выдает: “Я дизайнер, мне лучше знать как надо”.

Что делаем, знатоки?

Пишите в комментариях, как бы вы поступили. Завтра — с меня разбор вариантов, с Насти — рассказ, чем все закончилось.оо Открыть/Комментировать

2022-12-13 16:49:11 Открыть/Комментировать

2022-12-13 16:48:26 Небольшой опрос. Расскажите, на каком уровне находится работа над счастьем пользователя у вас в команде?

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

А в другом из продуктов, над которым я работала, был KPI выдерживать NPS, мы анализировали постоянно запускавшиеся фидбек-опросы и по итогам приоритизировали в беклоге задачи. А у вас как?

Если напишете в комментариях, будет очень интересно! Открыть/Комментировать

2022-12-13 16:48:13 #growth
Не могла пропустить этот доклад про счастье пользователя, еще и потому, что в середине Аделя сделала референс к названию канала (не знаю, специально или так получилось, но все же)

Авито довольно давно достигли PM-fit и выбрали модель монетизации, которая работает. Новые точки роста лежат в retention, а именно в работе над CX — решили работать над счастьем пользователя более плотно.

Как его измерить? 2 месяца исследований стратегий и опыта других компаний спустя выяснилось, что пользователь доволен, когда:
выполняет свою задачу с минимальными затратами
без негативных эмоций и в идеале получает удовольствия

Померить первую часть, если у тебя PM-fit, легко: кол-во объявлений, конверсия, ликвидность и т.п. в Авито давно уже считают и оптимизируют другие команды. Но с болевыми точками раньше не работали, и накопился продуктовый долг: критичные проблемы, просто мелкие неприятности, никогда не попадающие в приоритеты.

Начали с критичного, провоцирующего отток . Метрикой выбрали обращения в поддержку (люди не любят туда писать, так что если пишут — проблема близка к критичной), нормированные на значения (например кол-во объявлений), чтобы учесть рост бизнеса. Правда даже нормирование не всегда срабатывает: у доставки метрика все время росла, что нормально, тк это очень растущий продукт.

Сформировали беклог. Просто взять тикеты поддержки нельзя, система завязана на KPI и PNL поддержки, а также там есть проблемы, не-СХ, например, мошенничество (есть целая команда в авито). Разработали свою систему определения приоритетов: количество + критичность сценариев. Оценка результатов — иногда по total, но чаще a/b тестом — выкатывали обновление и после накладывали id пользователей, смотрели значимость.

Поставили цель. Это не могло быть 0 тикетов, тк есть сценарии, которые без принципиальной смены подхода (например, изменения схемы монетизации) невозможно решить. Выбрали бенчмарк рынка -50% нагрузки на саппорт за год для крупных компаний.

В итоге смогли сократить обращения на 40% — отличный результат, тк 50% был ОКР-ом.

Дальше перешли к проблемам, вызывающим сильные эмоции.

Качественные сигналы накладывали на CJM из беклогов с интервью, отзывов в сторах и опроса CSAT с добавлением числового подкрепления. Приоритизировали по частоте, критичности, а также учитывали, что какие-то проблемы — общие для нескольких стримов Авито.

Для измеряемых сигналов пробовали использовать NPS/ CES / CSAT, даже пробовали разработать cвою метрику. В итоге выбрали CSAT для отдельного сценария с использованием UXFeedback.

А как измерить тот, что не поддается числовому измерению? Путь CJM делили на красный/желтый/зеленый по наличию ошибок, брали за метрику % красного пути. Небольшие неизмеримые изменения правили «бандлами» и смотрели на общее изменение CSAT по сценарию.

Искать метрики непросто, но они нужны, чтобы «продавать изменения». Например, в продвижении рекламных услуг были dark patterns, их не хотели убирать, тк это выручка . Через метрики получилось показать, что это большая боль — смогли исправить.

По итогам изменений вышло увеличить CSAT на 8% и уменьшить красный путь на 20%.

И немного принципов для хорошего CХ:
уважение к пользователю
прозрачность и доверие
проще предотвратить проблему, чем чинить.

Источник: видео, 22 минуты Открыть/Комментировать