Я планирую развитие SaaS от пропускной способности поддержки, а не от списка пожеланий

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

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

Список пожеланий не равен плану развития

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

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

Это похоже на план ремонта в работающем доме. Можно красиво расписать замену всех комнат. Но сначала нужно понять, выдержит ли электрика, есть ли доступ к стояку и где жильцы останутся без воды. В продукте роль стояка часто играет поддержка: через неё проходят последствия каждого изменения.

Сначала отделяю сигнал от шума

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

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

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

У плана есть реальная пропускная способность

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

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

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

Поддержка должна видеть смысл изменения раньше клиента

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

Здесь полезна простая проверка. Дайте человеку, который отвечает клиентам, описание релиза и спросите: сможет ли он за минуту объяснить, зачем это изменение конкретному пользователю. Если нет, описание слишком техническое или сама ценность ещё не определена.

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

Не каждую боль нужно лечить новой функцией

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

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

Как превращаю обращения в решения для roadmap

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

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

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

Проверяю релиз не количеством тикетов

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

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

Что стоит сделать на ближайшей планёрке

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

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

Почему поддержка не должна выбирать продукт вместо команды

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

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

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

Хороший план показывает, от чего команда сознательно отказалась

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

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

Такая ясность помогает и поддержке. Вместо расплывчатого «когда-нибудь сделаем» она может объяснить клиенту текущий рабочий путь и не создавать ожидание точной даты там, где её нет. Доверие к SaaS растёт не от бесконечного списка будущих функций, а от предсказуемости того, как команда принимает решения.

Небольшой ритм лучше большой квартальной витрины

План не обязан быть документом на квартал с десятками строк. Для работающего продукта полезнее короткий повторяющийся ритм: собрать сигналы, выбрать одну-две темы, сформулировать ожидаемый самостоятельный результат, проверить выпуск и вернуться к наблюдениям. Через такой цикл видно, какие идеи действительно разгружают клиентов и поддержку, а какие только красиво выглядят на планёрке.

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

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

Вопросы, которые удерживают план в реальности

Перед тем как добавить тему в ближайший план, я бы ещё раз спросил: это затруднение повторяется у нескольких клиентов или только громко звучит? Можем ли мы описать один самостоятельный результат без названия будущей функции? У команды есть время не только сделать изменение, но и провести первые дни после выпуска? И, наконец, кто скажет через неделю, стало ли пользователю проще?

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

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