Aleks

«Мы добавили 15 фич, а метрики не выросли» — ловушка функционального креатива

2025-12-27T16:28:09.212Z

3 недели работы. Спринт закрыт. Код чистый, багов нет, дизайн — конфетка. Ты делал всё правильно: требования согласовал, архитектуру спроектировал, тесты написал. К среде приходит письмо от CEO: «Что произошло? Retention упал на 15%».

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

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

Ты никогда не задавался главным вопросом: зачем пользователь вообще открывает твой продукт? Какую задачу хочет выполнить, регистрируясь в приложении? И как эти 100 кнопок на твоем экране решают эту задачу?

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

Метрика, которая выдаёт беду: Time-to-Value (TTV) — время от входа в приложение до первого полезного результата. Когда она растёт с 2 минут до 30 минут или часов, это значит, что пользователь блуждает, не зная, зачем он здесь.

Как это ломает продукт: три последовательных удара

1️⃣ Time-to-Value взлетает

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

2 минуты → 30 минут → несколько сессий.

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

2️⃣ Activation становится иллюзией

Ты смотришь на дашборд и видишь: Activation Rate высокий — 65%! Люди кликают, смотрят, нажимают. Активность есть. Но это не активность. Это растерянность. Пользователь не знает, зачем это нужно, и просто исследует интерфейс в надежде найти смысл.

Вот почему бывает парадокс:

Activation Rate: 65% (много кликов)
Retention Day 7: 4% (почти никто не вернулся)

Первое число вводит в заблуждение. Второе — рассказывает правду.

3️⃣ Retention падает не через неделю, а в первый день

День 1: Пользователь заходит, не понимает зачем, закрывает.
День 2: Может быть, вернётся? Нет. Забыл, что вообще это было.
День 7: Даже если в ленте напоминание, юзер уже не вспомнит, какую задачую он хотел сделать. Или решил ее уже у конкурентов

Эта цепочка начинается не на неделе — она начинается за первые 5 минут.

Какие ваши доказательства?

Покажу по блокам, самый популярные места где "делаем потому что так принято". Но если докопаться до сути и сформулировать JobStory, то задача из технической плоскости превращается в продуктовую, управляемую и измеримую метриками.

Пример 1: От «создать фильтр» к «найти горячего лида за 30 секунд»

Фича: «Пользователь может создать фильтр по статусу лида"
JobStory: «Когда я получаю 50 лидов в день, мне нужно за 30 секунд выделить горячих для срочной обработки, чтобы не потерять сделку.»

Видишь разницу? Первая фраза — это то, что ты добавляешь в спринте. Вторая — это причина, по которой пользователь вообще платит. У технической фичи нет метрики ценности. Фильтр работает — вот и всё. У Job Story есть конкретный результат и время достижения.

Figma: На первом знакомстве не говорит "у нас есть компонент преобразования FIGMA макета в React сниппеты". Их целевая аудитория - дизайнеры, которые передают задачу разработчикам и контролируют их работу. "За 5 минут создать макет компонента и поделиться с разработчиком, чтобы он правильно отработал идею". Вокруг этого строится Dev Mode, комментарии, снипеты кода, уведомления об изменениях, адаптация под разные языки программирования и тд
Slack: Не «мессенджер для команды». Их главная ценность - "Быстро найти ответ на вопрос, который уже обсуждался в чате, чтобы не писать в личку и не отвлекать людей". Вокруг этого они создали множество отдельных инструментов: "поиск, тайреды, топ-поисковика, аналитика, фильтр, интеграции с email и тд". Результат: На 9% больше пользователей находят то, что искали. На 27% чаще кликают на первый результат. Это управляемая метрика ценности. Вокруг которой можно выстраивать тысячи инструментов.
Notion не продавал: «Универсальные документы и таблицы». Их ключевая ценность - "Быстро структурировать хаотичную информацию, задачи и знания в управляемую систему, в одном пространстве, без переключения между разными инструментами.". Это главная ценность вокруг которой строится набор отдельных ценностей "В ситуации когда нужно показать preview документы - пользователь может указать страницы через @ или прямую ссылку"
Stripe: Не «платёжный шлюз с API», а ценность "Когда я запускаю интернет-магазин, за 5 минут подключить приём платежей, чтобы начать продавать". И весь их акцент сместился из технической глубины на количество готовых интеграций и доступность из любых возможных точек создания магазина.
Loom: Не «видео-запись по ссылке». Работа: «за 2 минуты записать видео и объяснить что-то коллеге, вместо написания 10-страничного письма». Поэтому Loom добавил instant sharing, автоматические субтитры, быстрое редактирование. Результат: рост с 14M до 20M пользователей за год.

