На Habr вышел разбор, в котором сразу четыре продуктовые методики предлагают не противопоставлять, а складывать в одну рабочую схему. Для продактов и CPO это история не про очередной фреймворк на стену, а про старую боль: почему команда может честно слушать пользователей и все равно упираться в тупик при выборе квартальных приоритетов.
Как пишет Habr / Менеджмент, автор статьи описывает типичную для продуктовых команд ситуацию: несколько руководителей смотрят на один и тот же продукт, но через разные линзы. Один предлагает идти от базовой потребности аудитории и искать новую точку роста, второй делает ставку на мотивацию и геймификацию ради монетизации, третий требует довести до ума текущий пользовательский сценарий и улучшить саму «работу», которую продукт выполняет в конкретном контексте. Проблема не в том, что кто-то ошибается. Проблема в том, что все правы одновременно, а решения все равно приходится принимать волевым способом.
Не еще один фреймворк, а попытка свести их в одну карту
Ключевая мысль автора довольно здравая: JTBD, теория потребностей, мотиваторы и оценка ценности отвечают на разные вопросы об одном и том же человеке. Пользователь не живет по слайдам из продуктового курса. Когда он открывает сервис, у него одновременно есть потребность, конкретная задача в конкретной ситуации, внутренний или внешний мотив что-то сделать и оценка, стоит ли результат затраченных денег, времени, усилий и нервов. А команды, наоборот, часто разбирают это по частям: исследователи говорят о потребностях, продакты о jobs, маркетинг о мотивации, UX о когнитивной нагрузке, а потом все эти выводы сталкиваются на планировании как конкурирующие религии.
В статье предлагается собрать продуктовые методики в простую систему из нескольких уровней. Первый слой — аудитория: без четко названного сегмента все дальнейшие рассуждения быстро превращаются в спор о вкусе. Второй — потребность, то есть фундаментальный дефицит или запрос: безопасность, рост, заработок, новизна. Третий — работа в контексте, тот самый JTBD: что именно человек пытается сделать здесь и сейчас. Четвертый — мотиватор, который запускает действие: интерес, азарт, ощущение прогресса, избегание потерь и прочие триггеры. Пятый — ценность, выраженная как разница между выгодами и издержками. Причем речь не только о цене подписки, но и о времени на освоение, риске ошибки, когнитивной нагрузке и усилиях на входе.
Сам по себе этот список не выглядит сенсацией. И в этом как раз его сильная сторона. Автор честно оговаривает, что не изобретает новые сущности, а предлагает связку уже известных подходов. Для ценности он опирается на классическое определение из маркетинга, где value считается как выгоды минус затраты, и напоминает, что исследователи давно разобрали затратную часть шире денег. Для мотивации в тексте используется не абстрактное «надо лучше вовлекать», а вполне прикладной взгляд на механики, которые двигают человека к действию. Идея в том, что каждая из этих моделей глубока на своем участке, но слепа к соседнему. Отсюда и вечное фреймворкоблудие в компаниях, где каждый выбирает инструмент под свой темперамент, а не под реальную структуру пользовательского решения.
Почему это важно не только продактам, но и бизнесу
Для рынка это хороший симптом: русскоязычная продуктовая среда постепенно устает от споров в стиле «что правильнее — JTBD или потребности». Такой спор обычно удобен на конференции и бесполезен в работе. Бизнесу ведь не нужно победить одну методологию над другой. Бизнесу нужно понять, во что вкладывать команду в следующем квартале и почему именно туда. Если потребность не закрыта, никакая геймификация не спасет продукт надолго. Если job сформулирован смутно, можно долго украшать путь пользователя и не попасть в цель. Если ценность для клиента не превышает совокупные издержки, даже идеальная мотивационная механика будет работать как временный допинг.
Автор выводит из своей схемы два практических принципа. Первый: сначала направление, потом сила. Проще говоря, нельзя «усилить» ценность, пока не ясно, на какую потребность, какую задачу и какой мотив вообще направлен продукт. Второй принцип в полном тексте разворачивается как следствие первого: методики надо использовать не вместо друг друга, а по очереди и по роли. Это уже важный прикладной вывод для руководителей продукта, особенно там, где discovery, монетизация и UX живут в разных командах и каждая приносит свою правду. Такая сборка не обещает магического ответа, но хотя бы уменьшает число ситуаций, когда квартальный план выбирают по громкости голоса на встрече.
Для разработчиков и продуктовых аналитиков здесь тоже есть вполне прикладной смысл. Если смотреть на продукт через такую сборку, метрики перестают быть безликим дашбордом. Падение retention может сигналить о том, что продукт слабо решает саму job, даже если вовлечение пока держится. Высокий интерес к механике и низкая долгосрочная отдача могут указывать на перекос в мотиваторах. Жалобы на сложность, долгий onboarding или страх ошибки — это уже вопрос не «фичи не зашли», а цены входа в ценность. Для тех, кто строит продукт не по вдохновению, а по внятной причинно-следственной цепочке, это полезнее десятка плакатов про customer centricity.
Главный вопрос теперь не в том, красива ли схема на бумаге, а выдержит ли она реальную продуктовую мясорубку с бюджетами, дедлайнами и конфликтом функций. Если выдержит, у русскоязычных команд появится не новый культ, а более трезвый способ собирать продуктовые методики в одну систему и наконец спорить не о названиях фреймворков, а о том, где именно у пользователя ломается решение.