Хабрахабр

Custdev от Службы поддержки

И снова здравствуйте!

Вот теперь разработали и вывели курс «Product Owner». Мы продолжаем расширение тем, которые преподаются у нас. Автор курса Екатерина Марчук предлагает вам ознакомится со своей авторской статьёй и приглашает на открытый урок.

Как нам интерпретировать фидбек?

И каждый, кто знаком с понятием, осознает, насколько это важно, а если говорить прямо — жизненно необходимо для успешного запуска продукта. О customer development или развитии пользователей в последнее время говорят все кому не лень.

И самое главное, custdev позволяет нам проверять гипотезы. Customer develoment помогает понять ценность продукта, выявить скрытые мотивы потребителей, их реальные проблемы и потребности. Без проверки гипотез сложно вести проект в правильном направлении, потому что, как показывает практика, голые цифры, увы, не репрезентативны.

У нас же ни на что не хватает времени, в том числе — и на такие важные задачи. Но, как водится, на чисто теоретическом понимании всё и заканчивается.

Однако думать о плохой привычке и разбираться с ней — совершенно разные вещи. Почти у каждого есть плохая привычка, от которой хочется избавиться. Вместо управляемого сбора и анализа пользовательского фидбека получаем хаотический поток неструктурированной информации и не получаем развития пользователей. Так и здесь: мы вроде бы занимаемся развитием пользователей — собираем огромный объем обратной связи через колл-центры, социальные сети, тематические площадки, технические центры обслуживания и… не делаем ничего полезного.

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

Как вы думаете, почему механизм обработки фидбека часто выходит из строя?
В погоне за количеством
или Почему не надо запускать MVP без проверок

Давайте поговорим о жизненном цикле пользовательской обратной связи, то есть отзывов, заявок и обращений.

Давайте признаем: все мы обожаем KPI. Простой пример. Чем больше заявок обработано, тем выше будет лояльность. И если посмотреть на Службу поддержки, одной из ключевых компонент KPI будет количество закрытых заявок.
На первый взгляд всё логично. Так, да не так: индекс CSI (Customer Satisfaction Index, индекс удовлетворенности клиентов) не растет пропорционально количеству заявок, закрытых Службой поддержки. Чем выше лояльность, тем больше срок удержания пользователей. Почему?

При количественном подходе полученные заявки не валидируются должным образом, то есть никакой customer development не применяется. Все довольно просто. какую потребность, задачу или боль стараемся удовлетворить? Это равноценно попытке реализовать идею, функцию или целый продукт без проверки ключевых гипотез: зачем мы всё это делаем? Чем закончится такая попытка, думаю, всем очевидно. какую выгоду хотим принести?

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


Как мы дошли до жизни такой?
или о закономерных завалах в поддержке после запуска продукта

Владелец продукта Тимофей всегда полагается на свой опыт и чувство прекрасного. Возьмем стандартный сценарий. Каждому известно: опытная команда способна создать хороший и востребованный продукт самостоятельно. Так вышло, что при создании MVP сроки горели, стейкхолдеры лютовали, и Тимофей решил, что на глубинные исследования потребителей нет времени, можно обойтись без них. Особенно, когда нет времени. Исследования истинных потребностей не нужны!

Поэтому про A/B тест перед запуском забыли. Времени нет! Вы же помните, да? А soft launch не провели, потому что времени нет.

Что делает Тимофей? Результат закономерен: поток гневных обращений после релиза. Конечно, начинает в срочном порядке исправлять проблемы — все и сразу.

В спешке забыли написать и прикрутить. Метрик, само собой, у нас не было. И вот, наконец, мы по-настоящему вышли в релиз! А еще Тимофей решает загладить последний серьезный промах через добавление нового функционала. Благодарные пользователи несут нам деньги?
Вовсе нет! Ура? Заявок становится всё больше, еще больше, и вот эта лавина обрушивается в наш бэклог… Ничего удивительного, служба поддержки работает хорошо, не то что наш Тимофей. Вместо благодарности пользователи приносят еще больше заявок в Службу поддержки. Не будьте как Тимофей! Ему теперь разгребать сошедшую лавину и спасать продукт.

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

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


Как начать жизнь с чистого листа?
или Возвращение к истокам — вводим метрики!

Обязательно до релиза первого MVP!
Когда вы собираете первый MVP, вы строите модель ценностного предложения по профилям пользователей. Начинать нужно с создания простых метрик. В противном случае все ваши усилия пойдут только на нагрев окружающей среды и никакого результата вы не получите. Сами профили вы должны предварительно собрать и сформировать.
Если по какой-то невероятной причине ничего такого не делалось, идем в самое начало и действуем по порядку: создаем профили, проверяем гипотезы, строим наше предложение и только потом — бизнес-модель!

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

