Особенности Работы С Отзывами Пользователей В Команде Slack — Рассказ Продакт-Менеджера Компании

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

Особенности работы с отзывами пользователей в команде Slack — рассказ продакт-менеджера компании

Кеннет Бергер, первый менеджер по продукту Slack, присоединился к компании в 2014 году, когда сервис только начинал набирать популярность.

За первый год работы Бергер помог стартапу увеличить количество ежедневных пользователей сервиса со 100 тысяч до более чем 1 миллиона.

«Клиенты оценили проект так, о чем другие компании могли только мечтать», — пишет First Round Review. «Со стороны может показаться, что быть менеджером по продукту в такой организации довольно просто.

Это не совсем правда.

Даже когда продукт стабильно демонстрирует хорошие темпы роста, крайне важно отслеживать и правильно обрабатывать отзывы пользователей.

Ни одна компания не должна почивать на лаврах».

В интервью First Round Review Бергер рассказал, чему он научился за время работы в Slack, почему он ценит цели компании выше конкретных показателей, а также поделился советами о том, как обрабатывать обратную связь и определять, что важно в потоке комментариев и информационного шума.

.



Преследуйте цели, а не конкретные цифры.

«Проблема большинства стартапов в том, что они не знают, как справляться с обратной связью — они не знают, что с ней делать и на что обращать внимание», — говорит Бергер.

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

Это позволяет сотрудникам легко упустить действительно важные вещи.

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

«Многие команды зацикливаются на одной метрике и всеми силами стараются ее улучшить.

Все они занимаются отслеживанием одной цифры, которая почему-то служит показателем успеха.

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

Как пишет First Round Review, Кеннет Бергер, ранее работавший в Slack неуспешный Стартап YesGraph, как никто, понимает, что ситуация в компании может измениться в любой момент, и любой сотрудник может обнаружить, что какое-то время отслеживает устаревшие метрики.

Если команда сосредоточена на главных целях, этого можно легко избежать.

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

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

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

Но кроме них есть множество менее очевидных показателей, следовать которым каждая компания решает сама», — говорит Бергер.

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

По мнению Кеннета Бергера, любому бизнесу имеет смысл начать регулярно пересматривать собственные цели — например, раз в месяц или квартал.

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

.

При этом важно правильно расставить приоритеты между целями – это помогает выбрать порядок решения задач.



Гипотезы подтверждаются наблюдениями

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

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

В начале своего пребывания в Slack Кеннет Бергер искал способы привлечь к сервису больше пользователей.

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

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

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

Затем сотрудники экспериментировали с введением бесплатного демо-периода.

Показатели улучшились, но не так существенно, как хотелось бы команде.

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

В других случаях проверка гипотез часто приводила к кардинальным изменениям в стратегии Slack. Например, изначально компания не позиционировала продукт как корпоративный мессенджер.

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

Все действия в компании стали полностью прозрачными.

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

«Пользователям нужна была ясность, а в то время у нас даже не было скриншота самого продукта на его веб-странице», — объясняет Бергер.

Теперь позиционирование Slack строится вокруг сообщений — они являются связующим звеном всего, что происходит при взаимодействии с сервисом.

Еще одна проблема, с которой столкнулась команда, заключалась в том, как показать пользователям полезность сервиса.

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



Необходимо помнить о возможных отклонениях

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

Менеджеры по продуктам тоже должны этому научиться.

Специалист перечислил наиболее распространенные источники отклонений.



«Отказ от выборки»

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

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

и не интересуются самим продуктом.



«Подтверждение отклонено»

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

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

Как отмечает специалист, именно неверная интерпретация данных была одной из причин его предыдущего проекта — YesGraph. Молодые команды, «которые могут взглянуть на продукт под иным углом, чем просто A/B-тестирование отдельных элементов интерфейса», должны воспользоваться этой возможностью и продумать все возможные варианты.



«Отчет об отклонении»

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

Те источники данных, в которые сложнее «погрузиться» просто игнорируются.

Важно правильно оценить все источники данных и их важность — тогда снижается вероятность упустить важные моменты.



Объедините качественные и количественные данные

При проверке гипотез важно выбрать наиболее эффективные источники исходных данных.

«Вопрос в том, как именно вы получаете обратную связь от пользователей и как лучше всего это сделать», — объясняет Кеннет Бергер.

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

Бергер руководствуется следующим правилом:

Количественные данные покажут вам, что что-то не так, а качественные объяснят, почему.

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

Однако стоимость включения показателей в число отслеживаемых на самом деле может оказаться гораздо выше, чем кажется – за информационным шумом скрывается высокий риск не услышать важное мнение.

«Нужно уметь подавлять желание реагировать на каждый отзыв в Твиттере.

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

«Вам не обязательно уделять одинаковое внимание всем поступающим отзывам.

Выбирайте первоисточники и определяйте ценность каждого комментария».



Собирайте данные, которых у вас нет

Чаще всего основные проблемы продукта можно выявить, взглянув на его метрики.

Получить качественную обратную связь гораздо сложнее и требует немало усилий.

«Не ограничивайте себя только теми каналами, которые у вас есть», — говорит Бергер.

Нам необходимо выйти за их рамки и собрать данные, которые могли бы дать полную картину проблемы.

Когда Бергер впервые присоединился к команде Slack, ему казалось, что ему не над чем работать: пользователи оставляли о продукте только положительные отзывы.

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

В то время самые крупные команды, использующие Slack, насчитывали 300-400 сотрудников, и обратной связи от них вообще не было — они были в восторге от продукта компании, похожей по размеру на сам Slack. Так Кеннет Бергер узнал о проблемах, с которыми сталкиваются большие команды, и смог начать искать решения.

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

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

«Моя гипотеза заключалась в том, что продукт не приносил пользу большим командам так, как должен был бы», — объясняет Бергер.

Менеджер быстро определил крупнейшие команды, использующие Slack, и приступил к проверке собственной диссертации.

Несколько недель он работал с сотрудниками таких компаний, не задавая им конкретных вопросов, а пытаясь выяснить, как они пользуются сервисом.

Вопросы были, по словам специалиста, самые простые: «Как вы используете SlackЭ», «Для чего вы его используетеЭ», «Какие еще инструменты вы используетеЭ» При первом запуске Slack некоторые уведомления отправлялись пользователям по умолчанию, и их нельзя было отключить.

Другие оповещения могут быть настроены.

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

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

Это очень помогло сервису в его развитии, — говорит Бергер.

Самое главное при выборе кандидатов для предоставления обратной связи — это наличие гипотезы.

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

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

«Некоторые люди просто не могут адекватно пользоваться этой услугой», — говорит он.

Вместе с данным постом часто просматривают: