Как убить фичегонку и вернуть продукту фокус
Открываешь презентацию, проводишь демо - сейлзы в восторге «мы умеем всё, давай продавать». А потом проходишь CJM нового пользователя и чувствуешь полный ад: много кнопок, куча настроек, тяжелые сценарии. Без онбординга с гидом не выжить, слишком сложно.
Такие демо - это не про «мощный продукт», а про расфокус стратегии. Каждый «маленький запрос», каждая «ещё одна фича — и сделка наша» превращаются в ещё одну кнопку, вкладку, настройку — и тихо растят TTV, усложняют обучение и убивают adoption новых фич до 2–3%.
TTV (Time To Value) - показывает, за сколько времени пользователь впервые получает реальную ценность от продукта. Adoption - показывает, какая часть пользователей не просто попробовала, а начала регулярно пользоваться продуктом и встроила его в свою жизнь или работу
Этот пост о том, как перестать быть «доставщиком фич по запросам» и начать защищать ядро продукта.
Из него ты узнаешь:
— по каким метрикам видно, что продукт уже задыхается;
— как убирать расфокус не «силой воли», а через фильтры и процессы;
— как говорить «нет» стейкхолдерам так, чтобы не похоронить ни сделки, ни стратегию.
Если твой roadmap сейчас больше похож на свалку просьб, чем на продуктовую линию, дальше будут конкретные метрики, скрипты и решения, которые можно применить уже в ближайший понедельник.
Ловушка «ещё одна фича»
Интуитивно кажется, что больше функций = больше ценности, особенно когда вокруг звучат суммы контрактов и «конкретные запросы» от клиентов.
Но пользователю не нужны фичи как таковые — ему нужна решённая задача с минимальным трением, а каждая новая кнопка крадёт внимание и силы на выбор, растит TTV (Time to Value — время до первой ощутимой пользы).
Опасность в том, что базовые метрики типа DAU могут не падать: старые пользователи держатся на мышечной памяти и терпят боль. Продукт превращается в «музей всего, что когда‑то просили», и ты замечаешь проблему только по просадке конверсии новых, старению аудитории и отсутствию органического роста.
Три ранних красных флага
1. TTV растёт: новички умирают на входе
Вчера путь занимал три клика, сегодня — семь, завтра — пользователь просто не доходит до первой ценности.
Для B2B/SaaS адекватная цель — чтобы новый пользователь сделал одно осмысленное действие (создал объект, нашёл результат, отправил первое сообщение) за 30 секунд; если TTV стабильно >60 секунд и продолжает расти месяц к месяцу — это ранний сигнал ожирения.
Посчитать просто: в продуктовой аналитике смотри путь от регистрации до первого значимного действия и меряй время до этого события и его динамику изменения. Измеряй как по количеству шагов, так и по продолжительности в секундах.
Если когорты новых пользователей с каждым месяцем дольше «добираются до смысла», то интерфейс и логика сценариев разрастаются быстрее, чем пользователи успевают учиться.
2. Adoption новых фич падает в пол
Ты выпускаешь «бомбическую» фичу, а через месяц видишь, что её попробовали 2–3% активных пользователей. Это не обязательно баг — часто фича просто утонула в шуме из сотни других точек внимания.
Хороший ориентир: новая фича должна набрать хотя бы 10–15% adoption от активной аудитории за первый месяц, если она претендует быть частью ядра. Если три последние фичи подряд имеют adoption <10%, проблема не в идеях, а в том, что продукт уже перегружен, и новые элементы просто не пробиваются сквозь старый слой.
3. Техдолг съедает спринты
Каждая следующая фича подцепляется к старому коду, рождая каскадные баги и неочевидные комбинации поведения, которые боятся трогать даже синьоры.
Здоровый режим — когда 60–70% спринта уходит на новое и развитие, а 30–40% — на поддержку и багфиксы.
Если команда тратит более 70% времени на поддержку, фактически продукт обслуживает сам себя, а не пользователей. Это не «мы сильно загружены», а формальный повод ставить стопор на новые фичи и инвестировать в переработку архитектуры и упрощение.
Как одна фича рождает десять и ломает B2B
В B2B ловушка усиливается деньгами: контракт на $200k почти в кармане, продажник приводит «маленький запрос», который «нельзя не сделать». Ты идёшь навстречу, под это пишется код, делаются настройки, запускается, деньги в кармане. Проходит месяц - другие клиенты просят свою вариацию - и так по кругу.
Через год roadmap уже не выглядит как эволюция продукта — это коллекция кастомных костылей под отдельных клиентов, которые конфликтуют между собой, плодят кейсы-исключения (edge-cases) и выжигают мотивацию разработчиков. Новичку в кодовой базе объясняют 15 чекбоксов в одном компоненте, завязанных на поведение трёх legacy‑клиентов, и любое исправление бага рискует сломать критичный сценарий для одного из них. Код не задокументирован, уйдет разработчик - создается мусорный рудимент.
Простой фильтр, который меняет эту динамику:
- 1 клиент просит — это консалтинг, а не продукт. Либо отдельные деньги и отдельный модуль, который не трогает ядро, либо вежливый отказ.
- 10+ клиентов просят независимо друг от друга — это продуктовый сигнал, можно двигать в roadmap.
- 5–9 клиентов — серая зона, где нужна глубинка: это специфика узкого сегмента (значит, модуль/пакет) или симптом более широкой боли, о которой ты слышишь пока фрагментарно.
Игнорируя такой фильтр, ты приходишь к состоянию, где продукт технически жив, но стратегически мёртв: масштабировать его дорого и больно, а любое расширение только усиливает хрупкость.
Инструмент 1: Квартальный разбор фичей: что жить, что удалить
Раз в квартал все фичи проходят «трибунал»: не доказывает ценность — освобождает место. Собери список фич, выпущенных за последние 12 месяцев, включая внутренние «маленькие улучшения».
- Adoption rate — долю пользователей, которые хотя бы раз пользовались фичей за период.
- Frequency — как часто типичный пользователь её трогает (раз в день, неделю, месяц).
- Support load — количество обращений в поддержку, связанных с этой функцией.
Красная зона (кандидаты на удаление):
- adoption <5% и frequency <1 раза в месяц;
- ≥10 тикетов в поддержку без явного тренда на улучшение;
- техдолг и операционные расходы выше, чем профит по ключевым метрикам.
Чтобы защищать решения перед стейкхолдерами, показывай не вкусовщину, а метрики + высвобождённые ресурсы. Например: «удаляем 3 фичи с adoption <3% и высоким support load — высвобождаем до 200 человеко‑часов в год на развитие ядра».
Инструмент 2: RICE и правило смерти фичи
Перед тем как заносить новую идею в roadmap, прогоняй её через два фильтра: RICE‑скоринг и план удаления.
Защита с помощью RICE приоритизации:
RICE объединяет четыре параметра:
- Reach — сколько пользователей затронет фича за квартал (в процентах или абсолютных числах).
- Impact — насколько сильно это улучшит их опыт (шкала 1–3: от маргинального до трансформирующего эффекта).
- Confidence — насколько уверены вы в оценках (100%, 50%, 25%).
- Effort — сколько недель‑команд потребуется на реализацию.
Формула: (R×I×C)/E(R×I×C)/E даёт численный RICE‑скор.
Дальше вводишь правила: условно, >100 — приоритет, 50–100 — обсуждение, <50 — отклоняем или выносим в кастомизацию.
Это позволяет, например, отдать приоритет массовой фиче вроде экспорта в PDF для 20% пользователей с умеренными трудозатратами, а интеграцию под одного крупного клиента честно отправить в «обсуждение кастомного модуля за отдельные деньги».
«Клаузула смерти» как защита от зомби‑фич
Второй фильтр — Feature Death Clause (таймер смерти): каждая фича живёт с заранее прописанным условием удаления.
Формулировка уровня: «Если adoption <10% через месяц после релиза среди активных пользователей целевого сегмента — мы её убираем или радикально перерабатываем».
Такое правило снижает эмоциональную привязку команды к своим идеям и переключает фокус с «доказать, что мы были правы» на «доказать, что это реально нужно пользователю». Психологически это позволяет быстрее убивать зомби‑фичи и не превращать их в вечный техдолг.
Инструмент 3: как аргументировать отказ
Младшему PM часто не хватает не аргументов, а именно готовых формулировок «нет», которые не выглядят как саботаж.
Скрипт для CEO: «локальный запрос, не продукт»
Когда CEO приносит «Клиент A хочет, это плюс $500k в год с его контракта», не спорь лбом в лоб «давайте не делать». Сформулируй это как вариант с разными уровнями риска и цены.
Генеральный директор ( СЕО, CFO) отвечает за деньги и экосистему, продуктовый менеджер за ценности. Ты не можешь просто отказаться. Продуктовая стратегия не должна ограничивать заработок денег в бизнесе.
СЕО скорее всего не волнует "Как вы это сделаете". Нужно только явно обозначить, что эта фича будет доступна только этому клиенту а не всем пользователям
Шаг 1: Смести ракурс, но не отрицай ценность денег:
«Ок, это важная возможность. Давайте выберем формат так, чтобы не ломать продукт для остальных клиентов».
Шаг 2: вместо абстрактных вопросов — быстрый чек + компромисс
"Сейчас это запрос одного клиента. Предлагаю сделать первым шагом кастомный модуль/проект под него, с изоляцией от ядра, и параллельно проверить, есть ли похожий спрос у других. Если по пути увидим, что эту же возможность хотят ещё 5–10 клиентов, вернёмся к обсуждению включения в ядро"
Шаг 3: Разговор про риск в терминах CEO: деньги и скорость
Если мы вносим это в ядро, мы увеличиваем сложность для 100% всех пользователей. Если вынести в отдельный модуль под этого клиента - мы заработаем те же деньги, но ограничим влияние на остальную базу. Сохраним темп и скорость разработки ядра.
Скрипт для Sales: «давай проверим, правда ли блокер»
Когда продажи говорят «без этой фичи потеряем сделку», задача не «поставить их на место», а быстро понять: это реальный блокер или удобный аргумент давления. Нельзя бездумно всех отправлять шаблонно заполнять формальные документы. Так вы потеряете мотивацию и вовлеченность отдела продаж
Шаг 1: Всегда согласен рассмотреть (не идти против сделки)
Сначала признай риск, чтобы не войти в позицию «против сделки». Нужно обсуждать с продажниками, они главный защитник и идейный поставщик действительных ценностей в продукт. С ними нужно держать хорошие отношения.
Шаг 2: Проверить это обоснованный блокатор или давление клиента
Один из вариантов: "Ок, давай разберемся, чтобы не уронить сделку и не сломать продукт. Это Must-have или nice-to-have для клиента? Они сами сказали, что уйдут без этой фичи, или это наше чтение между строк?". Если клиент не говорил прямым текстом, то это давление на отдел продаж
Шаг 3: Оценка охватов У нас за последний год ещё кто‑то просил то же самое? Можешь назвать 2–3 похожих клиента? Если это 1 клиент — считаем кастомным запросом, если уже есть 5-10 клиентов, то это сильный сигнал для добавления в план работ.
Скрипт для себя: «какая метрика двинется»
Когда сомневаешься, задай себе один прямой вопрос: «Какую из моих ключевых метрик эта фича двинет и на сколько?»
Если ты не можешь назвать конкретную метрику (TTV, активация, удержание, ARPU) и порядок эффекта — фича не готова или вообще не про продукт. Если ответ в духе «ну, в целом продавать станет проще» — это сигнал не про разработку, а про то, что нужно менять скрипты продаж, материалы, упаковку, а не утяжелять продукт ещё одной опцией.
Если метрика есть, но эффект туманный («наверное, чуть улучшит активацию») — зафиксируй гипотезу в одном предложении и реши честно: это важнее, чем любая другая фича в твоём ТОП-5 по влиянию на продукт сейчас? Если нет — фича идёт в бэклог «потом», а не в ближайший релиз.
Инструмент 4: дашборд продукта
Сделай один простой еженедельный дашборд, который станет твоей «панелью перегруза». По нему за минуту должно быть видно: продукт ещё бежит вперёд или уже тонет в собственных фичах.
- TTV для новых пользователей (<30 секунд)
Показывает, насколько быстро новичок доходит до первой ценности. Если здесь начинаются минуты, а не секунды — продукт тяжелеет. - Adoption rate последних 3 фич (>15%)
Показывает, приживаются ли новые идеи. Если фичи стабильно не добирают до 10–15% использования, значит, они тонут в шуме перегруженного интерфейса. - % спринта на поддержку (<40%)
Отражает уровень техдолга и перегруженности системы. Когда поддержка съедает больше 60–70% спринта, продукт уже обслуживает сам себя, а не пользователей. - Количество фич в годовом roadmap (<20)
Помогает не раздувать фронт работ. Если в годовом плане десятки фич, фокус размывается по определению. - Средний adoption за 3 месяца по фичам (>12%)
Показывает, умеете ли вы вообще делать востребованные улучшения, а не просто выпускать «по ощущениям».
Установи себе жёсткие триггеры:
- рост TTV на 20% месяц‑к‑месяцу — закладываешь спринт на упрощение интерфейса и сценариев;
- adoption новой фичи <5% через две недели — кандидат на удаление или радикальный ребрендинг;
- поддержка >70% спринта/релиза — ставишь паузу на новые фичи минимум на месяц и идёшь гасить перегруз.
Гид к действию
- Посчитай TTV для новой когорты. Определи первое ценностное действие в CJM, построй метрику и замерь среднее время как базовый уровень.
- Проверь adoption последних трёх релизов. Если хотя бы одна фича не дотягивает до 10% использования среди активных — запиши её в список кандидатов на переработку/удаление.
- Собери оценку по техдолгу у разработчиков. Спроси прямо: какой процент спринта/релиза уходит на поддержку; если слышишь >60%, это формальный повод пересмотреть приоритеты.
- Веди учет фичей и приоретизацию беклога. Начни вести таблицу с фичами, adoption, frequency и количеством тикетов по каждой. В самом простом варианте - выбери любую систему приоретизации которая делит весь список на 5% (здесь и сейчас) 15% (подождет) 80% (надо бы сделать)
- Подготовься к отказам
Если соглашаться со всеми идеями - продукт теряет фокус. Это не страшно в короткой дистанции, но смертельно в стратегическом плане. Нужно научиться обоснованно отказывать. - Найди фичи на удаление
Пусть это будет маленькая, малозаметная опция — важен сам факт осознанного «минуса» из Roadmap.
Кейсы: когда меньше = ускорение роста
Хочется верить, что хороший продукт — это длинный список возможностей. На деле почти все большие истории роста построены наоборот: на жёстком урезании всего лишнего и гиперфокусе на одной‑двух суперсилах.
Instagram: выкинуть 90% и вырасти в миллиард
До Instagram был Burbn — перегруженное приложение с чек‑инами, планированием, геймификацией и кучей мелких активностей, в котором пользователи терялись. Команда увидела, что люди больше всего цепляются за фото, лайки и комментарии, и вычистила почти всё, оставив три базовые функции — фотопубликации, ленту и простые социальные взаимодействия.
Результат: продукт стал сфокусированным и интуитивным, а дальнейший рост шёл уже через углубление одной суперсилы — визуального шеринга.
Кейс показывает, что радикальное упрощение часто создаёт новую S‑кривую, вместо бесконечного наращивания фич.
Superhuman: одна суперсила вместо всего
Superhuman выстроил продукт вокруг одной идеи — максимально быстрая работа с почтой, подчиняя этому и интерфейс, и фичи, и обучение пользователей.
Команда использует правило 100 мс: каждая ключевая интеракция должна укладываться примерно в 100 мс, чтобы ощущаться мгновенной.
Любая потенциальная функция отбирается через фильтр: делает ли она работу с письмами быстрее; если нет — в продукт не попадает.
Фокус на скорости дал возможность удерживать готовую платить аудиторию с высокой удовлетворённостью и выстроить премиальный бренд в перегретом рынке почтовых клиентов.
Slack: не всё, что можно, надо строить
Рынок командных коммуникаций был насыщен, но Slack выбрал стратегию простоты: каналы, быстрый поиск и небольшое, но важное ядро интеграций, вместо попытки стать сразу «комбайном на всё». Множество потенциальных возможностей — от тяжёлых аналитических панелей до развлекательных функций — сознательно не шли в приоритет, чтобы не разрушать ощущение лёгкого входа и понятного сценария.
Такой выбор позволил продукту быстро сокращать время до первого полезного сообщения в команде до минут и закрепиться как стандарт рабочего мессенджера. Ставка на ясное ядро, а не на бесконечное расширение, стала конкурентным преимуществом.
Go deeper: куда копать дальше
- Barry Schwartz — “The Paradox of Choice: Why More Is Less” (книга)
- Eric Ries — The Lean Startup (основа lean и MVP)
- Dan Olsen — The Lean Product Playbook (пирамиды и процесс достижения PMF).
- Top 50 Resources on Product/Market Fit» от Sachin Rekhi
- Статья: The Art of Minimalism in Software Engineering: Focusing on Core Features for Maximum Impact
- Paul Graham — “The 18 Mistakes That Kill Startups”
- A Minimalist’s Guide to Software Development: Less Code, More Elegance