�� Что такое «фиче-фабрика» и почему продакты убивают свои продукты фичами

Около 7-10 лет назад, когда еще активно консультировал компании как менеджер процессов, я постоянно сталкивался с одним и тем же типом начинающих продактов.

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

Звучит логично, да? ��

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

Только есть одна проблема — это почти никогда не работает❗

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

❎ 90% аудитории не понимали, зачем были сделаны эти функции
❎ 70% говорили, что пользоваться продуктом стало сложнее, а многие вообще уходили к конкурентам, которые делали «меньше, но понятнее»

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

�� Почему вообще команды попадают в эту ловушку? Все просто:

�� Страх пустого бэклога. Признаться руководству, что «сейчас новых задач нет, надо идти в дискавери» страшно. Кажется, что мы выглядим бездельниками. И тогда мы начинаем искусственно наполнять задачи.
��Фокус на output, а не на outcome. Привыкли оценивать свою работу по количеству задач, а не по реальной пользе для бизнеса и пользователей. Отсюда гонка «сделать больше», а не «сделать лучше».
�� Отсутствие культуры Discovery. Команды боятся тратить время на исследования и проверку гипотез.

☝️Что делать, чтобы из этой ловушки выбраться?

Я переобучал таких продактов простой, но важной вещи: сначала разговаривать с пользователями — потом делать фичи, а не наоборот. Самым эффективным инструментом стал подход, называемый Jobs To Be Done (JTBD).

Суть JTBD проста: люди «нанимают» ваш продукт для выполнения конкретных задач в конкретных ситуациях. И ваша работа — понять, какие это задачи и в каком контексте они возникают. ��

Например, ваш пользователь покупает телефон. Кто-то берет его, чтобы снимать рилсы в TikTok, кто-то для рабочих встреч в Zoom, а кто-то просто звонить маме раз в неделю. Это три разные аудитории и три разных «продукта». Во всяком случае, рамках JTBD мы представляем так, чтобы максимально эффективно продумать пользовательские пути (о них поговорим также в постах далее..)

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

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

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

✅ Какую конкретную задачу пользователя мы сейчас решаем?
✅ Понимаем ли мы контекст, в котором он обращается к нашему продукту?
✅ Проверяли ли мы это гипотезами и интервью?

Если нет ответа хотя бы на один из вопросов — стоп Возвращаемся к пользователю и исследованию JTBD.

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

Чем больше лайков будет на посте, тем раньше выложу!