AI-анализ встреч и документов
Не указано: Илья Красинский, Иван Замесин
Встреча была посвящена применению Jobs to Be Done для диагностики продуктовых решений, сегментации клиентов и коммуникации ценности. Обсуждалось, почему продуктовые команды часто начинают с разработки фич, а не с понимания задач, контекста и критериев успеха клиентов. На кейсах из EdTech, e-commerce, B2B-сервисов, HR-консалтинга и финансовых продуктов рассматривались способы выбирать фокусные сегменты, оценивать их потенциал и улучшать продуктовые метрики. Ключевой смысл обсуждения — использовать JTBD не как формальный фреймворк, а как способ связывать бизнес-цели, личные задачи руководителей, клиентские работы, ценность и конкретные продуктовые решения.
Ключевая цель интервью — показать, почему продуктовые команды должны перестать начинать работу с идеи продукта, технологии, рынка «как категории» или бэклога фичей и перейти к системному пониманию задач клиентов, сегментов, ценности, контекста использования и критериев выбора. Илья Красинский и Иван Замесин обсуждают Jobs to Be Done не как очередной исследовательский фреймворк, а как язык и причинно-следственную модель, позволяющую принимать более сильные продуктовые, коммерческие и стратегические решения: выбирать сегменты, создавать ценность, объяснять её пользователям, влиять на руководителей и снижать риск дорогостоящих продуктовых ошибок.
Главный тезис Ивана Замесина состоит в том, что JTBD меняет не отдельный продуктовый процесс, а способ мышления фаундера и руководителя о бизнесе. После освоения этой логики руководитель перестаёт видеть компанию как набор продуктов, команд, экранов, функций и каналов. Он начинает видеть сегменты людей, их работы, контексты, критерии успеха, текущие альтернативы и возможные стратегии роста. Это превращает JTBD в инструмент стратегического выбора: компания может решить, на какой сегмент сместиться, какой сегмент добавить, какую связанную job начать выполнять, где изменить цену, выйти ли в новую географию, B2B- или B2C-модель. Сегментация важна не потому, что она даёт более красивый портрет аудитории, а потому, что открывает ранее невидимые варианты действий.
В центре обсуждения находится жёсткая причинно-следственная цепочка: у человека есть потребности и возникающие из них задачи; продукт создаёт ценность, когда помогает выполнить задачу эффективнее; коммуникация должна объяснять эту ценность в понятном для клиента контексте; опыт получения ценности приводит к покупке, удержанию, допродажам, рекомендациям и, в итоге, к бизнес-результату. В этой модели бизнес-ценность не появляется непосредственно из написанного кода, красивого интерфейса, бренда, набора фич или самого факта запуска продукта. Она является следствием того, что компания нашла значимую работу клиента и действительно выполнила её лучше существующих альтернатив.
Из этой логики следует ключевое различие между job, ценностью и фичей. Job — это то, что человек пытается сделать в своей ситуации. Ценность — то, насколько лучше, быстрее, надёжнее, понятнее или дешевле он может выполнить эту работу с помощью продукта. Фича — способ, за счёт которого продукт доставляет ценность. На примере Rick.ai это выглядит так: директору по маркетингу не нужен граф CRM-воронки, отчёт, нейросеть или команда заботы сами по себе. В конкретной ситуации — например, перед сложным совещанием — ему нужно аргументированно объяснить, почему лиды не конвертируются, почему канал ошибочно выглядит убыточным и какие действия нужно предпринять. Наглядный отчёт, анализ потерянных UTM-меток, автоматическое выявление узких мест или помощь команды — это разные способы доставить ему нужную аргументацию. При этом техническая фича не создаёт ценность, если пользователь не увидел её в нужный момент, не понял вывод или не может применить результат в своей рабочей ситуации.
Илья особенно подчёркивает значение контекста и триггера. Пользователь не нуждается в одной и той же ценности постоянно: аналитический отчёт маркетологу не нужен ночью, но критически нужен перед встречей, где он будет объяснять результаты. Точно так же человеку не нужен «английский язык», «CRM», «банковское приложение», «обучение» или «репетитор» как абстрактная сущность. Ему нужен результат в конкретной ситуации: сдать экзамен, перейти на работу в другой стране, не потерять сделку, понять причину падения продаж, уверенно провести занятие, закрыть вакансию, не опоздать, найти подходящий фильм на вечер. Поэтому ценность должна быть не только создана, но и доставлена через правильный канал, в правильное время, в правильной форме и с минимальным усилием со стороны клиента.
Участники противопоставляют сегментацию по jobs классическим персонам и демографии. Демография, роль, возраст, страна, должность или доход могут быть полезными дополнительными признаками, но не объясняют, чего человек хочет, как он оценивает хороший результат, какого риска боится, что уже пробовал и почему выбирает одно решение вместо другого. Два клиента могут быть одинаковыми по полу, возрасту и доходу, но иметь принципиально разные критерии выбора. И наоборот, люди из разных стран и профессий могут быть близки по ситуации и работе. Формула «людям нужен английский» в этой модели бессодержательна, пока не понятно, кому именно, в каком контексте, для какого результата, в какие сроки, с какими ограничениями и по каким критериям нужен язык. Отсюда же следует, что один рынок часто состоит из множества фактически разных продуктов: английский для IELTS, для карьерного перехода, для общения, для жизни после эмиграции и для просмотра сериалов — это разные сценарии ценности, продаж и поставки результата.
Особое место занимает идея раннего фокуса на сегменте. Иван описывает типичный путь ошибки: основатель придумывает широкий продукт, команда его реализует, затем сталкивается с плохими конверсиями, высокой стоимостью, слабой экономикой и начинает переделывать решение. Кейс Cevy Kids показывает альтернативу: вместо абстрактного продукта «про развитие ребёнка» команда сфокусировалась на родителях детей с СДВГ, у которых есть конкретные и острые jobs — справляться с истериками, понимать, как действовать в сложных ситуациях, передавать инструкции няне или школе, снижать число конфликтных эпизодов. По словам Ивана, после этой фокусировки стоимость продукта снизилась в пять раз, улучшилась экономика и выросла удовлетворённость клиентов. Смысл кейса не в том, что любой бизнес должен сузить аудиторию, а в том, что нужно найти сегмент, где есть частая, важная, плохо решаемая работа и готовность платить за её качественное выполнение.
Сегментация должна быть связана с экономикой. Недостаточно услышать на интервью, что у человека есть проблема или интерес. Нужно понимать размер сегмента, частотность job, бюджет на её выполнение, используемые альтернативы, удовлетворённость ими, барьеры и причины неудовлетворённости. Сегмент может быть реальным, но убыточным: у него нет бюджета, решение принимается слишком сложно, потребность возникает редко или клиент требует непропорционально много усилий на продажу и поддержку. В кейсе корпоративных автопарков именно такая логика позволила отбросить слабые сегменты и сфокусироваться на клиентах, у которых одновременно были задача, деньги и неудовлетворённость текущим способом снижения аварийности. В результате, по приведённому Иваном примеру, новый продукт обеспечил около 75% роста выручки всех продуктов компании.
При этом участники различают два масштаба продуктовой работы. Локальная оптимизация начинается с уже платящих клиентов: компания изучает, кто уже получает ценность, какие у этих людей Core Job и Big Job, какие барьеры они проходили, когда случился Aha-момент и как выглядел путь от возникновения потребности до покупки. Это сравнительно низкорисковый способ улучшать конверсию, активацию, удержание, средний чек и коммуникацию. Глобальный поиск означает исследование новых сегментов, других работ, новых рынков, другой географии, ценового уровня или перехода между B2B и B2C. Он может дать кратный рост, но риск ошибки значительно выше. Поэтому выбор масштаба исследования должен зависеть от бизнес-задачи и цены ошибки: лендинг можно быстро и дёшево протестировать на одном сегменте, а для дорогого нового направления нужны более сильные количественные и экспертные основания.
Важная организационная часть интервью посвящена тому, как внедрять такой подход в компаниях. И Иван, и Илья считают ошибкой продавать руководителю «исследование», «фреймворк», «JTBD» или «ещё одну методологию». Для руководителя это часто означает дополнительную работу, задержку планов, риск не выполнить KPI, не получить бюджет, не защитить обязательства перед акционером или не справиться с личной ответственностью. Вместо этого продуктовая команда должна понять личные jobs руководителя: получить признание, успешно выступить с результатом, увеличить влияние, выбить бюджет и команду, стать ближе к генеральному директору, сделать работу «по-человечески», не подставиться и не быть уволенным. После этого продуктовую аргументацию нужно связывать не с абстрактной правильностью JTBD, а с тем, как исследования и сегментация повышают вероятность личного и бизнесового успеха руководителя.
Иван предлагает показывать руководителю не просто недостатки продуктовой идеи, а конфликт между текущим курсом и его собственными целями. Если запустить продукт без понимания сегмента, работающей ценности и рынка, он может не получить успешный кейс, бюджет, признание или защиту перед руководством. Если же сначала собрать аргументацию, проверить сегмент, оценить экономику и подтвердить неудовлетворённую job, риск провала уменьшится. При этом цифры нужны не только для объективности. В корпоративной среде они также позволяют распределить ответственность: руководитель может обосновать решение перед акционерами, коллегами или вышестоящим менеджментом не личным мнением, а отчётом, исследованием и наблюдаемыми данными. Илья уточняет, что это не отменяет стремления людей принять хорошее решение: данные одновременно дают опору на реальность и снижают страх быть единолично виноватым.
Отдельная линия разговора посвящена коммуникации ценности — особенно лендингам, продажам и e-commerce. Лендинг должен начинаться не с продукта, фичи, игрового формата, приложения, курса или списка возможностей, а с точки А клиента: его ситуации, контекста, триггера, эмоции, барьера и желаемого результата. Затем он должен показывать точку Б: как изменится жизнь или работа человека после получения ценности. Между ними должны быть понятны сам механизм ценности, снижение страхов, доказательства, Aha-момент и первый посильный шаг. CTA должен вести не к слишком большому обязательству вроде «оставить заявку на сервис», а к первому micro job — действию, которое человек готов сделать прямо сейчас, чтобы снизить неопределённость и приблизиться к результату.
Разборы Yoga Academy, приложения для подготовки к собеседованиям и Альфа-Босс демонстрируют общую проблему: многие лендинги описывают продукт с позиции создателей, а не ситуацию пользователя. «Практикуйся по 20 минут», «оформляй заявки», «контролируй», «получи профессию», «используй приложение» — это либо свойства продукта, либо промежуточные действия. Они не отвечают на вопрос, что пользователь пытается изменить в своей жизни или работе. В случае приложения для интервью реальная ценность может быть связана с получением желаемой работы, завершением болезненного поиска и уверенностью на собеседовании. В случае топ-менеджера банковского сервиса ценностью может быть не возможность вручную оформлять заявки и контролировать поручения, а отсутствие необходимости делать лишнюю операционную работу, своевременное получение критически важной информации, уверенность, что вопрос будет решён, и снижение персонального риска.
В e-commerce эта логика проявляется через проблемы discovery и гипервыбора. Покупатель часто приходит не за конкретным SKU, а с ситуацией: выбрать фильм на вечер, купить подарок, подобрать парфюм, найти технику, выбрать обувь. Он вынужден пройти последовательность работ — сориентироваться, определить критерии, сравнить, снизить риск ошибки, заказать, дождаться результата. Если магазин строится по структуре товарной базы, а не по job-сценариям, пользователь тратит много времени, устаёт, теряет уверенность и уходит. Важно, что продукт конкурирует не только с другим магазином. Он конкурирует за время, внимание и деньги клиента с любыми альтернативами выполнения более высокой job: например, вместо долгого выбора кроссовок человек может посмотреть сериал, пойти гулять или заняться чем-то ещё, что быстрее даст ему отдых или удовольствие. Поэтому сильный продукт сокращает путь к результату, уменьшает число решений, даёт уверенность раньше и устраняет лишние промежуточные работы.
Финальная технологическая линия интервью — сочетание JTBD и ИИ. Иван считает, что современные модели уже способны быстро генерировать гипотезы сегментов, графы работ, ценностные предложения, варианты лендингов, тарифов, допродаж и сценариев. Илья соглашается, но подчёркивает: если спросить ИИ слишком общо, он выдаст усреднённый и слабый ответ. Чтобы получить содержательную гипотезу, нужно точно описать сегмент, ситуацию, job, ограничения, триггер и критерии успеха. ИИ не заменяет понимание клиента, но значительно снижает стоимость поиска идей, подготовки материалов, создания прототипов и проверки решений. В такой модели JTBD даёт структуру правильных вопросов, а ИИ ускоряет генерацию и тестирование возможных ответов.
Главный вывод состоит в том, что продуктовая работа должна начинаться не с вопроса «какой продукт, экран, технологию или фичу сделать», а с вопроса «какую работу, для какого сегмента, в каком контексте и с какими критериями результата мы можем выполнить лучше существующих альтернатив». Фичи, код, интерфейсы, отчёты, нейросети, процессы продаж и команды поддержки нужны только как способы доставки ценности. Если команда не понимает job, сегмент, контекст и критерии клиента, она с высокой вероятностью будет создавать лишние функции, продавать продукт «всем», терять деньги на невыгодных клиентах и объяснять ценность на внутреннем языке компании.
JTBD в интерпретации участников — не набор шаблонов для интервью и не маркетинговая терминология. Это воспроизводимая система, которая связывает бизнес-цель, сегментацию, исследование, ценность, коммуникацию, продуктовую стратегию и экономику. Её практическая задача — уменьшить неопределённость, сделать выбор продуктовых направлений более обоснованным, сократить ненужную работу как для команды, так и для пользователя, а также помочь людям внутри компаний влиять на решения без продажи «очередного фреймворка». Лучшие продукты в этой логике не заставляют клиента делать больше работы удобнее — они автоматизируют, сокращают или полностью устраняют ненужные шаги на пути к желаемому результату.
Иван Замесин выступает как основной методологический спикер и последовательно отстаивает JTBD как фундаментальную модель продуктового и стратегического мышления. Для него продукт не существует сам по себе: любая оплачиваемая ценность должна быть связана с выполнением работы клиента. Поэтому задача компании — не изобретать и продавать сущности вроде CRM, чекапа, приложения, курса, нового B2B-продукта или набора фич, а понимать, какие люди в каких ситуациях пытаются достичь какого результата и почему текущие способы делают это недостаточно хорошо.
Его центральная конструкция выглядит так: потребность и контекст создают job; ценность — это более эффективное выполнение job; фича — механизм, за счёт которого эта ценность доставляется; коммуникация должна объяснить пользователю, как продукт поможет выполнить его работу и снимет барьеры; бизнес-результат возникает после того, как клиент реально получает ценность. Иван считает, что нарушение этой последовательности создаёт фичевую культуру: компания начинает с продукта, потом создаёт экраны и функции, а задачи клиента, сегменты и ценность остаются «в тумане».
Иван особенно настаивает на том, что сегментация должна начинаться с jobs, а не с демографии или персон. Демография, доход, роль, профессия, страна и другие признаки могут быть полезны как вторичный слой, но сами не объясняют желание, критерии успеха, бюджет, контекст и способ выбора. Для качественного сегмента необходимо понимать: какую работу человек выполняет, как часто она возникает, что для него считается хорошим результатом, какое решение он использует сейчас, сколько платит, чем недоволен и какие барьеры мешают сменить подход.
Для действующего продукта Иван рекомендует начинать с платящих клиентов и локального оптимума. Нужно найти сегменты, уже получающие наибольшую ценность, и провести интервью о Core Job, Big Job, критериях, ценности, барьерах, Aha-моментах и последовательности работ до покупки. Далее эти данные можно использовать для улучшения привлечения, воронки, продаж, активации, удержания и среднего чека. По его словам, такой тип исследования стабильно даёт заметный эффект, потому что опирается на уже подтверждённый спрос.
Для более крупных ставок Иван предлагает переходить к количественной оценке сегментов: измерять размер, бюджет, частотность задачи, удовлетворённость текущим решением и причины неудовлетворённости. Если количественное исследование недоступно, полезны экспертные интервью с людьми, которые уже продают нужному сегменту. Главные вопросы к экспертам — какие сегменты существуют, какие из них крупнее, платежеспособнее и неудовлетворённее, а также какие риски и особенности продаж нужно учитывать.
В стратегическом плане Иван видит discovery как поиск не абстрактных инсайтов, а возможности реализовать конкретную стратегию для конкретной бизнес-задачи. Если бизнес хочет расти, нужно сначала определить возможные направления роста: добавить новый сегмент, сместиться в более маржинальный, выйти в другую географию, перейти в B2B или B2C, решить дополнительные jobs текущих клиентов, изменить ценовое позиционирование. Затем исследование должно собрать данные, позволяющие понять, какая из стратегий имеет основания сработать. В этом для него состоит практическая ценность сегментации: она превращает рост из абстрактного требования в карту проверяемых вариантов.
В организационном контексте Иван считает, что JTBD нельзя продавать как методологию. Руководителю не нужен фреймворк, исследование или новая нагрузка — ему нужны выполнение плана, сильный отчёт, бюджет, признание, влияние и защита от провала. Поэтому продакту, дизайнеру или маркетологу нужно сначала понять личные jobs руководителя, затем показать, как текущий продуктовый курс угрожает этим целям, и предложить исследование или сегментацию как способ повысить вероятность успеха. Цифры для Ивана важны не только как доказательство реальности, но и как инструмент снижения ответственности: они позволяют руководителю защищать решение перед системой.
В коммуникации Иван предлагает диагностировать не красоту текста, а полноту клиентской логики: видит ли пользователь себя в точке А, понимает ли контекст, может ли представить точку Б, видит ли ценность, сняты ли барьеры, существует ли Aha-момент и соответствует ли CTA первому micro job. Он считает, что лендинг, продажи и интерфейс должны быть продолжением сегментации, а не отдельным слоем упаковки.
В финале Иван описывает личную мотивацию: он стремится сделать продуктовую работу менее тревожной и менее зависящей от притворной уверенности. Для него хорошая методология — это способ понять, что исследовать, какие решения рассматривать и как не принимать продуктовые решения наугад. ИИ он рассматривает как ускоритель этого процесса: модели могут быстро генерировать гипотезы и артефакты, но качественный результат зависит от того, насколько точно человек описал сегмент, job, контекст и критерии ценности.
Илья Красинский в разговоре выполняет роль ведущего и активного со-спикера, который связывает методологические тезисы Ивана с практикой продуктовых команд, корпоративных решений, B2B-продаж, аналитики, лендингов и масштабированных компаний. Его основная мотивация — борьба с бессмысленным производством фич. Он регулярно видит, как компании из разных индустрий — EdTech, SaaS, банков, интернет-магазинов, B2B- и B2C-сервисов — создают функции без ясного понимания того, кому, зачем и в какой ситуации они нужны. Для него распространение JTBD — способ дать «людям доброй воли» аргументы, чтобы сопротивляться инерции бэклогов и продуктовых инициатив, придуманных без связи с клиентской ценностью.
Илья поддерживает идею JTBD как воспроизводимой методологии. Он подчёркивает, что фреймворк нужен не ради терминов и не потому, что без него невозможно работать, а потому, что большие объёмы повторяющихся решений требуют проверяемой последовательности действий. Внутри любой компании уже есть методология — она выражается фразой «у нас так принято». Однако одни методы проверены большим количеством кейсов и дают более устойчивый результат, а другие основаны на локальной культуре, случайных успехах или интуиции сильных сотрудников. Для Ильи качество фреймворка определяется воспроизводимостью: разные люди должны получать сопоставимый результат, а не интерпретировать схему каждый по-своему.
Его важный вклад — практическое уточнение различия между фичей и ценностью. Илья первоначально склонен считать фичей прежде всего кодовую автоматизацию: например, построение CRM-графа, анализ переходов по воронке, выявление задержек сделок. Но в ходе разговора он соглашается с более широкой формулировкой: фича — это особенность продукта или сервиса, которая помогает доставить ценность. При этом он постоянно подчёркивает, что создание кода — только малая часть продукта. Чтобы техническая возможность стала ценностью, нужно распознать ситуацию пользователя, выбрать правильный момент, правильно упаковать вывод, объяснить его человеческим языком, доставить через подходящий канал и проверить огромное число пограничных сценариев.
На примере Rick.ai Илья показывает, что пользователю важна не аналитика сама по себе. Директор по маркетингу хочет быть подготовленным к разговору, иметь аргументированный ответ о причинах плохих лидов, дорогого привлечения или неэффективной кампании. Сервис должен не просто строить отчёты, а в нужный момент опровергать неверную объяснительную модель клиента и давать более точное объяснение: например, показать, что кампания выглядит убыточной из-за потерянных UTM-меток, а не из-за реального плохого качества трафика. Илья считает, что большая часть роста метрик и среднего чека происходит не из-за кода как такового, а из-за коммуникации полезности и изменения поведения пользователя.
Илья много говорит о контексте. Для него один из важнейших вкладов JTBD — язык ситуации, триггера и момента потребности. Он подчёркивает, что людям не нужна ценность «всегда»: она нужна в конкретный момент, когда активируется задача. Именно поэтому продукт должен не только иметь полезную функцию, но и попасть в жизненный или рабочий ритм пользователя. Если ценность скрыта в интерфейсе, не пришла в Telegram, почту или другой нужный канал, не была показана перед важным совещанием или в момент выбора, то она может не существовать для пользователя, даже если технически полностью реализована.
В вопросах сегментации Илья критикует стереотипные персоны и убеждение, что компания уже знает, чем клиенты отличаются друг от друга. Он считает, что команды слишком часто думают по себе, проецируют собственные представления на рынок и делают выводы вида «всем нужен английский», «всем нужна CRM» или «всем нужен чекап». Его примеры Skyeng, e-commerce, Альфа-Банка и B2B-продаж показывают, что за общей категорией скрываются разные сценарии, разные критерии и разная готовность покупать. Он подчёркивает необходимость сегментировать клиента на всём пути: в рекламе, на лендинге, после заявки, в продажах и в самом продукте.
Илья вносит важный коммерческий взгляд через ABCD/X-сегментацию. Он показывает, что компании часто тратят время на клиентов, которые не могут купить, требуют слишком много усилий, не подходят под продукт или пока недоступны из-за отсутствия доверия и бренда. При этом сегмент A — клиенты, которым продукт уже подходит и которые готовы покупать, — может быть недообслужен именно потому, что не создаёт шума. Однако Илья критично относится к собственной модели: признаёт, что не довёл её до достаточной воспроизводимости и что без кросс-проверок разные люди могут по-разному распределять клиентов по категориям.
В вопросах влияния на руководство Илья поддерживает позицию Ивана, но добавляет богатое описание личных мотивов топ-менеджеров. Он считает, что за формальными целями запуска продукта часто стоят желание признания, публичного успеха, статуса, расширения влияния, бюджета, команды, близости к генеральному директору, безопасности и защиты от увольнения. Поэтому продуктовая команда должна не просто говорить, что продукт «не взлетит» или что «надо провести исследование». Она должна показать, как текущая идея угрожает личным и карьерным целям руководителя, а более обоснованный путь увеличивает его шансы на успех.
Илья также подчёркивает двойную роль цифр. Он согласен, что данные помогают руководителю прикрыть ответственность и объяснить решения в корпоративной среде. Но он не считает, что это единственная функция. По его наблюдениям, большинство людей всё же хочет сделать работу хорошо и ищет способ опереться на реальность, даже если использует несовершенные методы. Поэтому сильная аргументация должна одновременно показывать фактическую картину, риски продукта, экономические последствия и более надёжный путь действий.
Его позиция по e-commerce связана с проблемами discovery и гипервыбора. Илья считает, что покупатель часто не знает точный товар, а приходит с ситуацией: найти фильм для определённого вечера, выбрать парфюм, технику, кроссовки, подарок. Если сервис построен вокруг внутренней структуры каталога, а не вокруг job-сценариев, человек вынужден слишком долго выбирать, теряет уверенность и уходит. Поэтому продукт должен не увеличивать количество вариантов, а помогать человеку быстрее понять, что ему подходит, и получать результат с меньшим количеством усилий.
В финале Илья поддерживает сочетание JTBD и ИИ, но подчёркивает дисциплину постановки задачи. Нейросети способны давать сильные идеи, строить сценарии и помогать с коммуникацией, однако без точного описания сегмента, ситуации, желаемого результата и критериев они будут выдавать усреднённые ответы. Для него ИИ становится особенно полезным не вместо продуктового мышления, а после того, как команда научилась формулировать клиентскую реальность на языке jobs, контекстов и ценности.
Иван Замесин связывает ценность Jobs to Be Done не с набором отдельных исследовательских или продуктовых техник, а с перестройкой способа мыслить о бизнесе целиком. По его словам, методология на базовом уровне проста, но, если она «входит в мозг», становится второй натурой. Тогда фаундер или бизнес-руководитель перестаёт воспринимать продукт как набор экранов, функций, технологий или инициатив и начинает видеть бизнес через сегменты клиентов, их работы, ценность, контексты и возможные стратегии.
Для Ивана особенно важна работа с собственниками бизнеса именно потому, что они уже действуют на высоком уровне абстракции. Они вынуждены ежедневно думать о бизнес-модели, рынке, продукте, команде, масштабе и направлениях роста. Поэтому JTBD меняет не отдельный этап работы, например формирование бэклога или проведение интервью, а саму «среду», в которой руководитель принимает решения. Вместо вопроса «Какой продукт сделать?» появляется вопрос «Какие задачи каких сегментов мы можем выполнять лучше и за счёт чего?». Вместо обсуждения набора фич — выбор того, где есть более денежный, частотный, неудовлетворённый или перспективный сегмент.
В логике Ивана сегментация открывает пространство стратегий. Когда известны сегменты по работам, их критерии, бюджеты, неудовлетворённость, текущие способы решения и графы работ, компания может не просто оптимизировать существующий продукт. Она получает возможность выбрать: масштабироваться на новый сегмент, сместиться в более маржинальный сегмент, решать дополнительные работы текущей аудитории, менять ценовой уровень, расширяться географически или переходить между B2B- и B2C-моделью. Это уже не тактический выбор между двумя вариантами реализации, а выбор направления развития бизнеса.
Илья Красинский поддерживает эту интерпретацию, подчёркивая, что фреймворки нужны для воспроизводимого результата. Для него методология — это не абстрактная «надстройка» и не язык ради языка, а последовательность действий, которая позволяет с меньшей случайностью получать предсказуемый эффект. Он противопоставляет проверенные методы внутренним практикам компаний, которые могли однажды сработать, но не обязательно могут быть повторены другим человеком или в другом контексте.
Таким образом, стратегичность JTBD в обсуждении определяется тем, что подход начинает с первопричины — работ и критериев клиента — и связывает их с бизнес-целями. Фаундер получает не только способ улучшить отдельный лендинг, провести интервью или уточнить оффер, но и способ осмысленно выбирать, какие рынки, сегменты, продукты и бизнес-модели заслуживают инвестиций.
Оглавление:
Иван Замесин приводит Cevy Kids как типовой пример перехода от абстрактного продукта к узкому сегменту с конкретными работами. Изначально у команды была широкая идея продукта, связанного с развитием ребёнка. Однако после реализации выяснилось, что продукт оказался дорогим, конверсии были плохими, а экономика не сходилась. То есть исходная формулировка — «развитие ребёнка» — не давала достаточно ясного ответа, кому именно продукт нужен, в какой ситуации он становится необходимым и за какую ценность пользователи готовы платить.
После поиска сегмента команда сфокусировалась на родителях детей с СДВГ. В изложении Ивана решающим оказался не сам медицинский или демографический признак, а наличие у родителей очень конкретных и острых задач. Речь шла о ситуациях, когда у ребёнка истерика или приступ, а родитель не понимает, что делать; когда ребёнка нужно передать няне или в школу и необходимо объяснить окружающим, как с ним взаимодействовать; когда требуется снизить число истерик или справиться с определённым поведением. Эти задачи значительно конкретнее, чем общая цель «развивать ребёнка».
Переход изменил продуктовую логику. Вместо абстрактного обучения команда стала помогать решать конкретные jobs: понимать, как реагировать на истерики, снижать их частоту, действовать в понятных сложных ситуациях, передавать инструкции другим взрослым. По словам Ивана, это сразу привело к снижению стоимости продукта в пять раз, к улучшению экономики, появлению довольных клиентов и высоким оценкам. В транскрипте не раскрываются точные механизмы снижения стоимости, но прямая связь сформулирована так: сфокусированный продукт для конкретных задач оказался лучше понятен рынку, легче продавался и создавал более очевидную ценность.
Илья Красинский подтверждает, что знаком с командой и их лендингом, а также что давал им практически ту же рекомендацию. Это усиливает основной вывод кейса: проблема не решалась добавлением новых функций или улучшением общего продукта «для всех родителей». Изменение произошло после уточнения, для кого продукт существует и какие реальные ситуации он должен закрывать.
Кейс Cevy Kids показывает, что сегментация влияет одновременно на позиционирование, содержание продукта, цену, конверсию, клиентское удовлетворение и экономику. Узость сегмента в этом случае не ограничивает рынок произвольно, а убирает размытость: компания перестаёт продавать неопределённое развитие и начинает решать набор жизненно значимых задач конкретных людей.
Иван Замесин описывает типичный путь продукта как последовательность дорогостоящих ошибок. Сначала фаундер или бизнес-руководитель придумывает продукт, нанимает команду, команда его разрабатывает и пытается продавать. Затем обнаруживается, что продукт дорогой, конверсия низкая, а юнит-экономика не сходится. После этого может появиться человек, который предлагает всё переделать. Этот цикл способен повторяться несколько раз, причём его продолжительность зависит от компетенции участников.
В этой модели сегментация и нишевание — не дополнительная опция для зрелого бизнеса, а базовая неизбежная работа. По формулировке Ивана, все продукты рано или поздно должны это сделать: разница только в том, сделают ли они это сразу, с меньшими потерями, или спустя год, два или три года «с лютыми страданиями». Причина в том, что продукт не существует сам по себе: он должен выполнять определённые работы для конкретных групп людей. Если компания не понимает, для каких именно сегментов она работает и почему эти люди должны выбрать её решение, она пытается продавать неопределённую сущность слишком широкому рынку.
Иван выделяет несколько типовых ошибок, возникающих без сегментации. Первая — компания придумывает продукт и предполагает, что он нужен некоторым людям, но оказывается, что таких людей либо нет, либо продукт нужен им недостаточно сильно. Даже если аудитория существует, у неё может быть маленький бюджет, слабая готовность покупать или неудобный для бизнеса паттерн покупки. В результате компания способна потратить годы на продажу мало кому нужного предложения.
Вторая ошибка — работа «для всех». Пользователи приходят с разными запросами, обещают купить при появлении очередной функции, а компания старается удовлетворить их всех. Это размывает ресурсы, создаёт бесконечный поток требований и лишает команду возможности сфокусироваться на конкретных jobs конкретного сегмента. В логике Ивана, такой подход приводит не к расширению ценности, а к упущенной выгоде: компания могла бы сильнее заработать, если бы точнее обслуживала ограниченный, но перспективный сегмент.
Илья связывает эту проблему с наблюдаемой им практикой: команды часто пытаются продавать один и тот же продукт всем, особенно в B2B. В его ABCD/X-сегментации сам факт существования продукта уже разделяет аудиторию на разные типы клиентов: одни покупают быстро и почти без дополнительной работы, другим продукт подходит лишь частично, третьи могут быть убыточными или ошибочно привлечёнными, четвёртые не способны позволить себе решение, а некоторые компании ещё недоступны из-за недостатка бренда или доверия. Следовательно, попытка тратить равное внимание на всех лидов противоречит реальному распределению ценности и усилий.
Нишевание в этой логике означает не отказ от роста, а выбор точки, где можно сначала создать работающую экономику и устойчивую ценность. После этого появляются основания для расширения: на соседние сегменты, другие работы, иной ценовой уровень или другой рынок. Но первоначальная попытка идти ко всем сразу подменяет эту стратегию надеждой, что широкий продукт сам найдёт спрос.
Илья Красинский формулирует типичное сопротивление так: внутри компании могут сказать, что JTBD — это «ещё один фреймворк», «ещё одна методология», которую придётся изучать и внедрять. Он отмечает, что в русскоязычном IT особенно распространена идея, будто для хороших результатов достаточно здравого смысла, хотя в других профессиональных областях — химии, биологии, физике — методы и воспроизводимые подходы считаются нормой. Однако Иван Замесин предлагает не побеждать это сопротивление спором о ценности методологии.
Его главный ответ: не нужно продавать ни исследования, ни методологию, ни фреймворк. Как только сотрудник приходит к руководителю с предложением «давайте проведём исследование» или «нам нужен фреймворк», руководитель считывает это как новую нагрузку, затраты времени, риск не выполнить текущие обязательства и угрозу личным целям. У него уже могут быть планы, KPI, обещания акционерам, бюджетные обязательства и личная мотивация. В этом контексте продуктовая работа воспринимается как отвлечение от того, за что он отвечает.
Иван сравнивает такую реакцию с отношением к дополнительным домашним заданиям в дорогой школе: человек уже платит за ожидаемый результат и не хочет получать сверху дополнительную работу, которую изначально не планировал. Аналогично руководитель не хочет, чтобы команда пришла и потребовала от него «выучить JTBD», запустить большой исследовательский процесс или отложить основные цели ради фреймворка.
Поэтому практический ответ на сопротивление — не говорить о методологии как о самостоятельном объекте. Подход должен работать в фоне, как backend, iPhone или ChatGPT: решать задачу руководителя с минимальными инвестициями и без создания ощущения новой бюрократии. Вместо фразы «нам нужно внедрить JTBD» команда должна показать, как она поможет повысить вероятность выполнения плана, снизить риск ошибки, получить более сильную аргументацию или избежать провала продукта.
Илья приводит похожую логику на примере Kanban. По его словам, метод легче внедрялся, когда никто не называл его Kanban и не продавал концепцию. Вместо этого руководителю показывали конкретный затор: задачи застряли, поток не движется, нужно изменить приоритеты, чтобы убрать блокировку. Методология оставалась внутри решения, а не становилась отдельным предметом продажи.
Следовательно, сопротивление фреймворку нужно интерпретировать не как отказ от понимания клиентов или улучшения продукта, а как защиту от дополнительной работы и неопределённых затрат. Ответом должна быть не защита термина JTBD, а демонстрация прямой пользы для уже существующих целей команды и руководителя.
Иван Замесин подчёркивает, что руководитель воспринимает предложение провести исследование не в нейтральном продуктовом вакууме. У него есть обязательства перед акционерами, конкретные коммиты, цели, сроки, ответственность и личные жизненные обстоятельства. В его примере это может быть даже необходимость купить квартиру, связанная с выполнением плана и доходом. Поэтому призыв «давайте не делать текущую работу, а займёмся исследованием» легко воспринимается как угроза: команда предлагает отвлечься от обязательств и заняться неопределённой «феечной продуктовой работой».
С точки зрения Ивана, правильный фокус — выполнять личные jobs руководителя. Необходимо понять, чего он пытается добиться через запуск продукта или изменение инициативы. Ему может быть нужно выполнить план, подготовить сильный отчёт для акционера, получить бюджет, избежать неудачи, снизить собственную ответственность, укрепить положение внутри компании или подтвердить статус успешного руководителя. Исследование и JTBD должны быть не предметом убеждения, а средством помочь ему достичь этих результатов.
Илья развивает эту мысль через обсуждение реальных мотиваций руководителей. По его наблюдениям, желание запустить продукт может быть связано с признанием, публичным успехом, выступлением на конференции, расширением влияния, получением большего бюджета и команды, прямым контактом с генеральным директором, желанием «сделать по-человечески» или страхом не подставиться и не быть уволенным. Формальные KPI и бизнес-цели в таком случае важны, но они могут быть инструментом выполнения более личных целей.
Иван формулирует ключевой переход: цели руководителя — это то, с чем он осознанно себя отождествляет, чтобы выполнять свои личные jobs. Если команда хочет изменить продуктовый курс, ей недостаточно показать, что «так правильнее по JTBD» или что «нужны интервью». Необходимо объяснить, как текущая идея помешает руководителю получить желаемый личный и профессиональный результат, а другой способ работы повысит вероятность успеха.
Практический смысл этого подхода состоит в изменении языка коммуникации. Команда не просит ресурсов на исследование ради исследования. Она говорит: чтобы успешно запустить продукт, получить доказуемый результат, не потратить бюджет впустую, защитить решение перед руководством и не оказаться ответственным за предсказуемый провал, нужны определённые данные, сегментация и проверки. Тогда продуктовая методология становится инструментом снижения риска и повышения шансов самого руководителя, а не внешней инициативой команды.
В обсуждении Иван Замесин предлагает начинать с прямого вопроса руководителю: какой бизнес-результат он хочет получить. Однако дальнейший разговор не должен останавливаться на формальной цели. Илья Красинский показывает, что за заявлениями о доле рынка, IPO, первом продукте в новой категории или «великих продажах» могут стоять более личные мотивы: признание, влияние, желание получить доверие генерального директора, расширить команду, выбить бюджет, избежать увольнения или перестать быть крайним в корпоративном конфликте.
Иван связывает эти уровни в единую конструкцию. Руководитель может хотеть запустить успешный продукт, но этот успех нужен ему не сам по себе: через него он хочет получить признание, статус, ресурсы, безопасность или возможность реализовать собственное представление о правильной работе. Поэтому задача продуктовой команды — не просто доказать, что исходный продуктовый план слабый. Нужно показать, что движение по этому плану не приведёт к желаемому для руководителя исходу.
Иван формулирует это довольно жёстко: нужно показать провал продукта, но не как отвлечённую продуктовую ошибку, а как риск для личных jobs руководителя. Если продукт не взлетит, он не получит прорывной кейс, не сможет уверенно выступить с успехом, не получит бюджет и влияние, не укрепит отношения с генеральным директором, а в крайнем случае может оказаться ответственным за неудачу. После этого нужно показать альтернативный путь: исследования, сегментация, оценка рынка, проверка ценности или прототипирование необходимы потому, что именно они повышают вероятность его успеха.
Илья приводит пример Стаси, которая пришла в фонд и за один вечер посчитала экономику пяти продуктов. Вместо того чтобы просить доверия к исследовательской методике, она показала конкретную потерю — около десяти миллионов долларов. Это изменило разговор: её не просто услышали, а наняли на высокий доход. Кейс иллюстрирует, что сильнее всего действует не теоретическое объяснение правильного подхода, а обнаружение связи между текущими решениями и измеримым риском для бизнеса и людей, которые за него отвечают.
При этом Илья признаёт ограничение: не всех руководителей удастся убедить, не все компании готовы слышать аргументы, а в организациях могут действовать двойные стандарты и скрытые мотивы. Иван в ответ допускает, что если компания игнорирует голос разума и движется к очевидному провалу, то сотруднику может быть не нужно ехать с ней «в пропасть». В этом есть важный предел влияния продуктовой команды: её задача — качественно собрать аргументацию и связать её с мотивацией руководителя, но она не может гарантировать рациональное решение в любой организационной среде.
Особое значение получают цифры и формализованные доказательства. По словам Ивана, они нужны не только для измеримости или проверки гипотезы, но и для снижения личной ответственности: руководитель может сказать, что решение принято на основе отчёта, размера сегмента, неудовлетворённости или данных о воронке. Илья уточняет, что цифры не стоит противопоставлять стремлению сделать хорошо: люди часто искренне хотят опираться на реальность. Но защита от ответственности остаётся одним из наиболее сильных мотивов, поэтому продуктовой команде важно превращать JTBD-выводы в понятную, защищаемую аргументацию.
Иван Замесин объясняет относительную «моноизвестность» продуктовых фреймворков в России прежде всего размером рынка и профессионального сообщества. По его словам, русскоязычная продуктовая тусовка значительно меньше западной. Когда участников мало, многие знают друг друга лично или через один-два профессиональных контакта, поэтому идеи, авторы и методы распространяются быстрее и становятся заметнее внутри общего поля.
Илья Красинский дополняет это историей централизации профессиональной среды. Он связывает её с ролью Москвы, ФРИИ-акселератора, Сколково и других структур, через которые проходили команды, акселераторы и специалисты. В результате сформировалась своего рода «труба»: многие стремились в Москву, а внутри неё существовала небольшая, плотная и взаимосвязанная среда. Участники общались между собой, переходили между компаниями, учились у одних и тех же людей, работали с похожими кейсами и быстро передавали друг другу практики.
В этой ситуации фреймворк может распространяться не только через книги, конференции или формальное образование, но и через прямое профессиональное взаимодействие. Люди видят, как подход используют коллеги, консультанты, участники акселераторов или известные внутри круга специалисты. Поэтому один метод может стать известным широкой части сообщества относительно быстро: не потому, что он обязательно единственный или универсальный, а потому, что каналы распространения плотные и пересекаются.
Илья также замечает, что русскоязычная среда во многом монокультурна по сравнению с большим числом стран, где люди с детства живут в более языково и культурно фрагментированной среде. В рамках встречи этот тезис используется как дополнительное объяснение того, почему в России или близком русскоязычном пространстве легче формируются общие профессиональные языки и коллективно известные фигуры.
При этом оба спикера не утверждают, что такая централизация сама по себе делает подход лучше. Скорее она объясняет механизм распространения: ограниченное число профессиональных центров, небольшая тусовка, тесные связи и высокая вирусность внутри неё создают условия, при которых определённые подходы, включая JTBD, становятся узнаваемыми гораздо шире, чем можно было бы ожидать от их числа авторов или источников.
Иван Замесин возражает против представления, будто Jobs to Be Done — преимущественно российская или локальная продуктовая методология. По его словам, на Западе огромное количество продуктов уже сделано с логикой JTBD, даже если компании не всегда явно используют это название. Он предлагает смотреть не только на профессиональные сообщества и авторов, но и на сами лендинги: в коммуникациях товаров и сервисов регулярно описываются ситуации клиента, его намерения, желаемый результат и условия выбора.
Илья Красинский подтверждает это на примере Лондона. По его наблюдению, там JTBD-логика заметна буквально в городской коммуникации: в текстах формулируются ситуации «когда у меня есть такая ситуация, я хочу…», то есть не свойства продукта, а контекст и желаемый результат пользователя. Он также упоминает, что через Deep Research можно быстро найти множество компаний, сотрудники которых евангелируют этот подход; одним из ранних известных ему примеров был Intercom.
Фрагментация западного рынка не отменяет широкого использования JTBD, а означает, что подход развивается во множестве независимых сообществ, индустрий, стран и локальных контекстов. В отличие от маленькой российской среды, где сравнительно немного известных имён могут быть заметны почти всем участникам рынка, на Западе существует гораздо больше людей, команд и школ мысли. Они могут быть хорошо известны внутри своих профессиональных кругов, но не обязательно узнаваемы за их пределами.
Илья подчёркивает, что в более крупных рынках просто «всего больше»: больше людей, компаний, сообществ, локальных авторитетов и практик. Поэтому отсутствие единого центра не означает отсутствия самого подхода. Напротив, JTBD может быть встроен в продуктовые тексты, маркетинг, дизайн и бизнес-решения без обязательной принадлежности к одному сообществу или использования общей терминологии.
Важный вывод встречи состоит в том, что JTBD на Западе распространён не только как методологический бренд, но и как практическая логика коммуникации ценности. Продукты формулируют, какую задачу пользователя они помогают выполнить, в каком контексте и с каким результатом. Именно это, по мнению спикеров, является более значимым признаком использования подхода, чем публичное самоопределение компании через термин Jobs to Be Done.
Илья Красинский ставит вопрос о персонах, отмечая, что сам отказался от этого метода как дизайнер и арт-директор много лет назад. Иван Замесин отвечает через базовую причинно-следственную логику: если всё начинается с задач и работ клиентов, а ценность означает более эффективное выполнение этих работ, то сегментировать, принимать решения и приоритизировать продуктовые изменения без понимания самих работ невозможно.
В изложении Ивана демография может быть дополнительным признаком, но не должна быть первичной основой сегментации. Она не объясняет, чего человек хочет, как он оценивает результат, какие критерии считает важными, в каком контексте у него возникает потребность и какое решение он уже использует. Если сегментировать только по портрету пользователя, можно знать, например, возраст, пол, страну или роль, но не знать первопричину выбора.
Илья приводит пример из исследования Instagram: девушки из Нигерии, Китая, Европы и России могут различаться не столько возрастом, сколько ситуациями, в которых они находятся. Его тезис состоит в том, что классическая сегментация часто начинается с ложной уверенности: компания считает, что уже знает, чем люди отличаются друг от друга. Вместо этого нужно исследовать реальные ситуации, интересы и способы действий, а не строить продукт на стереотипных представлениях.
Иван уточняет, что важен не только контекст. В полной конструкции job существенны «хочу» и критерии. Он использует пример покупки квартиры: человек может хотеть купить квартиру, но критерием удачного решения будет возможность сдавать её в аренду дороже ипотечного взноса. Именно критерии определяют, как пользователь оценивает ценность, сравнивает варианты и делает выбор. Контекст, триггеры и особенности ситуации задают разные «хочу», а эти «хочу» — разные критерии успеха.
Поэтому демография способна описывать лишь часть конструкции. Иван формулирует это как знание «когда» без знания того, что именно человек хочет и как желает получить результат. Следствием становится ложное ощущение, что сегменты понятны: формально они могут быть выделены, но их реальные критерии и ожидания окажутся разными, а продукт не попадёт в них.
Спикеры показывают это на примере изучения немецкого языка. Фраза «Я переехал в Германию, хочу выучить немецкий, чтобы найти работу» ещё не описывает сегмент достаточно глубоко. Люди могут отличаться тревожностью, склонностью к интроверсии, финансовыми возможностями, требованиями к скорости, готовностью общаться, желаемым способом обучения и критериями результата. Для одного успех — купить продукты без переводчика, для другого — сдать экзамен на нужный балл. Внешне у всех может быть одна задача «выучить немецкий», но в реальности это разные варианты ценности, продукта и коммуникации.
Иван Замесин формулирует центральную причинно-следственную связь, за пределы которой, по его мнению, бизнес не может выйти. У человека есть задачи, которые происходят из его потребностей. Ценность продукта состоит в том, что он позволяет выполнять эти задачи эффективнее. Затем компания коммуницирует пользователю, что его задачи будут выполнены с определённой ценностью и без определённых страхов, тревог и сомнений. Через контекст и контент компания привлекает человека, а через диагностические сессии или другие механики конвертирует его.
Если ценность действительно доставляется, клиент продолжает покупать, может докупать, рекомендовать продукт и положительно его оценивать. На этом этапе компания получает бизнес-ценность. То есть выручка, удержание, рекомендации и другие бизнес-результаты в этой логике не являются стартовой точкой. Они становятся следствием того, что продукт понял и более эффективно выполнил значимую задачу клиента.
Иван отдельно оговаривает существование другого типа причинно-следственной связи — продукта на дофаминовом цикле, который встраивается в поведение человека и формирует зависимость. Однако в основном обсуждении он концентрируется на модели, где бизнес-ценность строится через выполнение клиентских jobs. Для него это не просто один из возможных подходов, а ограничение, которое нельзя игнорировать: если человек использует продукт и платит, то продукт должен выполнять для него какую-либо работу.
Илья Красинский помогает развернуть эту связь на примере аналитического продукта Rick.ai. Пользователь — директор по маркетингу или собственник — не покупает систему отчётов ради самих отчётов. В определённой ситуации, например перед встречей, где его спрашивают о качестве лидов или стоимости привлечения, ему нужна аргументированная и наглядная позиция. Ценность состоит в том, что он может быстро увидеть объяснение, почему лиды или продажи выглядят определённым образом, и получить основание для решения. Отчёты, таблицы, графики, команда заботы и будущая нейросеть — это способы доставить эту ценность.
В разговоре также подчёркивается роль контекста. Формулировка «всегда иметь отчёт» слишком общая: человеку не нужен отчёт в два часа ночи или в момент, когда у него нет соответствующей ситуации. Он нужен, например, за час до совещания, когда необходимо защищать решение или отвечать на неудобные вопросы. Поэтому коммуникация ценности должна быть привязана не только к работе, но и к моменту, триггеру и контексту, в котором эта работа активируется.
Таким образом, цепочка устроена следующим образом: потребность и ситуация формируют задачу; продукт создаёт ценность, если делает выполнение задачи эффективнее; коммуникация объясняет эту способность в понятных пользователю терминах и снижает барьеры; полученный опыт ценности ведёт к покупке, повторному использованию, рекомендациям и бизнес-результату. Разрыв на любом звене приводит к проблемам: если не известна задача — непонятно, что создавать; если не сформулирована ценность — трудно коммуницировать; если ценность не доставлена в нужный момент — даже хорошая функция не меняет поведение клиента.
Иван Замесин утверждает, что в продукте не может быть чего-то, чем человек пользуется и за что платит, если это не выполняет его задачи. В терминологии Jobs to Be Done такая задача называется работой. Это положение служит фундаментом всей его аргументации: ценность не существует отдельно от того, насколько эффективнее клиент может достичь нужного результата.
Из этого следует, что продуктовая работа не может разумно начинаться с набора функций. Если компания не знает, какую работу клиента она помогает выполнять, она не может определить, что является ценностью, что следует коммуницировать, какие сегменты выбирать и как приоритизировать изменения. Иван называет попытку принимать такие решения без знания jobs оксюмороном и нонсенсом.
Илья Красинский развивает это на примере CRM. Он говорит, что продавцам сама CRM не нужна: никто не любит заполнять сделки и вносить данные ради процесса. Реальные задачи находятся на другом уровне: сфокусироваться на лидах, которые готовы заплатить; понять, где сделки застряли; определить, какой этап воронки требует оптимизации; увидеть ошибки продавца, из-за которых сделки откладываются, теряются или не закрываются. Если продукт предлагает пользователю только сущность «CRM», он продаёт средство без раскрытия работы, которую это средство должно выполнять.
Аналогичная логика звучит в разборе Альфа-Босс. Илья критикует формулировки вокруг оформления заявок, контроля поручений, тарифов и функций. По его мнению, топ-менеджер не просыпается с желанием разбираться в банковском приложении, вручную контролировать выполнение задач или выполнять ещё больше операционной работы. Если продукт описывает именно эти действия как главную ценность, он говорит о том, что важно самой компании, а не о том, чего пытается добиться пользователь в своей рабочей ситуации.
При этом спикеры не утверждают, что задачи клиента всегда осознаются и формулируются самим клиентом правильно. Напротив, Илья отмечает, что люди могут говорить языком фичей и проблем, потому что так привыкли. В B2B заказчик может попросить конкретную функцию, но это уже поздняя стадия его осмысления ситуации: он пережил некоторую потребность, выбрал объяснительную модель и сформулировал решение на доступном ему языке. Поэтому команде нужно отвечать не на буквальную формулировку, а на запрос, который за ней стоит.
В результате работа клиента становится критерием того, имеет ли продукт оплачиваемую ценность. Код, интерфейс, сервис, консультация, автоматизация или команда заботы могут быть разными способами реализации. Но если они не улучшают выполнение значимой работы в конкретном контексте, то для пользователя они остаются лишней сложностью, а не ценностью, за которую он готов платить.
Иван Замесин определяет фичу как форму доставки ценности и аргументацию того, за счёт чего продукт выполняет работу клиента эффективнее. Фича отвечает на вопрос «за счёт чего?», но не отвечает на главный вопрос «какую работу клиента мы выполняем лучше и в чём для него ценность?». Поэтому фича не должна быть первичной единицей продуктового мышления: она появляется после того, как определены job, ценность, контекст и критерии результата.
Разбор Rick.ai показывает это различие. Илья сначала описывает ценность продукта для директора по маркетингу как возможность быть подготовленным к встрече, иметь аргументированный ответ на вопросы о плохих лидах, стоимости клиента или причинах провала продаж. Иван уточняет эту формулировку: пользователь хочет видеть наглядную аргументацию, почему лиды плохие, и иметь к ней доступ в нужный момент. Это и есть ценность в конкретной работе пользователя.
Далее возникает вопрос, за счёт чего эта ценность создаётся. Ответами могут быть отчёты, графы CRM-воронки, данные об утерянных UTM-метках, команда заботы, знающая типичные ошибки, или нейросеть, обученная на большом числе кейсов. Все эти элементы являются фичами в широком смысле Ивана: они представляют собой особенности продукта или сервиса, которые обеспечивают ценность. Сами по себе они не являются конечной ценностью. Пользователь не хочет «команду заботы» или «граф всех движений сделки» как самостоятельные объекты; он хочет получить убедительное объяснение и основание для действия.
Илья первоначально предлагает более узкое понимание фичи: для него фича жёстко связана с написанным кодом. Он приводит пример технической возможности построить граф всех переходов, сделок и пользователей в CRM. Такая функция может быть реализована, но сама по себе не даёт пользователю ценности. Ещё нужно понять, в какой момент показать график, кому он нужен, какую гипотезу он должен опровергнуть, как сопроводить его текстом и как проверить систему на пограничных случаях. Илья подчёркивает, что значительная часть работы лежит не в коде, а в коммуникации, доставке и изменении поведения пользователя.
Иван расширяет понятие фичи за пределы кода. Он использует пример прозрачной бутылки: прозрачность — это особенность продукта, которая позволяет видеть количество жидкости. Она отвечает на вопрос «за счёт чего пользователь получает возможность увидеть, сколько внутри воды». Однако ценность возникает только в ситуации, где эта способность связана с задачей пользователя. Прозрачность сама по себе не является абстрактной выгодой вне контекста использования.
В ходе разговора спикеры приходят к общему языку: фича — это особенность продукта, за счёт которой ценность может быть создана и job может быть выполнена эффективнее. Но такая формулировка не отменяет замечание Ильи: наличие фичи ещё не гарантирует доставку ценности. Супернейросеть может существовать в коде, но если пользователь не оказывается на нужном экране, не получает сообщение в почте или Telegram и не видит результат в момент активной задачи, ценность не реализуется.
Поэтому правильный порядок мышления, который отстаивает Иван, выглядит так: сначала определяется работа, затем — ценность и критерии её эффективности, после — контекст и момент доставки, и только затем выбирается фича, команда, алгоритм или иной механизм реализации. Именно перенос фич на последнее место, по его мнению, создаёт свободу искать более сильные решения: не улучшать привычный продукт по инерции, а думать, как в данном контексте эффективнее выполнить нужную работу клиента.
В обсуждении Rick.ai Иван Замесин последовательно отделяет три уровня: задачу пользователя, ценность для пользователя и фичу как способ эту ценность доставить. Начальная формулировка Ильи Красинского описывает одну из задач пользователя Rick.ai так: директор по маркетингу или собственник хочет быть подготовленным к встрече, иметь аргументированный ответ на вопросы о качестве лидов, причинах дорогого клиента или снижении продаж. В частности, речь идёт о ситуации, когда маркетолога спрашивают, почему пришли «кривые лиды» и что с ними произошло. Это не описание интерфейса, отчёта или технологии, а описание того, чего человек пытается добиться в своей рабочей ситуации.
Иван уточняет эту формулировку как одну из Core Job: пользователь хочет иметь аргументацию, почему лиды плохие. Важно, что это не единственная работа сервиса, а один из возможных сценариев: сам Илья говорит, что в Rick.ai таких сценариев может быть сто или двести. Однако на конкретном сценарии можно увидеть различие понятий. Job — это необходимость быть способным объяснить происходящее с лидами и обосновать свою позицию на встрече. Она существует независимо от того, будет ли для её выполнения использован аналитический сервис, Google Таблицы, ручная работа команды заботы или другой инструмент.
Ценность Иван формулирует не как наличие отчёта само по себе, а как более эффективное выполнение этой работы. В диалоге она конкретизируется так: пользователь всегда имеет доступ к наглядной аргументации, почему лиды плохие. В уточнении Ильи особенно важен ситуационный аспект: отчёт нужен не «всегда» в буквальном смысле, а в момент, когда у директора по маркетингу возникает конкретная ситуация — например, перед совещанием, на котором нужно ответить на вопросы коллег или руководства. Поэтому ценность включает не только факт получения данных, но и своевременность, доступность и наглядность аргументации.
Илья описывает практическое содержание такой ценности через пример с ошибочной объяснительной моделью клиента. Команда может думать, что продажи снизились из-за органического трафика, потому что так показывает некорректно настроенный счётчик. Однако API и более корректный анализ показывают, что часть заказов на самом деле пришла из платных каналов, но по пути были потеряны UTM-метки. В результате компания ошибочно считает платные кампании убыточными и готова их отключить. Ценность Rick.ai состоит не в том, что он строит граф или обрабатывает CRM-данные, а в том, что пользователь получает убедительный отчёт, опровергающий неверную гипотезу и предлагающий более точное объяснение происходящего.
Фича, по определению Ивана, — это форма или способ доставки ценности, ответ на вопрос «за счёт чего» работа выполняется лучше. В случае Rick.ai такой фичей может быть команда заботы, которая знает типичные ошибки и умеет подсказать пользователю нужную интерпретацию данных. В будущем эту же функцию может выполнять «супернейросеть», обученная на большом числе кейсов. С точки зрения Ивана, и команда заботы, и нейросеть являются фичами в широком смысле: это особенности продукта или сервиса, благодаря которым пользователь получает ценность.
Илья первоначально возражает против такого расширенного понимания: для него фича в IT тесно связана с кодом и конкретной автоматизацией. Он приводит пример реальной разработки Rick.ai: сервис должен построить граф всех переходов, сделок и пользовательских путей в CRM, отследить время нахождения сделки на разных этапах. Илья называет это фичей, но подчёркивает, что сам по себе этот граф не имеет ценности для пользователя. Пока граф не показан нужному человеку, в нужной ситуации, с понятной интерпретацией и текстом, он остаётся технической возможностью, а не результатом для клиента.
В ходе диалога участники приходят к согласованной формулировке: фича — это особенность продукта, за счёт которой создаётся ценность и job выполняется эффективнее. При этом Илья сохраняет важное уточнение: кодовая автоматизация — лишь часть этой особенности. Чтобы фича реально работала, нужны распознавание состояния пользователя, правильный выбор момента, верная упаковка результата, текстовая интерпретация и постоянная проверка пограничных случаев. Поэтому практическая ошибка продуктовой команды состоит в том, чтобы принять технический артефакт — граф, отчёт, алгоритм или модель — за ценность. Ценность возникает только тогда, когда этот артефакт помогает пользователю выполнить его работу лучше в реальной ситуации.
Иван иллюстрирует эту логику примером прозрачной бутылки. Прозрачность является фичей, то есть особенностью объекта. Она доставляет ценность, когда позволяет человеку видеть, сколько жидкости осталось. Аналогично, ассистент, аналитический отчёт или «турбоэкспорт» могут быть особенностями продукта, но их смысл не в существовании самих по себе, а в том, что они обеспечивают более эффективное выполнение нужной человеку работы. В этой модели job отвечает на вопрос, что пользователь хочет сделать; ценность — насколько и в чём выполнение этой работы стало лучше; фича — благодаря чему продукт обеспечивает это улучшение.
Илья Красинский в разговоре о Rick.ai подчёркивает, что автоматизация сама по себе не равна ценности. Он приводит пример технической фичи: система анализирует данные CRM, строит граф всех путей пользователей и сделок, показывает переходы между этапами и время нахождения на них. С инженерной точки зрения это сложная работа и полноценная разработка. Но для пользователя, по словам Ильи, ценность такого графа может быть равна нулю, если сервис не определил, кому этот граф нужен, в какой момент он нужен и как его нужно объяснить.
Основная причина состоит в том, что пользователь не нанимает продукт ради кода, модели, базы данных или визуализации. В примере Rick.ai директор по маркетингу хочет иметь аргументацию для рабочей встречи. Если нейросеть существует где-то в системе, но пользователь не попал на нужный экран, не получил сообщение в почте или Telegram и не увидел результат до совещания, то технически работа может быть выполнена, а клиентская job — нет. Илья прямо указывает на этот разрыв: наличие «супернейросети где-то в коде» не имеет практического значения, если люди до неё не доходят и если она не делает доставку результата через подходящий канал.
Иван Замесин соглашается с этим уточнением и связывает его с принципом эффективности выполнения job. Для него правильная постановка задачи звучит не как «создать отчёт» и не как «сделать нейросеть», а как «обеспечить, чтобы клиент имел аргументацию в нужный момент». Когда сформулирована такая ценность, появляется свобода выбирать способ доставки: другой алгоритм, другую команду, иной канал коммуникации, фокусировку на другом сегменте или иной триггер. Технология становится подчинённой задачей, а не исходным центром продуктового решения.
Илья отмечает, что в его опыте большая часть работы над продуктами, где растут метрики или средний чек, находится не в области кода. Она находится в области коммуникации полезности и изменения поведения клиента. Даже если автоматизация уже может построить нужный анализ, остаётся большая работа по определению ситуации клиента, по выбору правильного ракурса данных, по созданию текста и по проверке того, что система не ошибается в нестандартных сценариях. Поэтому создание продукта не заканчивается на реализации функции: её ещё нужно превратить в понятный, своевременный и применимый для человека результат.
На примере Rick.ai Илья поясняет, как это происходит в ручном режиме. Сейчас часть подобных задач решает команда заботы. Она понимает ситуацию клиента, знает типичные ошибки, может распознать неверную гипотезу и показать данные под тем углом, который нужен пользователю. Например, она может не просто выдать массив информации, а доказать, что причина плохих продаж лежит не в качестве лидов или неэффективности рекламного канала, а в том, что компания вовремя не позвонила части лидов либо потеряла UTM-метки при передаче данных. Ручная работа команды в этом смысле выполняет роль формы доставки ценности, пока автоматизация не научилась делать это надёжно.
Иван называет команду заботы, знающую типичные ошибки, фичей в широком смысле — способом обеспечить клиенту нужную ценность. Илья уточняет, что команда закрывает те места, где Rick.ai ещё не успел автоматизировать работу или где полная автоматизация пока плохо достижима. Следовательно, граница проходит не между «ручным» и «автоматическим», а между доставленным и недоставленным результатом. И ручная команда, и автоматизированная система могут создавать ценность, если в конкретном контексте помогают пользователю получить нужную аргументацию.
В обсуждении также возникает различие между технической возможностью и пользовательским результатом. Внутри Rick.ai могут существовать данные, алгоритмы и графы, но пользователь не обязан уметь самостоятельно превращать их в аргумент для встречи. Если для этого ему нужно самому искать экран, интерпретировать показатели и собирать объяснение, продукт переносит значительную часть работы обратно на клиента. Тогда автоматизация не сокращает его издержки в достаточной степени. Напротив, когда сервис сам распознаёт ситуацию, выбирает релевантный отчёт, объясняет его и доставляет пользователю через подходящий канал, он действительно упрощает выполнение job.
Таким образом, в логике встречи код является средством, а не самостоятельным носителем ценности. Автоматизация становится ценной, когда она сокращает путь пользователя к нужному результату: помогает вовремя увидеть существенный факт, понять его, использовать в нужной ситуации и изменить решение или поведение. Без этого сложная разработка может остаться невидимой технической инфраструктурой, не влияющей на то, за что клиент готов платить.
В обсуждении Rick.ai Илья Красинский выделяет один из ключевых для него вкладов Jobs to Be Done: методология дала язык для описания «ситуации» и «контекста». По его формулировке, у одного и того же человека в разных ситуациях возникают разные потребности. Поэтому недостаточно сказать, что директор по маркетингу хочет иметь отчёт или всегда нуждается в аналитике. Нужно понять, в какой конкретный момент он сталкивается с необходимостью объяснить ситуацию, принять решение или защитить свою позицию.
В примере сервиса Rick.ai пользовательская работа активируется не постоянно. Илья возражает против слишком общего слова «всегда»: в два часа ночи или в четыре утра маркетологу не обязательно нужна аргументация о лидах. Она становится важной, например, за час до совещания, когда руководитель или коллеги будут задавать вопросы о причинах плохих продаж, дорогих лидов или неэффективных кампаний. Именно приближение такой встречи, получение вопроса или необходимость отстоять решение становятся триггером, который переводит потребность из фоновой в актуальную.
Иван Замесин принимает это уточнение и говорит, что в такой ситуации появляется контекст. Его подход состоит в том, чтобы не ограничиваться формулировкой «у клиента есть доступ к отчёту», а понимать, когда и почему этот доступ должен быть активирован. Ценность Rick.ai тогда заключается не просто в наличии данных, а в том, что пользователь получает наглядную аргументацию именно в тот момент, когда должен ею воспользоваться. Это меняет постановку продуктовой задачи: нужно не сделать общий кабинет с отчётами, а обеспечить релевантный результат в нужном контексте.
Контекст влияет и на способ доставки. Если полезный отчёт доступен лишь на отдельном экране, до которого пользователь должен догадаться дойти, это может быть недостаточным решением. Илья подчёркивает, что сервис может не принести ценность, если пользователь не оказался на нужной странице или если система не отправила сообщение в почту либо Telegram. Следовательно, понимание триггера позволяет определить не только содержание сообщения, но и канал, время и форму коммуникации. В одном контексте достаточно показать интерфейсный элемент, в другом — необходимо заранее прислать уведомление, краткое объяснение и готовый аргумент.
В этой логике контекст не является второстепенной деталью вокруг основной функции продукта. Он определяет, будет ли пользователь вообще способен распознать ценность и применить её. Илья связывает это с тем, что многие продукты ошибочно создают нечто полезное в абстракции, но не встраивают результат в живой сценарий пользователя. Например, можно технически верно выявить потерю UTM-меток или разрыв воронки, но если эта информация не попала к маркетологу до разговора о сокращении бюджета на рекламную кампанию, сервис не предотвратил ошибочное решение.
Иван продолжает эту мысль через идею эффективности выполнения job. Когда команда знает ситуацию, триггер и нужный момент, она может по-разному организовать выполнение работы: использовать нейросеть, команду заботы, другой алгоритм или иной процесс. При этом неизменным остаётся критерий: пользователь должен получить возможность выполнить свою задачу лучше именно тогда, когда это имеет значение. Контекст ограничивает не продуктовую креативность, а, напротив, делает её более прикладной: команда начинает искать способы не просто создать функцию, а встроить полезный результат в реальный путь клиента.
Таким образом, ценность в транскрипте привязана к моменту использования. Отчёт не является одинаково ценным во все моменты жизни пользователя; его полезность возникает в ситуации, где человеку требуется аргументированно объяснить происходящее, защитить решение или сориентироваться в проблеме. Триггер показывает, когда такая ситуация наступила, а продуктовая работа состоит в том, чтобы распознать этот момент и доставить релевантную ценность без лишнего усилия со стороны клиента.
Иван Замесин строит свою аргументацию вокруг причинно-следственной цепочки: у человека есть задачи, ценность состоит в более эффективном выполнении этих задач, а продукт и его фичи являются способами обеспечить такое улучшение. Из этого следует, что фича не может быть исходной единицей приоритизации. Если команда начинает с вопроса «что нам запилить», она сначала выбирает форму решения, а уже потом пытается придумать, зачем это нужно пользователю. По мнению Ивана, это переворачивает правильный порядок продуктового мышления.
На примере Rick.ai он показывает иной порядок рассуждения. Сначала определяется job: директор по маркетингу хочет иметь аргументацию, почему лиды некачественные или почему определённые показатели выглядят плохо. Затем описывается ценность: он получает наглядную аргументацию, имеет к ней доступ в нужной ситуации и может использовать её на встрече. Только после этого возникает вопрос «за счёт чего?» — то есть какие особенности продукта, процессы, алгоритмы или люди позволят обеспечить данный результат. Фича появляется в конце как ответ на вопрос о механизме доставки ценности, а не как самостоятельная цель.
Илья Красинский соглашается с этим порядком и переводит его на язык распространённой продуктовой ситуации. Компания может решить, что ей нужно сделать CRM, опираясь на общие предположения, технологические возможности или знакомую рыночную сущность. Однако продавцам сама CRM не нужна: они не хотят заполнять карточки сделок и выполнять дополнительную административную работу. Их реальные задачи могут быть другими — сфокусироваться на лидах, готовых заплатить, обнаружить зависшие сделки, понять, какой этап воронки нуждается в оптимизации, увидеть ошибки продавцов, из-за которых сделки затягиваются или теряются. Если начать именно с этих задач, CRM перестаёт быть обязательной отправной точкой, а становится лишь одной из возможных форм решения.
По словам Ивана, преимущество фокуса на эффективности job состоит в том, что он открывает «бесконечную свободу» способов создания ценности. Команда может применить другой алгоритм, другой интерфейс, иной канал коммуникации, другой процесс работы команды или другую специализацию по сегменту. Если же команда зафиксировалась на фиче, она ограничила себя одной формой решения ещё до того, как поняла, какую работу нужно выполнять и по каким критериям пользователь оценит результат.
Этот принцип объясняет, почему Илья считает многие фичи ненужными для пользователя. Пользователь не покупает код, экраны или автоматизацию как таковые. В его модели фичи прежде всего нужны самой компании: они позволяют масштабировать обслуживание, автоматизировать ручную работу команды и обслуживать больше клиентов. Например, ценность Rick.ai потенциально можно было бы доставлять через Google Таблицы и ручную работу. Автоматизация нужна не потому, что клиент хочет «фичу», а потому, что компания хочет давать ту же или большую ценность быстрее, дешевле и большему числу клиентов.
Иван подчёркивает, что фокус на job также позволяет выбирать правильную метрику. Если ценность состоит в том, что клиент имеет аргументацию в контексте важной встречи, то измерять нужно не наличие реализованной фичи, а то, насколько надёжно и эффективно пользователь получает эту аргументацию в соответствующей ситуации. Техническая готовность отчёта или нейросети ещё не доказывает, что job выполняется. Напротив, продукт может иметь меньше технологических элементов, но лучше решать клиентскую задачу.
В дальнейшем разговоре Иван связывает эту ошибку с тем, как в организациях рождаются продуктовые инициативы. Бизнес-руководитель может сказать: «Надо сделать B2B-продукт на наших технологиях» или «Надо сделать чекап». Команда слышит установку «сделать продукт» и начинает создавать сущность: экраны, функции, бэклог и roadmap. В такой системе причинная связь между задачей клиента, ценностью и результатом оказывается «в тумане», а на поверхности остаются только фичи, которые можно обсуждать и выполнять.
Поэтому выбор фичи должен быть последним не из-за отрицания технологий, а потому, что технология без связи с работой клиента не даёт надёжного основания для продуктового решения. Сначала нужно определить, какую работу пользователь пытается выполнить, в каком контексте, каким должен быть результат, что мешает его получить и насколько эффективнее продукт способен это обеспечить. После этого фича перестаёт быть предметом веры или вкуса: она становится проверяемым способом доставить уже понятную ценность.
В разговоре Илья Красинский использует CRM как пример продукта, который часто создают и продают на уровне сущности, а не на уровне клиентской работы. Он говорит, что нет продавца, которому нужна CRM сама по себе, и что никто не любит вручную вносить информацию в систему. Когда компания предполагает, что пользователи хотят «CRM в 2025 году», она может ошибочно считать название категории доказательством спроса. На практике сотрудники продаж воспринимают такую систему как дополнительную работу, если она не помогает им решать более важные задачи.
Илья формулирует реальные задачи продаж через конкретные ситуации в воронке. Продавцам и руководителям продаж нужно понимать, на каких лидах следует сфокусироваться, потому что эти лиды уже готовы платить. Им важно видеть сделки, которые застряли на определённых этапах, и понимать, какой шаг воронки требуется оптимизировать. Также им нужно обнаруживать ошибки продавцов, из-за которых сделки откладываются, забываются, теряются или не доходят до закрытия. Эти задачи не сводятся к ведению базы данных; они связаны с управлением вниманием, приоритетами и вероятностью продажи.
В этой формулировке CRM должна не требовать от продавца дополнительной работы ради заполнения системы, а сокращать работу, необходимую для принятия решений. Если она помогает автоматически выделить горячие лиды, показать зависшие сделки или обнаружить потерянные шаги в воронке, она выполняет пользовательскую job. Если же продукт только предлагает заполнять поля, следить за статусами и поддерживать актуальность карточек, он может не создавать ценности для человека, который и так перегружен продажами.
Иван Замесин использует этот пример, чтобы закрепить общую логику: фича — лишь аргументация «за счёт чего» обеспечивается ценность. Система учёта сделок, экран с воронкой или автоматизация напоминаний не являются исходной ценностью. Они могут быть формами, через которые продавец получает нужный результат. Приоритет должен быть задан не вопросом «какие возможности CRM разработать», а вопросом «какую работу продавца или руководителя продаж нужно выполнять эффективнее».
Илья также связывает плохое понимание задачи с плохими метриками. Когда команда пытается продать пользователям набор фич, те могут отвечать, что не хотят больше работать и не хотят вручную заполнять сделки. В результате возникают плохие конверсии, слабые продажи и несходящаяся юнит-экономика. К Илье, по его словам, компании часто приходят уже на этой стадии — когда разработанный продукт не продаётся, а финансовая модель не работает. Причина оказывается не в недостаточной убедительности презентации фич, а в том, что продукт изначально не был привязан к реальной работе пользователя.
В более широком контексте встречи CRM показывает разницу между словами клиента и его реальной задачей. Пользователь может просить конкретную функцию, потому что привык говорить на языке решений. Но команда не должна останавливаться на этой формулировке. Илья позже отмечает, что в B2B люди часто называют фичи, однако это уже «постконтактная» формулировка: клиент прошёл определённый путь, осознал потребность и выражает её в доступном ему языке. За запросом на функцию нужно искать, какую работу человек пытается выполнить и что существующее решение не позволяет сделать достаточно хорошо.
Следовательно, CRM в этой логике нужна не как отдельный класс продукта, а как возможное средство. Она оправдана, если помогает продавцу или руководителю быстрее видеть, кому продавать, где теряются сделки, какие действия дадут наибольший эффект и почему текущая воронка работает плохо. Если таких результатов нет, то даже удобная и технически качественная CRM остаётся продуктом, который пользователю предлагают обслуживать, а не инструментом, который обслуживает пользователя.
Иван Замесин объясняет склонность к «пилению фич» тем, что понимание Jobs to Be Done чаще есть у продуктовых руководителей, тогда как бизнес-руководители могут узнавать о нём значительно позже или не знать вовсе. При этом именно бизнес-руководители часто инициируют новые продукты и задают направление всей организации. Они могут рассуждать так: компания уже делает B2C-продукт, у неё есть определённые технологии, поэтому теперь нужно сделать B2B-продукт на тех же технологиях. В такой логике исходной точкой становится не работа конкретного клиента, а существующая бизнес-сущность, технология или желание освоить новую категорию.
Илья Красинский называет таких инициаторов в определённом смысле любителями в продуктовом мышлении: они придумывают продукты, не обладая нужными компетенциями для проверки, существует ли реальная задача и какой сегмент готов за её решение платить. Он приводит пример с чекапами: логика может выглядеть как «все делают чекапы, давайте и мы будем делать чекапы — у нас получится». Эта формулировка не начинается с клиента, его контекста, критериев результата и неудовлетворённости текущим способом решения задачи. Она начинается с наблюдаемой рыночной сущности, которую хочется повторить.
По наблюдению Ивана, когда руководитель говорит «надо сделать продукт», вся команда естественным образом подстраивается под эту рамку. Дизайнеры, разработчики, маркетологи и продакты начинают обсуждать, каким должен быть продукт, какие у него будут экраны, фичи, название, позиционирование и roadmap. Причинно-следственная связь между задачами клиента, ценностью, коммуникацией и бизнес-результатом остаётся неявной. В результате команда видит в первую очередь набор фич, которые были кому-то поручены, и начинает двигаться по ним, не имея ясного ответа, какую работу клиента каждая из них делает лучше.
Иван связывает это и с более простой моделью мышления. Сосредоточиться на решении, экранах, макетах, технологиях и знакомом продукте проще, чем восстанавливать сложную картину реальных работ, контекстов и критериев людей. По его словам, привычная причинно-следственная связь выглядит очевидно: есть продукт, значит нужно сделать его лучше или продать большему числу людей. Переход к вопросу о том, какие задачи существуют до продукта и почему клиент выберет одно решение вместо другого, требует иной оптики и исследования.
Илья добавляет психологическое объяснение: предприниматель или топ-менеджер часто имел какой-то личный опыт, увидел нечто на рынке и сформировал идею. После этого он настолько верит в неё, что перестаёт ставить её под сомнение. Люди могут думать по себе, полагая, что если им кажется важным английский, обучение, холодильник или иной продукт, то это автоматически нужно большой группе людей. Из такого фокуса на сущности рождается установка «людям нужен продукт», хотя, по мнению Ильи, людям сам продукт не нужен — им нужны результаты в их собственных ситуациях.
Иван считает, что эта модель сохраняется ещё и потому, что иногда она внешне работает. Внутри компании могут быть сильный дизайнер, маркетолог или разработчик, который интуитивно понимает, как сделать продукт лучше. Он компенсирует слабую исходную постановку, и запуск получает какой-то результат. Однако бизнес-руководитель может сделать неправильный вывод: «мы придумали продукт, значит именно наша исходная идея была правильной». Так фокус на сущностях не только возникает, но и закрепляется организационно.
В транскрипте противоположностью такого подхода становится движение от задач. Вопрос должен звучать не как «какой продукт на наших технологиях сделать» и не как «какую новую фичу добавить», а как «какие сегменты людей выполняют какие работы, что они хотят получить, как оценивают результат и где существующие решения не справляются». Технологии, продуктовые категории и фичи после этого не исчезают, но занимают подчинённое место: они становятся способами реализовать уже понятную ценность.
Иван Замесин называет особенно опасной ситуацию, когда продукт, запущенный без ясного понимания клиентских задач, всё же начинает работать. В типичном сценарии бизнес придумывает некую категорию продукта — например, «чекап», — а затем в команде находится сильный дизайнер, маркетолог, разработчик или другой компетентный человек. Он может интуитивно сделать решение более жизнеспособным или самостоятельно привнести недостающие элементы понимания клиента. Продукт достигает приемлемого результата, но это не означает, что исходная управленческая логика была верной.
По словам Ивана, руководитель в такой ситуации легко делает ошибочный вывод: «Мы придумали чекап — и он заработал». Из поля зрения исчезают реальные причины успеха: компетентность отдельных людей, удачные коррекции в ходе работы, интуитивно найденная ценность, существующий спрос или другие факторы. Вместо обучения тому, как продукт на самом деле был приведён к успеху, организация закрепляет веру в то, что достаточно придумать сущность продукта и дать команде команду её реализовать.
Илья Красинский развивает эту мысль через тему организационной памяти. Пока продукт разрабатывался, конкретный топ-менеджер может уже перейти в другую компанию. Команды могут поменяться, а контекст решений — исчезнуть. В результате у организации остаётся упрощённая история: продукт был запущен и компания росла. Но понимание, какие именно решения дали эффект, какие были ошибочными и кто их исправил, не сохраняется. Следующий руководитель или следующая команда могут воспроизвести только видимую форму — запуск нового продукта или набор фич — без тех скрытых компетенций, которые сделали предыдущий запуск жизнеспособным.
Иван говорит, что в таких условиях решения часто «как-то» реализуются, дают некоторый результат, но средняя организация не обучается. Особенно если сотрудники меняются, а продукт продолжает существовать за счёт уже созданной основы. Илья описывает похожий феномен на уровне масштабированного бизнеса: одно или несколько ранних удачных решений могут давать экспоненциальный эффект и запас прочности. Позже новые сотрудники могут принимать неудачные решения, но компания продолжит расти за счёт старых когорт и уже работающих частотных сценариев. Это маскирует ухудшение качества новых решений.
Илья приводит пример анализа когорт в крупных компаниях. В резюме сотрудников могут быть указаны улучшения метрик, однако при рассмотрении конкретных когорт может выясниться, что их работа в первой сессии, наоборот, ухудшила показатели и снизила число новых клиентов. Положительная динамика компании сохраняется благодаря старым когортам: если бизнес уже масштабирован и в него продолжает поступать поток пользователей, рост может происходить даже без новых сильных решений. Тогда сотрудник делает вывод, что рост компании — результат его действий, хотя данные этого не подтверждают.
Иван формулирует эту логику через распределение компетенций в организации. Небольшой процент сотрудников может обеспечивать значительную часть успеха компании. Большинство сотрудников не наследуют их ментальную модель, а делают то, что понимают, — в данном случае пилят фичи. При этом запас прочности исходных решений и решений компетентных людей может быть достаточным, чтобы компания продолжала жить и расти, несмотря на менее качественные последующие действия.
В результате успешный запуск становится плохим учебным материалом, если организация не исследует его причинность. Видимый результат подтверждает не обязательно правильную гипотезу, а иногда только то, что сильные специалисты компенсировали слабую постановку или что бизнес уже имел достаточную инерцию. Поэтому в логике встречи важно не судить о качестве подхода только по факту роста или запуска. Нужно понимать, какие сегменты, jobs, ценности, механики и решения на самом деле сделали продукт востребованным и какие решения были лишь случайно пережиты системой.
Иван Замесин предлагает не начинать с продажи методологии, исследований или фреймворков. Ранее в разговоре он объясняет, почему предложение «давайте сделаем исследование» часто воспринимается руководителем как угроза: у него есть план, обязательства перед акционером, KPI, личные риски и необходимость выполнять взятые обязательства. Если сотрудник приходит с формулировкой «давайте отложим работу и проведём вашу феечную продуктовую работу», руководитель может увидеть в этом дополнительную нагрузку, задержку результата и риск не выполнить собственные цели.
Поэтому, когда продукт уже придуман без исследования, первый шаг для продакта, дизайнера, маркетолога или другого «человека доброй воли» — понять, каких бизнес-результатов хочет руководитель и какие личные задачи за ними стоят. Иван предлагает прийти к руководителю с вопросом: «Какие у тебя бизнес-цели? Какой результат ты хочешь получить?» Этот вопрос нужен не для формального сбора KPI, а для того, чтобы увидеть мотивацию, по которой человек привязан к запуску продукта: признание, рост влияния, бюджет, команда, близость к генеральному директору, защита от увольнения, желание сделать работу «по-человечески».
Илья Красинский уточняет, что на практике такой разговор может оказаться длинным рассказом о доле рынка, новом рынке, сцене конференции, IPO, уникальности продукта или желании «сделать продажи великими». Однако за этими формулировками обычно есть более личные мотивы. Руководителю важно быть признанным, получить больше доверия и ресурсов, не подставиться, не стать крайним в конфликте, добиться влияния внутри компании или показать неприятную реальность руководству. Понимание этих мотивов позволяет менять не только продуктовую логику, но и язык влияния.
Далее Иван предлагает не противопоставлять «правильную продуктовую работу» исходной идее как абстрактно более профессиональный подход. Вместо этого нужно показать, что текущая идея не позволит руководителю выполнить его личные и бизнесовые задачи, а исследование, сегментация, оценка рынка или проверка гипотез повышают шанс на желаемый результат. Иными словами, продакту не нужно продавать руководителю JTBD. Нужно помочь ему с большей вероятностью выполнить план, показать акционеру сильный отчёт, получить нужный бюджет и не провалить запуск.
Ключевым инструментом становится аргументация риском. Иван формулирует её предельно прямо: нужно показать провал продукта, но не как техническую ошибку или несогласие сотрудника, а как угрозу личным целям руководителя. Если текущий продукт не найдёт рынок, руководитель не выступит на конференции с феноменальным успехом, не получит признание, не получит бюджет, не станет влиятельнее и может оказаться ответственным за неудачу. После этого альтернативный путь нужно показать не как дополнительную методологическую нагрузку, а как условие достижения желаемого: чтобы продукт стал успешным, чтобы руководитель получил поддержку и чтобы его считали сильным управленцем.
Илья приводит пример своей бывшей product manager Стаси. Она пришла в фонд, сделала домашнюю работу и посчитала экономику пяти продуктов. Фонд рассчитывал анализировать экономику три месяца, а Стася быстро показала, что в этих продуктах потеряны десять миллионов долларов. Этот пример иллюстрирует, что влияние возникает, когда человек приносит не теоретическое возражение и не просьбу «дать время на фреймворк», а аргумент, который меняет понимание риска и решения. В результате Стасю приняли на работу с высоким доходом.
При этом Илья и Иван не обещают, что такой подход сработает всегда. В обсуждении признаётся, что некоторые руководители могут не услышать аргументы, использовать двойные стандарты или уволить человека, который пытается вскрыть проблему. Один из участников чата, по словам Ивана, сообщил, что его выгнали после подобного захода. Ответ Ивана: если организация не слышит голос разума и движется к провалу, возможно, не стоит ехать вместе с ней. Тем самым влияние на руководителя рассматривается не как гарантированная манипулятивная техника, а как способ честно соотнести продуктовую реальность с его личными целями и оценить, возможно ли в этой среде работать.
Иван Замесин предлагает различать формальные цели руководителя и личные jobs, ради которых эти цели становятся для него значимыми. Формально руководитель может хотеть запустить новый продукт, выполнить KPI, получить бюджет, собрать команду, увеличить долю рынка или сделать успешный кейс. Но, по мысли Ивана, человек сознательно отождествляется с этими целями, чтобы решать более глубокие личные задачи. Именно эти задачи становятся настоящей точкой мотивации и принятия решений.
Илья Красинский описывает типичный набор таких мотивов. Руководитель может хотеть выступить на сцене и рассказать, что он создал новую нишу или запустил первый в своей категории продукт. В разговоре звучат примеры «мы первыми сделаем B2B-маркетплейс», «выйдем на IPO», «сделаем первый голосовой Twitter». Внешне это продуктовые или стратегические цели, но Илья видит за ними желание быть крутым, получить признание и подтвердить собственную значимость.
Другой личный мотив — увеличение влияния внутри компании. Илья говорит, что руководители часто оценивают себя через объём доверия: дали ли им больше команду, больше бюджет, больше полномочий, прямой контакт с генеральным директором. Он использует метафору «быть любимой женой» генерального директора, описывая положение любимчика или особенно доверенного управленца. В таком контексте запуск продукта может быть нужен не только ради выручки, но и как способ занять более сильную позицию в иерархии и стать незаменимым для руководства.
Существенная личная job — не быть уволенным, не подставиться и не стать крайним. Илья подчёркивает, что страх в управленческой среде очень велик. Руководителю может быть важно иметь документы, аргументы и факты, особенно в конфликте между подразделениями. Он приводит пример известного оператора связи, где команду просили собрать больше доказательств, чтобы показать разработчикам, что они недостаточно тестируют продукт. Доказательства в такой ситуации нужны не только для улучшения продукта, но и для распределения ответственности и защиты собственной позиции.
Ещё одна мотивация — сделать работу «по-человечески». Илья описывает руководителей, которые приходят в новую организацию, видят хаос и хотят исправить процессы. В этом случае человек может не стремиться только к деньгам или карьерному продвижению. Ему важно воплотить собственное представление о правильной организации работы, доказать, что он способен привести систему в порядок, и не быть вынужденным мириться с тем, что считает неправильным.
Иван обобщает эти примеры. У руководителя может быть job успешно запустить продукт, но за ней стоят желание получить признание, вырастить влияние, стать ближе к генеральному директору, получить бюджет и команду, сделать «по-человечески», не быть уволенным или, как он иронично выражается, «поиграть в Lego с большим бюджетом и командой». Последняя формулировка не отменяет серьёзности других мотивов: она показывает, что запуск продукта может давать руководителю ощущение масштаба, творческой власти и управленческой субъектности.
Илья отдельно замечает, что деньги часто переоценивают как универсальную мотивацию. По его наблюдениям, среди большого числа предпринимателей и руководителей лишь небольшая доля действительно мотивирована деньгами как главным источником удовольствия. Для большинства деньги могут быть важны, но не объясняют, почему человек так настойчиво продвигает конкретный продукт, требует бюджет или стремится к видимой победе. Более сильными мотиваторами оказываются признание, статус, влияние, безопасность, возможность доказать компетентность и возможность быть услышанным наверху.
Практический смысл этого анализа для продуктовой команды состоит в том, что формальные бизнес-цели недостаточны для влияния на решение. Если продакт предлагает другой путь, он должен понимать, какую личную job руководитель пытается выполнить через продуктовую инициативу. Тогда можно показать, как сегментация, исследование или изменение продукта помогут не просто «улучшить процесс», а дадут руководителю то, ради чего он на самом деле принимает рискованные решения.
Иван Замесин считает, что прямой спор о качестве продуктовой идеи обычно слабее, чем демонстрация её последствий для самого руководителя. Когда человек уже придумал продукт, название, концепцию, позиционирование и даже логотип, он психологически и организационно связан с этим решением. Если сотрудник приходит только с фразой «надо сделать исследования, оценить рынок и подготовить прототипы», руководитель может услышать предложение замедлиться, усложнить работу и поставить под угрозу свои KPI. Даже если рекомендация продуктово верна, она не отвечает на его непосредственный вопрос: как ему выполнить план, сохранить доверие и добиться нужного результата.
Поэтому Иван предлагает показать провал текущего продукта как угрозу не абстрактным метрикам, а личным jobs руководителя. Логика строится так: если он продолжит запуск без понимания сегмента и ценности, продукт может не получить рынок, не стать прорывным, не принести бюджет, не дать повода для признания и поставить под угрозу карьерную устойчивость. В формулировке Ивана нужно дать человеку увидеть: он, возможно, поиграет в создание продукта с командой, но не получит всё остальное, ради чего вообще затеял инициативу.
Такая постановка важна потому, что личные цели руководителя являются точкой принятия решения. Если он хочет выступить на конференции с успешным кейсом, получить больше влияния или показать генеральному директору сильный результат, нужно связать продуктовую реальность именно с этими ожиданиями. Альтернативный путь — исследование, сегментация, тестирование, оценка рынка — тогда становится не «ещё одной методологией», а средством повысить вероятность личного успеха руководителя.
Иван предлагает после демонстрации риска показать положительную альтернативу на том же языке. Не достаточно сказать: «Ваш продукт провалится». Нужно сказать: «Чтобы вы успешно запустили продукт, получили бюджет, признание и поддержку, вам нужно сделать вот это». То есть сотрудник не отнимает у руководителя амбицию, а предлагает более надёжный маршрут к ней. В этой логике исследование рынка не противостоит скорости или бизнесовому результату; оно снижает вероятность, что ресурсы будут вложены в продукт для сегмента, у которого нет достаточной потребности, бюджета или готовности покупать.
Илья Красинский поддерживает эту мысль примером с расчётом экономики нескольких продуктов. Стася не просто высказала мнение, что фонд ошибается или что нужно сначала провести исследование. Она показала, сколько денег уже было потеряно, и тем самым перевела разговор в плоскость последствий для тех, кто принимает решения. Такой аргумент одновременно меняет понимание бизнеса и влияет на персональный риск руководителей: после появления расчётов сложнее продолжать действовать так, как будто проблемы нет.
В обсуждении подчёркивается, что руководитель часто воспринимает цифры и исследования не только как путь к объективности, но и как средство снять ответственность. Если имеется отчёт, который показывает малый размер сегмента, неудовлетворённость пользователей или отсутствие спроса, руководителю проще обосновать изменение курса перед акционерами и коллегами. Поэтому доказательство конфликта между идеей и личными целями должно быть не только эмоциональным, но и достаточно аргументированным, чтобы человек мог использовать его внутри своей управленческой системы.
При этом Иван и Илья признают ограничения подхода. Не каждый руководитель готов пересматривать своё решение, даже если ему показали риски. В некоторых организациях могут доминировать интриги, двойные стандарты или нежелание слышать неприятную информацию. Однако если руководитель действительно хочет успеха, признания, влияния или безопасности, то наиболее сильный способ повлиять на него — не читать лекцию о JTBD, а показать, что текущая продуктовая идея снижает вероятность получить именно эти результаты.
В разговоре Иван Замесин отделяет роль качественных интервью от роли количественных данных. Качественное исследование в JTBD-логике нужно, чтобы понять, какие сегменты существуют, какие работы выполняют люди, что они хотят получить, как оценивают результат, какие барьеры испытывают и как выглядит последовательность их действий до покупки решения. Такое интервью даёт структуру реальности: позволяет увидеть не абстрактную аудиторию, а конкретные группы людей с разными jobs, критериями и текущими способами решения задач.
Для существующего продукта Иван рекомендует начинать с уже платящих клиентов. Он предлагает сегментировать более маржинальные группы, использовать сегментацию Шона Эллиса и проводить интервью с теми, кто уже ценит продукт. В интервью следует выяснять Core Job и Big Job, ценность, барьеры, Aha-моменты и последовательность работ от появления потребности до покупки. По его оценке, такое исследование имеет высокую вероятность улучшить метрики: помочь сместиться в другой сегмент, увеличить конверсию, снизить отвал или повысить средний чек.
Однако качественные интервью не заменяют количественную проверку, когда решение требует больших инвестиций. Илья поднимает вопрос участника: что делать, если в интервью видно, что идея не взлетит, но цифр ещё нет и аргументация кажется слабой. Иван отвечает, что крупные решения не принимаются без цифр и количественной аргументации. Качественное исследование позволяет понять, что искать и как сегментировать рынок, но для серьёзной ставки необходимо собрать подтверждение размера сегмента, его бюджета, частотности работы, текущих решений и уровня неудовлетворённости.
Иван описывает последовательность перехода от качественного к количественному исследованию. На качественном этапе команда узнаёт, какие люди и работы существуют. На количественном — формирует анкету и ищет людей по признаку, что у них с высокой вероятностью есть конкретная работа и они уже платят за её решение больше определённой суммы. Затем у них спрашивают, выполняют ли они эту задачу, как часто, сколько платили за её выполнение, какое решение используют, насколько удовлетворены и по каким причинам неудовлетворены. Благодаря этому можно оценить размер сегмента, бюджет на работу или набор работ, используемые альтернативы и незакрытые ожидания.
В качестве примера Иван приводит сегментацию рынка корпоративной безопасности автопарков. Юра Весневский начинал с набора гипотез о продуктах, но не понимал, как приоритизировать несопоставимые идеи. Он провёл интервью с руководителями, изучил их задачу снижения аварийности, выделил связанные работы — корректировку стиля вождения, проверки, выявление нарушений режима труда и отдыха, выработку привычек. После качественного понимания сегментов были отброшены убыточные группы с малым числом машин, низким бюджетом или сложным принятием решений. Затем через опросы была оценена величина сегментов, бюджеты и качество текущего выполнения работ. Это позволило выбрать фокусный сегмент, создать продукт и обеспечить значимый рост выручки компании.
Илья подчёркивает, что для больших компаний и дорогих решений количественное исследование особенно оправдано. В его формулировке, если компания крупная, а цена ошибки высока, то необходимо делать «количественник». Иван добавляет, что такие B2B-исследования не всегда запредельно дороги: он упоминает исследования стоимостью в несколько сотен тысяч рублей, в том числе для генеральных директоров компаний определённого масштаба выручки. Смысл расходов в том, чтобы не принимать масштабное решение только на основании отдельных интервью или внутренней уверенности команды.
При этом количественное исследование не рассматривается как единственный способ усилить аргументацию. Если опрос слишком дорог, респондентов мало или собрать их невозможно, Иван предлагает экспертные интервью как лучшее доступное приближение. Нужно разговаривать с людьми, которые уже продают интересующему сегменту: коммерческими директорами, маркетинговыми директорами и другими экспертами. Они могут назвать сегменты, оценить их размер, платежеспособность, неудовлетворённость, риски и способы продаж. Илья дополняет это поиском цифрового следа, профессиональными сообществами, реферальными контактами и разговорами с бывшими сотрудниками компаний.
Таким образом, качественные интервью создают JTBD-карту: показывают, какие задачи, сегменты, критерии и барьеры существуют. Количественные данные проверяют масштаб и экономический смысл этой карты, особенно перед большими инвестициями. JTBD-аргументация связывает найденные факты с решением: объясняет, почему выбранный сегмент имеет конкретную работу, бюджет и неудовлетворённость, а предложенное решение может выполнить эту работу лучше. Вместе эти элементы позволяют говорить с руководителем не на уровне вкуса, фич или общих мнений, а на уровне клиентской реальности, размера возможности и риска решения.
Иван Замесин в ответ на вопрос о роли цифр говорит, что крупные решения без количественной аргументации не принимаются. В чате участники называют измеримость, уверенность и снижение страха. Иван соглашается, но выделяет главное: цифры позволяют снять ответственность и прикрыть свою позицию отчётом. Руководителю проще сказать: «Вот данные, вот отчёт, здесь видно, что сегмент маленький, а идти нужно в другую сторону», чем единолично заявить, что он не верит в уже утверждённую идею.
В этой логике цифры являются не только инструментом познания, но и управленческим артефактом. Они позволяют перевести решение из плоскости личного мнения в плоскость обоснованной позиции. Илья Красинский иллюстрирует это через продуктовую аналитику: если на экран с определённой job приходит мало пользователей, то какую бы фичу команда ни разрабатывала, у неё почти не было шанса повлиять на общий результат. Такой отчёт позволяет сотруднику показать, что исходная задача была поставлена на слабом основании и что плохой результат нельзя полностью приписать исполнителю.
Иван формулирует это предельно прагматично: долгосрочно в корпорациях выигрывают те, кто лучше покрывает свою ответственность отчётами. В его высказывании нет отрицания реальной полезности измерений; он подчёркивает, что в организационном контексте данные выполняют дополнительную функцию. Они становятся защитой в среде, где решения требуют согласований, где есть акционеры, конфликтующие подразделения, личные риски и возможность быть назначенным виноватым.
Илья частично уточняет эту позицию. Он считает противопоставление «цифры как объективная реальность» и «цифры как прикрытие» ложной дихотомией. По его наблюдениям, большинство людей всё же хочет сделать работу хорошо, даже в сложных организациях с интригами и конфликтами. Они используют привычные методы, потому что считают их единственно возможными в своей ситуации. Поэтому цифры для них могут быть и попыткой опереться на реальность, и способом получить ощущение уверенности в том, что решение не основано на произвольном мнении.
Иван соглашается с этим дополнением: цифры действительно являются аргументом при принятии решений, но их значение не сводится к отражению реальности. Когда руководитель должен изменить курс, отказаться от любимой идеи, запросить бюджет или объяснить решение акционеру, ему нужен материал, который позволяет распределить ответственность между ним и подтверждёнными фактами. Отчёт уменьшает персональную уязвимость: руководитель может показать, что действовал не импульсивно, а на основании наблюдаемой ситуации рынка или продукта.
Эта функция особенно важна в контексте обсуждавшихся личных jobs руководителя. Если ему важно не подставиться, не быть уволенным, сохранить доверие и получить поддержку, то цифры снижают риск принятия решения «на глаз». Поэтому продакт, дизайнер или маркетолог, который хочет изменить продуктовый курс, должен не только обнаружить через интервью, что сегмент не подходит или что текущая ценность недостаточна. Он должен по возможности принести измеримую аргументацию, которую руководитель сможет использовать в разговоре с более высоким уровнем управления.
В итоге цифры в транскрипте выступают двойным инструментом. С одной стороны, они помогают увидеть размер сегмента, бюджеты, частотность работ, удовлетворённость и реальные продуктовые ограничения. С другой — делают выводы социально применимыми внутри компании: позволяют человеку объяснить своё решение, защититься от обвинений и снизить субъективную цену ошибки. Именно поэтому сильная продуктовая аргументация сочетает качественное понимание jobs с количественными свидетельствами: первое объясняет, что происходит и почему, второе делает это объяснение достаточно безопасным для управленческого действия.
Иван Замесин подчёркивает, что ценность сегментации заключается не в накоплении информации о пользователях как таковой. Знание о том, «кто такие клиенты», само по себе не является конечным бизнес-результатом. Главный эффект появляется тогда, когда сегментация по jobs и дополнительным признакам открывает пространство решений, которое без неё не было видно. Команда перестаёт рассуждать абстрактно о росте продукта и получает возможность выбирать между конкретными стратегическими ходами, привязанными к определённым сегментам, их задачам, бюджетам, критериям выбора и способам выполнения работ.
В логике Ивана, product discovery должен начинаться не с общего поиска «инсайтов» или неструктурированных идей, а с конкретной бизнес-задачи. У компании может быть цель вырастить продукт, повысить конверсию, увеличить ценность, отстроиться от конкурентов, запустить новое направление или масштабировать выручку. После определения цели возникает следующий вопрос: какие стратегии в принципе могут привести к этому результату? Сегментация нужна именно для того, чтобы ответить на него не фантазией, а наблюдением за рынком и людьми.
Например, если задача состоит в масштабировании уже работающего продукта, знание сегментов позволяет рассмотреть несколько разных направлений роста. Можно добавить новый сегмент с похожей работой, сместиться в более маржинальный сегмент, начать выполнять для текущих клиентов другие работы, перейти в B2B или B2C, изменить ценовое позиционирование либо расшириться географически. Иван приводит пример Яндекс Такси: перевозка людей из точки А в точку Б может масштабироваться не только выходом в другой город, например из Москвы в Петербург, но и созданием другого ценового и сервисного сегмента внутри той же работы. Так появляются «Комфорт» и более статусные тарифы: сама базовая job остаётся похожей, но меняются критерии того, как клиент хочет её выполнить.
Сегментация также помогает увидеть возможность не просто добавить сегмент, а сознательно сместить фокус. Иван рассказывает о Феде Кирееве, который работал с услугами для отелей. Вместо того чтобы пытаться одинаково обслуживать всех клиентов, он обнаружил сегмент сетей отелей. Для коммерческого директора сети ценность решения была выше, поскольку сеть включала больше объектов и услуг. Смещение в такой сегмент создавало возможность значительно увеличить margin per user и кратно вырастить выручку. Это не вывод вида «мы лучше узнали клиентов», а стратегическое решение: выбрать сегмент, где та же или близкая ценность имеет существенно больший экономический потенциал.
Иван также различает локальный и глобальный оптимум сегментации. Локальный оптимум строится на исследовании уже платящих клиентов: компания лучше понимает существующие сегменты, их Core Job, Big Job, барьеры, ценность, Aha-моменты и последовательность работ до покупки. За счёт этого можно точнее привлекать людей, улучшать воронку, активировать ценность, снижать отвал, увеличивать удержание и иногда средний чек. Риск такого движения сравнительно низкий, потому что компания работает в пределах уже проверенной модели и существующего спроса.
Глобальный оптимум возникает, когда компания исследует не только текущих клиентов, но и другие сегменты, решения конкурентов, работы за пределами своего текущего рынка и потенциально новые бизнес-модели. Например, страховая компания может не ограничиваться изучением клиентов, которым уже продаёт ДМС или другие страховые услуги, а искать новые работы, которые другие люди выполняют вне рамки страховки. Такой подход потенциально способен дать кратный рост, поскольку позволяет найти более крупные, денежные или частотные сегменты. Однако Иван отдельно оговаривает, что риск здесь существенно выше: новая инвестиция может не сработать, потому что компания выходит за пределы уже подтверждённого поля.
Таким образом, сегментация в обсуждении понимается как способ построить причинно-следственную связь между бизнес-целью, доступными стратегиями и необходимым исследованием. Сначала формулируется задача бизнеса, затем определяется набор возможных стратегий, а затем исследование собирает информацию, которая позволяет проверить, можно ли реализовать хотя бы одну из этих стратегий. Знание о сегментах становится инструментом принятия решений: оно показывает, какие сегменты существуют, какие работы они выполняют, где есть бюджет, неудовлетворённость, частотность и возможность создать или усилить ценность. Без этого компания видит только привычный продукт и набор фичей; с этим — видит карту возможных направлений развития.
Иван Замесин описывает запуск продукта без понимания сегмента как ситуацию с высокой вероятностью системных ошибок. Первая и наиболее типичная ошибка состоит в том, что команда сначала придумывает продукт, затем предполагает, кому он должен быть нужен, а уже после пытается продать готовое решение. В такой логике сегмент не обнаруживается, а конструируется из ожиданий команды. В результате может выясниться, что таких клиентов либо почти нет, либо они существуют, но продукт им нужен недостаточно сильно.
По словам Ивана, особенно опасен не только сценарий полного отсутствия рынка, но и более правдоподобный сценарий «слабого спроса». Люди могут формально подходить под портрет, проявлять интерес, соглашаться на разговоры или даже время от времени покупать, но иметь маленький бюджет, принимать решение медленно, покупать нерегулярно и не считать решение приоритетным. Тогда команда может годами улучшать продукт, снижать цены, добавлять функции и перестраивать продажи, не замечая базовой проблемы: она работает с сегментом, где нет достаточной готовности и возможности платить. Иван формулирует это как риск «два года положить на то, чтобы продавать мало кому нужный продукт».
Эта логика ранее была показана на кейсе Cevy Kids. Исходно команда делала продукт про развитие ребёнка в широком смысле. Он оказался дорогим, плохо конвертировал, а экономика не сходилась. После фокусировки на родителях детей с СДВГ продукт получил более конкретный набор работ: справиться с истериками ребёнка, понять, как реагировать на приступы, передать ребёнка няне или школе вместе с понятными инструкциями. Переход от общей категории «развитие ребёнка» к узким и насущным jobs привёл к кратному снижению стоимости, улучшению экономики и более высокой удовлетворённости клиентов. Важен не сам факт сужения аудитории, а нахождение сегмента, где есть конкретная задача с ясной ценностью решения.
Вторая ошибка, которую выделяет Иван, — попытка работать «для всех». Когда компания не знает сегменты, к ней начинают приходить люди с разными запросами. Они говорят: «Дайте мне такую возможность — куплю», «Добавьте другую функцию — куплю», «Сделайте отдельный сценарий — куплю». Команда принимает эти запросы за признаки спроса и начинает строить продукт, который должен удовлетворить всех сразу. В результате ресурсы размазываются между несовместимыми или малоприоритетными требованиями, а компания теряет упущенную выгоду: вместо сильной ценности для конкретной группы она создаёт усреднённое решение с размытым предложением.
Эта ошибка непосредственно связана с критикой фичевого подхода, которую оба спикера обсуждали ранее. Если продуктовая логика начинается с сущности продукта и набора возможностей, а не с конкретных работ определённых людей, то каждое новое пожелание выглядит как потенциально полезная фича. Однако при сегментации становится возможным спрашивать не «просит ли это кто-то из клиентов», а «для какого сегмента и какой job это важно, насколько этот сегмент ценен, часто ли возникает задача, каков бюджет и соответствует ли он стратегии компании». Тогда часть запросов можно осознанно не делать, потому что они не усиливают ценность для фокусного сегмента.
Третья ошибка — работа на убыточные или невыгодные сегменты. Иван прямо указывает, что демографически или внешне заметный сегмент может не иметь бюджета, редко выполнять нужную работу, тяжело принимать решения или требовать непропорционально много усилий на продажу и обслуживание. В этом случае клиенты могут быть реальными, их проблема — настоящей, а потребность — искренней, но бизнес-модель на них не будет сходиться. Сегментация нужна, чтобы не путать наличие запроса с экономической привлекательностью сегмента.
В кейсе о безопасности дорожного движения корпоративных автопарков Иван показывает практическое применение этого принципа. Исследователь выделил сегменты начальников пассажирских перевозок и связанных с ними ролей, изучил их задачи — снижение аварийности, корректировку стиля вождения, проверки, выявление нарушений режима труда и отдыха — а затем отсеял убыточные сегменты. Причинами были малое количество машин, недостаточный бюджет или сложность принятия решений из существующего бюджета. После этого фокус был выбран среди сегментов, где работа действительно выполнялась, был бюджет и существовала неудовлетворённость текущими решениями. Именно такой фокус позволил запустить продукт, который дал значимый рост выручки компании.
Иван также уточняет, что для выбора сегмента недостаточно качественно услышать проблему. Нужны оценки размера сегмента, бюджета, частотности job, текущего решения, степени удовлетворённости и причин неудовлетворённости. Качественные интервью дают понимание того, какие сегменты и работы существуют, а количественное исследование позволяет оценить масштаб и экономический потенциал. Если количественный этап невозможен или слишком дорог, приближением могут быть экспертные интервью с людьми, которые уже продают таким клиентам и способны оценить платежеспособность, риски и особенности продаж.
В совокупности ошибки запуска без сегментации возникают потому, что команда принимает за ориентир собственную идею продукта, единичные просьбы клиентов или поверхностное сходство аудитории. Сегментация переводит решение в другую плоскость: вместо вопроса «кому бы продать то, что мы сделали?» появляется вопрос «какие люди регулярно выполняют какую работу, насколько плохо она сейчас решается, сколько они готовы за это платить и на каких из них нам выгодно фокусироваться».
Иван Замесин объясняет, что демографическая сегментация способна давать ложное ощущение понимания аудитории. Демографические признаки сами по себе могут быть полезны, но они не являются первопричиной ценности и выбора. Если компания знает только возраст, пол, доход, страну, должность или другой внешний признак, она может понимать, в каком контексте приблизительно находится человек, но не понимать, что именно он хочет получить, как оценивает результат и почему выбирает то или иное решение.
В терминологии Ивана, особенно важно «хочу» вместе с критериями. Он приводит пример с покупкой квартиры: человек может говорить, что хочет купить квартиру, но его критерий хорошего результата состоит в том, чтобы сдавать её в аренду дороже ипотечного взноса. Именно критерий показывает, как клиент будет оценивать ценность. Для такого человека важна не формальная покупка недвижимости, а экономический результат конкретного типа. Если продукт, коммуникация или предложение не попадают в этот критерий, знание возраста, дохода или семейного положения не поможет сделать ценность убедительной.
Контекст, триггеры, особенности ситуации и желаемое «чтобы» создают разные варианты «хочу». По словам Ивана, разные контексты и триггеры приводят к разным желаниям и к разным критериям. Поэтому два человека, внешне относящиеся к одному демографическому сегменту, могут принципиально по-разному выбирать продукт. И наоборот, люди из разных стран, возрастов или социальных групп могут быть близки друг к другу по своей ситуации, job и способу оценки результата.
Илья Красинский дополняет эту мысль примером из исследований Instagram. В обсуждении упоминается, что девочка в Нигерии, девочка в Китае, девочка в Европе и девочка в России могут отличаться между собой не столько возрастом или иными демографическими параметрами, сколько ситуацией, в которой находятся. Илья использует этот пример, чтобы показать ограничение классической сегментации: она часто начинается с предположения, что команда уже знает, чем люди отличаются. Однако именно это предположение нуждается в проверке. Вместо опоры на стереотипы о группах нужно исследовать реальные ситуации, интересы и способы выполнения задач.
Иван формулирует риск предельно ясно: если сегментировать только по демографии, компания из всей job знает лишь часть «когда» или внешнюю рамку ситуации, но не знает «что человек хочет» и «как он хочет это получить». В итоге может появиться кажущееся понимание сегментов: они выглядят понятными, различимыми, имеют названия и портреты. Но у разных групп могут быть принципиально разные «хочу» и критерии, в которые продукт не попадает. Тогда компания уверенно делает предложение для «молодых специалистов», «предпринимателей», «мам 25–35» или «директоров», не замечая, что внутри каждой такой категории существуют разные работы и разные основания для покупки.
Этот риск особенно заметен в примере изучения немецкого языка, который приводит Иван. Поверхностная формулировка job может выглядеть так: «Я переехал в Германию, хочу выучить немецкий, чтобы найти работу». Если остановиться на ней, может показаться, что сегмент один и продукт должен быть один. Но при дальнейшем исследовании проявляются различия: тревожным людям может быть трудно общаться, интровертам может быть важен другой формат, одним нужно быстро получить результат, другим подходит длинная траектория, у обеспеченных людей могут быть более высокие требования, а у менее обеспеченных — другие ограничения. Одни будут считать обучение успешным, если смогут покупать продукты без переводчика, другие — если сдадут экзамен на нужный балл. Внешне все могут быть «переехавшими в Германию», но фактически их критерии и желаемый результат различаются.
Илья также обращает внимание, что Jobs to Be Done — лишь один слой сегментации, а не отмена всех остальных признаков. В обсуждении не утверждается, что демографию следует игнорировать. Напротив, Иван говорит о сегментации в первую очередь по jobs и во вторую — по дополнительным признакам, включая демографию. Демография становится полезной после того, как найдена причинно-следственная основа: какая работа выполняется, в каком контексте, с каким желаемым результатом, какими барьерами и критериями. Тогда дополнительные признаки помогают находить, описывать и достигать сегмент, но не подменяют понимание ценности.
Таким образом, ложная картина возникает не потому, что демография всегда неверна, а потому, что её ошибочно принимают за объяснение мотивации. Она описывает часть внешнего портрета, но не отвечает на ключевые продуктовые вопросы: какую работу человек пытается выполнить, какой результат для него считается хорошим, какие страхи и ограничения мешают, какие альтернативы он рассматривает и почему текущий способ не устраивает. Без ответов на эти вопросы компания может точно описать человека, но ошибиться в том, что ему предлагать.
Иван Замесин считает, что Jobs to Be Done особенно важен в e-commerce, когда товары внешне мало отличаются друг от друга и различия их фактических возможностей невелики. В таком случае продукту трудно победить только характеристиками ассортимента: похожие товары есть у многих продавцов, а сами по себе свойства продукта могут быть понятны и сравнимы. Поэтому критическим становится знание jobs, критериев выбора и графа работ клиента. По формулировке Ивана, в такой ситуации это фактически единственное, с чем можно конкурировать.
Смысл подхода состоит в том, что покупка товара не исчерпывается фактом наличия товара в каталоге. Человек не просто «хочет пылесос», «хочет power bank» или «хочет кроссовки». Он должен пройти ряд более мелких работ: разобраться, какой товар нужен, определить бюджет, выбрать бренд, сравнить предложения, убедиться в правильности решения, оформить заказ, получить товар. Каждый из этих этапов может быть сложным, тревожным или утомительным. Поэтому ценность e-commerce-сервиса определяется не только тем, что нужный товар можно купить, но и тем, насколько эффективно он помогает человеку пройти путь выбора и покупки.
Иван иллюстрирует это примером изучения немецкого языка, а затем переносит принцип на товары. Даже если базовая job одинаково звучит как «выучить немецкий» или «купить пылесос», люди могут хотеть разного результата и по-разному оценивать успех. В e-commerce это означает, что покупателю важны не абстрактные фильтры, карточки и подборки, а конкретные критерии: быстро ли он нашёл подходящий вариант, уверен ли в выборе, не переплатил ли, соответствует ли товар его ситуации, насколько легко его заказать и получить.
Илья Красинский развивает эту мысль через понятие discovery. По его словам, одна из главных проблем e-commerce — помочь человеку быстро обнаружить то, что ему подходит. Он приводит примеры с фильмами, парфюмом, холодильниками, кружками, стиральными машинами и обувью. Во всех этих случаях значительная часть покупателей не приходит с заранее определённым товаром. Они знают лишь общую цель или ситуацию: хотят посмотреть фильм с девушкой, отдохнуть вечером в одиночестве, выбрать аромат, купить технику, найти кроссовки. Если сервис не помогает перевести эту ситуацию в понятный выбор, человек долго ищет, устаёт и уходит.
В обсуждении e-commerce трактуется широко: Илья относит к нему не только интернет-магазины, но и сайты, сервисы, мобильные продукты, где есть много относительно известных продуктов и существующий спрос. В этом смысле банкинг, кинотеатры, маркетплейсы и сервисы с каталогом также сталкиваются с задачей помочь человеку выбрать и быстро получить ценность. Общая проблема состоит в том, что интерфейс часто строится вокруг структуры базы данных, ассортимента или представлений команды о «хороших товарах», а не вокруг сценария, в котором находится пользователь.
Jobs to Be Done в такой среде требует исследовать не только конечную покупку, но и путь к ней. Нужно понять, что именно запускает поиск, как пользователь формулирует критерии, что вызывает сомнение, где он сравнивает альтернативы, на каком шаге фрустрируется и как он понимает, что решение уже достаточно хорошее. Тогда продукт может перестроить не просто карточку товара или фильтр, а сам способ выполнения работы: сократить число шагов, дать нужную информацию в нужный момент, снизить неопределённость и помочь принять решение.
Подход также меняет понимание конкуренции. Если товары внешне похожи, то конкурентом становится не только другой продавец такого же товара, но и любой сервис, который быстрее и проще помогает человеку получить желаемый результат. В e-commerce преимущество получает не тот, кто просто расширил каталог или добавил очередную фичу, а тот, кто уменьшил усилия клиента на пути от неопределённой потребности к уверенной покупке и получению результата.
Иван Замесин объясняет, что в e-commerce покупка обычно состоит из последовательной цепочки работ. Человек хочет купить пылесос, power bank или другой товар, но для этого ему необходимо сделать множество промежуточных действий: разобраться в вариантах, понять бюджет, сравнить бренды и цены, оформить заказ, дождаться доставки. Иван оценивает число таких работ как значительное — порядка десяти-пятнадцати, в зависимости от товара и ситуации. С точки зрения JTBD это не единое действие «купить», а граф последовательных работ, через который клиент движется к конечному результату.
Ключевая особенность такой цепочки состоит в том, что основная ценность часто наступает только на последнем этапе. Пока товар не доставлен и не используется, человек вкладывает время, внимание, деньги и усилия в ожидании будущей ценности. Он ищет, сравнивает, принимает решения и взаимодействует с сервисом, но конечное подкрепление получает только тогда, когда пылесос доставлен, фильм выбран и просмотрен или иной желаемый результат реально достигнут.
Иван связывает этот момент с дофаминовым подкреплением. По его логике, именно в точке получения результата клиент подтверждает для себя, что ритейлер или маркетплейс был хорошим: товар получен, задача решена, ожидание оправдалось. Однако путь до этой точки влияет на восприятие не меньше самого финального результата. Чем дольше человек идёт к завершению работы, чем больше на пути непонимания, сомнений и фрустрации, тем выше вероятность, что он не дойдёт до покупки или в следующий раз выберет другое решение.
Поэтому конкурентное преимущество в e-commerce возникает, когда сервис даёт подкрепление на несколько шагов и быстрее во времени. Иван формулирует это как способность дать нужный результат «на три шага быстрее». Речь не обязательно только о физической скорости доставки. Ускорение может состоять в сокращении времени выбора, устранении лишнего сравнения, снижении тревоги, более быстром подтверждении правильности решения или помощи в понимании того, что именно подходит человеку. Если один сервис заставляет долго разбираться, а другой позволяет быстрее почувствовать движение к результату, второй выигрывает даже при сопоставимом ассортименте.
Илья Красинский подробно раскрывает, как это выглядит на практике. В кино-сервисе один и тот же человек может искать фильм в разных контекстах: посмотреть с девушкой, отдохнуть вечером после тяжёлого дня, провести время с друзьями и пивом. Если сервис не распознаёт или не помогает выразить эту ситуацию, пользователь может час искать фильм, устать и уйти. В этом случае проблема заключается не в отсутствии фильмов, а в том, что последовательная работа «выбрать фильм для конкретного вечера» слишком тяжела и не приводит к быстрому результату.
Аналогично работает выбор парфюма, техники, одежды и других товаров. Илья отмечает, что покупатели могут прийти за конкретной моделью, уже выбрав её через поисковую систему. Но большая доля аудитории такого выбора не сделала. Эти люди бродят по каталогу, кладут товары в корзину, сомневаются, перегружаются и уходят. Для них магазин должен решать не задачу «показать как можно больше товаров», а задачу «помочь определиться без избыточных усилий».
В этой логике время — не нейтральная характеристика интерфейса. Длительный путь до результата означает накопление фрустрации. Пользователь каждый раз должен заново удерживать в голове цель, обрабатывать информацию, сравнивать, бояться ошибки и преодолевать неопределённость. Если на этом пути нет промежуточной ценности, понятности и уверенности, его внимание переключается на другие способы потратить время. Именно поэтому анализ графа работ нужен не только для улучшения воронки, но и для понимания того, где продукт может сократить или устранить целые этапы клиентского усилия.
Иван далее связывает этот принцип с более общей механикой развития продуктов: продукты либо автоматизируют работы, либо сокращают их, либо полностью делают ненужными. Для e-commerce это означает, что сильное решение не обязательно должно заставить клиента лучше выполнять все этапы выбора вручную. Оно может убрать часть этапов, взять на себя сравнение, заранее сузить пространство выбора или предложить подходящее решение в момент возникновения контекста. Чем меньше клиенту приходится выполнять лишних работ до получения результата, тем сильнее ценность продукта.
Илья Красинский описывает discovery как одну из центральных проблем e-commerce. Под discovery в обсуждении понимается ситуация, когда человек ещё не знает точно, какой товар, фильм, услуга или вариант ему нужен, но хочет решить задачу. Проблема возникает, если сервис не помогает перейти от общей ситуации к конкретному подходящему выбору. Тогда пользователь вынужден самостоятельно исследовать каталог, интерпретировать характеристики, сравнивать варианты и угадывать, что соответствует его потребности.
Илья приводит пример кино-сервисов. Пользователь может прийти не за названием конкретного фильма, а с контекстом: хочется провести вечер с девушкой, отдохнуть после работы, посмотреть что-то с друзьями. Если сервис предлагает только большой каталог и не помогает быстро выбрать фильм для этой ситуации, человек может провести в поиске час, устать и уйти. Конверсия падает не потому, что в каталоге недостаточно контента, а потому, что работа по выбору слишком сложна и не приносит быстрого результата.
Та же логика действует в магазинах парфюма, техники, одежды и других категорий. Покупатель, который уже знает точный товар, может воспользоваться поиском и быстро завершить покупку. Однако, по словам Ильи, значительная часть людей приходит без готового решения. Они могут долго бродить по сайту, складывать что-то в корзину, переосмысливать выбор и в итоге уходить без покупки. Внешне это может выглядеть как обычный отвал в воронке, но причина лежит в неразрешённой job: человек не смог понять, что именно ему купить.
Отдельно Илья выделяет гипервыбор. Это ситуация, когда даже у пользователя с достаточно ясным намерением оказывается слишком много почти одинаковых вариантов. Он приводит пример с обувью: человек знает модель кед, которую любит, но сталкивается с несколькими очень похожими вариантами. Вместо облегчения выбора ассортимент создаёт дополнительную когнитивную нагрузку. Пользователь должен разобраться в различиях, понять, важны ли они, и принять решение, не чувствуя достаточной уверенности. В результате он устаёт и может отказаться от покупки, хотя изначально пришёл с высокой готовностью.
Илья связывает эти проблемы с тем, как обычно устроены поиск и каталог. По его оценке, поиском пользуется относительно небольшая доля людей, и часто он сделан плохо: не по job-сценариям, а по логике структуры базы данных. Разработчики или команды знают, какие товары есть в системе, как их можно сортировать и какие параметры доступны. Но пользователь не обязан знать эту структуру, терминологию, категории или «правильные» фильтры. Он приходит с жизненной ситуацией и собственным языком, а сервис заставляет его перевести эту ситуацию на язык внутренней товарной базы.
Илья также подчёркивает, что низкая конверсия в e-commerce может быть признаком серьёзной проблемы discovery. В транскрипте он высказывает ориентир: если средняя конверсия магазина в добавление товара в корзину ниже двух процентов, вероятно, существуют значительные сложности с discovery. Это не универсальная формула из внешнего источника, а практическое наблюдение, приведённое им в разговоре. Смысл наблюдения в том, что большая часть трафика может не доходить до действия не из-за цены или отсутствия спроса, а потому, что люди не смогли обнаружить подходящий товар и уверенно выбрать его.
Подход Jobs to Be Done предлагает анализировать не сам факт отказа, а предшествующий ему путь. Нужно понимать, с какой ситуацией человек пришёл, какую работу пытался выполнить, что уже знал, чего не знал, какие критерии использовал, какие альтернативы рассматривал и в какой момент потерял уверенность. Тогда оптимизацией становится не механическое добавление фильтров, карточек или рекламных блоков, а перепроектирование пути выбора так, чтобы он соответствовал реальной логике клиента.
Иван Замесин связывает это с последовательными работами и скоростью получения подкрепления. Discovery и гипервыбор увеличивают число работ, которые клиент должен выполнить до покупки, а также делают эти работы менее понятными. Вместо движения к результату возникает ощущение бесконечного поиска. Поэтому решение состоит не в том, чтобы дать человеку ещё больше вариантов, а в том, чтобы снизить количество лишних решений, сократить неопределённость и быстрее привести его к подходящему выбору.
Иван Замесин предлагает смотреть на конкуренцию шире, чем на набор прямых конкурентов в одной товарной категории. Он объясняет это на примере покупки кроссовок. На поверхности кажется, что магазин кроссовок конкурирует с другими магазинами кроссовок. Однако покупка обуви может быть частью более высокой работы — например, «кайфануть». Если человек хочет получить удовольствие, снять напряжение или приятно провести время, он может выполнить эту работу множеством альтернативных способов: пойти гулять, посмотреть сериал, заказать что-то вкусное, поиграть в Fortnite или купить кроссовки.
Из этого следует, что продукт конкурирует за ограниченный бюджет времени, внимания и денег, который клиент готов потратить на выполнение конкретной более высокой job. Если путь к покупке сложный, долгий, фрустрирующий или не даёт уверенности, человек не обязательно пойдёт к другому продавцу аналогичного товара. Он может вообще отказаться от покупки и выбрать другой способ получить эмоциональный или функциональный результат. Поэтому потеря клиента не всегда означает, что конкурент предложил тот же товар дешевле или удобнее. Иногда клиент просто переключился на совершенно другой сценарий.
Иван подчёркивает, что такая конкуренция неизбежна: продукт не может не участвовать в борьбе за ресурсы клиента. Даже если компания определяет рынок узко — например, как рынок одежды, кино, доставки или образования, — реальная жизнь пользователя шире этой категории. Человек сравнивает не только продукты внутри индустрии, но и разные варианты того, что сделать со своим вечером, деньгами, вниманием или желанием почувствовать себя лучше.
Этот взгляд усиливает значимость e-commerce discovery. Если интернет-магазин плохо помогает выбрать товар, то он проигрывает не только другому магазину с лучшим каталогом. Он проигрывает альтернативным занятиям, которые требуют меньше усилий и быстрее дают эмоциональное подкрепление. Когда покупка кроссовок превращается в длинный путь сравнения, сомнений и усталости, сериал или игра могут оказаться более лёгким способом выполнить высокоуровневую job «кайфануть». В этом смысле плохой пользовательский опыт снижает не только конверсию в конкретной товарной категории, но и вероятность того, что человек вообще продолжит выполнять исходный сценарий.
Логика применима и к другим обсуждённым кейсам. В обучении английскому человек может выбирать не только между разными школами, но и между тем, чтобы продолжить учиться, отложить задачу, самостоятельно смотреть сериалы, общаться с людьми, использовать переводчик или вообще не инвестировать время в язык прямо сейчас. В корпоративных продуктах руководитель может выбирать не только между сервисами, но и между тем, чтобы делегировать задачу, отложить её, решить привычным ручным способом или не заниматься ею до появления более сильного триггера. Поэтому продукт должен понимать не только своих категорийных конкурентов, но и то, как клиент в действительности может обходиться без него.
Иванова формулировка также показывает, почему важно исследовать Big Job и работы более высокого уровня. Если компания видит только нижний уровень — «купить кроссовки», «заказать доставку», «оформить продукт», — она может ошибочно улучшать локальные фичи. Если же она понимает, какую более широкую задачу человек пытается выполнить, становится видно, почему пользователь может уйти даже при наличии подходящего товара. Он уходит не обязательно потому, что товар плох, а потому, что способ достижения более важного результата оказался слишком тяжёлым или проиграл альтернативам.
Таким образом, прямые конкуренты — только часть конкурентного поля. Реальная конкуренция строится вокруг работ, которые клиент хочет выполнить, и вокруг ресурсов, которые он готов на это потратить. Чем лучше продукт помогает выполнить job быстро, понятно и с меньшими усилиями, тем выше вероятность, что он получит эти ресурсы вместо любых других альтернатив.
Илья Красинский и Иван Замесин используют обучение английскому как пример того, почему единая категория продукта не равна единому продукту для всех клиентов. На уровне сущности можно сказать: компания продаёт английский язык. Но в логике Jobs to Be Done «английский» не является достаточным описанием потребности. Люди приходят не за языком как таковым, а с разными ситуациями, триггерами, задачами, критериями результата и ограничениями. Поэтому один и тот же образовательный продукт может требовать разных сценариев, преподавателей, коммуникаций и способов продажи.
Илья перечисляет несколько различающихся контекстов. Студент приходит с одной job, предприниматель — с другой, опытный специалист или senior с деньгами — с третьей, IT-специалист — с четвёртой. Отдельными группами он упоминает людей из Казахстана и с Кавказа. При этом различия не сводятся к формальной географии или профессии. За этими группами стоят разные ситуации, ожидания, мотивации и способы принятия решения. Сам Илья говорит, что основных jobs может быть порядка десяти-двадцати, а более мелких — сто-двести, и они должны учитываться на разных этапах пути клиента.
Наиболее очевидное различие состоит в желаемом результате. Сдать IELTS или другой экзамен — это один тип продукта. Свободно общаться — другой. Смотреть сериалы — третий. Для каждого случая различаются критерии успеха. Экзаменационный сегмент может оценивать результат по баллу, сроку, требованиям поступления или подтверждению квалификации. Человеку, который хочет свободно общаться, может быть важнее снизить страх речи, понимать собеседника и уверенно разговаривать. Тому, кто хочет смотреть сериалы, важны восприятие речи, словарный запас и возможность понимать контент без постоянного перевода. Внешне все «изучают английский», но фактически хотят разных outcomes.
Иван развивает тот же принцип на примере немецкого языка после переезда в Германию. Формулировка «хочу выучить язык, чтобы найти работу» может скрывать множество сегментов. Для тревожного человека будет важен один формат. Для интроверта, которому тяжело общаться, — другой. Одному нужно быстро добиться минимального результата, другому подходит более долгий процесс. Одни могут позволить себе дорогое решение и ожидают высокого качества, другие ограничены в бюджете. У разных людей различаются не только ограничения, но и то, как они определяют успех: купить продукты без переводчика, сдать экзамен, устроиться на работу, начать свободно говорить.
Илья отмечает, что в случае Skyeng одно время процесс продаж стал слишком универсальным: «всем продавать английский». Предприниматель, который приходит учить язык, может не иметь времени на стандартный длинный путь, включая вводный урок, и быть готовым сразу оплатить обучение. Если его вести по процессу, рассчитанному на другой сегмент, компания создаёт ненужное трение. Это пример того, как единый процесс продаж ухудшает результат: клиенту предлагают не ту последовательность действий, которая соответствует его job и готовности купить.
Из этого вытекает необходимость сегментировать не только сообщение на рекламном объявлении или лендинге. Илья говорит, что сегментация должна происходить в рекламных каналах, на лендинге, после оставления заявки, в продажах и далее в продукте. Один сегмент может нуждаться в ином первом шаге, другой — в другом доказательстве ценности, третий — в ином формате обучения. Если же всем показать одинаковую программу, одинаковый оффер и одинаковый путь, часть клиентов либо не узнает себя в коммуникации, либо не дойдёт до покупки, либо не получит достаточную ценность после покупки.
Кейс Skysmart, который приводит Иван, показывает, что различаться должен не только маркетинг. После изучения jobs родителей и детей были изменены и продажи, и методология обучения. Для разных детей с разной степенью отставания и готовностью учиться требовались разные методики. То есть сегментация влияла одновременно на коммуникацию ценности и на её фактическую доставку. Это особенно важно: нельзя ограничиться красивой персонализацией рекламы, если сам продукт остаётся одинаковым и не соответствует критериям конкретной группы.
Таким образом, высказывание «людям нужен английский» в рамках встречи рассматривается как опасное упрощение. Оно фокусирует команду на сущности продукта, а не на результате клиента. Когда компания понимает реальные jobs, она может создавать разные сценарии, ценностные предложения, методики, каналы и процессы продаж. Тогда «один рынок английского» превращается в набор сегментов, каждый из которых по-своему оценивает, нужен ли ему продукт и является ли результат достаточно ценным.
Илья Красинский подчёркивает, что сегментация не должна быть разовым упражнением для создания портретов аудитории или подготовки одного лендинга. В контексте обучения английскому он прямо говорит, что клиентов необходимо сегментировать последовательно на разных этапах: в рекламных каналах, на лендинге, после оставления заявки, в продажах и в самом продукте. Его тезис состоит в том, что на каждом из этих этапов могут действовать разные закономерности, а метрики между сегментами способны заметно различаться.
На уровне рекламы сегментация нужна для того, чтобы человек вообще увидел релевантное сообщение. Разные сегменты приходят в разном контексте и с разными задачами, поэтому коммуникация «учите английский» или иной общий продуктовый посыл не обязательно активирует внимание. Если человек готовится к экзамену, хочет получить работу, переехал в другую страну, стремится общаться с иностранными коллегами или хочет смотреть сериалы, для него значимы разные обещания и критерии. Реклама должна не рассказывать обо всём продукте сразу, а попадать в ситуацию и желаемый результат конкретного сегмента.
На лендинге сегментация помогает человеку узнать себя в точке А и увидеть релевантную точку Б. В разборе лендингов Иван формулирует этот принцип через вопросы: узнаёт ли человек себя в своём контексте, описаны ли триггеры, эмоции, барьеры, желаемая жизнь после получения результата, есть ли ценность и способ прожить Aha-момент. Если общий лендинг говорит только о профессии, приложении, программе, функциях или формате, он может не попасть в важную для сегмента работу. Сегментация на лендинге означает не обязательно создание отдельной страницы для каждого портрета, а построение коммуникации вокруг конкретных jobs и критериев, по которым пользователь может понять: «Это про меня».
После оставления заявки сегментация нужна, потому что сам факт лида ещё не делает клиентов одинаковыми. В обсуждении Skyeng Илья указывает, что разные люди имеют различную готовность к покупке. Например, предприниматель может не иметь времени на вводный урок и быть готовым оплатить продукт сразу, тогда как другой сегмент нуждается в дополнительном знакомстве, диагностике, объяснении процесса или подтверждении результата. Если всех вести по единому сценарию, часть пользователей будет получать ненужные шаги и терять интерес.
В продажах сегментация становится основой персонализированной аргументации. Кейс Skysmart показывает, как это может быть организовано технологически. Sales-менеджер выясняет, какая задача есть у родителя в отношении занятий ребёнка с репетитором, выбирает соответствующую job в интерфейсе и получает скрипт, сгенерированный на основе ценности и цитат клиентов, уже получивших результат. Здесь сегментация не остаётся в исследовательском отчёте: она превращается в практический инструмент продажи. Разговор строится не вокруг универсального описания репетитора, а вокруг ценности для конкретной задачи клиента.
Наконец, сегментация должна продолжаться внутри самого продукта. Иван подчёркивает, что разные клиенты и пользователи могут требовать разной методологии, поскольку по-разному выполняют работу и по-разному оценивают результат. В Skysmart после исследования была доработана методология обучения: преподавателю давали более подходящий способ работы с конкретным ребёнком с учётом отставания, готовности учиться и особенностей родителя. Это показывает, что коммуникация без адаптации фактической ценности недостаточна. Если компания продала клиенту обещание, релевантное его job, но затем дала стандартный продукт, она рискует не выполнить обещание.
Илья также отмечает, что сегментация на разных этапах может давать «перекошенные» результаты метрик. Сегмент, который хорошо реагирует на рекламу, не обязательно так же хорошо конвертируется в заявку, продажу, активацию или удержание. И наоборот, менее массовый входной сегмент может давать лучший средний чек, удержание и экономику. Поэтому нельзя оценивать сегментацию только по одному показателю или одному этапу воронки. Нужно видеть путь целиком: кого привлекли, кто узнал себя в коммуникации, кто оставил заявку, какому сценарию продаж соответствовал, получил ли нужную ценность и продолжил ли пользоваться продуктом.
В этой модели сегментация является сквозной логикой управления опытом клиента. Она позволяет не просто «таргетировать аудиторию», а согласовать рекламу, лендинг, первый контакт, продажи, продуктовую механику и дальнейшее удержание вокруг одной и той же работы клиента. Если на каждом этапе сохраняется связь с job, контекстом, критериями и барьерами, компания может последовательно снижать трение и усиливать ценность. Если же сегментация заканчивается на уровне рекламы или портрета пользователя, далее система снова возвращается к универсальному продукту и усреднённой коммуникации.
Иван Замесин рассказывает о кейсе Феди Киреева из Skysmart как о примере того, что исследование jobs может менять не только тексты и продажи, но и саму поставку ценности. У Феди была задача продавать премиальных репетиторов. Вместо того чтобы начинать с предположений о том, какие преимущества нужно добавить в оффер, он провёл около сорока интервью с сегментами клиентов — родителями, которые выбирали занятия с репетиторами для детей.
В результате интервью были выявлены jobs и ценность, которую получают разные сегменты. Эта работа стала основой для изменения продаж. Поскольку все клиенты проходили через sales, была создана специальная административная система для менеджеров. В разговоре с лидом менеджер спрашивал, какие задачи родитель хочет решить с помощью занятий ребёнка с репетитором. Затем он выбирал соответствующую job в интерфейсе и запускал генерацию скрипта.
Скрипт формировался ChatGPT на основе той ценности, которую уже получили другие клиенты с похожей job. Важным элементом были не абстрактные маркетинговые формулировки, а клиентские цитаты о результате. То есть менеджер не просто рассказывал про репетиторов, платформу или пакет занятий. Он получал возможность вести разговор на языке задачи родителя и описывать результат через опыт людей, которые уже прошли похожий путь.
Иван называет результат: средний чек вырос в три с половиной раза. Он связывает рост не с одной только автоматизацией продаж, а с тем, что коммуникация стала строиться вокруг job. Вместо универсального оффера клиент слышал аргументацию, релевантную конкретной цели: например, тому, что родитель хотел изменить в обучении ребёнка, какую проблему преодолеть, какого результата достичь и почему стандартный подход мог быть недостаточен.
При этом Иван отдельно подчёркивает, что кейс не свёлся к более точному скрипту. Федя также переделал методологию обучения. Выяснилось, что детям с разным отставанием, разной способностью и готовностью учиться нужны разные подходы. Важным становился не только сам ребёнок, но и контекст родителя, его ожидания и критерии того, что будет считаться хорошим результатом. Поэтому преподавателю требовалась методология, адаптированная к конкретной ситуации, а не единый стандартный процесс для всех.
Илья Красинский поддерживает вывод Ивана и подчёркивает, что подобные результаты показывают ошибочность представления об одном универсальном продукте. Если сегменты отличаются jobs, то они могут нуждаться в разных сценариях, разных преподавателях, разной аргументации и разных траекториях достижения результата. В этой логике обучение нельзя описать просто как «продажу репетитора» или «продажу английского»: нужно понимать, на какую работу клиент нанимает решение и какие критерии применяет к его качеству.
Кейс Skysmart также демонстрирует последовательность перехода от исследования к бизнес-результату. Сначала собираются данные о сегментах, их работах и ценности. Затем эти знания переводятся в продажи через диагностику job и персонализированную аргументацию. После этого меняется поставка ценности в самом продукте — методика обучения и работа преподавателя. Рост среднего чека в 3,5 раза в изложении Ивана является результатом именно этой связки: коммуникация попадает в конкретную job, а продукт способен дать соответствующую ценность.
Этот пример важен и потому, что он опровергает упрощённый тезис, будто сегментация нужна только для более точной рекламы. В кейсе сегментация стала способом пересобрать всю цепочку: от понимания клиента до процесса продаж и реального обучения. Если бы менялась только коммуникация, а методология оставалась одинаковой для всех, продукт мог бы продать обещание, но не выполнить его. Если бы менялся только образовательный процесс без изменений в продажах, часть подходящих клиентов могла бы не понять ценность до оплаты. Эффект возникает, когда обе части синхронизированы.
Иван Замесин связывает распространённое убеждение «людям нужен наш продукт» с фокусировкой на сущности самого продукта. Команда создаёт или планирует определённое решение, начинает думать о его экранах, функциях, макетах, технологиях и способах продаж — и постепенно эта сущность становится центром объяснительной модели. Отсюда возникает простая причинно-следственная связь: если продукт существует или кажется хорошей идеей, значит, людям он должен быть нужен. Иван считает такую связь более простой и очевидной, чем анализ реальных работ клиентов, поэтому она легко закрепляется в мышлении.
Илья Красинский формулирует это ещё жёстче: предприниматели и топ-менеджеры часто думают по себе. У них есть личный опыт, собственные представления о мире, привычные процессы и набор наблюдений из их окружения. Из этого опыта возникает идея: «всем нужен английский», «всем нужна CRM», «всем нужен чекап», «всем нужен новый B2B-маркетплейс» или иной продукт. Проблема не в том, что такие идеи всегда ложны, а в том, что они часто не ставятся под сомнение. Команда начинает строить решение, не проверив, существует ли у конкретных сегментов достаточно важная job и готовы ли они менять текущий способ её выполнения.
В разговоре обсуждается, что люди часто живут внутри уже созданных систем: компаний, процессов, продуктов, организационных привычек. Эти системы не являются природными, но человек может воспринимать их как естественный и универсальный порядок вещей. Он видит, как устроена его компания, как работают знакомые ему процессы, какие продукты используют люди вокруг, — и предполагает, что во внешнем мире всё устроено аналогично. Поэтому его собственная объяснительная модель подменяет исследование реальных пользователей.
Иван добавляет, что такая модель может сохраняться, потому что иногда она действительно даёт результат. Компания может быть создана на нескольких сильных исходных решениях, принятых компетентными людьми, а затем продолжать расти. Это создаёт впечатление, что фокус на сущности продукта, фичах и внутренней логике компании является правильным подходом. Но успешный результат не обязательно подтверждает, что каждый последующий продуктовый выбор был обоснованным или что команда понимает реальные jobs клиентов.
Илья приводит пример с CRM, чтобы показать разрыв между сущностью и задачей. Он говорит, что продавцам не нужна CRM сама по себе: никто не любит заносить информацию в систему и делать дополнительную работу. Однако человеку могут быть нужны другие результаты: фокусироваться на лидах, уже готовых платить, видеть застой в сделках, понимать, какой этап воронки нужно оптимизировать, обнаруживать ошибки в работе sales-менеджеров, предотвращать потерю и забывание сделок. Если компания говорит «мы делаем CRM», она продаёт сущность. Если она понимает jobs, она может проектировать решение вокруг конкретного результата и даже прийти к выводу, что часть привычных действий пользователя нужно устранить, а не заставить его выполнять лучше.
Та же проблема возникает с фичами. В споре о Rick.ai Иван формулирует, что фича — это способ или форма доставки ценности, а не ценность сама по себе. Илья соглашается, что код, автоматизация, графы воронок, отчёты и другие возможности продукта не являются тем, за что клиент в действительности платит. Клиенту важен результат: например, иметь аргументированный и наглядный ответ на встрече о том, почему лиды не конвертировались. Автоматизация, команда заботы или нейросеть могут быть разными способами доставить эту ценность. Когда команда фокусируется на продуктовой сущности, она рискует считать сам механизм ценностью.
Иван связывает эту ошибку с тем, как бизнес-руководители инициируют продукты. Руководитель может сказать: «У нас есть технологии, давайте сделаем B2B-продукт», «Все делают чекапы, давайте тоже», «Мы сделаем новый сервис». Такое решение задаёт всей команде рамку: надо делать продукт. Дизайнеры, продакты и разработчики начинают производить фичи, потому что работа сформулирована как создание сущности. Причинно-следственная связь от задач клиента к ценности и бизнес-результату оказывается «в тумане», а видимой становится только ближайшая часть — то, что можно построить.
Альтернативой, которую предлагают спикеры, является перенос фокуса на job и желаемый результат. Вместо вопроса «нужен ли людям английский, CRM, приложение или чекап?» нужно исследовать, в каких ситуациях люди находятся, чего хотят добиться, по каким критериям оценивают успех, как сейчас выполняют работу, что их не устраивает и какие альтернативы уже используют. Тогда продукт перестаёт быть данностью, а становится гипотезой о способе более эффективно выполнить работу клиента.
Иван Замесин объясняет, что успешная компания способна продолжать расти, даже если значительная часть решений отдельных сотрудников или команд слаба. По его мнению, в успешной организации часто небольшой процент сотрудников обеспечивает существенную долю общего результата. Эти люди могут принимать сильные решения, создавать фундамент продукта, находить работающие сегменты, строить удачные каналы или формировать эффективные механики. Однако остальные сотрудники не обязательно наследуют их ментальную модель и не обязательно понимают, почему система изначально заработала.
Вместо этого последующие команды могут делать то, что им кажется понятным: пилить фичи, следовать существующим процессам, повторять внешние признаки прошлых успехов. Иван говорит, что запаса прочности исходных решений и решений компетентных людей может быть достаточно, чтобы компания продолжала расти даже на фоне неудачных решений. Поэтому сам по себе рост не доказывает, что каждый продуктовый эксперимент, новая функция или улучшение метрики действительно создали ценность.
Илья Красинский развивает эту мысль через анализ когорт. Он рассказывает, что изучал компании, в том числе крупные банки, телеком-операторов и другие корпоративные организации, где в резюме сотрудников могли быть указаны улучшения определённых метрик. Однако при рассмотрении когорт иногда было видно, что работа конкретного человека в первой сессии ухудшала показатели и снижала количество новых клиентов. На уровне общей динамики это могло быть незаметно, потому что положительный вклад старых когорт перекрывал ухудшение новых.
Илья описывает механизм через метафору ванны: если в бизнес уже поступает устойчивый поток клиентов, а «труба» не сливает воду, ванна продолжает наполняться. В масштабированном бизнесе, особенно с частотными B2B- или B2C-сценариями, рост может происходить за счёт уже работающих когорт, существующего спроса, бренда, дистрибуции, привычки пользователей или накопленных эффектов. По его словам, при такой структуре бизнес способен вырасти на 30–50 процентов в год даже в ситуации, когда ничего существенного не улучшать и оставить лишь минимальную работу команды заботы.
Из-за этого возникает ошибка атрибуции. Сотрудник видит, что компания росла в период его работы, и делает вывод, что рост был следствием его решений. Руководители могут делать аналогичный вывод о собственных продуктовых идеях. Если новый продукт или направление формально запустились в успешной компании, успех приписывается самому факту появления продукта, хотя реальный результат мог возникнуть благодаря работе сильного дизайнера, маркетолога, разработчика, существующей аудитории или уже заложенной ранее модели.
Иван ранее описывал похожий механизм на примере запуска чекапа. Руководитель может придумать продукт, а в команде найдётся компетентный человек, который интуитивно или осознанно сделает решение правильно. Продукт сработает, но бизнес сделает неверный вывод: «Мы придумали чекап — значит, именно наша первоначальная идея была правильной». После этого такая модель принятия решений закрепляется. Руководитель снова начинает запускать продукты от сущности, игнорируя необходимость сегментации и исследования, потому что прошлый успех кажется подтверждением его интуиции.
Поэтому в обсуждении рост компании рассматривается как ненадёжный индикатор качества конкретного продуктового решения. Для оценки нужно отделять вклад новых когорт, конкретных сегментов, отдельных изменений и уже существующих источников роста. Иначе организация может долго не замечать, что новые решения ухудшают продукт, потому что общий результат поддерживается накопленным запасом прочности.
Этот тезис также объясняет, почему в компаниях может сохраняться фичевая культура. Если плохие продуктовые решения не приводят к немедленному провалу, у команды не возникает сильной обратной связи. Люди продолжают верить, что работают правильно, поскольку видят положительные общие цифры. Только более детальная диагностика — через когорты, сегменты, реальные jobs, ценность и конкретные воронки — позволяет увидеть, какие действия действительно создают результат, а какие маскируются общим ростом бизнеса.
Иван Замесин предлагает начинать JTBD-работу не с перестройки продукта, смены бизнес-модели или поиска «следующей большой идеи», а с исследования уже существующих платящих клиентов. Такой старт применим, когда продукт уже существует и «всё хорошо продаётся»: у компании есть клиентская база, реальные оплаты и, следовательно, доступ к людям, которые уже подтвердили ценность продукта своим поведением. Это позволяет не строить работу на предположениях о рынке, а извлекать информацию из фактического опыта использования и покупки.
Первый фокус, по Ивану, — сегментация текущих клиентов. В первую очередь клиентов следует разделять по jobs, то есть по задачам, ради которых они наняли продукт; дополнительные признаки используются во вторую очередь. Илья Красинский уточняет, что такой подход принципиально отличается от попытки продавать один и тот же продукт всем. Сам факт продукта уже частично сегментирует аудиторию: среди пришедших есть те, кому текущая ценность подходит, те, кому она подходит не полностью, и те, для кого продукт в принципе неудачен или недоступен. Задача первых недель — не придумать универсальный портрет пользователя, а понять, какие реальные сегменты уже покупают, за что именно они платят и где для них находится ценность.
Иван рекомендует начать с более маржинальных сегментов и применить сегментацию Шона Эллиса, чтобы найти тех, кто уже по-настоящему ценит продукт. После этого нужно провести интервью с платящими клиентами. В интервью исследуются Core Job и Big Job, ценность, которую клиент получил, барьеры, Aha-моменты и путь выполнения работ до покупки решения. Практический смысл такого исследования — узнать не просто «кто клиент», а что он пытается сделать, как оценивает успешность результата, какие альтернативы использовал, где испытывал трудности и почему продукт оказался предпочтительнее.
Иван называет этот тип исследования «суперзолотым» и говорит, что по его опыту и опыту выпускников его тренинга оно стабильно работает: может привести к смещению в более сильный сегмент, росту конверсии, снижению отвалов, росту среднего чека или улучшению коммуникации. Он оценивает вероятность заметного улучшения метрик от такой работы в 60–70%. При этом речь не о гарантии любого результата, а о сравнительно надёжном первом шаге: команда изучает уже подтверждённый спрос и получает основания точнее привлекать, конвертировать, активировать и удерживать клиентов.
Илья дополняет, что фреймворк в этом контексте нужен не как интеллектуальная надстройка и не как объект продажи команде или руководителю. Методология нужна для воспроизводимой последовательности действий: вместо того чтобы снова обсуждать абстрактный продукт или набор фич, команда получает способ увидеть различия между клиентами, проверить их на данных и сосредоточить ресурсы на тех, кто уже получает либо способен получить наибольшую ценность.
Иван Замесин разделяет два направления JTBD-работы: локальный и глобальный оптимум. Локальный оптимум начинается с существующего продукта и текущих платящих клиентов. Команда не выходит за пределы уже работающих сегментов, не меняет радикально бизнес-модель, не уходит в другую страну и не начинает конкурировать за принципиально иные работы. Вместо этого она детальнее изучает, кто уже покупает продукт, какие jobs выполняет, какую ценность получает и какие препятствия проходит на пути к покупке и использованию.
Локальная оптимизация направлена на более точную работу внутри уже подтверждённого рынка. Иван описывает её как возможность лучше привлекать существующие сегменты, точнее коммуницировать ценность, улучшать воронку, повышать конверсию, помогать клиенту быстрее активировать ценность и снижать отток. Продукт при этом не обязан меняться полностью: иногда достаточно улучшить сообщение на лендинге, канал привлечения, сценарий продажи или способ доставки ценности в нужный момент. Главная характеристика такого подхода — сравнительно низкий риск: компания изучает людей, которые уже платят, поэтому вероятность, что инвестиция даст эффект, выше.
Глобальный оптимум, напротив, предполагает выход за границы нынешних сегментов. В качестве примера Иван приводит страховую компанию. Локальный путь для неё — лучше узнать нынешних B2B- и B2C-клиентов, которым уже продаются страховые продукты, и точнее работать с ними. Глобальный путь — поговорить с клиентами конкурирующих страховых компаний или вообще искать другие работы за пределами текущей категории страхования: понять, какие другие задачи других людей компания могла бы выполнять, возможно, с иной бизнес-моделью.
Цель глобального поиска — найти более крупные, более денежные или более частотные сегменты, а также возможности изменить сам способ заработка. Именно поэтому такой подход потенциально способен дать кратный рост выручки, а не только улучшение отдельных метрик в существующей воронке. Однако Иван подчёркивает, что вместе с потенциалом растёт и риск: вероятность того, что крупная инвестиция в новый рынок, новый сегмент или новую модель не сработает, существенно выше, чем при улучшении уже существующего продукта для существующей аудитории.
Таким образом, отличие двух подходов не в том, что один «правильный», а другой нет. Они различаются объектом поиска, горизонтом изменений и ценой ошибки. Локальная работа отвечает на вопрос, как эффективнее развивать уже работающую систему. Глобальная — может ли компания найти новый источник роста, изменив сегмент, работу, бизнес-модель или рынок. Выбор между ними зависит от задачи продукта и готовности бизнеса принимать риск.
Иван Замесин предлагает строить интервью с платящими клиентами вокруг структуры выполняемых ими работ, а не вокруг абстрактного мнения о продукте. Важно узнать, какие Core Job и Big Job клиент выполняет с помощью продукта. Core Job в его формулировке может быть не одной: у клиента может быть три, четыре, пять или шесть ключевых работ. Они могут быть последовательными, когда одна работа ведёт к следующей, или частотными, когда одна и та же задача возникает регулярно.
Для каждой выявленной работы Иван предлагает уточнять критерии. Недостаточно зафиксировать формулу вроде «хочу купить квартиру» или «хочу нанять data scientist». Нужно понять, что для конкретного человека означает хороший результат. В примере с покупкой квартиры критерием может быть возможность сдавать её в аренду дороже ипотечного платежа. Именно через критерии клиент оценивает ценность решения и сравнивает альтернативы. Без этого команда может узнать название задачи, но не понять, почему один продукт воспринимается как хороший, а другой — как недостаточный.
Отдельный блок вопросов должен быть посвящён ценности. Иван формулирует ценность как более эффективное выполнение клиентской работы. Поэтому важно спрашивать не только, чем человек пользовался, но и что изменилось благодаря продукту: что стало быстрее, понятнее, надёжнее, доступнее, проще или менее рискованно. Важно выяснить, какую ценность клиент видит сам и в каких выражениях он её описывает. Эти формулировки затем могут стать основой для коммуникации на лендинге, в продажах и в самом продукте.
Также Иван предлагает узнавать барьеры — если клиент их помнит. Это препятствия, страхи, тревоги, сомнения или неудобства, которые возникали до выбора продукта или в процессе выполнения работы. В его логике проблема не существует сама по себе: она возникает, когда клиент уже нанял некоторое решение для выполнения работы, но решение выполнило её хуже ожиданий. Поэтому исследование барьеров должно связывать трудность с конкретной работой, текущим способом её выполнения и ожиданиями человека от результата.
Следующий важный вопрос — про Aha-момент. Нужно выяснить, в какой момент клиент увидел, что решение действительно работает и что он получает обещанную ценность. Для образовательного продукта это может быть момент, когда человек начинает уверенно практиковать и видит, что способен работать с клиентами. Для другого продукта это может быть первый полученный отчёт, первый успешно закрытый кейс или первое устранённое препятствие. Знание Aha-момента помогает не только анализировать прошлый опыт клиента, но и проектировать активацию: дать человеку прожить подтверждение ценности как можно раньше.
Наконец, Иван рекомендует просить клиента подробно восстановить последовательность работ от возникновения потребности до покупки решения. Его пример: если компания продаёт ремонт, нужно спросить, что человек делал шаг за шагом с момента решения переехать в новую квартиру до покупки конкретного продукта. Такой разговор раскрывает граф работ: как клиент ориентировался, выбирал, сравнивал, искал информацию, сталкивался с барьерами и принимал решение. Это позволяет увидеть, где продукт уже помогает, где он появляется слишком поздно, какую ценность можно отдать раньше и какие части пути остаются неудобными.
По Ивану Замесину, исследование текущих клиентов работает потому, что переводит развитие продукта с уровня общих предположений на уровень подтверждённых сегментов и конкретных работ. Если компания изучает людей, которые уже платят, она не просто собирает отзывы. Она узнаёт, какие задачи фактически приводят к покупке, какую ценность клиенты получают, какие критерии используют для оценки результата и какие барьеры им пришлось преодолеть. Это создаёт основание для более точных продуктовых и коммуникационных решений.
Конверсия может расти потому, что компания начинает привлекать и убеждать клиентов на языке их реальных jobs, а не на языке собственных фич. Иван подчёркивает, что продуктовая фича — это форма доставки ценности, но не сама ценность. Когда команда знает, какую работу клиент пытается выполнить, какой контекст и триггер её запускают и что для клиента считается хорошим результатом, она может точнее сформулировать обещание. Вместо сообщения о функциях появляется коммуникация о том, что клиент сможет сделать эффективнее, за счёт чего это произойдёт и какие страхи будут сняты.
Удержание улучшается, когда продукт не ограничивается продажей, а помогает клиенту получить ценность в процессе выполнения работы. Иван говорит о необходимости лучше активировать ценность и удерживать клиентов в рамках локальной оптимизации. Если известно, какой Aha-момент подтверждает полезность продукта, команда может приблизить его, сделать заметнее или встроить в пользовательский путь. Если известно, на каких этапах графа работ клиент испытывает трудности, продукт способен сопровождать его не только в финальной точке, но и раньше — там, где возникает неопределённость, фрустрация или риск отказа.
Средний чек может расти, когда сегментация обнаруживает более ценные или более маржинальные группы клиентов, а также когда продукт точнее адаптируется к их задачам. Показательный кейс, который приводит Иван, связан со Skysmart. После интервью с сегментами репетиторов были выявлены jobs и ценность для родителей. Затем в продажах появилась система, где sales выяснял, какая задача стоит у конкретного лида, выбирал её и генерировал соответствующий скрипт на основе ценностных формулировок клиентов. Одновременно была доработана методология обучения под отставание ребёнка, его готовность учиться и ситуацию родителя. По словам Ивана, сочетание точной коммуникации и адаптированной ценности увеличило средний чек в 3,5 раза.
Илья Красинский подчёркивает, что сегментация должна происходить на всём пути, а не только в одном месте: в рекламных каналах, на лендинге, после оставления заявки, в продажах и после покупки. Причина в том, что на разных этапах проявляются разные различия между сегментами и разные перекосы метрик. Исследование текущих клиентов позволяет увидеть эти различия не как разрозненные проблемы воронки, а как следствие того, что разным людям нужны разные сценарии, коммуникация, преподаватели, условия или способы доставки одной и той же базовой ценности.
В результате ценность исследования состоит не в накоплении информации о пользователях как таковой. Как формулирует Иван, главная ценность сегментации — появление пространства стратегических решений, которое ранее было недоступно. Команда может точнее выбирать, на кого работать, какие части опыта улучшать, какую ценность усиливать, как её объяснять и где не тратить ресурсы.
Илья Красинский описывает ABCD/X-сегментацию как практический способ не расходовать время продаж и команды на клиентов, которые не дают адекватной отдачи. По его словам, этот фреймворк появился не как умозрительная схема, а из большого числа разборов B2B-продаж, пайплайнов в amoCRM и Битрикс24, а также работы со стартапами во ФРИИ. Повторяющаяся проблема состояла в том, что компании пытались продавать всем один и тот же продукт, из-за чего получали низкие конверсии и тратили много усилий на заведомо слабые сделки.
Сегмент A у Ильи — это клиенты, которым продукт уже подходит и которые покупают практически сразу. Сам факт наличия продукта уже выделяет эту аудиторию: у неё активирована соответствующая job, она понимает необходимость решения и готова вкладывать внимание, время или деньги. Илья подчёркивает, что такие клиенты нередко остаются без должного внимания именно потому, что они уже довольны и не создают много шума. Компания может быть чрезмерно занята трудными лидами, хотя наиболее перспективный сегмент уже существует в её клиентской базе.
Сегмент B включает клиентов, которым продукт подходит не полностью. У них может быть важная незакрытая смежная работа: например, нужны корпоративные договоры, требования безопасности или другие условия, без которых основная ценность не превращается в покупку. Это не обязательно плохие клиенты. Однако работа с ними требует понимать, какие именно jobs не закрыты, сколько будет стоить их закрытие и оправдана ли такая доработка с точки зрения экономики.
Сегмент C Илья связывает с клиентами, которые могли купить по ошибке, с которыми компания не хочет работать либо плохо умеет работать. В репликах из чата также упоминается категория клиентов, которые «выносят мозг» и не покупают; Илья соотносит её со своим C-сегментом. Сегмент D — это те, кто не может позволить себе продукт из-за нехватки денег. Илья особенно выделяет стартапы и других клиентов, которые хотят получить продукт очень дёшево, требуют много внимания, но экономически невыгодны в обслуживании.
Отдельно Илья выделяет X-сегмент — компании или клиентов, до которых продукт ещё не дорос. Для работы с ними может не хватать бренда, репутации, имени или иных условий доверия. Смысл этого выделения не в том, чтобы считать такой сегмент плохим навсегда, а в том, чтобы не путать стратегически привлекательную, но пока недоступную аудиторию с текущей реальной возможностью продаж.
Практический результат ABCD/X-сегментации — показать команде, что время системно расходуется на B, C и D, тогда как сегмент A может оставаться недообслуженным. Фреймворк должен помочь перенести фокус с попытки «дожать всех» на осознанную работу с теми, у кого уже есть подходящая задача, готовность покупать и совпадение с текущей ценностью продукта. Вместе с тем Илья сам критично относится к этой версии модели: он считает, что не успел её доработать до достаточной воспроизводимости и не добавил необходимые кросс-проверки, из-за чего разные люди могут классифицировать клиентов по-разному.
Илья Красинский определяет методологию как последовательность действий, которая воспроизводимо даёт предсказуемый результат. В этой логике фреймворк ценен не названием, не количеством слайдов и не интеллектуальной привлекательностью. Он нужен, когда команде требуется получать результат не случайно и не только благодаря одному сильному специалисту, а в большом числе повторяющихся ситуаций. Илья связывает эту потребность с опытом ФРИИ: когда через программы регулярно проходят десятки и сотни команд, невозможно опираться только на индивидуальный здравый смысл или уникальную интуицию.
Он подчёркивает, что работа без формализованных методологий возможна: в любой компании уже существуют свои способы принятия решений, даже если они не названы фреймворками. Фраза «у нас так принято» фактически означает, что в организации есть собственная методология. Но различие состоит в степени проверки. Одни методы уже проверены временем и многими людьми, другие сложились внутри конкретной компании случайно или на основе единичного удачного опыта и могут не переноситься на другие команды и обстоятельства.
Илья приводит собственный ABCD/X-фреймворк как пример незавершённой воспроизводимости. Хотя модель выросла из большого количества сделок и разборов, он признаёт, что не добавил в неё кросс-чеки. В результате разные люди применяют её по-разному: один эксперт с опытом может получить качественный результат, а другой человек, увидевший выступление или ролик, может интерпретировать подход иначе и начать делать «что-то своё». Для Ильи это признак слабости фреймворка, а не просто неизбежная вариативность.
Иван Замесин поддерживает сам принцип методологии как способа сделать продуктовую работу менее тревожной и более управляемой. В финале встречи он описывает собственную профессиональную проблему: долгое время он не понимал, что именно нужно делать при высокой ответственности, ожиданиях и неопределённости. Кейсы не всегда переносились на его ситуацию, а общие фреймворки не отвечали на вопрос, как приложить их к конкретной задаче. Поэтому его мотивация — собрать подход, который даёт более ясный ответ на вопрос, как делать продукт.
Илья также объясняет, почему он опирается на работу Ивана: по его мнению, тот глубоко проработал большое число вопросов и добился достаточной воспроизводимости результатов. Илья не воспринимает это как необходимость выучить все слайды, но считает важным иметь систему, к которой можно обратиться в ситуации неопределённости и получить проверенный ход рассуждений. В этом смысле воспроизводимость — это не механическое выполнение инструкции, а возможность для разных участников команды использовать общий язык, одинаково понимать причинно-следственные связи и не возвращаться каждый раз к изобретению базовых принципов с нуля.
Иван Замесин предлагает рассматривать discovery не как самостоятельный поиск «интересных инсайтов», а как этап решения конкретной бизнес-задачи. По его формулировке, компания всегда имеет некоторую цель: вырастить продукт, вывести его на рынок, увеличить ценность, отстроиться от конкурента, повысить конверсию или оплату. Discovery должен быть подчинён этой цели. Поэтому искать нужно не просто людей, мнения, гипотезы или деньги в абстрактном виде, а возможность реализовать стратегию, которая способна решить исходную задачу.
Иван сначала формулирует распространённый вопрос: что именно команда ищет в discovery? В ответах участников появляются «люди», «гипотезы», «инсайты» и «деньги». Он уточняет, что деньги действительно являются конечным мотивом, но заработать их можно через поиск очень конкретных возможностей. Если бизнес-задача — масштабировать работающий продукт, discovery нужен для определения, какая из возможных стратегий масштабирования имеет основания сработать на реальном рынке.
В основе такого поиска лежит знание сегментов, выделенных прежде всего по jobs, а затем по дополнительным признакам, включая демографию. Второй опорой становится граф работ: понимание того, какие последовательные действия выполняют люди, как они их выполняют сейчас, где испытывают неудовлетворённость и какие критерии применяют. Эти знания открывают набор стратегий. Не нужно начинать с открытого вопроса «что нам придумать?». Следует сначала определить бизнес-задачу, затем перечислить стратегии, которые теоретически способны её решить, и только потом собирать информацию, необходимую для проверки каждой стратегии.
Иван описывает логику как новую причинно-следственную связь: сначала фиксируется цель или бизнес-задача; затем рассматриваются стратегии, которые могут выполнить эту задачу в теории; затем запускается поиск данных, позволяющих реализовать хотя бы одну из стратегий. Так discovery превращается в целевой поиск. Например, если есть гипотеза о росте через другой сегмент, нужно исследовать наличие такого сегмента, его задачи, бюджет, частотность работ и способы выполнения. Если рассматривается переход в B2B, надо искать подтверждение существования людей и организаций, которые готовы покупать соответствующую ценность.
Илья Красинский развивает эту мысль через тезис о фреймворках. По его мнению, метод нужен именно для получения воспроизводимого результата: он помогает не обсуждать стратегию на абстрактной сессии, а видеть карту вариантов и оценивать их на основе характеристик сегментов. В такой системе discovery не заканчивается наблюдением «мы узнали что-то новое». Его ценность возникает тогда, когда новая информация даёт команде основание выбрать действие: сфокусироваться, сместиться в иной сегмент, поменять способ доставки ценности, расширить рынок или отказаться от невыгодного направления.
Иван Замесин говорит, что после понимания сегментов и графов работ у компании появляется набор конкретных стратегий масштабирования. Их смысл в том, что рост перестаёт выглядеть как абстрактное требование «сделать больше выручки». Команда может видеть разные способы развития, связанные с тем, на кого она работает, какие работы выполняет, в какой модели это делает и по каким критериям клиент выбирает решение.
Первая стратегия — добавить новый сегмент. В этом случае компания находит ещё одну группу людей, у которой есть похожая или совместимая работа, и начинает обслуживать её своим продуктом. Иван приводит пример Яндекс Такси: сервис, который перевозит людей в Москве для определённой задачи, начинает перевозить таких же людей в Санкт-Петербурге. Это расширение на другой сегмент, связанный с географией, при сохранении базовой работы и модели услуги.
Вторая стратегия — сместиться в другой сегмент, где ценность продукта выше или экономика лучше. Иван рассказывает о Феде Кирееве, который занимался продажей и допродажей услуг отелей. Он обнаружил сегмент сетей отелей, для коммерческого директора которых его предложение было существенно ценнее: у такого клиента больше отелей и больше услуг, а значит, выше потенциальный margin per user. Вместо распыления на прежнюю аудиторию произошёл фокус на сегменте, способном дать кратный рост выручки.
Третья стратегия — переход или расширение между B2B и B2C. Компания может использовать имеющиеся технологии, команду или продукт для выполнения похожих работ в другой модели потребления. Иван оговаривает, что это не должно быть произвольной попыткой «пойти в B2B» или «сделать B2C». Необходимо проверить, существуют ли люди и организации, для которых соответствующая работа действительно важна и которые могут стать платящим сегментом.
Четвёртая стратегия — выполнять другие работы для уже существующего человека. Иван формулирует это через пример такси: сервис не только везёт клиента из точки А в точку Б, но может начать привозить ему продукты. Клиент уже известен, доступ к нему существует, однако расширяется набор jobs, которые компания способна для него выполнять. Это не обязательно продажа случайной дополнительной услуги: смысл в том, чтобы искать другие реальные работы человека в связанных контекстах.
Пятая стратегия — смещение по цене. Один и тот же общий тип работы может выполняться для людей с разными требованиями к качеству, комфорту, статусу или риску. Сегментация позволяет увидеть, где продукт может стать более доступным, а где — премиальным, если у разных сегментов различаются критерии успешного результата и готовность платить.
Наконец, географическое расширение в логике Ивана не является просто масштабированием присутствия. Оно становится одной из форм добавления сегмента: компания проверяет, есть ли в новой географии люди с сопоставимой job, контекстом и возможностью пользоваться текущим решением. Во всех этих стратегиях сегментация выступает не как отчёт о клиентах, а как карта вариантов роста. Она помогает определить, куда именно можно двигаться, что исследовать перед движением и какие различия между сегментами будут определять экономику нового направления.
Иван Замесин использует Яндекс Такси как пример того, что одна и та же общая работа — добраться из точки А в точку Б — может по-разному выполняться для разных сегментов. В базовом варианте сервис перевозит людей недорого, то есть обслуживает клиентов, для которых существенны доступность и выполнение основной транспортной задачи. Это соответствует тарифу «Эконом»: клиенту важно доехать, и ключевым критерием может быть цена.
Дальше сервис может не менять общую работу полностью, а найти людей, которые хотят выполнить её по другим критериям. Иван описывает пассажиров, которым нужна более комфортная или статусная машина, а также водитель, который не будет конфликтовать, если клиент попросит выключить музыку или изменить температуру. Так появляется тариф «Комфорт». Работа «добраться из точки А в точку Б» сохраняется, но критерии хорошего выполнения меняются: важными становятся комфорт, предсказуемость взаимодействия, уровень автомобиля и отношение водителя.
Следующий шаг — ещё более статусный формат поездки. Здесь возникает сегмент, для которого базовая транспортная функция недостаточна: ценность определяется не только перемещением, но и статусностью, качеством сервиса или соответствием определённому образу ситуации. Тем самым пример показывает, что сегментация не сводится к поиску новых демографических групп. Можно обнаружить несколько сегментов вокруг одной и той же работы, если люди хотят выполнить её с разными критериями и готовы платить за различия в результате.
Илья Красинский поддерживает эту логику, называя набор стратегий «картой». По его словам, вместо абстрактного обсуждения на стратегической сессии команда может увидеть конкретные направления и оценивать их, например, по среднему чеку. В этом смысле тарифы не являются просто набором фич или маркетинговых названий. Они отражают стратегическое решение обслуживать разные сегменты одной транспортной задачи — тех, для кого различаются ожидания от цены, комфорта, статуса и взаимодействия во время поездки.
Этот пример также иллюстрирует общий тезис Ивана: jobs являются первопричиной, а продуктовая форма вторична. Компания сначала понимает, какие люди и как хотят выполнять работу, затем создаёт форму сервиса, подходящую их критериям. Тарифы «Эконом», «Комфорт» и более статусные варианты можно понимать как разные способы доставить ценность разным сегментам, а не как результат произвольного добавления продуктовых функций.
Иван Замесин приводит пример компании, продающей дорогие услуги HR-консалтинга: автоматизированный найм компетентных сотрудников, который должен быть быстрым и достаточно точным. Исходная продуктовая задача заключалась не просто в росте продаж, а в увеличении ценности для уже существующих клиентов. Руководитель этого направления взял набор механик создания ценности и начал изучать, как клиенты проходят процесс найма сейчас.
Ключевым объектом исследования стал граф работ клиента. Иван поясняет это на примере человека, который никогда не нанимал data scientist. До выполнения основной задачи найма у такого клиента возникает ориентационная работа: понять, как вообще нанять такого специалиста, насколько это сложно, какие шаги предстоят и что нужно учитывать. Если компания помогает выполнить эту ориентационную работу, она уже создаёт ценность до того, как закрыта сама вакансия. Одной из механик ценности здесь становится ясность о графе работ: клиент получает понятную картину процесса и может лучше ориентироваться в незнакомой ситуации.
Предприниматель провёл около 15 интервью, чтобы выяснить, как выглядит граф работ у разных сегментов клиентов. Для каждого сегмента он изучал последовательность действий и определял, какие механики ценности можно применить. Один сегмент мог нуждаться в одних формах поддержки, другой — в других, поскольку у них различались контекст найма, опыт, риски и то, как они оценивают результат. Это позволяло не ограничиваться одной услугой «найм сотрудника», а проектировать ценность вокруг всего процесса, который клиенту приходится проходить.
По словам Ивана, после такого исследования продукт был переделан, и возвращаемость клиентов заметно выросла: они стали закрывать через компанию всё больше вакансий. Логика этого результата состоит в том, что клиент получает помощь не только в финальном исходе, но и в выполнении сопутствующих работ. Компания становится полезной на большем числе этапов графа найма, уменьшает неопределённость, снижает трудности и тем самым создаёт основания для повторного сотрудничества.
Этот кейс показывает, что удержание и повторные продажи могут строиться не только на скидках, аккаунт-менеджменте или добавлении новых фич. Если компания понимает последовательность работ, которые клиент выполняет до, во время и после основной задачи, она может добавлять ценность именно в тех точках, где у клиента возникают пробелы. За счёт этого продукт начинает закрывать более широкий и более связный набор потребностей в рамках уже существующей клиентской работы.
Илья Красинский утверждает, что качественно проведённая JTBD-сегментация почти всегда вызывает у команды инсайт и удивление. Он связывает это с тем, что удивление буквально означает получение новой информации: команда сталкивается с наблюдением, которого не ожидала, а значит, её прежняя объяснительная модель клиентов не подтвердилась. Илья называет это критерием информации по Шеннону: если результат полностью совпал с ожиданиями, он не изменил понимание реальности.
Такой эффект особенно важен потому, что продуктовые команды часто уверены, что и так знают своих пользователей. Иван отмечает распространённую реакцию давно работающей команды на исследование: «Мы и так это всё знали». Илья интерпретирует это как типичную защитную реакцию и рационализацию. По его мнению, в таких случаях люди могут защищать уже сложившуюся картину мира, а не проверять, действительно ли она описывает поведение клиентов и структуру спроса.
Илья приводит пример Skyeng. В ходе сегментации команда увидела больше школьников и студентов на взрослом английском, чем предполагалось; причиной было то, что люди находили Skyeng через поисковую выдачу и не понимали, что существует отдельный Skysmart. Также обнаружилось много посещений старых лендингов и промостраниц, созданных прежними командами и уже не поддерживаемых. Внутренняя модель команды могла исходить из того, что она управляет одной актуальной страницей, а остальные страницы как будто не существуют. Исследование показало, что реальное поведение пользователей устроено иначе.
Другим примером стало опровержение гипотезы о мотивации к изучению английского. Команда предполагала, что заметная часть людей приходит ради сдачи экзамена или ведения блогов на Западе. По словам Ильи, такие сценарии оказались менее значимыми, чем ожидалось. Сегментация в данном случае не просто дала новые формулировки для лендинга, а изменила представление о том, какие люди на самом деле приходят, по каким причинам и какие сценарии являются массовыми.
Удивление, таким образом, выполняет диагностическую функцию. Оно сигнализирует, что команда вышла за пределы собственных стереотипов, привычных сущностей и внутренних представлений о пользователях. Но само удивление не является финальной целью исследования. Оно важно как признак того, что появилась новая информация, на основе которой можно пересмотреть сегменты, изменить коммуникацию, скорректировать воронку, по-другому распределить ресурсы или выбрать другой продуктовый фокус.
Иван Замесин связывает способ выбора сегмента с ценой ошибки и объёмом необходимых инвестиций. После того как команда обнаружила сегменты, нельзя автоматически считать, что каждый из них требует одинакового уровня проверки. Если изменение можно сделать дёшево и быстро, а риск невелик, допустимо выбрать наиболее перспективный сегмент экспертно или на основании небольшого объёма данных, получить минимальное подтверждение и сразу протестировать гипотезу.
В качестве примера Иван приводит ситуацию, когда для проверки достаточно переделать лендинг. Если такая правка почти ничего не стоит и не требует необратимых изменений в продукте, команда может быстро адаптировать коммуникацию под выбранный сегмент и посмотреть на реакцию рынка. Здесь нет необходимости сначала строить сложное исследование на месяцы: скорость проверки сама становится частью рационального подхода, поскольку стоимость неудачи низка.
Иная ситуация возникает, если для движения в сегмент нужно много инвестировать. Тогда, по Ивану, необходимо собрать более сильную аргументацию: почему именно в этот сегмент следует идти, каков его размер, какой у него бюджет, как часто в нём возникает соответствующая работа, какими решениями люди пользуются сейчас, насколько они удовлетворены и почему существующее решение не справляется. Чем дороже решение и чем сложнее его откатить, тем больше требуется подтверждений до начала масштабных действий.
Эта логика раскрывается в кейсе Юры Весневского, работавшего с безопасностью дорожного движения корпоративных автопарков. Вместо выбора между набором продуктовых гипотез он сначала исследовал сегменты и работы начальников пассажирских перевозок: снижение аварийности, корректировка стиля вождения, проверки, выявление нарушений режима труда и отдыха, выработка привычек. Затем он отбросил убыточные сегменты — например, с малым количеством машин, небольшим бюджетом или сложным процессом принятия решений — и оценил оставшиеся по бюджету, размеру и характеру задач. Это стало основанием для выбора фокусного сегмента и запуска продукта.
Иван также описывает роль количественного исследования, когда решение требует более высокой уверенности. После качественного этапа, на котором становятся понятны сегменты и их работы, можно провести опрос: выяснить, выполняет ли человек определённую задачу, как часто, сколько он платил за её выполнение, каким решением пользовался, насколько удовлетворён и почему неудовлетворён. По словам Ивана, такие исследования могут стоить несколько сотен тысяч рублей даже в B2B-сегменте и позволяют точнее оценить размер сегмента, бюджет и потенциальную неудовлетворённость.
Илья Красинский добавляет, что для крупных компаний и дорогих решений количественное исследование особенно уместно. Но если речь идёт о небольшом стартапе или если формальный количественный опрос недоступен, можно искать людей через цифровой след, реферальные сообщества, профессиональные контакты, конференции и разговоры с бывшими сотрудниками компаний. Важен не обязательный формат исследования, а достаточность аргументации для масштаба решения. Небольшой обратимый тест может опираться на более лёгкую проверку; крупная ставка требует более глубокого подтверждения сегмента и его экономики.
Иван Замесин описывает оценку сегментов как переход от качественного понимания рынка к проверяемой количественной аргументации. На качественном этапе задача состоит в том, чтобы обнаружить группы людей с похожими работами, понять, какие именно jobs они выполняют, как устроен их граф работ, какими решениями они пользуются и где испытывают затруднения. Однако этого недостаточно для выбора направления инвестиций: качественное исследование позволяет увидеть существование сегментов, но не показывает с достаточной точностью, насколько каждый из них велик, денежен и перспективен.
Для количественной оценки, по словам Ивана, сначала нужно найти людей, у которых с высокой вероятностью существует интересующая работа и которые уже тратят на её выполнение больше определённой суммы. После этого им задают прямые вопросы о наличии job: выполняют ли они эту задачу вообще, насколько часто её выполняют, сколько платили за каждое выполнение, каким текущим решением пользуются и насколько удовлетворены этим решением. Если человек сообщает о неудовлетворённости, исследование должно раскрыть её причины: что именно в существующем решении не устраивает, где оно не выполняет работу оптимально, какие препятствия остаются нерешёнными.
Такая логика связывает оценку сегмента не с абстрактным портретом аудитории, а с экономикой конкретной работы. Размер сегмента определяется не просто количеством людей определённого типа, а количеством людей, у которых есть конкретная job. Бюджет показывает, сколько они уже готовы или вынуждены тратить на её выполнение. Частотность показывает регулярность потребности: возникает ли задача редко, эпизодически или повторяется постоянно. Текущее решение указывает, как клиент закрывает job сейчас, а удовлетворённость и причины неудовлетворённости помогают понять, существует ли возможность создать для него более ценное решение.
Иван подчёркивает, что результатом такого исследования становится возможность достаточно точно оценить размер сегмента и его бюджет — либо по отдельной работе, либо по совокупности связанных работ. Кроме того, появляется понимание, выполняется ли работа вообще, каким способом выполняется, насколько хорошо существующее решение справляется и где находится пространство для улучшения. Особенно перспективными оказываются сегменты, где одновременно есть работа, бюджет и неудовлетворённость: люди уже платят за попытку решить задачу, но продолжают страдать или искать альтернативы.
Количественное исследование в этой модели нужно не как замена интервью, а как следующий слой аргументации после них. Качественные интервью позволяют увидеть сегменты и сформулировать гипотезы, а количественный опрос позволяет проверить распространённость jobs, бюджетов, неудовлетворённости и барьеров. Иван отмечает, что даже B2B-исследования могут быть относительно доступными: в разговоре приводится пример исследования генеральных директоров компаний с выручкой до 150 млн рублей, которое стоило несколько сотен тысяч рублей и было проведено достаточно быстро. Такой уровень данных нужен прежде всего тогда, когда решение о выборе сегмента требует значительных инвестиций и должно быть обосновано перед руководством.
Иван Замесин разбирает кейс Юры Весневского, связанный с безопасностью дорожного движения в корпоративных автопарках, как пример перехода от набора продуктовых гипотез к выбору сегмента на основе jobs и экономики. На входе у команды был набор представлений о новых продуктах, которые можно было бы запустить. Проблема такого подхода, по формулировке Ивана, состоит в том, что продуктовые гипотезы сложно сравнивать: они оказываются несопоставимыми, и у команды нет ясного принципа приоритизации.
Вместо выбора между идеями продуктов Юра начал искать сегменты и проводить интервью. В каждом интервью он извлекал конструкцию задач конкретного клиента. В качестве примера Иван приводит начальника пассажирских перевозок, для которого верхнеуровневая job звучала как стремление снизить аварийность парка. Затем исследование раскрывало работы более низкого уровня: корректировать стиль вождения, проводить проверки, выявлять нарушения режима труда и отдыха, формировать нужные привычки у водителей и выполнять другие действия, связанные с безопасностью. Таким образом, изучался не абстрактный спрос на продукт, а относительно конкретный граф работ клиента.
На выходе обнаружился набор групп людей с разными сочетаниями задач и условий. Сегменты выделялись по сходным работам, а не по формальному отраслевому или демографическому признаку. После этого часть сегментов была сразу исключена из рассмотрения как убыточная. По словам Ивана, основаниями для исключения были малое количество машин, отсутствие бюджета, небольшой бюджет или сложность принятия решений по бюджету. Это важный момент кейса: сегментация не сводится к поиску тех, кому продукт потенциально может быть полезен. Она позволяет отказаться от клиентов, которым продукт в принципе может быть нужен, но работа с которыми не создаст устойчивой экономики.
Далее Юра использовал доступ к директорам и руководителям по безопасности, чтобы провести несколько опросов и оценить найденные сегменты. Он задавал вопросы о том, выполняют ли респонденты нужную задачу и каким бюджетом располагают. В результате появилась оценка размера сегментов с определённой погрешностью: стало понятнее, сколько существует людей с такими задачами, какой бюджет они выделяют и какие работы для них особенно важны. Качественное исследование давало картину того, как устроена работа в каждом сегменте, а опросы помогали оценить её рыночный масштаб и платежеспособность.
На основе этих данных был выбран фокусный сегмент. Иван описывает критерий его привлекательности так: в нём должна существовать реальная работа, на которую выделяется бюджет, но которая выполняется плохо. В таком сегменте клиенты уже несут затраты, испытывают неудовлетворённость или ищут способ решить задачу лучше. Это создаёт основание для разработки продукта, а не просто для реализации заранее придуманной функции.
По итогам Юра запустил продукт, который, по словам Ивана, хорошо вырос и обеспечивал 75% роста выручки всех продуктов компании. Кейс используется как иллюстрация того, что сегментация помогает не только точнее упаковать уже существующее предложение, но и выбрать, какой продукт вообще имеет смысл запускать. Центральным результатом стало не увеличение числа функций, а отказ от невыгодных сегментов и фокусировка на сегменте с достаточным бюджетом, реальной job и неудовлетворённым способом её выполнения.
Иван Замесин приводит работу с Яндекс Практикумом как пример исследования на более ранней стадии, когда ещё не определён не только сегмент, но и сам рынок, в котором следует развивать продукт. В отличие от локальной оптимизации существующих продаж, здесь речь шла о поиске направления: у команды были ресурсы и желание запустить новый продукт в сфере классического образования, но исходно не было ясности, какой именно рынок выбрать.
По словам Ивана, команда рассматривала множество вариантов: лицеи, платную школу и другие направления в образовании. Рынок меняли шесть раз, прежде чем остановились на онлайн-магистратурах. Этот фрагмент показывает, что поиск рынка не строился как прямое подтверждение первой идеи. Напротив, команда последовательно отказывалась от вариантов и продолжала искать, пока не нашла область, на которой решила сфокусироваться.
После выбора рынка онлайн-магистратур была применена та же логика, что и в сегментации других продуктов. Исследовались люди, которые поступают на платные онлайн-магистратуры: какие сегменты среди них существуют, чем они отличаются по задачам и как их можно оценить. Затем сегменты были оценены и выбран один фокусный. В транскрипте не раскрываются его конкретные характеристики, однако подчёркивается сам метод: рынок выбирается не только через категорию продукта, а через исследование реальных групп клиентов и их работ.
Иван указывает, что менее чем за год с начала работы продукт достиг 10% доли рынка онлайн-магистратур. В логике встречи этот результат не подаётся как следствие одной удачной идеи или единственного решения. Он связывается с последовательностью действий: сначала поиск подходящего рынка, затем изучение сегментов внутри него, их оценка и концентрация на выбранной группе клиентов. Кейс противопоставлен подходу, при котором компания сразу начинает строить продукт на основании поверхностной идеи о том, что «нужно сделать школу», «лицей» или другой привычный образовательный формат.
Этот пример также иллюстрирует различие между глобальным и локальным оптимумом, о котором ранее говорил Иван. Локальный подход улучшает работу с существующими клиентами и сегментами, а глобальный предполагает поиск иных рынков, других сегментов или новых бизнес-моделей. Поиск онлайн-магистратур был именно глобальным шагом: команда не ограничилась улучшением существующего образовательного предложения, а перебирала рынки, пока не нашла направление с потенциалом масштабирования.
Илья Красинский подчёркивает, что отсутствие готовой базы респондентов не означает невозможность провести исследование. Если у людей есть реальная потребность и сегмент достаточно велик, они, по его мнению, почти неизбежно оставляют цифровой след. Поэтому поиск респондентов можно строить не только через дорогие формальные выборки, но и через наблюдение за тем, какие действия совершают люди в процессе выполнения нужной работы.
В качестве примера Илья называет людей, которые делают ремонт. Их можно обнаружить через связанные действия: поиск квартиры и новостроек, обращения к сервисам и организациям вроде Дом.РФ или ВТБ, покупку стройматериалов, поиск дизайнера, чтение профильных статей, сайтов и исследований. Логика состоит в том, чтобы искать не абстрактных «пользователей ремонта», а следы конкретной ситуации и связанного с ней графа работ. Это позволяет находить людей, у которых потребность уже проявилась в поведении.
Илья также говорит о реферальных сообществах как о простом и часто недорогом способе доступа к респондентам. В акселераторах использовался подход, при котором команда открыто сообщала потенциальному собеседнику, что проводит исследование рынка, объясняла, кто делает исследование, и просила уделить время интервью. По словам Ильи, люди нередко соглашались и делились информацией. Здесь важна не скрытая добыча данных, а прямой человеческий контакт и понятная просьба.
Отдельно Илья отмечает ценность профессиональных связей, возникающих в неформальном общении на конференциях и в сообществах. Он формулирует это резко, но смысл заключается в том, что при личном контакте и восприятии исследователя как адекватного человека люди чаще раскрывают полезные детали, объясняют контекст рынка и делятся практическим опытом. Такой способ особенно полезен для доступа к информации, которая не лежит в открытой аналитике и не всегда формализована внутри компаний.
Ещё один приём, который называет Илья, — разговоры с людьми, увольняющимися или уже ушедшими из компаний. Здесь он отдельно оговаривает, что задача не в получении секретной информации и не в нарушении каких-либо обязательств. Полезно спросить человека о том, как в компании был устроен определённый процесс, как там принимались решения и как решалась интересующая задача. Бывшие сотрудники могут объяснить практику рынка и раскрыть способы работы, которые трудно увидеть снаружи.
Илья связывает поиск респондентов и экспертных контактов с участием в комьюнити. По его мнению, профессиональные сообщества производят значительно больше методов и приёмов, чем способен придумать один человек. Поэтому исследователю полезно не ограничиваться своим набором способов рекрутинга, а обращаться к людям, которые уже решали сходную задачу. Если вопрос сформулирован адекватно, в сообществе может найтись человек, способный подсказать путь к нужному сегменту или способ проведения исследования.
Иван Замесин предлагает экспертные интервью как лучшее доступное приближение в ситуациях, когда количественное исследование провести невозможно, слишком дорого или когда нужных людей сложно собрать в достаточном объёме для опроса. Такой метод не подменяет количественную проверку в полном смысле, но позволяет собрать структурированное знание о рынке через людей, которые уже регулярно продают нужному сегменту или работают с ним.
Собеседниками для таких интервью должны быть люди, которые знают целевую аудиторию из практики продаж. Иван называет, например, коммерческих директоров и директоров по маркетингу компаний, продающих этим клиентам. Их ценность состоит в том, что они уже наблюдали разные типы покупателей, знают, кто реально приобретает продукт, кто располагает бюджетом, кто долго принимает решения и какие сложности возникают при работе с отдельными группами.
Экспертное интервью особенно полезно на стадии, когда необходимо сузить пространство гипотез. Вместо того чтобы пытаться сразу подтвердить размер рынка с высокой статистической точностью, команда может выяснить, какие сегменты в принципе существуют, какие из них кажутся крупными, какие более платёжеспособны и какие сильнее неудовлетворены текущими решениями. Такое интервью позволяет получить ориентиры для дальнейших исследований, разработки продукта и приоритизации сегментов.
Иван подчёркивает, что доступ к экспертам сам по себе требует усилий. Их может быть сложно мотивировать на разговор: из двадцати отправленных сообщений на беседу могут согласиться трое. Однако даже несколько содержательных разговоров способны дать «суперзолото», поскольку эксперты могут рассказать о реальных барьерах, рисках и правилах игры на рынке. Поэтому низкая конверсия рекрутинга не означает бесполезность подхода; она является ожидаемой частью процесса.
Существенное условие качества такого интервью — отсутствие у эксперта мотивации искажать информацию. Иван прямо указывает, что коммерческий или маркетинговый руководитель способен достаточно точно описать рынок, если ему незачем врать исследователю. Также важен вопрос прямой конкуренции: если интервьюируемый воспринимает исследователя как непосредственного конкурента, он может быть менее готов раскрывать детали. В разговоре упоминается и возможность оплаты: при вознаграждении порядка 20, 30, 50 или 100 тысяч рублей эксперт потенциально может рассказать значительно больше и глубже.
Таким образом, экспертные интервью в обсуждаемой логике нужны для снижения неопределённости там, где невозможно быстро получить количественные данные. Они помогают увидеть сегменты, их экономические различия, риски запуска и особенности продаж. Их результатом становится не окончательная статистическая оценка рынка, а более качественная карта гипотез, с которой можно переходить к выбору направления, последующим интервью с клиентами или количественной проверке.
Иван Замесин предлагает использовать экспертные интервью не как свободную беседу «о рынке вообще», а как способ получить ответы на конкретные вопросы о сегментах и механике продаж. Первый прямой вопрос, который можно задать эксперту: какие сегменты вообще существуют на рынке и чем они занимаются. Такой вопрос помогает выявить группы клиентов, которые могут быть неочевидны для команды, особенно если она пока смотрит на рынок через собственную продуктовую категорию.
Если сегменты уже предварительно выделены, Иван предлагает уточнять их сравнительные характеристики. Эксперта можно спросить, какой сегмент самый большой, какой наиболее платёжеспособный и какой наиболее неудовлетворён существующими решениями. Эти три измерения отражают разные аспекты перспективности. Большой сегмент даёт потенциальный масштаб, платёжеспособный — возможность строить экономику, а неудовлетворённый — пространство для создания новой ценности. Они не обязательно совпадают в одной группе, поэтому экспертное мнение помогает увидеть компромиссы между ними.
Отдельный блок вопросов должен быть посвящён трендам. Эксперт, который постоянно работает с рынком, может рассказать, какие изменения происходят в спросе, поведении покупателей, структуре сегментов и способах принятия решений. В транскрипте не конкретизируются виды трендов, но сама рекомендация показывает, что оценка сегмента не должна быть статичной: важно понимать не только текущее состояние, но и то, куда движется рынок.
Главным вопросом к экспертам Иван называет вопрос о рисках. Его формулировка: какие риски вы видите при создании продукта для сегмента X и что самое важное нужно знать, чтобы продавать продукт сегменту X. Этот вопрос нужен, чтобы эксперт раскрыл не только привлекательность сегмента, но и то, что способно сделать идею неработающей. Речь может идти о барьерах клиентов, особенностях закупок, сложностях внедрения, скрытых ожиданиях и практических «секретиках» рынка.
По словам Ивана, эксперт способен рассказать о приёмах продаж и главных барьерах, которые редко становятся очевидными из внешнего наблюдения. Это особенно важно, если продукт ещё не запущен и у команды нет собственной статистики продаж. Вместо поверхностной гипотезы «этому сегменту нужен наш продукт» можно получить более прикладное знание: почему представители сегмента покупают или не покупают, какие условия должны быть выполнены, как они оценивают риск и на каком языке с ними нужно разговаривать.
Иван также указывает на условия, при которых такие ответы становятся доступными. Нужно суметь мотивировать эксперта поговорить, не быть для него прямым конкурентом и при необходимости предложить вознаграждение. В этом случае экспертное интервью становится способом получить знания о размере, бюджете, неудовлетворённости, рисках и продажах не из предположений команды, а из опыта человека, который уже действует внутри соответствующего рынка.
Иван Замесин говорит, что современные нейросети, в частности OpenAI o3, уже хорошо справляются с рядом продуктовых задач. По его словам, они могут помогать генерировать гипотезы сегментов, строить графы работ, формулировать гипотезы ценности, создавать коммуникации для лендингов, предлагать тарифы, идеи допродаж и способы усиления предложения. В этой логике ИИ становится инструментом для ускорения этапа discovery и разработки гипотез, а не самостоятельной заменой исследования рынка.
Ранее в разговоре Иван также отмечает, что при наличии понимания сегмента можно идти в нейросети, чтобы искать другую нишу. Это связывает использование ИИ с задачей сегментации: нейросеть способна помочь расширить пространство вариантов, предложить возможные сегменты и направления, которые команда не рассматривала. Однако исходная рамка остаётся продуктовой: нужно искать не просто новые идеи функций, а людей с конкретными работами, контекстами и критериями ценности.
Илья Красинский подтверждает, что ИИ способен строить дерево сценариев на 20–30 элементов и выдавать гипотезы, которые команда могла не замечать. Он описывает ситуацию, когда человек читает предложенные сценарии и узнаёт в них реальных клиентов, на которых раньше не обращал внимания. Иногда именно такие «тихие» клиенты уже активно пользуются продуктом и могут оказаться сегментом, который стоит масштабировать, хотя они не создают много шума и не формулируют запросы в явном виде.
В применении к коммуникации ИИ, по словам Ивана, может помочь перевести знание о ценности и jobs в лендинг, сценарии продаж или коммерческие материалы. Это соответствует общей позиции встречи: когда известны сегменты, их работы, ценность, барьеры и последовательность действий до покупки, коммуникация начинает выводиться из этой информации более естественно. Нейросеть в таком случае ускоряет оформление и генерацию вариантов, но содержательная основа должна быть связана с реальным пониманием клиента.
Иван также рассматривает ИИ в контексте будущего создания продуктов. Он говорит, что сочетание инструментов вроде Lovable и OpenAI может в ближайшей перспективе позволять за вечер создавать приложения, которые уже можно монетизировать. Илья уточняет, что часть таких изменений происходит уже сейчас: код во многих случаях вообще не является главным условием решения job, а нейросеть может выполнять сложные интеллектуальные задачи, например готовить документы для прохождения службы безопасности. В общей логике разговора ИИ снижает стоимость проверки продуктовых гипотез, автоматизации и создания первых решений, но не отменяет необходимость понимать, какую работу клиента нужно выполнить.
Илья Красинский подчёркивает, что нейросеть не даст качественный результат, если просто задать ей общий вопрос. По его словам, при таком запросе получается плохой, усреднённый ответ. Чтобы извлечь из модели более полезный результат, нужно понимать, как направлять её внимание и как активировать не наиболее типовой, а более специфичный набор знаний, содержащийся в модели.
В качестве основы для такого запроса Илья называет структуру Jobs to Be Done. Нужно достаточно чётко описать, что это за сегмент людей, в какой ситуации они находятся, в каком контексте возникает потребность, чего они хотят и какие детали сопровождают эту ситуацию. Он прямо связывает качество промпта с деталями JTBD-сценария: сегмент, контекст, задача, желаемый результат и критерии клиента помогают избежать стандартного «мейнстримного» ответа.
Илья объясняет этот принцип через метафору матрицы внимания и весов модели. Корректно составленный промпт должен активировать не усредненное знание обо всех пользователях, а более специфические связи. В качестве условного примера он приводит не просто абстрактного пользователя, а «португальца-таксиста», которому нужно сдавать налоги в определённое время. Смысл такого примера в том, что конкретизация меняет ответ: модель начинает рассуждать не о типичном человеке вообще, а о конкретном человеке в определённой жизненной и рабочей ситуации.
Эта позиция напрямую связана с обсуждением сегментации. Если команда сама не знает, для кого создаёт продукт, какую job клиент выполняет, в каком контексте она возникает и по каким критериям клиент оценивает результат, то она не может дать ИИ достаточно точную рамку. В таком случае нейросеть лишь воспроизводит обобщённые предположения, а не помогает обнаружить работающую продуктовую возможность.
Иван Замесин дополняет эту мысль практическим утверждением: нейросети хорошо генерируют графы работ, гипотезы ценности, лендинги и другие продуктовые артефакты. Но в контексте всей встречи это работает именно тогда, когда исходные данные заданы через jobs и сегменты. ИИ помогает развернуть и обработать правильно поставленную продуктовую задачу, а не снимает необходимость в исходной диагностике клиента и рынка.
Иван Замесин показывает диагностику лендинга как последовательную проверку того, насколько коммуникация строится вокруг клиентской работы и ценности, а не вокруг описания продукта или набора фич. Первый вопрос диагностики — использует ли лендинг Core Job и Big Job в сегментации и коммуникации либо просто перечисляет особенности решения. Core Job относится к конкретной работе, которую пользователь хочет выполнить, а Big Job включает более широкий контекст, ситуацию, триггеры, эмоции и проблемы, из-за которых эта работа становится актуальной.
Следующий важный элемент — Aha-момент. Иван предлагает проверять, может ли человек прожить его до оплаты. Aha-моментом называется переживание, в котором пользователь начинает чувствовать, что решение действительно поможет ему достичь желаемого результата. На лендинге это может быть выражено через истории, видео, отзывы или другие формы демонстрации будущего эффекта. Важно не просто заявить, что курс или сервис хороший, а дать человеку возможность увидеть: «я уже понимаю, как это будет работать для меня».
Отдельной частью диагностики является точка А. По словам Ивана, в точке А человек должен узнать себя: увидеть свой контекст, триггер, эмоции, страхи или текущую ситуацию. Идеальный эффект — реакция «это про меня». Описание одной лишь роли или общей категории клиента недостаточно. Например, фраза «для генеральных директоров» не объясняет, в какой ситуации находится генеральный директор, какую работу он пытается выполнить и почему это важно именно сейчас.
Точка Б, напротив, описывает состояние после успешного выполнения работы. Лендинг должен помогать человеку представить себя в этой точке: как изменится его жизнь, работа или поведение после использования решения. Иван подчёркивает, что недостаточно сказать «это был хороший курс» или показать общий результат. Нужно дать конкретный образ нового состояния: человек действует увереннее, получает нужный результат, работает по понятному процессу, привлекает клиентов или избавляется от определённой тревоги.
Диагностика также включает проверку барьеров, страхов и тревог. Иван предлагает задаваться вопросом, снижает ли лендинг сомнения, возникающие у пользователя в первой точке контакта. Пользователь может сомневаться в компетенции экспертов, в том, что продукт реально даст нужный результат, в возможности найти клиентов, в сложности процесса или в риске потратить деньги и время впустую. Кроме прямых конкурентов, важной альтернативой может быть бездействие, самостоятельное обучение или самостоятельное решение задачи. Поэтому лендинг должен учитывать, между какими способами выполнения job человек выбирает.
Наконец, Иван отдельно выделяет call to action. CTA должен быть направлен на первый micro job, то есть на ближайшее небольшое действие, которое пользователь готов выполнить сейчас. Илья Красинский развивает эту мысль: если в кнопке сразу обещать итоговую ценность или требовать большого обязательства, человеку может быть страшно, долго или не до этого. Первый шаг должен быть посильным и подтверждать, что пользователь находится в правильном месте. В диагностической системе это помогает оценить, не просит ли лендинг слишком многого на слишком раннем этапе.
В конце встречи Иван показывает более формализованный алгоритм самодиагностики. В нём предлагается отвечать на вопросы о сегментации, знании фокусного сегмента, его потенциальной маржинальности, размере, источниках информации, сегментах конкурентов, личных jobs руководителей, способах создания ценности, использовании CJM, а также о коммуникации ценности. Некоторые вопросы имеют больший вес. По результату набирается балл, а низкий результат, по словам Ивана, указывает на то, что продукту особенно поможет сегментация. Внутри чек-листа также содержатся подсказки, что делать при отсутствии сегментации или недостатке экспертизы для её проведения.
На примере Yoga Academy Иван Замесин показывает, что формулировка «получите новую профессию преподавателя хатха-йоги» может отражать Core Job, но сама по себе не исчерпывает качественную коммуникацию. Получение профессии — это направление желаемого результата, однако лендинг должен отвечать на вопрос, является ли заявленная ценность действительно важной для наиболее перспективных сегментов и попадает ли она в их критерии выбора.
Иван отдельно рассматривает блоки о практике с клиентами, наставниках и возможности начать зарабатывать во время обучения. Эти элементы потенциально могут быть ценностью, но их нельзя автоматически считать сильными аргументами. Нужно понимать, как на них реагирует аудитория и являются ли они стандартным ожиданием рынка или реальным преимуществом. Илья Красинский называет такие базовые ожидания активирующим знанием: например, наличие колёс и руля у машины не является причиной выбора, если это воспринимается как обязательная норма. В случае с йогой два месяца практики под наставничеством могут быть ценностью, если обычно практики намного больше или если без неё невозможно начать работать, но это требует проверки на конкретном сегменте.
Главный недостаток проанализированного лендинга Иван видит в слабой точке А. На странице есть общие формулировки об углублении личной практики и становлении преподавателем, но почти нет контекста, эмоций и триггеров. Человек не видит жизненную ситуацию, в которой он мог бы узнать себя. Иван приводит гипотетические варианты: человек давно хочет начать преподавать, но боится, что к нему не пойдут клиенты; видит, как менее сильный знакомый уже зарабатывает на преподавании, и переживает из-за собственного бездействия; сомневается в своей способности стать практикующим специалистом. Эти примеры не объявляются фактами о целевой аудитории Yoga Academy, а показывают, какого типа знание должно появиться после исследования сегментов.
Иван также не видит на лендинге способа прожить Aha-момент. Такой момент мог бы создаваться, например, через видео или истории выпускников, где человек рассказывает, что стал уверенным преподавателем, начал практиковать, получил довольных учеников и увидел изменение собственной жизни. Илья добавляет, что в образовательных продуктах такого типа может сильно работать личность преподавателя: люди могут выбрать школу, потому что им близки мысли, речь и способ мышления конкретного наставника. Однако оба спикера не утверждают, что это обязательно применимо именно к данному кейсу; это рассматривается как возможный элемент ценности и доверия.
Точка Б на лендинге также должна быть конкретнее. Вместо общего утверждения о хорошем обучении пользователь должен увидеть свою жизнь после курса: он ведёт занятия, к нему приходят ученики, он чувствует уверенность в работе, понимает, что делать на сессии, и имеет понятную методику. Это не просто описание программы, а демонстрация того, ради чего человек проходит обучение.
Кроме того, лендинг должен снижать барьеры. В контексте подготовки преподавателей такими барьерами могут быть сомнения в экспертности школы, тревога о возможности найти клиентов, страх не справиться с практикой или убеждение, что выгоднее учиться самостоятельно. Иван подчёркивает, что главный конкурент продукта может быть не другая школа йоги, а вариант ничего не делать, самостоятельно искать знания или самостоятельно искать первых клиентов. Поэтому качественная коммуникация должна отвечать не только на вопрос «что входит в программу», но и на вопрос «почему это решение поможет мне безопаснее и эффективнее прийти к желаемой жизни».
Иван Замесин формулирует принцип CTA так: призыв к действию должен соответствовать первому micro job пользователя. То есть кнопка и следующее действие не должны требовать сразу максимальной вовлечённости, оплаты или сложного решения. Они должны предлагать небольшой, естественный шаг в графе работ человека, который он готов сделать в текущем контексте.
Илья Красинский соглашается с этой логикой и объясняет её через разницу между конечной ценностью и ближайшим действием. Если предложить человеку сразу «убить дракона», то есть получить большой итоговый результат, он может воспринять это как слишком долгий, болезненный, страшный или требующий много времени путь. Даже если конечная ценность ему нужна, в момент первого контакта он ещё не готов к полной инвестиции. Поэтому задача CTA — не заставить его немедленно пройти весь путь, а помочь встать на первую доступную ступень.
По словам Ильи, первый шаг должен давать пользователю небольшую микроценность или подтверждение, что его ситуация верно понята. Человек должен увидеть, что у него действительно есть соответствующая задача, что продукт попадает в его ожидания и что можно безопасно потратить немного внимания на следующий шаг. Таким образом, CTA не просто снижает технический порог заполнения формы; он должен соответствовать психологической готовности человека к действию.
В контексте диагностики лендингов Иван применяет этот принцип критически к формулировкам вроде «оставить заявку на сервис», особенно если это предполагает большую инвестицию. Такая кнопка может быть слишком тяжёлым шагом для человека, который ещё не понял ценность, не прожил Aha-момент, не увидел себя в точке Б и не получил ответа на свои страхи. До такого действия может быть нужна более ранняя работа: посмотреть демо, понять процесс, получить первичную диагностику или увидеть, как решение работает в похожем контексте.
Этот принцип связывает CTA с общей логикой Jobs to Be Done. Пользователь проходит последовательность работ от появления потребности до выбора и покупки решения. Если призыв к действию игнорирует эту последовательность и предлагает действие, к которому человек ещё не готов, он создаёт дополнительный барьер. Если же CTA соответствует ближайшей micro job, он поддерживает движение пользователя по пути к основной ценности.
При разборе лендинга приложения для подготовки к собеседованиям Иван Замесин обращает внимание на то, что текущая коммуникация сосредоточена на самом способе подготовки: игровой механике, mock-интервью и практике по 20 минут в день. По его оценке, такая подача говорит скорее о продукте, чем о конечной ценности для пользователя. Формулировка о превращении скучной подготовки в игру может быть описанием формата, но сама по себе не объясняет, почему именно этот сервис лучше выполняет важную для клиента работу.
Илья Красинский формулирует возможную более высокоуровневую job как получение работы мечты. В транскрипте отдельно проговаривается различие между «проходить mock-интервью» и «получить работу мечты». Первое может быть промежуточной работой или способом подготовки, а второе — более значимым результатом, ради которого пользователь вообще ищет приложение. Поэтому лендинг должен связывать подготовку с ожидаемым итогом, а не оставлять её самодостаточной целью.
Иван также подчёркивает необходимость использовать язык самого пользователя. Если люди действительно говорят «хочу проходить интервью», коммуникация может начинаться с этой формулировки, но должна продолжаться ценностью: как сервис позволит выполнять эту задачу эффективнее. Само утверждение «практикуйся 20 минут в день» не является ценностью, потому что пользователь может практиковаться столько же времени и другими способами. Лендингу необходимо отвечать на вопрос: в чём преимущество подготовки именно с этим продуктом.
В качестве примеров возможной ценности Иван называет отсутствие необходимости ждать, пока найдётся другой человек для тренировки, и получение обратной связи, релевантной компаниям, в которые пользователь собирается устраиваться. Если кандидат хочет попасть, например, в Amazon, ценность могла бы состоять в том, что его собеседуют или оценивают в формате, близком к требованиям Amazon. Важен не сам факт использования ИИ или игры, а то, как конкретно этот механизм повышает шансы выполнить job.
По диагностике Ивана, на рассматриваемом лендинге отсутствуют или слабо выражены ключевые элементы. Нет ясной точки А, в которой пользователь узнаёт свой контекст, триггер и эмоции. Нет Aha-момента, позволяющего почувствовать, что подготовка действительно сработает. Нет понятной точки Б, в которой человек представляет себя получившим желаемую работу, завершившим поиск и испытывающим облегчение. Нет работы с барьерами и объяснения ценности. Итоговая оценка Ивана звучит жёстко: на странице «ничего нет» из необходимой коммуникационной конструкции, поэтому он предполагает, что лендинг конвертирует плохо.
Илья добавляет важную оговорку: лендинг может показывать приемлемую конверсию на органическом трафике, если люди были заранее проблематизированы другим контентом — например, блогом или YouTube-роликами. В таком случае страница может не создавать спрос и не объяснять ценность, а лишь не слишком мешать уже мотивированному человеку скачать приложение. Но это не отменяет диагностического вывода: если лендинг должен сам убеждать и конвертировать более широкую аудиторию, он должен говорить не только об игровой форме и времени практики, а о конкретной задаче пользователя, его ситуации, препятствиях, ожидаемом результате и способе, которым продукт помогает прийти к желаемой работе.
Иван Замесин проводит принципиальное различие между задачей клиента, ценностью, проблемой и фичей. В его логике задача клиента, или job, является первопричиной: человек стремится что-то сделать в определённой ситуации и оценивает, насколько эффективно ему удалось этого достичь. Ценность возникает тогда, когда продукт помогает выполнить эту задачу лучше: быстрее, понятнее, с меньшим риском, меньшими усилиями или с более предсказуемым результатом. Фича же — это лишь форма доставки этой ценности, то есть ответ на вопрос «за счёт чего продукт помогает выполнить задачу». Поэтому коммуникация, начинающаяся с фичи, начинает рассказ с технического средства, а не с причины, по которой человеку вообще может быть нужен продукт.
Илья Красинский поддерживает эту позицию на примере лендинга приложения для подготовки к собеседованиям. Формулировка про игровой формат, искусственный интеллект и двадцать минут практики в день описывает устройство продукта: механику, формат и часть процесса. Но она не отвечает на вопрос, ради чего человек пришёл. По его интерпретации, пользователь может находиться в ситуации, где ему нужно получить хорошую работу, пройти важное интервью, закончить тяжёлый период поиска и почувствовать уверенность. Если начать с игрового формата подготовки, лендинг рассказывает о внутренней логике создателей продукта, а не о желаемом результате пользователя.
Иван уточняет, что даже общая формулировка вроде «решаем проблему клиента» недостаточна. Он отдельно говорит, что предпочитает бороться не только с фичами, но и с языком проблем. Для него задача — более фундаментальная категория, поскольку проблема описывает не весь контекст, а ситуацию, когда конкретное решение оказалось хуже ожиданий. Коммуникация через задачу позволяет не привязываться к текущему неудачному способу решения и не ограничивать продукт существующей проблемой. Она удерживает внимание на том, что именно человек пытается сделать.
Илья развивает это через модель первого контакта пользователя с коммуникацией. По его словам, в первые мгновения человек пытается узнать себя: свою ситуацию, контекст, личный интерес, ожидаемый результат. Если этого узнавания не происходит, пользователь не понимает, зачем он оказался на странице, и уходит. Проблема в том, что у создателя продукта и пользователя разные объяснительные модели: команда знает продукт, его устройство, технические возможности и внутреннюю логику, а пользователь приходит со своим жизненным опытом, текущей ситуацией и собственным языком описания желаемого результата. Поэтому переносить на пользователя язык команды — значит требовать от него уже проделать тот путь понимания, который он ещё не проделал.
В обсуждении лендинга Yoga Academy Иван показывает, как задача может быть разложена на более содержательную коммуникацию. Формулировка «получите новую профессию» относится к Core Job — получению профессии преподавателя йоги. Однако, по его оценке, этого недостаточно, если на странице не видны контекст, триггеры, страхи и ожидаемая точка Б. Человеку важно не только услышать абстрактное обещание профессии, но и представить себя уверенным преподавателем, который ведёт занятия, понимает, что делать, имеет клиентов и получает подтверждение своей компетентности. Такая коммуникация показывает не просто продуктовую услугу, а изменение положения человека в его собственной ситуации.
Иван также связывает коммуникацию задачи с тем, как строится призыв к действию. CTA не должен требовать сразу совершить крупное действие — купить, оставить большую заявку или принять на себя значимое обязательство. Он должен предлагать первый micro job: посильный шаг, который человек готов сделать сейчас, чтобы приблизиться к основной цели и проверить соответствие продукта своим ожиданиям. В этом смысле коммуникация задачи нужна не только для заголовка лендинга. Она должна последовательно связывать точку А клиента, его желаемую точку Б, ценность, барьеры, Aha-момент и первый реалистичный шаг.
Таким образом, по позиции Ивана и Ильи, фича может быть полезна в коммуникации, но лишь после того, как человеку понятно, какую задачу он решает и почему результат продукта для него ценен. Абстрактная проблема также может быть использована как триггер, но не должна заменять понимание работы клиента. Коммуникация через job позволяет говорить не о том, что команда сделала, а о том, что изменится для человека в нужной ему ситуации.
Иван Замесин формулирует ключевую причинно-следственную связь: проблема не существует в вакууме. Она возникает тогда, когда человек нанял конкретное решение для выполнения конкретной работы, но это решение выполнило работу ниже ожиданий. Следовательно, проблема не является исходной точкой продуктового мышления: до неё уже существуют задача клиента, контекст её возникновения, ожидания от результата и выбранный способ выполнения этой задачи.
Эта формулировка меняет смысл продуктового исследования. Если команда фиксируется только на проблеме, она рискует изучать последствия неудачного решения, а не фундаментальную работу, которую человек пытается выполнить. Например, пользователь может жаловаться на неудобный интерфейс, отсутствие нужной функции или долгий путь в продукте. Но такие жалобы ещё не объясняют, какую работу он стремится выполнить, почему она важна именно сейчас, по каким критериям он оценивает результат и какие альтернативы у него есть. Без этого команда может улучшить отдельную деталь текущего решения, но не обязательно приблизить человека к желаемому результату.
Илья Красинский связывает эту логику с ситуацией B2B-продаж, когда клиенты или ЛПР говорят на языке фичей: просят определённые функции, экраны, отчёты или возможности. По его словам, такой запрос уже относится к постконтакту. Человек успел заметить ситуацию, осознать необходимость изменений, принять решение что-то делать и сформулировать потребность в терминах, которым его научил рынок или его собственный опыт. Поэтому буквальное выполнение просьбы о фиче не всегда означает работу с реальной задачей.
Илья вспоминает правило из своего опыта B2B-продаж: отвечать нужно не на формулировку, а на запрос, стоящий за ней. В контексте обсуждения это означает: за жалобой, запросом на функцию или описанием проблемы нужно увидеть, какую работу человек пытается выполнить и на какую работу он фактически «нанимает» продукт. По его формулировке, через проблему можно понять, к какому решению клиент уже пришёл, но обращаться следует к самой работе.
Иван дополняет, что работа с задачей открывает возможность менять граф работ. Если команда остаётся на уровне проблемы, она чаще пытается исправить привычный способ выполнения действия: добавить функцию, сделать шаг удобнее, ускорить форму или улучшить интерфейс. Если же она видит более высокоуровневую задачу, появляется свобода изменить сам путь к результату, убрать часть действий или найти способ решить задачу принципиально иначе.
Следовательно, проблема в трактовке Ивана — важный сигнал, но не самостоятельная единица анализа. Она указывает, что текущее решение не соответствует ожиданиям при выполнении определённой работы. Для продуктовой команды это означает необходимость исследовать не только то, чем недоволен клиент, но и контекст, цель, критерии успеха, альтернативные решения и весь путь действий, в котором возникло неудовлетворение.
Иван Замесин использует пример пекинских пробок, чтобы показать отличие мышления через проблему от мышления через работу клиента. В базовой формулировке задача звучит как «добраться из точки А в точку Б». Для сегмента людей, которым нельзя опаздывать, привычное решение — ехать на машине по дорогам общего пользования — перестаёт работать из-за тяжёлых пробок. Если смотреть только на проблему, можно пытаться улучшать автомобильное перемещение: искать более быстрые маршруты, менять навигацию, оптимизировать поездку или мириться с задержкой. Но фокус на самой работе позволяет отвязаться от машины как от обязательной формы решения.
Нестандартным решением в приведённом Иваном кейсе становится сервис с двумя людьми на мопеде. Пользователь вызывает их через WeChat. Один человек доставляет владельца автомобиля на мопеде, а второй садится за руль его машины и везёт автомобиль в нужную точку. Это решение не идеально по всем параметрам: Иван прямо отмечает, что человеку приходится ехать на мопеде, дышать выхлопом и сталкиваться с менее комфортным способом передвижения. Однако для конкретного сегмента ключевой критерий — не опоздать — оказывается выполненным лучше, чем при использовании собственной машины в пробке.
Смысл примера состоит в том, что продуктовая задача не сводится к улучшению существующего решения. Когда команда формулирует работу как «доехать вовремя», она может рассматривать любой способ, который обеспечивает этот результат. Машина, маршрут, мопед, водитель, передача управления автомобилем и координация двух исполнителей становятся элементами нового графа работ. Продукт не делает старый путь немного удобнее, а перепроектирует последовательность действий так, чтобы клиент достиг целевого результата в условиях, где привычный путь перестал быть эффективным.
Иван подчёркивает, что именно это считает главной особенностью Jobs to Be Done: подход позволяет выйти из парадигмы продукта. В парадигме продукта команда видит существующую сущность — автомобиль, приложение, CRM, курс, маркетплейс — и думает, как сделать её лучше. В парадигме job команда спрашивает, какую работу нужно выполнить и как можно выполнить её эффективнее, даже если ответ не похож на привычный продукт.
Илья Красинский связывает этот принцип с общим движением от решения к желаемому результату. По его словам, во многих фреймворках решение специально оказывается в конце рассуждения: сначала определяется outcome, то есть то, чего человек действительно хочет достичь, а уже потом создаётся путь к нему. Он отмечает, что такой подход помогает не конкурировать с рынком количеством сделанной работы и не воспроизводить стандартные решения, а искать более высокоуровневый способ достижения результата.
В итоге фокус на job позволяет не воспринимать текущий граф действий как данность. Он делает видимыми промежуточные шаги, ограничения и ожидания клиента, после чего команда может сократить, заменить, автоматизировать или устранить части этого пути. Кейс с мопедами важен именно тем, что демонстрирует: полезное решение может выглядеть странно, если оценивать его с позиции привычного продукта, но быть рациональным, если оценивать его по тому, насколько хорошо оно выполняет ключевую задачу клиента.
Илья Красинский в конце встречи формулирует общую закономерность развития продуктов: по сути, продукты делают две вещи. Они либо автоматизируют существующую работу, уменьшая время и издержки на её выполнение, либо делают эту работу ненужной. В этой логике продуктовая ценность измеряется не количеством созданных функций, а тем, насколько изменился объём усилий, который пользователь должен приложить для достижения результата.
Иван Замесин уточняет эту мысль через две связанные механики: продукт либо «убивает» job более низкого уровня, либо выводит пользователя на более высокий уровень работы. Устранение job означает, что отдельное действие перестаёт требоваться как самостоятельная работа. В качестве примера Иван приводит подключение к Wi‑Fi: раньше для этого нужно было совершать больше действий, тогда как более простой интерфейс сокращает путь до выбора сети. Пользователь по-прежнему хочет получить доступ к интернету, но часть промежуточной работы по подключению становится значительно меньше.
Эта идея особенно важна для понимания того, почему автоматизация не равна простому добавлению кода. В обсуждении Rick.ai Илья подчёркивал, что техническая возможность сама по себе не создаёт ценность. Например, построить граф переходов по CRM, сделкам и этапам воронки — это фича, то есть часть технической инфраструктуры. Но ценность для директора по маркетингу возникает только в ситуации, когда в нужный момент он получает понятный отчёт, который помогает аргументированно объяснить, почему лиды не конвертировались, что произошло с каналами и какие действия нужны дальше. Автоматизация ценна, если она снимает с пользователя работу по поиску, интерпретации и подготовке нужной аргументации.
Илья также подчёркивает, что значительная часть реальной работы над продуктом лежит не в коде. Даже если в продукте существует сильная нейросеть или сложная аналитическая функция, результат не появится, если пользователь не дойдёт до неё, не получит её вывод в подходящий момент или не поймёт, как воспользоваться результатом. Поэтому развитие продукта предполагает не только автоматизацию вычислений, но и сокращение всей цепочки действий: обнаружения ситуации, поиска информации, интерпретации, принятия решения и получения результата.
Иван показывает более радикальный вариант на примере сервисов, которые отменяют целый класс действий. В его формулировке, когда человек заказывает еду по подписке, ему может не понадобиться выполнять связанные с готовкой работы: организовывать приготовление, заниматься кухней и проходить привычный путь до еды. Продукт здесь не просто помогает готовить лучше; он переводит человека к более высокоуровневому результату — получить еду — и устраняет необходимость в части прежнего графа работ.
Оба спикера связывают этот принцип с долгосрочной эволюцией продуктов. Иван говорит, что продукты на горизонте десятков лет выходят на всё более высокий уровень работ. Сначала они облегчают отдельный шаг, затем сокращают цепочку действий, а затем могут отменить необходимость в прежнем типе работы полностью. Илья формулирует похожую мысль: сначала работа может быть оптимизирована, упрощена и удешевлена, а затем кто-то находит более высокий уровень решения и делает прежние усилия избыточными.
Таким образом, в обсуждении развитие продукта понимается не как накопление функциональности. Оно состоит в том, чтобы последовательно уменьшать усилия клиента, автоматизировать повторяющиеся действия, доставлять результат в нужном контексте и, когда возможно, избавлять человека от необходимости выполнять промежуточную работу вообще.
Идея идеального решения в обсуждении Ильи Красинского и Ивана Замесина связана с тем, что продукт должен выполнять нужную клиенту работу с наименьшим участием самого клиента. Илья формулирует это предельно резко: идеальное решение — это ситуация, когда «мы ничего не делали и всё автоматически получилось». В таком понимании продуктовая зрелость состоит не в том, чтобы дать пользователю больше функций и ручного контроля, а в том, чтобы убрать лишнюю работу на пути к результату.
Иван Замесин объясняет эту логику через сокращение или уничтожение промежуточных jobs. Если человеку нужно подключиться к Wi‑Fi, то ценность не в том, чтобы дать ему более сложный набор настроек, а в том, чтобы сократить количество действий до нужного результата. Если человеку нужно получить еду, то продукт может не улучшать сам процесс готовки, а устранить необходимость готовить. Если пользователю нужно получить обоснованный ответ о качестве лидов, то ценность аналитического сервиса состоит не в самом отчёте, а в том, что человек без долгой ручной работы получает аргументацию в момент, когда она ему требуется.
Эта позиция противопоставляется продуктовому подходу, при котором количество действий пользователя ошибочно воспринимается как вовлечение или полезность. В разборе Альфа-Босс Илья критиковал идею предлагать топ-менеджеру оформлять заявки, разбираться в тарифах, ставить поручения и контролировать их выполнение. С его точки зрения, сама возможность удобно сделать эти действия не означает, что пользователь хочет делать их лично. Если продукт приглашает человека выполнять дополнительную работу, которую он стремится делегировать или вообще избежать, то удобный интерфейс не устраняет фундаментальное несоответствие между продуктом и задачей клиента.
Иван связывает минимизацию участия пользователя с эффективностью выполнения job. Ценность определяется тем, насколько лучше выполняется работа: быстрее ли достигается результат, уменьшается ли количество усилий, снижается ли неопределённость, появляется ли доступ к нужной информации в контексте. Именно поэтому фича должна рассматриваться как способ доставки ценности, а не как самостоятельный объект ценности. Хорошая автоматизация, команда заботы, нейросеть, прозрачная бутылка или удобный интерфейс имеют значение только в той мере, в какой они делают нужный результат доступнее для клиента.
Илья приводит пример с автоматом Калашникова как иллюстрацию принципа: решение становится сильнее, когда не требуется создавать отдельную сложную систему для каждого шага, а часть процесса происходит за счёт уже существующей механики. В рамках разговора этот пример нужен не для обсуждения устройства конкретного объекта, а для объяснения общего подхода: хорошее решение уменьшает количество специально организуемых действий и использует систему так, чтобы результат возникал с меньшим количеством ручной работы.
Следовательно, идеальное продуктовое решение не обязательно означает полное отсутствие действий пользователя в буквальном смысле. Оно означает, что пользователь участвует только там, где его участие действительно необходимо для выполнения его собственной задачи. Всё, что может быть снято, автоматизировано, делегировано, предвосхищено или устранено, становится областью для продуктового улучшения.
В разборе лендинга Альфа-Босс Иван Замесин и Илья Красинский видят одну и ту же базовую проблему: коммуникация построена вокруг функций и представлений команды о продукте, а не вокруг конкретной ситуации, задач и критериев результата топ-менеджера. Иван отмечает, что формулировка «для тех, кто решает: генеральных директоров, финансовых директоров» называет только роль пользователя. Она не создаёт точку А, потому что не объясняет, в какой ситуации находится этот человек, что его тревожит, какой триггер привёл его к продукту и какого результата он пытается достичь.
Иван отдельно обращает внимание на формулировки вроде «оформляйте короткие заявки на документы», «подписывайте документы по сделкам онлайн», «договаривайтесь об условиях», «ставьте поручения» и «решайте вопросы». Часть из них он признаёт ближе к потенциальной ценности, например возможность подписывать документы по сделкам онлайн. Однако в целом лендинг, по его оценке, демонстрирует набор функций и действий в приложении, а не объясняет, зачем пользователю нужен результат этих действий. Не показано, выполняют ли эти функции значимую работу конкретного сегмента и почему именно для него они представляют ценность.
Илья особенно резко реагирует на слово «контролируете». Он утверждает, что такая формулировка характерна для менеджеров, которые сами не доверяют системе, в которой работают, и потому проецируют потребность в контроле на пользователей. По его наблюдению, пользователи редко приходят с формулировкой «я хочу контролировать сделки в приложении». Он предлагает не считать внутренний язык команды языком клиента: слово может быть привычным для создателей продукта, но не отражать того, как пользователь воспринимает собственную ситуацию и желаемый результат.
Критика Ильи строится также на несоответствии между образом жизни топ-менеджера и предлагаемыми действиями. Он описывает человека, у которого одновременно есть личные заботы, высокий уровень ответственности, проблемы в команде, риск тяжёлого совещания и множество задач, которые могут иметь серьёзные последствия. В таком контексте предложение изучать банковские акции, скидки, тарифы, оформлять заявки и разбираться с функциями приложения выглядит как приглашение выполнить ещё одну порцию нежелательной работы. Лендинг не показывает, какую критически важную задачу снимает продукт с пользователя; он показывает, какие действия пользователь сможет делать сам.
Иван также указывает на слабость CTA «оставить заявку на сервис». По его оценке, это слишком большое действие, поскольку от пользователя сразу требуется взять на себя заметное обязательство. В логике JTBD призыв к действию должен соответствовать первому micro job — небольшому шагу, который человек готов сделать сейчас. Кроме того, на лендинге, по мнению Ивана, не хватает Aha-момента, коммуникации точки Б и снижения барьеров. Пользователь не видит достаточно убедительно, как изменится его ситуация после использования сервиса и почему стоит доверить этому продукту часть значимых процессов.
Разбор показывает, что ошибка лендинга заключается не только в неудачных формулировках. Он выстроен от продукта к пользователю: сначала предполагается, что приложение и его функции сами по себе интересны топ-менеджеру, а затем перечисляются возможности. Илья и Иван предлагают обратную логику: сначала нужно понять, какие разные сегменты руководителей существуют, какие задачи они выполняют, в каком контексте возникает потребность, что они стремятся не делать лично и по каким критериям оценивают хороший результат. Только после этого можно понять, какие функции действительно стоит показывать и как их связать с ценностью.
Илья Красинский в разборе Альфа-Босс подчёркивает, что удобство выполнения действия не делает это действие желательным для пользователя. Топ-менеджер может технически иметь возможность оформить заявку, изучить тарифы, поставить поручение или проверить его исполнение в мобильном приложении. Но из этого не следует, что он хочет заниматься этими действиями лично. В его интерпретации лендинг предлагает руководителю «поебаться с продуктом» в ситуации, когда у него и без того есть избыток задач, рисков и ответственности.
Главная причина состоит в том, что перечисленные действия относятся к работам, которые руководитель часто стремится делегировать, сократить или снять с себя. Илья говорит, что не знает топ-менеджеров, которые хотят лично ставить поручения и контролировать их выполнение как самостоятельную ценность. В его примере руководитель может поручить сотруднику зафиксировать задачу, поставить её на контроль и проверить результат к определённому сроку. Наличие людей и управленческой структуры меняет саму задачу топ-менеджера: ему нужен не интерфейс для ручного администрирования каждого шага, а уверенность, что значимый вопрос будет решён без лишнего вовлечения с его стороны.
Это продолжает общую мысль Ивана Замесина о том, что ценность продукта измеряется эффективностью выполнения job. Если приложение просто делает ручную работу чуть удобнее, но не избавляет пользователя от нежелательного участия, оно может не попасть в его реальную потребность. Для топ-менеджера важнее может быть не возможность «контролировать», а отсутствие необходимости постоянно контролировать, своевременное получение важного сигнала, понятная уверенность в статусе критической ситуации или автоматическое доведение вопроса до решения.
Илья также отмечает, что у руководителей существуют разные стили управления. Поэтому даже одинаковые на вид функции контроля и поручений не могут автоматически считаться универсальной ценностью для всего сегмента «генеральные и финансовые директора». Один руководитель может делегировать почти всё, другой лично участвовать в отдельных решениях, третий нуждаться в данных перед совещанием, четвёртый — в защите от организационных рисков. Без сегментации по работам и контекстам лендинг начинает обращаться к условному усреднённому руководителю, который может не существовать как реальный пользователь.
В этом смысле удобная реализация не компенсирует ошибку в выборе объекта автоматизации. Если продукт упрощает действие, которое клиент не хочет делать, он улучшает не ту часть его жизни. Более сильным решением было бы понять, какую работу руководитель на самом деле пытается выполнить — например, не пропустить критическое решение, не оказаться неподготовленным, не потерять влияние, не стать крайним или обеспечить движение важного вопроса, — и затем убрать из его пути как можно больше ручных операций.
Иван Замесин в конце встречи показывает алгоритм диагностики, предназначенный для самопроверки продуктовой работы. Его цель — не просто поставить общую оценку продукту, а последовательно проверить, насколько команда понимает сегменты, задачи клиентов, ценность, источники информации, коммуникацию и логику продуктовых решений. Чек-лист переводит обсуждение из абстрактного уровня «у нас вроде бы есть продуктовая работа» в набор конкретных вопросов, на которые можно дать проверяемые ответы.
Первый крупный блок диагностики касается сегментации. Иван предлагает проверить, используются ли Core Job и Big Job для выделения сегментов, есть ли подтверждение, что команда работает именно на определённый сегмент, оценивается ли потенциальная маржинальность, известен ли размер сегмента и понимает ли команда возможность создавать для него дополнительную ценность. Важна не декларация о целевой аудитории, а наличие оснований считать выбранный сегмент реальным, доступным и значимым для бизнеса.
Отдельно в чек-листе рассматриваются источники знания о клиентах. Иван упоминает вопросы о том, знает ли команда сегменты конкурентов, понимает ли личные работы руководителей и клиентов, имеет ли собственный опыт продаж и опирается ли на реальные данные, а не только на внутренние предположения. Этот блок связан с предыдущей частью встречи, где обсуждались интервью с платящими клиентами, количественные исследования, цифровой след, экспертные интервью и разговоры с людьми, которые уже продают нужному сегменту.
Следующий блок касается создания ценности. В нём проверяется, понимает ли команда, какие работы клиента выполняет продукт, как создаётся новая ценность и как она связана с последовательностью действий пользователя. Иван противопоставляет такой подход ситуации, когда команда просто «пилит фичи» или формально использует CJM без опоры на реальные jobs. Смысл диагностики состоит в том, чтобы увидеть, исходит ли продукт из причинно-следственной связи «задача клиента — ценность — способ доставки ценности», либо команда начинает с готового решения и затем пытается оправдать его существование.
Ещё одна часть чек-листа посвящена коммуникации. По словам Ивана, вопросы, которые они использовали при разборе лендингов Yoga Academy, приложения для подготовки к собеседованиям и Альфа-Босс, относятся именно к этому разделу. Проверяется, коммуницируется ли Core Job или Big Job, может ли человек узнать себя в точке А, показана ли точка Б, есть ли Aha-момент, снижаются ли барьеры и страхи, понимает ли пользователь ценность, а также соответствует ли CTA первому micro job, а не требует сразу слишком большой инвестиции времени, денег или усилий.
Механика чек-листа предполагает оценку ответов в баллах. Иван говорит, что у части вопросов есть повышенный вес: если вопрос помечен как x2, балл умножается на два. После заполнения нужно посчитать общий результат. Он называет ориентир: если итог меньше тридцати баллов, продукту «очень-очень поможет сегментация». При этом ценность диагностики не сводится к числу. Иван подчёркивает, что по каждому отсутствующему элементу в чек-листе указано, что делать дальше: например, когда сегментации нет, можно выделять сегменты экспертно при достаточной экспертизе или переходить к дополнительному исследованию, если её не хватает.
Илья Красинский положительно реагирует на такую форму, потому что она превращает разрозненные рассуждения о JTBD в воспроизводимый инструмент. В его трактовке методология — это последовательность действий, которая даёт предсказуемый результат. Именно поэтому чек-лист важен: он помогает разным людям не просто повторять терминологию, а проверять ключевые условия качественной продуктовой работы и видеть, где именно находятся пробелы — в сегментации, ценности, исследовании, коммуникации или выборе решения.
Илья Красинский в финале встречи просит участников, которые будут использовать диагностический чек-лист и другие материалы Ивана Замесина, ссылаться на Ивана как на автора. Для Ильи это не формальный вопрос вежливости. Он подчёркивает, что за инструментами стоят большое количество кейсов, попыток, экспериментов, доработок и ответов на вопросы. Когда методология распространяется без указания создателя, исчезает видимость этой проделанной работы и создаётся впечатление, что схема возникла сама собой или представляет собой очевидный набор общих идей.
Вторая причина связана с качеством воспроизведения подхода. Илья говорит, что методологии часто начинают пересказывать и искажать. Он приводит пример формул LTV, которые приписывали ему, хотя в таких пересказах он регулярно находил ошибки. В его логике ссылка на автора помогает сохранить связь с актуальной версией метода, исходными определениями и необходимыми уточнениями. Это особенно важно для подходов, где небольшая подмена понятия может изменить логику целиком: например, смешать job с проблемой, ценность с фичей, сегментацию с демографическим портретом или исследование с формальным набором интервью.
Илья отдельно оговаривает, что в целом спокойно относится к копированию и даже к пиратству. Однако он различает свободное распространение идеи и потерю авторства. Копирование может помогать распространению полезных методов, но отсутствие ссылки на источник повышает риск, что метод будут применять в упрощённом, субъективном или неверно интерпретированном виде. Кроме того, автор продолжает развивать инструмент, замечать ограничения и выпускать обновления, поэтому сохранение связи с ним полезно и для тех, кто применяет подход.
Эта мысль перекликается с рассуждением Ильи об ABCD/X-сегментации. Он признаёт, что его собственный фреймворк был основан на большом количестве реальных сделок и разборов, но считает, что не успел довести его до достаточной воспроизводимости: разным людям не хватало кросс-чеков, поэтому они применяли его по-разному. Для него это пример того, почему нельзя сводить методологию к набору красивых терминов или схем. Нужно понимать, как она создавалась, какие ограничения в ней обнаружены и насколько стабильно она даёт результат в руках разных людей.
Таким образом, сохранение авторства в разговоре понимается как способ поддерживать качество знания. Оно признаёт труд создателя, позволяет обращаться к первоисточнику за уточнениями и обновлениями, снижает риск ложных интерпретаций и помогает не превратить рабочую методологию в набор упрощённых, но плохо применимых лозунгов.
Илья Красинский с самого начала встречи формулирует свою мотивацию как сопротивление привычке компаний бесконечно «пилить фичи». По его словам, он регулярно видит одну и ту же картину в EdTech, интернет-магазинах, банках, сервисах, SaaS, B2B- и B2C-компаниях: команды создают новые функции, но не начинают с понимания того, какие задачи людей должны решать и какую ценность реально создавать. Его интерес к распространению JTBD связан с желанием дать людям внутри компаний аргументацию, которая позволит хотя бы сопротивляться этому потоку фичей.
Иван Замесин объясняет, что причина проблемы часто лежит не в некомпетентности отдельных исполнителей, а в том, как запускаются продуктовые инициативы. Бизнес-руководитель может решить сделать новый продукт, исходя из технологии, категории рынка или собственной идеи: например, компания делает B2C-продукт и решает сделать B2B-продукт на тех же технологиях. Затем это решение передаётся команде как задача «сделать продукт». Если исходная причинно-следственная связь между задачами клиента, ценностью и бизнес-результатом не была построена, команда получает в качестве единственно понятного объекта работы функции и начинает создавать их.
По позиции Ивана, JTBD нужен не как очередной фреймворк, который следует отдельно продавать руководителям, а как способ помогать им достигать их собственных целей. Он прямо говорит: не нужно продавать исследования и методологии. Когда руководитель слышит предложение сделать исследование, он может воспринимать это как дополнительную работу, риск срыва планов и угрозу личным обязательствам. Вместо этого продуктовая команда должна показать, как более точное понимание сегментов и задач поможет руководителю выполнить план, получить сильный отчёт перед акционером, снизить риск провала, сохранить позицию и получить признание.
Илья поддерживает эту мысль на примере внедрения Kanban. По его словам, метод лучше внедряется, когда его не называют методологией, а показывают конкретную проблему: задачи застревают, возникает затор, и нужно изменить порядок работы. Такой же подход применим к JTBD. Не требуется убеждать всех «учить фреймворк». Гораздо важнее показать на конкретном продукте, что команда тратит ресурсы на неподтверждённые функции, плохо попадает в сегмент, не умеет объяснить ценность, создаёт лишние шаги для пользователя или обслуживает убыточных клиентов.
В разговоре несколько раз показывается, что переход к задачам клиента меняет практические решения. В Cevy Kids уход от абстрактного продукта про развитие ребёнка к сегменту родителей детей с СДВГ и их конкретным задачам привёл к снижению стоимости продукта в пять раз, улучшению экономики и росту удовлетворённости. В кейсе Skysmart понимание jobs родителей и детей позволило изменить коммуникацию продаж и методологию обучения, после чего средний чек вырос в три с половиной раза. В e-commerce обсуждались проблемы discovery и гипервыбора: улучшение пути выбора может быть важнее добавления новых возможностей, потому что человек иначе вообще не дойдёт до покупки.
Илья в заключении подчёркивает, что распространение подхода не должно превращаться в агрессивную продажу «новой экономики» или очередного курса. Его просьба к участникам — применять методы на практике, рассказывать о них дизайнерам, менеджерам и коллегам, показывать собственным примером, что можно меньше делать лишнего и больше создавать полезного. Он описывает это как попытку дать людям доброй воли инструменты, с которыми они будут меньше страдать от бессмысленной работы и смогут создавать более качественные продукты.
Следовательно, распространение JTBD в этой встрече имеет не только образовательную цель. Это попытка изменить порядок продуктового мышления: сначала задача, сегмент, контекст, критерии и ценность; затем коммуникация, путь пользователя и только после этого — фичи как возможный способ доставки результата. Чем лучше команда удерживает эту последовательность, тем меньше вероятность, что она будет создавать функции, существующие только потому, что их можно создать.
Иван Замесин завершает встречу личным объяснением своей мотивации. По его словам, на протяжении карьеры он часто не понимал, что делать в продукте, несмотря на большую ответственность, ожидания, клиентов, пользователей, необходимость запускать продукты с нуля и работать с инвестициями. Внешне можно было демонстрировать уверенность и ссылаться на знакомые кейсы, но за этим, как он говорит, стояли тревога и фрустрация: отдельные примеры не переносились на его ситуацию, а существующие фреймворки не давали ясного ответа, как применять их на практике.
Для Ивана поиск ответа на вопрос «как делать продукт» стал основной линией работы. Он говорит, что некоторое удовлетворительное объяснение появилось у него пару лет назад, а более сильный и цельный ответ — осенью 2024 года. В контексте всей встречи этим ответом является не единичная техника, а причинно-следственная система: нужно понимать бизнес-задачу, сегменты, jobs, ценность, граф работ, барьеры, контекст, критерии успеха и возможные стратегии. Тогда discovery перестаёт быть поиском абстрактных «инсайтов» и становится поиском данных, которые позволяют реализовать одну из стратегий для решения конкретной бизнес-задачи.
Иван описывает продуктовую работу как интеллектуальную игру не в смысле безответственного развлечения, а как структурированное упражнение, в котором становится понятнее, что именно исследовать и какие решения проверять. Если нужно масштабировать продукт, можно рассматривать стратегии добавления нового сегмента, смещения в более маржинальный сегмент, выхода в B2B или B2C, работы с другими задачами текущих клиентов, изменения ценового сегмента или географического расширения. Если нужно увеличить ценность, можно изучить граф работ и найти, где дать ясность, снизить барьер, перенести ценность раньше или сократить путь пользователя. Наличие такого пространства стратегий снижает ощущение, что команда действует наугад.
Развитие ИИ, по мнению Ивана, усиливает этот переход. Он говорит, что нейросети уже хорошо помогают в продуктовых задачах: генерируют гипотезы, графы работ, гипотезы ценности, коммуникации для лендингов, тарифы, допродажи и другие варианты решений. В его прогнозе сочетание инструментов вроде Lovable и OpenAI в ближайшем будущем позволит за вечер получать приложение, которое уже можно монетизировать. Для него это означает, что технический барьер между гипотезой и проверкой продукта становится всё ниже.
Илья Красинский соглашается, что это уже частично происходит, хотя замечает, что в дизайне и программировании ещё остаются сложности. Он подчёркивает, что во многих случаях код вообще не является главным условием решения job. В качестве примера он говорит, что ИИ уже помогает ему составлять юридические документы, с которыми можно проходить службу безопасности. В его интерпретации это показывает, что ценность создаётся не кодом как таковым, а тем, что инструмент берёт на себя часть работы, которую раньше приходилось выполнять специалисту вручную.
При этом Илья обращает внимание на условие качественной работы с ИИ: если просто задать общий вопрос, результат будет усреднённым и слабым. Чтобы получить содержательную гипотезу, нужно точно описать сегмент, ситуацию, контекст, задачу и критерии клиента. Он связывает это с JTBD: формулировка «кто этот человек, когда он находится в этой ситуации, чего хочет и как оценивает результат» позволяет активировать не общий шаблонный ответ, а более специфические сценарии. По его словам, ИИ может строить деревья из десятков сценариев, среди которых команда обнаруживает сегменты, на которые раньше не обращала внимания.
Таким образом, JTBD и ИИ в обсуждении дополняют друг друга. JTBD задаёт язык и структуру мышления, которые позволяют понять, что именно нужно исследовать, какую работу клиента улучшать и как оценивать ценность. ИИ ускоряет генерацию гипотез, подготовку материалов, поиск сценариев и создание первых решений. Вместе они уменьшают неопределённость, потому что продуктовая работа становится не набором интуитивных ставок и бесконечного производства фичей, а более управляемым процессом поиска, проверки и перепроектирования пути клиента.