Пример 2: «Push-уведомления» vs «подталкивание к прогрессу»

От общего: «Отправляем пуш на добавление в корзину»
К точному: «Когда пользователь оставил товар в корзине на 2 часа, мы напоминаем, что доставка завтра — чтобы он не пошёл к конкуренту»

Видишь разницу? Первый пуш — о приложении. Второй — о результате, который пользователь получит. Пуш, который не связан с работой пользователя, убивает push-enable rate. Люди выключают уведомления и уходят. Пуш, который продвигает работу, наоборот, привлекает. Потому что он говорит о результате, а не о приложении.

Uber Eats: Не пишет «Закажи снова». Пишет «Ваша паста карбонара прибудет через 25 минут». Push-open rate = 12% (вместо 3% в индустрии). Потому что второй пуш про результат — еда уже едет к тебе.
DoorDash: Не пишет «Еда ждёт тебя». Пишет «Твой заказ готов! Курьер выехал, будет через 12 минут». Push-open rate = 18% (вместо 4%). Потому что это про момент, когда нужно действовать.
LinkedIn: Не пишет «Просмотр профиля». Пишет «Ты появился в 8 поисках на этой неделе у этих компаний». Open rate = +50%. Потому что пуш про видимость у компаний, которая создаёт возможность.

Пример 3: «Онбординг‑тур» vs «найти письма начальника»

Инструмент vs цель, на онбордингах это самое популярное. Онбординг-тур, это инструмент для уменьшения Time-to-Value в рамках JobStory, а не сама цель разработки.

Плохой онбординг (про интерфейс):

❌ Шаг 1: «Это панель слева. Нажми, чтобы открыть проекты»
❌ Шаг 2: «Это кнопка создания. Нажми, чтобы добавить задачу»
❌ Шаг 3: «Это фильтры. Используй их для поиска»
❌ Шаг 4: «Это экспорт. Нажми, чтобы скачать»
Результат: пользователь понимает интерфейс, но не видит практического применения или кейса который он может решить здесь и сейчас для упрощения своей жизни
Completion Rate (прошёл весь тур): 70%
Retention Day 7: 4%

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

Хороший онбординг (про задачу пользователя):

Начни с вопроса: «Какая у тебя проблема, которую надо решить прямо сейчас?»
Например "Много писем в день, надо найти ключевое от руководителей, команды"

Из этого строить простую демку под задачу:

Шаг 1: подключим твою рабочую почту (кнопка добавления источника)
Шаг 2: добавь фильтры - система предложит заготовки (секция автоматизаций)
Шаг 3: проверь все ли нужные письма попали в разметку (валидация)
Шаг 4: скорректируй фильтры при необходимости (персонализация)
Шаг 5: сохрани фильтры, здесь всегда можешь их настроить (закрепление)

Результат: Пользователь закончил онбординг не потому, что прошёл 5 шагов. Он закончил с результатом — он не потеряет письма от руководителя. Это работа, которую он хотел сделать.

GitHub Copilot не учит использовать команды (/search, /debug, /explain, /ai). Когда ты начинаешь писать код, Copilot сразу дописывает его теневым текстом (preview). Первый результат ты видишь за 10 секунд после подключения.
Stripe не показывает настройки вебхуков и ключей. Он предлагает создать тестовый платеж или подписку. Результат онбординга - подключенный платежный шлюз.

Пример 4: «Кастомизация» vs «контекст проблемы»

Плохо (техническая возможность):

Пользователь может настроить 50 параметров автоматизации под себя

Хорошо (ценность для работы):

Когда я открываю почту утром, приложение показывает отчёт по завершённым задачам, договорённостям, сделкам и предложения на Daily стендап + расписание встреч на сегодня. Чтобы за 3 минуты подготовиться к дню вместо 30 минут просмотра.

Разница в когнитивной нагрузке

Если ты показываешь пользователю 50 параметров с названиями типа «Trigger Type», «Condition Logic», «Output Format» — он теряется. Нужно разбираться с документацией, искать примеры, погружаться в детали. Это пугает почти всех, кроме программистов или интеграторов.

Примеры:

Zapier не показывает список триггеров, условий и действий. Он на первом касании показывает готовые сценарии: «Когда контракт подписан в Dubsado → создаёт папку в Google Drive → отправляет письмо». Пользователь выбирает шаблон, вставляет свои данные — готово. Глубокая кастомизация — это второй шаг, если первого шаблона не хватило.

