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

В статье мы разберемся с системой развития продукта на основе пользовательской обратной связи. Поговорим обо всем пути — от сбора отзывов по разным каналам до анализа и реализации.

Кому и зачем нужна обратная связь

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

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

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

Развитие продукта через фидбек дает бизнесу:

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

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

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

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

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

Собираем фидбек — какие есть способы? 

Для получения объективной картины важно наладить разные каналы сбора обратной связи. Ключевые каналы и правила их использования ↓ 

Опросы и анкеты

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

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

Когда использовать:

• после ключевых действий пользователя,

• для регулярного отслеживания метрик,

• при большом количестве пользователей.

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

Встроенные виджеты на сайте/приложении/в боте

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

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

Преимущества этого подхода при сборе фидбека: 

• минимальные усилия для пользователя,

• структурированные данные,

• контекстное получение фидбека. 

Саппорт или техническая поддержка 

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

Особенности работы техподдержки:

• показывает уже случившиеся проблемы,

• требует системы категоризации,

• источник срочных исправлений.

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

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

Отдел продаж и пресейл

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

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

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

Аккаунт-менеджмент и Customer Success

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

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

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

Глубинные интервью и CustDev

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

Когда применять:

• На ранних этапах развития продукта

• Для тестирования новых гипотез

• При анализе сложных проблем пользователей

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

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

Так много каналов. Как это все объединить? 

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

Что можно сделать: 

1. Интегрировать чаты и мессенджеры. Если команда или пользователи общаются в мессенджерах (Slack, Microsoft Teams, Телеграм), то стоит настроить интеграцию, чтобы создавать задачи напрямую из чата. То есть, заметив в диалоге с коллегами идею или баг, достаточно упомянуть бота – и предложение сразу зафиксируется в бэклоге. 

2. Настроить e-mail. Обратная связь нередко приходит на электронную почту – например, через форму «Напишите нам» на сайте или просто на support@вашпродукт. Чтобы такие письма тоже включать в единый поток задач, Kaiten предлагает интеграции с почтовыми сервисами. Так письма от клиента превратится в тикет, который команда не забудет обработать.

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

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

Мы собрали фидбек — и что с ним делать дальше? 

Собрать фидбек — только начало. Дальше предстоит большой цикл работы: проанализировать, отфильтровать, решить, что делать сейчас, а что потом, реализовать задумку и снова спросить у пользователей. Такой процесс требует системности. 

Как с этим разобраться по шагам ↓

Шаг 1. Сбор и консолидация запросов

На этом этапе мы собираем все обращения в один список — интервью, опросы, тикеты саппорта, идеи от отделов продаж и аккаунтов. Все это можно объединить, например, в доску: 

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

Шаг 2. Анализ и отсеивание лишнего 

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

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

Шаг 3. Приоритизировать запросы

Этот этап — один из ключевых в развитии продукта. Ресурсы всегда ограничены, все сразу сделать невозможно, поэтому нужно расставить задачи в правильном порядке. Есть множество методик приоритизации. Одна из популярных и простых — метод MoSCoW.

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

• Массовость запроса. Если функцию просят 50 клиентов — ей приоритет выше, чем у идеи от одного пользователя. Важно не только количество компаний, но и их размер: запрос от одного крупного клиента с 10 000 пользователей может перевесить 50 мелких клиентов по 5 юзеров.

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

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

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

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

Шаг 4. Формирование бэклога 

Когда отфильтрованные запросы расставлены по приоритетам — пора оформлять их в задачи. 

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

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

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

Шаг 5. От планирования к реализации 

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

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

Шаг 6. Разработка и выпуск изменений 

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

Шаг 7. Сбор фидбека на изменения 

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

Это замыкает цикл: вы исходно получили запрос → реализовали → теперь уточните, насколько успешно вы это сделали. 

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

Что в итоге

Относитесь к работе с фидбеком как к непрерывному процессу. Новые вводные поступают постоянно, приоритизация периодически меняется вместе с бизнес-целями и рынком. Поэтому цикл шагов 1–7 повторяется снова и снова.

Мы что-то изменили — как об этом рассказать юзерам? 

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

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

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

• База знаний/журнал обновлений. Там пользователи могут в любое время посмотреть историю релизов с подробностями. Это удобно для тех, кто мог пропустить несколько обновлений подряд.

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

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

Но не все так просто — есть и проблемы

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

Типичные проблемы при работе с фидбеком пользователей собрали в таблице ↓  

Нужно понимать, что даже реализовав что-то полезное по запросу клиентов, им это фича может просто не понравиться. Всегда найдется тот, недоволен всеми новинками. Тут нужно понять, в чем причина негатива: 

• С продуктом реально есть проблема, фича вышла сырая и требует доработки? 

• Новые функции мешают работоспособности клиентов? 

• Клиенту просто не нравится, что теперь все по-новому и ему нужно привыкнуть? 

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

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

А стоило ли улучшать? 

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

Придерживайтесь 2 правил при работе с фидбеком:

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

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

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