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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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