Пример 5: Список фичей вместо цели в PRD

Все начинается в документе требований. Если в PRD (Product Requirement Document) ты пишешь фичи, вместо целей и ценностей — весь продукт пойдёт по ложному пути.

Добавить фильтр по статусу лида

Критерии выходят техническими: фильтр работает, скорость быстрая, комбинация фильтров работает, данные возвращаются правильно. Проверяет код-ревью. Всё верно? Готово...

А платят не за фильтр, а за выполненную работу:

Менеджер за 10 секунд выделяет горячих лидов для обработки за день из 1500 поступивших

Критерии становятся продуктовыми: время фильтрации (10 сек?), эффективность следующей сделки (горячие ли правда горячие?), Time-to-Value, удобство ежедневного использования.

Теперь разработчик может предложить 10 решений:

Фильтр по статусу
AI разметка лидов
Готовые группы лидов по поведению
Рекомендательная система (который лид с наибольшей вероятностью конвертируется)
Автоматический рейтинг лидов по скорости ответа

Ты не завязан на одном решении — ты проверяешь от лица пользователя.

Guide To Action: не путай цель и инструмент

Метрики не растут, если менеджмент принимает неэффективные решения. Зачастую в IT-стартапах играют технические директора, они предельно эффективно описывают детали и крутые инициативы "это есть у конкурентов", "это должно быть" и тп. Это интересно им решать.

Но если вы не платформа IT-разработчиков для IT-команд, то скорее всего за такие решения вам не будет платить бизнес. Поэтому нужно учиться отделять цель пользователя (JobStory), от инструментов достижения (технические задачи)

Шаг 1: Перепроверь актуальность документов (PRD)

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

Возьми свой PRD документ. Найди все задачи, начинающиеся на «Пользователь может…» или «Добавить функцию…». Для каждой напиши Job Story: «Когда я [ситуация], мне нужно [результат], чтобы [цель]».

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

Шаг 2: Проверка управления: кто принимает решения о фичах

Большинство проблем с ростом начинаются не с кода, а с тем, кто решает, какую фичу разрабатывать. Часто в IT-командах это технический директор, разработчик или кто-то из технарей. Он смотрит на конкурентов: «У них есть экспорт в PDF — надо добавить и нам». Или: «Это должно быть, потому что это логично». Или: «Конкурент добавил фильтр — мы отстаём».

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

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

Чек-лист:

PR обсуждает не «как это сделать», а «зачем это нужно»?
Каждая фича привязана к метрике ценности (Time-to-Value, Success Rate)?
Есть ли интервью с пользователями перед разработкой (не после)?
Фича отзывается на реальную проблему или мы гадаем?

Любая разработка - это вложения денег, времени и ресурсов сотрудника. Так зачем мы это делаем, почему это нужно сделать? Задача - докопаться до сути, понять потребность пользователя и как это служит его цели или метрикам платформы. Если этого нет -> выкидывать задачу.

Шаг 3: Переформулировка беклога

Прежде чем фича уходит в разработку, ответь на 4 вопроса:

1. Какую работу выполнит пользователь?
(не «какие кнопки нажмёт», а зачем)

2. За какое время должна быть выполнена эта работа?
(Time-to-Value — конкретное число в минутах)

3. Как мы узнаем, что пользователь выполнил работу?
(конкретный метрик, не абстрактные слова)

4. Будет ли пользователь делать это регулярно?
(если один раз в год — это не Job, это фича)

Если ты не можешь ответить на все 4 — фичу не разрабатывай.

Что прочитать

«The JTBD Playbook» — Jim Kalbach
Что: 50 реальных примеров Job Stories из Figma, Slack, GitHub, Airbnb.
Зачем: Увидишь, как думают про пользователя в компаниях, которые растут.
«The Mom Test» — Rob Fitzpatrick
Что: Как правильно спрашивать пользователей о работе, не о фичах.
Зачем: Чтобы не гадать, а знать, что реально нужно.
«Competing Against Luck» — Clayton Christensen
Что: Jobs-to-Be-Done теория от создателя.
Зачем: Чтобы понять философию под этим всем.

Как убить фичегонку и вернуть продукту фокус

2025-12-15T17:39:39.184Z

Открываешь презентацию, проводишь демо - сейлзы в восторге «мы умеем всё, давай продавать». А потом проходишь 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 тикетов в поддержку без явного тренда на улучшение;
техдолг и операционные расходы выше, чем профит по ключевым метрикам.

Жёлтая зона (переработка/исследование):

adoption 5–10% или неплохая частота у узкого сегмента;
нужны интервью и юзабилити‑тесты, чтобы понять, это недогретая ценность или чужеродный элемент.

Зелёная зона (усиливать):

adoption >15% и хороший возврат пользователей к фиче;
именно здесь часто лежит твоя реальная суперсила, а не в перечне всего, что продукт «умеет».

Чтобы защищать решения перед стейкхолдерами, показывай не вкусовщину, а метрики + высвобождённые ресурсы. Например: «удаляем 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: дашборд продукта

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

Возьми 5 простых метрик:

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

Больше интересного публикую в блоге Telegram: @ai_pmf

50 продавцов и 0 покупателей: почему твой стартап завис и что делать

2025-12-11T20:22:56.089Z

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

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

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

Ловушка: балансировка сторон

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

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

1М пользователей хуже, чем 100 активных в одном месте

Uber в начале концентрировался на нескольких районах Сан‑Франциско: небольшое количество водителей и пассажиров, но высокая плотность — машины рядом, время ожидания несколько минут, большинство поисков заканчивались поездкой за 4 минуты.

Это и есть ликвидность: когда спрос быстро находит предложение в конкретной точке в вашей экосистеме

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

Tinder не шёл сразу «на весь мир», а выстраивал зацепки в конкретных кампусах и тусовках; Slack начинал с одной компании — своей; многие успешные сети начинали с маленького, но сверхплотного кластера людей, где «все видят всех» и быстро находят нужное

Твоя цель на старте — не MAU по всей стране, а локальная ликвидность в одном кластере.

Атомарные сети: начни с одной «вечеринки»

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

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

Для твоего стартапа это может быть:

Маркетплейс услуг — один офисный центр или конкретный район, а не весь город.
Доставка — пара кварталов, где ты закрываешь почти все заказы за целевое время.
B2B SaaS/маркетплейс — одна компания с 100+ сотрудниками или одна профессиональная комьюнити‑группа.

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

Не закупай серверы. Закупи ноги

На старте ты не знаешь, как должна работать система — где нужны курьеры, какие категории ищут, какие фичи действительно важны. Автоматизировать неизвестное — сжигать деньги.

Поэтому лучшая стратегия на первом этапе — притвориться, что система готова, пока ты сам крутишь маховик:

Reddit в начале сам наполнял площадку контентом с множества аккаунтов, чтобы новые пользователи не видели пустоту и понимали «тон» комьюнити.
DoorDash вручную оцифровывал меню и сам отвозил заказы, прежде чем строить полноценную логистику.
Ранний Uber платил водителям гарантированный доход, даже если заказов не хватало: им нужна была карта с машинами и данные о том, как реально ведут себя и водители, и пассажиры.

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

Куда лить бюджет: не всегда 50/50 это норма

На двусторонней платформе одна сторона создаёт ценность (контент, товары, поездки), вторая — её потребляет. Частая ошибка — делить маркетинг и ресурсы пополам, потому что «баланс важен»

На практике успешные маркетплейсы сначала заякоривают «hard side» — ту, которую сложнее всего привлечь и заменить:

Uber на старте субсидировал водителей, а не пассажиров: гарантированный заработок, бонусы за онлайн, программы привлечения новых драйверов. Машины на карте сами тянут спрос.
Medium и другие платформы контента сначала привлекали авторов и платили гарантии или давали заметную дистрибуцию, иначе читать было бы нечего.
Etsy, App Store и многие B2B‑платформы делали упор на инструменты и выгоды для создателей (мастеров, разработчиков), а не на широкие кампании под конечных потребителей.

Пропорция не обязана быть ровно 90/10, но на этапе холодного старта разумно принимать как базовое правило:

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

Сделай продукт полезным одной стороне даже без второй

Самая стабильная стратегия — сделать так, чтобы хотя бы одна сторона получала ценность даже при слабой второй стороне. Тогда ты не «висяк», а просто продукт, вокруг которого ещё не достроена сеть.

Классические примеры:

Instagram начинал как офлайн‑полезный редактор фотографий с фильтрами. Даже если никто не лайкал, фильтры сами по себе давали ценность. Соцсеть наслоилась сверху позже.
OpenTable стартовал как CRM и система резерваций для ресторанов: управление столиками, бронированиями и клиентской базой. Это было полезно ресторанам ещё до полноценной потребительской сети бронирований.