А еще мы делаем ошибки и можем не понять потребности пользователей. Может получиться так, что функция важна, но её не используют из-за убогой реализации. Всё это мы обязательно увидим в метриках, которые у нас есть. Тогда некоторыми функциями не будут пользоваться, потому что они не нужны. Ведь они у нас есть, правда?

А что делать, если вы проспали все полимеры и продукт увидел свет без положенной подготовительной работы? Хорошо. Беритесь за создание метрик и общение с пользователями. Не ставьте на продукте крест! И да пребудет с вами Сила! Плавно выходите на следующий цикл: снятие сливок с метрик -> обработка обратной связи -> реализация фич по назначенным приоритетам -> релиз.

И зададите вот какой вопрос: а почему нельзя просто провести A/B тесты перед релизом? Прекрасно, скажете вы. Посмотреть на их метрики, всё проверить, исправить погрешности и выйти в релиз?

И вы, безусловно, правы… если речь идет о продукте, который уже вышел на рынок. Очень хороший вопрос. Тогда вы четко понимаете целевую аудиторию, и когортные A/B тесты будут, пожалуй, одним из лучших инструментов для оценки.

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

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

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

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

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

Ненадолго. Когда мы разобрались с метриками и наш MVP уже готов увидеть свет, жмем на кнопку “Релиз!” и отправляемся нервно курить в сторонке.


Получаем первые отзывы
или Шестой подвиг Геракла

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

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

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

Не забудьте добавить счетчик этих обращений в вашу BTS (Bug tracking system). Заблаговременно сформулируйте простые и понятные критерии, каким образом будут группироваться однотипные обращения. Идеально, если вы можете автоматически получать из CRM цифры по уже агрегированным обращениям.

Например: пока количество обращений по одной проблеме меньше 5 – не заносим её в бэклог, за исключением тех случаев, когда проблема блокирует наш основной сценарий. Установите для счетчиков пороговые значения и назначьте соответствующие действия, которые нужно предпринимать по достижении каждого порога. Достигаем значения в 20 обращений — начинаем детальное изучение, общаемся с пользователями, пытаемся понять причину. После 5 обращений заносим в бэклог и отслеживаем. Ваши цифры могут быть другими, а правила будут зависеть от специфики продукта, количества клиентов и прочих факторов. Дошли до 50 – переводим в разряд критически важных, приоритезируем и берем в следующий спринт на проработку. Но принцип вы поняли.

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

Итак, ключевые шаги по приоритезации:

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

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

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


Как не остаться с длинным релизом
или Не пытайтесь объять необъятное

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

Время до релиза растягивается, промежуточного фидбека нет, а после релиза получаем ту самую лавину отзывов. Обычно эта история развивается так: на этапе формирования плана включаем 10 фич, через две недели у нас их 12, потом 15, а на релиз выходит целых 25. Красота!

А вот чем: И чем нам это грозит?

  • сроки доставки фич не выдерживаются;
  • не можем удержать клиентов/пользователей;
  • не получается привлечь новых клиентов — срывается план продаж;
  • доля рынка скукоживается;
  • стейкхолдеры недовольны;
  • демотивация всей команды.

Смыть. Повторить. Итог очевиден.

Что делать? Как же быть? Вы скажете: похвальное намерение, но что-то не выходит! Релизиться как можно чаще. Выйти на частый релизный цикл нелегко. Соглашусь. Но есть и общие моменты: через неделю после релиза у вас обычно есть четкая картина и по метрикам, и по полученным обращениям. Тут еще нужно понимать — это не просто частые релизы, это частые релизы с отработанной обратной связью.
Всё всегда зависит от специфики продукта. Из этой информации вы можете понять, где есть проблемы.

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

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

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

  • правильно ли вы поняли проблему/задачу/хотелку?
  • правильно ли назначили приоритет?
  • не осталось ли за кадром что-то более важное и значимое, о чем вы не знаете?
  • просчитали ли вы ценность от реализации той или иной фичи?

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

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

  • четкие приоритеты для каждой фичи;
  • цели спринтов;
  • оценка ценности каждого релиза.

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

Что в остатке?

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

Для перехода к следующему этапу вам понадобится честно ответить на несколько вопросов:

  • как вы оцениваете полученные показатели — они хорошие или плохие? гипотеза оправдывает ожидания или нет?
  • какие метрики нужно исправить в первую очередь?
  • как приоритезировать фичи?

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

Первый блин почти всегда выходит комом. И небольшое, но важное послесловие. Так, чтобы потом не приходилось вносить уточнения и снова общаться с пользователями. Честно говоря, с первой попытки почти невозможно выбрать четко подходящие и эффективные метрики, идеально настроить механизм сбора и обработки отзывов. Надо пробовать снова, экспериментировать, переделывать и повторять еще раз. Да, в первый раз может выйти полная ерунда, тут нечего скрывать. Только путём собственных проб и ошибок вы получите бесценный опыт развития потребителей и продуктов, начнете создавать личную философию работы, которая непременно приведет к успеху!

THE END

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть