Прокачайте ваш онбординг
с навигатором интерфейсов Experrto
Выберите категорию

Как, зачем и в каких случаях следует «убить» некоторые функции продукта?

Как, зачем и в каких случаях следует «убить» некоторые функции продукта?

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

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

Содержание статьи

Выбор «фич», от которых нужно избавиться

Как «убить» функцию приложения?

1. Заранее всех предупредите и все объясните
2. Обеспечьте плавный переход
3. Примиритесь со своим решением

Фреймворки приоритезации фич продуктов

Заключение

Выбор «фич», от которых нужно избавиться

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

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

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

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

  • Яндекс.Такси помогает вызвать такси в любое время и из любого места
  • Boom предоставляет доступ к неограниченной музыкальной библиотеке Вконтакте
  • Папа Джонс организует доставку пиццы и закусок на дом

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

Неактуальная «фича» может поставить ваш продукт под удар по следующим причинам:

  1. Размывание основной ценности. Ваше приложение существует для решения конкретной проблемы. Функции, которые по сути являются просто дополнением, мешают пользователю быстрее и четче распознать основную ценность продукта.
  2. Трата ресурсов. Любая, даже самая незначительная возможность продукта, должна быть реализована на высоком уровне, а это означает, что вам придется тратить время и ресурсы на ее поддержание и устранение ошибок по мере их возникновения (а возникают они всегда).
  3. Потеря денег. Чем дольше вы будете откладывать проблему неактуальных функций, тем больше денег потеряете. Все в этом мире имеет свою цену, и поддержка невостребованных возможностей продукта сильно ударит по прибыльности всего бизнеса.

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

Как же выбрать, какие фичи убрать, а какие оставить?

В процессе перед вами встанет масса разных вопросов. Ради простоты изложения остановим свое внимание на наиболее важных:

  • Дополняет ли эта «фича» основную ценность приложения? Убедитесь, что функция напрямую связана с основной миссией и ценностью вашего продукта.
  • Кто-нибудь ею пользуется? И способствует ли ее использование успеху пользователей? Внимательно изучите, сколько людей на самом деле используют ту или иную функцию, и есть ли вероятность, что они останутся с вами и в будущем.
  • Оправдан ли расход средств на поддержание функции? Тот факт, что та или иная функция приложения является дорогостоящей для разработки и обслуживания, не должен означать, что она бесполезно расходует финансы. Аналогично, низкая стоимость поддержания «фичи» не должна становиться основанием для ее включения в функциональный набор продукта. Вот почему так важно видеть общую картину: вносит ли эта функция достаточный вклад в ваш MRR? Имеют ли клиенты, которые используют эту функцию, более высокую пожизненную ценность?

Если вы ответили «нет» на любой из этих вопросов, возможно, пришло время навести в приложении порядок. Соучредитель Mind the Product Жанна Бастоу (Janna Bastow) объясняет, как следует подготовиться к этому процессу:

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

Как разработать MVP по методике бережливого UX?

Как «убить» функцию приложения?

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

1. Заранее всех предупредите и все объясните

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

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

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

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

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

Разберем пример. Когда руководство GrooveHQ осознало, что их приложение для live-чата оказалось делом безнадежным, расходующим средства и отвлекающим внимание от основной ценности продукта, они приняли тот факт, что время его ликвидировать, наконец, пришло. Решиться на этот шаг было нелегко, но менеджеры предпочли быть открытыми и честными со своими пользователями, что окупилось в долгосрочной перспективе. Электронное письмо CEO Алекса Тернбулла (Alex Turnbull) является прекрасным примером того, какой вид должно иметь ваше обращение к клиентам:

Пожалуйста, прочитайте. Новости о будущем Live Chat

Пожалуйста, прочитайте. Новости о будущем Live Chat

Привет всем!

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

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

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

Мы основали Groove, чтобы вы могли обеспечить поддержку своих клиентов при помощи супер-простого, элегантного и надежного продукта. И мы верим, что наше приложение службы поддержки (helpdesk app) — лучшее, что может быть. Но мы не нашли время, чтобы обеспечить Live Chat таким же уровнем внимания. Анализ приложения, метрик его использования показал, что оно должно быть гораздо лучше.

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

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

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

С вашей стороны не требуется никаких действий. Если вы используете Live Chat, то с 1-го сентября плата за него взиматься не будет, и он исчезнет с панели инструментов Groove и магазина приложений.

Я знаю, что кого-то эта новость обязательно разочарует, но мы надеемся, что вы понимаете, почему мы решились на это изменение: чтобы сфокусировать свое внимание на том, что у нас получается лучше всего, и продолжить работу над самым лучшим helpdesk-приложением в мире.

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

И снова, мы благодарны вам за ваше понимание и доверие.

Всего наилучшего,
Алекс, CEO Groove

Почему компании так боятся поговорить со своими клиентами?

2. Обеспечьте плавный переход

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

Когда HubSpot пересобрали свои инструменты для работы в социальных сетях, они организовали все так, чтобы старая и новая версия инструментов были одновременно доступны до тех пор, пока клиенты не привыкнут к новшествам. Велся постоянный мониторинг уровня отказов (тех пользователей, которые отключали новый интерфейс и возвращались к старому), и когда этот показатель стал минимальным, они отключили старую версию сервиса. И вот почему они действовали именно таким образом:

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

На протяжении несколько месяцев HubSpot вел постоянный мониторинг уровня отказов

На протяжении несколько месяцев HubSpot вел постоянный мониторинг уровня отказов

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

3. Примиритесь со своим решением

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

Своими действиями вам удалось высвободить определенную долю ресурсов компании, которые необходимо направить на работу над наиболее важными функциями продукта и сократить накопившееся отставание от конкурентов.

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

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

Фреймворки приоритезации фич продуктов

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

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

Фреймворки приоритезации фич продуктов

Еще один полезный фреймворк — «Квадрант ценности и сложности», который поможет вам определить проекты с самой высокой рентабельностью инвестиций как для вас, так и для ваших пользователей:

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

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

Нельзя не упомянуть и о таком методе приоритезации, как RICE, изначально разработанный Intercom. Эта модель обеспечивает такую работу команды, при которой функции продукта, которые оказывают наибольшее влияние на бизнес, разрабатываются в первую очередь:

Reach — охват, Impact — влияние, Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат, Effort — трудозатраты

Reach — охват, Impact — влияние, Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат, Effort — трудозатраты

  • Reach — количество людей, на которых повлияет наличие определенной фичи или ее изменение за конкретный период времени. Пример: число пользователей за квартал, количество транзакций за месяц.
  • Impact — как сильно эта функция повлияет на отдельно взятого пользователя. Оценить это влияние можно по шкале интенсивности влияние, где 3 — мощное влияние, 2 — сильное влияние, 1 — среднее влияние, 0,5 — слабое влияние, 0,25 — минимальное влияние. Пример: как сильно эта фича повлияет на коэффициент конверсии?
  • Confidence — насколько вы уверены в правильности своей оценки охвата и влияния? Имеются ли у вас данные, подтверждающие эту оценку? Этот параметр можно выразить процентом от уверенности, где 100% — сильная уверенность, 80% —средняя уверенность, 50% — слабая уверенность.
  • Effort — как много времени требует разработка и внедрение этой инициативы в продукт? Измеряется в человеко-часах или человеко-месяцах, в зависимости от объема работы.

Подробное руководство по UX-бенчмаркингу

Заключение

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

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

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

Прокачайте свой онбординг!

По материалам: appcues.com Изображение: freepik.com

Прокачайте ваш онбординг
с навигатором интерфейсов Experrto