Для тебя это значит:
Найди фичу или инструмент, который помогает создателю/продавцу/исполнителю жить лучше уже сегодня (учёт заказов, биллинг, витрина, CRM, аналитика). Сеть станет ускорителем, а не единственным источником ценности.

Какие метрики смотреть, когда отключать костыли

MAU и DAU красиво смотрятся в питче, но почти ничего не говорят о том, пережил ли твой маркетплейс холодный старт. Для этого смотри на метрики ликвидности.

Fill Rate — доля поисков, которые заканчиваются успешной сделкой (поездка, бронь, заказ, матч).
Если метрика низкая (условно < 40–50% для on‑demand и частотных сценариев) — пользователи не находят то, что ищут, проблема чаще в предложении или в качестве поиска, а не в количестве трафика. Когда ты стабильно выше условных 70–80% в конкретном сегменте — там появилась ликвидность, и можно аккуратно снижать субсидии и расширяться. Конкретные пороги зависят от категории: B2B с редкими сделками терпит иной уровень, чем такси или еда.
Time‑to‑Match — как быстро две стороны находят друг друга.
Для такси и доставки «несколько минут» — нормально, «десятки минут» — уже признак сломанной модели ожиданий. В менее срочных категориях важен порядок, а не конкретная цифра: цель — чтобы фактическое время было заметно ниже порога терпения пользователя.
Zero Rate / Empty View Rate — процент пользователей, которые видят пустой экран или «0 результатов». На старте он может быть большим, но твоя задача — по мере закачки предложения опустить его в работающем кластере к единичным процентам.
Utilization Rate (для исполнителей) — доля времени, когда поставщики услуг заняты.Если водители, курьеры, исполнители сидят без дела большую часть времени — нет ликвидности, даже если у тебя много зарегистрированных пользователей.

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

Антипример: масштабирование без локальной ликвидности

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

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

Какую стратегию выбрать под свой кейс

Выбор стратегии холодного старта зависит от того, что у тебя есть сегодня.

Ориентиры по стратегиям:

Есть бюджет на субсидии и «горячий» рынок исполнителей?
Инвестируй в сторону предложения: гарантии дохода, бонусы за онлайн, удобные инструменты и онбординг (как Uber и другие on‑demand сервисы).
Бюджета почти нет, но есть время команды?
Делай руками: сам наполняй контент, сам обрабатывай заказы, сам склеивай стороны, пока не станет ясно, как должна выглядеть система (DoorDash, Reddit).
Можешь построить полезный standalone‑инструмент?
Сначала делай utility‑продукт для одной стороны, потом наращивай сетевой слой (Instagram, OpenTable).
Можешь жёстко ограничить географию или сегмент?
Строй атомарные сети: один район, один кампус, одна профессия, один офисный центр (Tinder, local marketplaces).

Критическая точка наступает, когда в одном кластере ликвидность поддерживается без постоянных субсидий, а метрики fill rate, time‑to‑match и utilization стабильно держатся на целевых уровнях. Именно из таких локальных «очагов» вырастают большие сети.

Что сделать прямо сейчас?

Открой аналитику и посмотри воронку «поиск → просмотр → контакт → сделка» для каждой ключевой категории и географии. Если нет метрики Search‑to‑Fill — договорись с аналитиком и настрой её.
Найди сегменты, где Search‑to‑Fill и Time‑to‑Match хуже всего, и посмотри, как они завязаны на предложение: мало исполнителей, плохая геопокрытие, перекос по времени суток. Если fill < условных 50% в ядре кейса — это сигнал, что проблемы в предложении, а не в трафике.
Пересмотри сплит бюджета и усилий: временно заморозь или сократи маркетинг, который гонит новых покупателей в сегменты с низким fill, и переведи фокус на активизацию и набор создателей (продавцов, водителей, исполнителей, стримеров) в выбранном кластере.
Выбери одну локацию/нишевую аудиторию и закачай туда предложение: локальные партнёрки, ручной онбординг, субсидии, гарантии загрузки, офлайн‑активации. Цель — довести локальный Search‑to‑Fill до 70%+ и привести Time‑to‑Match к значению, которое твои пользователи воспринимают как «быстро».
Как только в этом кластере метрики стабильно держатся, а участие команды можно чуть снизить без обвала, копируй модель на следующий кластер вместо того, чтобы «чуть‑чуть улучшить всё везде».

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

Блог: @ai_pmf