Как внедрить обновление и не убить продукт

Как внедрить обновление и не убить продукт

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

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

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

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

В чем риски внедрения?

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

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

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

  2. Иногда обновления экономически невыгодны или противоречат первоначальной идее сервиса.

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

Как мы работаем с рисками и принимаем решения о внедрении обновлений?

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

Оцениваем рентабельность

Недавно мы встали перед выбором, какое из обновлений внедрить первым: постинг в Telegram или в Stories. Задачи примерно одинаковые по затратам ресурсов, и наши клиенты хотели оба этих обновления. Цепочка наших рассуждений и действий:

  1. Поняли, что внедрить оба обновления одновременно невозможно.
  2. Проанализировали, кто именно просит обновления.
  3. Рассчитали возможный доход при внедрении каждого из обновлений.
  4. Посмотрели емкость рынка и предложения конкурентов.

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

Люди, которые просят Телеграм, другие: мы тратим деньги на их привлечение, они приходят в сервис и тестируют его. Но покупку совершить не готовы: часть работы все равно придется делать руками, а сервис автопостинга должен автоматизировать! Как только мы добавили Телеграм, мы не только активировали часть этих клиентов (и отбили затраты на привлечение), но и доказали им, что действительно заботимся об интересах клиента.

Отзыв нашего клиента с yell.ru
Отзыв нашего клиента с yell.ru

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

Рассчитывайте рентабельность и учитывайте свои интересы
Рассчитывайте рентабельность и учитывайте свои интересы

Важно! При принятии решений не игнорируйте свою экономическую выгоду.

Проверяем, не противоречит ли обновление основной идее

Пользователи сервиса рассылок SMS Aero писали, что им не хватает функций по работе с базами контактов. Мы задумались об обновлении, но поняли, что оно противоречит основной идее.

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

Когда пользователь просит нас об этих функциях, мы предлагаем ему решение — провести фильтрацию и сегментирование баз данных в Excel, а затем объясняем, как за несколько минут загрузить эти данные из Excel в наш сервис и работать с рассылками дальше.

Противоречивые обновления не сделают продукт лучше
Противоречивые обновления не сделают продукт лучше

Важно! При принятии решения помните о первоначальной идее.

Проверяем реальные потребности заказчика

Этот пункт один из самых опасных. Определить реальные мотивы пользователей трудно: действительно ли пользователю не хватает функциональности сервиса или он просто хочет высказать свое мнение о продукте?

У нас есть крупный клиент, который просил нас внедрить обновления в модули SMS Aero. Мы посчитали трудозатраты и поняли, что будем готовы изменить модули через 6 месяцев и предложили клиенту другое решение проблемы. В ответ услышали: «Не сделаете модули сейчас, уходим к конкурентам». Было обидно. Но прошло полгода, а клиент от нас так и не ушел, пользуется нашим сервисом. Вопрос о модулях больше не поднимался. Кстати, обновление мы внедрили, как и обещали клиенту.

Как внедряем обновления без риска для жизни? Если у клиента реальная проблема, то он будет вместе с вами искать решение, а не ставить ультиматумы.

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

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

У нас была похожая ситуация. Некоторые пользователи жаловались, что не могут себе позволить доступ к SMS Aero. Мы опросили более сотни человек и нашли способ, как помочь им сэкономить — создали более дешевый канал для рассылки шаблонных SMS. Месяц разрабатывали обновление, 3 месяца тестировали и исправляли ошибки. Но после запуска функции выяснили: именно те клиенты, которые просили обновление, им не воспользовались. Возможно, мы ошиблись и неправильно определили, в чем была проблема и была ли она на самом деле.

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

Как внедряем обновления без риска для жизни?

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

Обновление последовательно движется от стадии разработки к тестированию, анонсированию и запуску.

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

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

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

Тестирование на реальных пользователях лучше сотни книг об их поведении
Тестирование на реальных пользователях лучше сотни книг об их поведении

Важно! Вводите обновление постепенно. Анализируйте данные на каждом этапе. Изучайте поведение реальных пользователей.

Как анонсируем?

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

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

Вывод

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

Шпаргалка по внедрению обновления в проект
Шпаргалка по внедрению обновления в проект

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

Делайте то, что выгодно вам и вашим клиентам. Надеемся, наш опыт оказался полезен.

3131
8 комментариев

Комментарий удалён модератором

Спасибо за комментарий! Способы проверки достоверности потребностей — тема для отдельного лонгрида). Если кратко — у нас несколько способов проверки:
1. Во-первых, на протяжении всей жизни сервиса (это 6 лет по одному продукту, и полгода по другому) мы ведем бэклог: записываем каждое пожелание от пользователей в Jira. То есть на момент появления любого пожелания мы уже знаем, сколько клиентов хотят такую же или похожую фичу и что они имеют ввиду, когда ее просят.
2. Сразу после того, как клиент высказывает пожелание, мы задаем вопрос «Чтобы что?». Такая постановка вопроса помогает узнать, какую проблему хочет решать клиент. Например (в продукте SMM): у нас есть встроенное сокращение ссылок с трекингом кликов. Клиент говорит, что ему срочно нужна функциональность UTM-меток. Мы спрашиваем: «Что вы хотите отслеживать метками?».
Варианта ответа 2 (по большому счету): либо собирать отчеты в Google Analytics, либо смотреть, сколько кликов было по каждой ссылке в разрезе соцсетей (знать, какая сеть активнее).
Клиент говорит, что второй вариант. У нас эта функциональность уже есть — рассказываем клиенту, учим пользоваться и показываем, почему удобнее.
3. Когда считаем, что поняли задачу клиента (именно результат, который он хочет получить), то проводим исследование. В зависимости от типа обновления (массовое, или специфическое) сегментируем клиентов и спрашиваем у них, как часто возникает задача, как они ее решают и т.д. Маячок, что проблема надумана: когда пользователи говорят: ДА, ПРОБЛЕМА ЕСТЬ!!!111, и на вопрос «Как справляетесь?» говорят: «Да никак, так и живем». Если бы проблема реально была, люди бы ее решали, а не просто переживали. После опроса принимаем решение о вводе обновления и его конечном виде.

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

4

Это та компания , которая прислала мне сегодня письмо "с 1 марта мы поднимаем цены. Цены вы сможете узнать 1 марта в разделе Цены"?

Это та компания, которая прислала вам сегодня письмо «Оператор связи «Теле2» изменяет политику предоставления услуг. В связи с этим с 1 марта 2018 года в SMS Aero изменятся цены на SMS-рассылки».
К сожалению, в случае с SMS мы не создаем услугу, а предоставляем комфортный доступ к уже имеющейся. Ценовая политика не всегда зависит только от нас: например, сейчас абсолютно все сервисы SMS-рассылок поднимают тарифы.

2

Комментарий удалён модератором

Вот написал ты статью. Опубликовал (а это на VC ого-го как непросто). Сидишь и радуешься. И тебе «блямц!» уведомление, что кто-то комментит. И ты радостный заходишь, а там спам. И как лицом об стену.
Нехорошо.
Спамер, не спамь!

1