AI-анализ встреч и документов
Яндекс: Иван Замесин Не указано: Слушатель
Встреча была посвящена customer development: поиску пользовательских сегментов, проведению проблемных интервью и проверке продуктовых гипотез до масштабной разработки. Целью было дать практический инструмент изучения текущего опыта, потребностей, болей и критериев успеха пользователей. Рассматривались структура интервью, оценка частотности и эмоциональной силы инсайтов, формулирование job stories, предпродажи, MVP и количественная валидация. Ключевой смысл — сокращать стоимость и время получения обратной связи, опираться на факты прошлого поведения и приоритизировать решения для платёжеспособных сегментов с сильной потребностью.
Лекция Ивана Замесина (Яндекс) посвящена customer development как способу снизить неопределённость в продуктовой работе и быстрее находить продукты, за которые пользователи готовы платить. Главная цель — научить продуктовых менеджеров, дизайнеров, аналитиков и предпринимателей не строить решения на собственных предположениях, а системно изучать реальный пользовательский опыт, выявлять сегменты с сильной потребностью, проверять спрос до дорогой разработки и превращать инсайты в приоритеты продукта. В логике Замесина современная продуктовая роль заключается уже не только в исполнении готового плана, а в поиске смысла: для кого создаётся продукт, какую работу он должен выполнить, какая проблема действительно важна и почему пользователь сменит привычный способ действия.
Основой подхода является изучение текущего поведения, а не сбор мнений о будущем продукте. Иван Замесин подчёркивает, что из интервью можно надёжно извлечь факты: как человек сейчас решает задачу, сколько тратит денег, времени и внимания, какие альтернативы использует, чем недоволен, какой результат считает успехом и что произойдёт, если задача не будет решена. Напротив, обещания вроде «я бы пользовался» или «я бы купил» ненадёжны, поскольку отражают текущее эмоциональное состояние человека, а не его будущее действие. Поэтому исследование должно быть привязано к конкретным прошлым эпизодам: важно попросить рассказать, когда проблема возникла в последний раз, что происходило пошагово, почему это было сложно, какие последствия возникли и как человек пытался справиться.
Центральный инструмент лекции — проблемное интервью. Его задача не в том, чтобы подтвердить идею команды или собрать список желаемых функций, а в том, чтобы обнаружить сильные и повторяющиеся потребности. Иван Замесин предлагает начинать с вопроса о текущем способе решения задачи, затем выяснять цену существующего решения, критерии успеха и неудобства пользователя. Каждая найденная проблема должна быть исследована по повторяющемуся циклу: последний реальный случай → причина сложности → эмоция → оценка эмоции по шкале от 1 до 10 → частота возникновения. Такой подход помогает отличить случайное неудобство от значимой проблемы. Особенно ценны ситуации, в которых пользователь не просто испытывает раздражение, а сталкивается со страхом, потерей контроля, риском потерять деньги, важный результат, партнёра или время.
Инсайты, по позиции Замесина, нужно оценивать одновременно по двум осям: частотности и эмоциональной силе. Проблема, о которой рассказал один человек, может быть яркой, но оставаться частным случаем; значимым сигналом она становится, когда повторяется у большинства представителей сегмента. При этом частая, но слабая боль не всегда создаёт готовность платить. Поэтому приоритет получают потребности, которые и распространены, и вызывают сильную эмоцию — ориентировочно на уровне 8–10 из 10. Для массового B2C допускается работа и с менее сильными, но очень распространёнными неудобствами либо с небольшими улучшениями пользовательского опыта: там ценность может возникать благодаря масштабу аудитории, регулярности поведения и борьбе за время и внимание.
Результаты интервью следует оформлять не как набор цитат или пожеланий, а как job stories — единообразно описанные пользовательские потребности в конкретном контексте. Для каждой такой истории фиксируются повторяемость, эмоциональная сила, последствия и текущие обходные пути. Это позволяет собрать исследовательскую доску, сопоставить разные боли, отложить менее приоритетные задачи в бэклог и не превращать громкие единичные запросы в немедленные задачи разработки. Иван Замесин подчёркивает, что важными инсайтами могут быть не только явные боли, но и неосознаваемые неудобства, к которым пользователь привык, сильные положительные ожидания — delighters — а также детали сценария и пользовательские костыли. Например, необычное использование календаря для личных заметок или сложность согласования встреч в нескольких часовых поясах могут раскрыть потребность, которую пользователь не сформулировал бы при общем вопросе «что вам не нравится?».
Отдельно рассматривается поиск и уточнение сегментов. По мнению Ивана Замесина, первоначальная гипотеза о целевой аудитории почти всегда неточна: команда ещё не знает рынок, роли участников процесса, мотивации, бюджет и реальные ограничения пользователей. Поэтому сегменты нужно формулировать как гипотезы, ранжировать по размеру, платёжеспособности, доступности и потенциальной силе боли или ценности delighter, а затем пересматривать после первых интервью. В B2B особенно важно разделять пользователя, исполнителя, инициатора, лицо, принимающее решение, и покупателя. Наличие неудобной ручной работы ещё не означает платёжеспособный спрос: если проблему можно делегировать ассистенту, а руководитель не ощущает её как критичную, продукт может не получить продаж. Подтверждённым считается сегмент, в котором совпадают сильная потребность, возможность принять решение и готовность платить.
После поиска проблемы должно следовать не полноценное строительство продукта, а решенческое интервью и попытка продажи. Иван Замесин предлагает оформить гипотезу в слайды, прототип, Google Docs, ручную услугу или иной минимальный MVP и прямо предложить пользователю купить. Реальный платёж, предоплата, гарантийное письмо, обязательство запустить пилот или согласие выделить рекламный бюджет — значительно более сильный сигнал, чем интерес к идее. Если клиент не покупает, отказ нужно разбирать: чего не хватило, что оказалось непонятным, неубедительным или дорогим, какие риски сохраняются. Возражения не должны автоматически превращаться в новые фичи; они становятся следующими гипотезами, которые проверяются на последующих клиентах. Если после нескольких итераций продажи не появляются, следует закрыть или пересобрать гипотезу, а не продолжать разработку из желания защитить исходную идею.
Замесин выстраивает общий цикл развития продукта как последовательность: поиск сегмента и потребности → проблемные интервью → гипотеза решения и ручная продажа → качественная валидация → количественная валидация → итеративное улучшение. Интервью нужны, чтобы понять контекст и причины поведения; прототипы и MVP — чтобы проверить восприятие конкретного решения; количественные эксперименты — чтобы увидеть конверсию, retention и unit-экономику на более широком масштабе. Даже после запуска рекомендуется разговаривать с каждым пользователем раннего MVP: низкая конверсия может быть вызвана не отсутствием спроса, а простыми препятствиями в пути пользователя — непонятным CTA, неясной ценностью, сложной оплатой или неочевидным интерфейсом. Метрики показывают, что произошло, а разговор с пользователем помогает понять почему.
Существенный мотив лекции — необходимость сделать ошибки дешёвыми и быстрыми. Иван Замесин ссылается на распространённую проблему стартапов: команды месяцами или годами развивают продукт в изоляции, а первый реальный фидбэк получают только после значительных расходов на разработку, персонал и инфраструктуру. По его позиции, при высокой вероятности провала новых гипотез задача команды не в том, чтобы избежать всех ошибок, а в том, чтобы как можно раньше обнаруживать неверные предположения. Десять–двадцать интервью, прототип, предпродажа или тестовая рассылка могут стоить несопоставимо дешевле, чем создание продукта для несуществующей потребности. В этом смысле custdev — не разовое исследование «перед запуском», а постоянный механизм сокращения времени от идеи до обратной связи.
Лекция также разделяет несколько типов продуктовой ценности. Наиболее понятный случай — painkiller, когда пользователь осознаёт сильную проблему и ищет способ от неё избавиться. Сложнее работать с неосознаваемыми болями, привычными костылями и инерцией: продукт должен показать пользователю заметно лучший способ действия, чтобы преодолеть привычку и бездействие. Ещё сложнее — массовые B2C-продукты, основанные на удовольствии, новизне, социальном одобрении, ожидании награды и дофаминово-эндорфиновом цикле, такие как социальные сети, новостные сервисы или Tinder. Для них интервью дают лишь частичные сигналы: пользователь не всегда способен объяснить, почему возвращается в продукт и будет ли возвращаться в будущем. Поэтому такие гипотезы требуют особенно реалистичных high-fidelity-прототипов, MVP и поведенческой проверки, а не только разговоров.
Для уже работающих продуктов Иван Замесин предлагает применять ABCD-сегментацию клиентской базы. A- и B-сегменты — это клиенты с сильной потребностью, быстрым циклом сделки, высокой выручкой и сравнительно низкой нагрузкой на поддержку; именно на них должны быть направлены сильные сотрудники, продуктовые улучшения и маркетинговые KPI. C- и D-сегменты, напротив, могут создавать много обращений, долго принимать решения, требовать дорогого сопровождения, мало платить или не платить вовсе. Спикер предупреждает о реактивной ловушке: команда видит громкий запрос в поддержке и сразу создаёт задачу, хотя этот запрос может исходить от низкоценного сегмента. В массовом B2C и B2B такие группы не обязательно нужно исключать, но их обслуживание следует максимально автоматизировать, не позволяя им поглощать непропорционально много продуктовых и операционных ресурсов.
Итоговый тезис Ивана Замесина состоит в том, что успешный продукт возникает не из уверенности команды в собственной идее, а из повторяющегося контакта с реальностью пользователя. Нужно искать не «что бы построить», а у кого, в каком контексте и почему уже возникает значимая потребность; проверять не намерения, а реальные действия и готовность платить; не бояться отказываться от сегментов, функций и ценовых гипотез; регулярно превращать обнаруженные факты в job stories, прототипы и эксперименты. Customer development становится дисциплиной, которая помогает создать не просто технически работающий продукт, а решение, способное преодолеть инерцию пользователя, создать заметную ценность и подтвердить свою жизнеспособность на рынке.
Оглавление:
Иван Замесин (Яндекс) представляет customer development как один из важнейших навыков не только для предпринимателей, но и для любых продуктовых специалистов. Его исходная позиция состоит в том, что границы профессиональных ролей становятся менее жёсткими: ценность специалиста всё меньше определяется способностью качественно исполнить поставленную задачу и всё больше — способностью понять, какую задачу вообще стоит решать.
Custdev в этой логике — практический инструмент изучения реального опыта пользователей и их потребностей. Он нужен, чтобы принимать решения о будущем продукта не на основании собственных предположений команды, а на основании повторяющихся фактов о поведении, затруднениях, целях и эмоциях людей. Спикер подчёркивает, что результатом такого исследования должен быть не абстрактный набор «мнений пользователей», а понимание, что именно делать в продукте, в какой последовательности и почему.
В широком продуктовом процессе customer development сокращает расстояние между гипотезой и обратной связью. Вместо длительной разработки решения в изоляции команда сначала разговаривает с людьми, уточняет сегменты, изучает текущие способы решения задачи, проверяет наличие и силу проблемы, а затем переходит к продаже, MVP и последующей количественной проверке. Таким образом, custdev выступает фундаментом для выбора направлений развития, снижения стоимости ошибок и поиска продукта, который действительно нужен рынку.
Иван Замесин противопоставляет современную роль продакт-менеджера тому, какой она была примерно десять лет назад. Ранее продакт, по его описанию, мог вести задачу по заранее определённому плану: от начала диаграммы Гантта до завершения работ и получения результата внутри компании. Такая роль была преимущественно связана с организацией исполнения уже сформулированной задачи.
Теперь, по мнению Замесина, продакт отвечает за более ранний и более неопределённый слой работы — за смысл продукта. Это означает необходимость самостоятельно искать пользовательские сегменты, понимать, для кого создаётся продукт, какую потребность он закрывает, насколько эта потребность существенна и за что пользователи потенциально готовы платить. Задача продакта не ограничивается управлением бэклогом или координацией команды: ему нужно установить, какие проблемы заслуживают инвестиций.
Эта эволюция делает исследование пользователей центральной частью продуктовой работы. Вместо уверенности, что команда заранее знает рынок и потребности аудитории, предлагается исходить из гипотез: сегмент и проблема предполагаются, затем проверяются в интервью и при необходимости отбрасываются. Продакт должен быть готов обнаружить, что первоначальная конструкция рынка неверна, а нужный сегмент, сценарий или ценностное предложение находятся в другом месте.
Иван Замесин связывает customer development не только с работой продакт-менеджера, но и с развитием продуктового дизайнера и аналитика. Он утверждает, что специалистам недостаточно владеть собственными техническими инструментами, если они не понимают пользователей и контекст их задач. Компетенции разных профессий размываются именно потому, что каждая из них должна быть связана с пониманием продукта и его аудитории.
Для продуктового дизайнера custdev важен как основа для осмысленных A/B-тестов. По логике спикера, тестировать интерфейсные решения без понимания сегмента, его задач и болей недостаточно: эксперимент может быть технически корректным, но проверять несущественную гипотезу. Понимание потребности позволяет сформулировать, что именно нужно улучшить в пользовательском опыте и какую реакцию считать полезной.
Для аналитика это также необходимое условие качественного эксперимента. До настройки метрик, расчёта конверсий или анализа результатов нужно понимать, кто является пользователем, что он пытается сделать, что для него считается успехом и в какой точке возникает затруднение. Custdev даёт этот слой контекста, благодаря которому аналитик способен не только измерить изменение метрики, но и связать её с реальной пользовательской потребностью.
Иван Замесин формулирует цель customer development как предоставление простого инструмента для изучения текущего опыта и потребностей людей. Ключевое слово здесь — «текущего»: исследование должно быть направлено не на фантазии пользователя о будущем продукте, а на то, как он уже действует, с какими обстоятельствами сталкивается, что использует и что испытывает в реальной ситуации.
Такой подход нужен, чтобы перейти от общих рассуждений о целевой аудитории к конкретным основаниям для продуктовых решений. Из рассказов пользователей можно понять, как устроена их жизнь или работа вокруг потребности, какие альтернативы уже используются, что их не устраивает, каковы издержки существующего процесса и какой результат воспринимается как успешный. Эти данные затем становятся материалом для выбора функций, ценностного предложения и порядка приоритизации.
Спикер показывает, что интервью не должно сводиться к одному вопросу о том, «что болит». Исследователь должен постепенно восстановить целый сценарий: способ решения задачи, цену существующего решения, затрачиваемое время и внимание, последствия неудачи, эмоциональный опыт и частотность проблемы. Именно совокупность этих фактов позволяет отличить случайное неудобство от устойчивой и значимой потребности.
Иван Замесин предлагает проводить большое число интервью, используя повторяемую структуру из восьми типичных вопросов. Эта структура призвана помочь исследовать существующую потребность пользователя, а не сразу обсуждать предполагаемое решение. Начало интервью посвящено тому, как человек уже справляется с задачей, сколько платит за используемый способ, какие ресурсы затрачивает и насколько удовлетворён получаемым результатом.
Следующий важный блок касается успеха пользователя. Респонденту предлагается объяснить, как он поймёт, что решил свою потребность хорошо. Затем при необходимости задаётся вопрос о последствиях невозможности решить задачу. Он помогает оценить серьёзность потребности и сопоставить её с другими: в одних случаях неудача может приводить к потере денег, рабочих результатов или существенным неудобствам семьи, а в других — лишь к небольшому разочарованию.
После этого интервьюер спрашивает о повседневных сложностях и болях. Получив первую проблему, он не ограничивается поверхностным ответом, а несколько раз проходит через один и тот же цикл уточнений: просит вспомнить последний реальный случай, выясняет, почему ситуация была трудной, какую эмоцию она вызвала и насколько сильной эта эмоция была по шкале от одного до десяти. По замыслу Замесина, такая последовательность превращает интервью в инструмент сбора проверяемых фактов, частотных проблем и эмоциональных сигналов.
Первый вопрос, который Иван Замесин предлагает задавать пользователю, — как тот сейчас решает свою потребность. Этот вопрос ставит исследование в практическую плоскость: важно не то, каким решение кажется интервьюеру, а то, что человек реально делает в настоящее время. Пользователь может применять существующий сервис, выполнять работу вручную, поручать её другому человеку, мириться с неудобством или вообще не решать задачу.
Описание текущего способа решения открывает доступ к контексту потребности. Оно позволяет увидеть альтернативы продукту, привычки пользователя, используемые инструменты, существующие компромиссы и ограничения. Если команда не знает, как пользователь обходится без её продукта, ей трудно понять, с чем именно она конкурирует. Конкурентом может быть другой сервис, ручной процесс, ассистент, привычка или бездействие.
Этот вопрос также создаёт основу для дальнейшего разговора о цене, времени, внимании и удовлетворённости. Пользователь должен не просто сказать, что задача у него есть, а восстановить цепочку действий, через которую он пытается её решить. Именно на этой цепочке затем можно находить точки напряжения, неэффективные шаги, скрытые костыли и причины, по которым существующий способ не даёт нужного результата.
Иван Замесин предлагает измерять стоимость текущего решения потребности шире, чем только прямыми платежами. Если пользователь платит за решение деньгами, интервьюер должен выяснить сумму и логику этих расходов. Это помогает понять экономическую ценность проблемы и существующий уровень готовности платить за её устранение.
Однако во многих продуктах, особенно массовых B2C-сервисах, пользователи могут платить не деньгами, а вниманием и временем. В качестве примеров спикер называет сервисы вроде Дзена, главной страницы Яндекса или Яндекс Музыки. Для таких продуктов важно спрашивать, сколько времени человек тратит, сколько внимания отдаёт и насколько его устраивает этот обмен. Пользовательская ценность может заключаться не в финансовой экономии, а в получаемом опыте, интересе, развлечении или привычном способе заполнить время.
Такой взгляд позволяет исследовать реальную цену существующего поведения. Даже бесплатный для пользователя продукт не является бесплатным в полном смысле: он конкурирует за ограниченные ресурсы человека — время, внимание и эмоциональную вовлечённость. Поэтому оценка затрат помогает определить, насколько значима потребность и есть ли возможность создать продукт, который даст пользователю более выгодный обмен.
После выяснения текущего способа решения потребности Иван Замесин предлагает спрашивать, доволен ли пользователь этим способом. Этот вопрос нужен не как формальная оценка сервиса, а как способ увидеть разрыв между тем, что человек вынужден делать сейчас, и тем, какой результат он хотел бы получать.
Удовлетворённость важна потому, что само наличие существующего решения ещё не означает отсутствия продуктовой возможности. Пользователь может регулярно платить за услугу, пользоваться привычным инструментом или тратить много времени на ручной процесс, но при этом оставаться неудовлетворённым. В таком случае исследователю нужно понять, какие именно части опыта вызывают недовольство, как часто это происходит и насколько сильно это влияет на человека.
Ответ о довольстве не следует считать окончательным. В дальнейшем интервью человек может назвать проблему, которая изначально не была для него очевидной или которую он привык считать нормой. Поэтому общий вопрос об удовлетворённости должен сопровождаться подробным разбором реальных случаев: когда возникла трудность, почему она оказалась существенной и какие эмоции вызвала.
Второй базовый вопрос проблемного интервью, по Ивану Замесину, звучит так: «Что для вас успех?» Он называет этот вопрос лакмусовой бумажкой, позволяющей понять пользовательские KPI. Смысл состоит в том, чтобы выяснить не просто наличие задачи, а желаемый конечный результат, по которому сам пользователь определит, что потребность решена хорошо.
Для массовых B2C-продуктов люди не всегда осмысляют свои цели как KPI. Но в прикладных услугах критерии успеха обычно формулируются довольно ясно. В качестве примера спикер приводит клининг: успех для клиента состоит не в самом факте заказа уборки, а в конкретном жизненном результате — проснуться в субботу без необходимости заниматься домашними делами и вернуться вечером в чистую квартиру.
Такое уточнение помогает не подменять потребность характеристиками продукта. Пользователь покупает не набор функций и не сам процесс выполнения услуги, а состояние, которого хочет достичь. Понимание этого состояния нужно, чтобы оценивать будущие решения: они должны быть направлены на достижение пользовательского результата, а не на реализацию того, что команда считает очевидной функциональностью.
Иван Замесин отмечает, что вопрос о последствиях невозможности решить потребность следует задавать не всегда, но он особенно полезен при изучении и ранжировании большого числа потребностей. Этот вопрос помогает определить, насколько критична проблема для пользователя и следует ли работать с ней в первую очередь либо вовсе исключить из приоритетов.
Спикер предлагает спрашивать, что произойдёт, если человек не сможет пользоваться продуктом или привычным способом решения задачи. Ответы могут показывать серьёзные последствия: ребёнок не сможет ходить в нужный детский сад, семье придётся тратить больше времени на дорогу, пользователь не получит премию на работе или столкнётся с ухудшением семейного благополучия. Такие последствия указывают на высокую цену сбоя и потенциально сильную потребность.
Для сравнения приводится пример невозможности зайти в Tinder в конкретный день. Это может быть неприятно, но, по формулировке спикера, реальных последствий может не возникнуть. Сопоставление подобных случаев позволяет отличать критичные задачи от несущественных. Вопрос о последствиях не заменяет измерение эмоций и частотности, но добавляет важный слой: он показывает цену нерешённой потребности в реальной жизни пользователя.
Иван Замесин рекомендует прямо спрашивать пользователя, что доставляет ему неудобство и с чем ему приходится справляться каждый день. Цель этого вопроса — извлечь из памяти человека его текущие боли и обозначить тему дальнейшего разговора. Он используется как приглашение перейти от общего описания опыта к обсуждению конкретных трудностей.
Спикер предупреждает, что на первый такой вопрос пользователь часто отвечает, что у него «в принципе всё нормально», либо называет лишь одну, две или три проблемы. Это не означает, что других сложностей нет. Скорее, многие проблемы не находятся у человека в активном фокусе внимания: он привык к ним, не успел вспомнить или не считает их достойными упоминания в первые минуты разговора.
Поэтому интервьюер должен сохранить первоначально названные боли, но не считать их исчерпывающим списком. В ходе следующих тридцати минут интервью пользователь может назвать значительно больше проблем, если его погрузить в детали конкретных ситуаций. Вопрос о неудобствах служит стартовой точкой, но полноценное выявление болей происходит через дальнейшее углубление в реальные эпизоды и действия.
По словам Ивана Замесина, интервьюер не должен ожидать, что пользователь сразу перечислит все свои боли в ответ на прямой вопрос. Первое упоминание проблемы — это только вход в исследование, а не готовый результат. Пользователь может осознавать лишь часть неудобств, а многие привычные затруднения остаются незамеченными до тех пор, пока разговор не касается конкретного сценария.
Спикер описывает вопрос «что болит?» как способ договориться с человеком о характере разговора: интервью будет посвящено его сложностям. После этого важно не останавливаться на общих утверждениях, а переходить к подробностям. Чем глубже исследователь разбирает один случай, тем больше связанных трудностей, обходных действий, эмоциональных реакций и контекстных факторов может проявиться.
Практический эффект такого подхода заключается в том, что за интервью длительностью тридцать–сорок пять минут можно собрать не несколько поверхностных жалоб, а набор конкретных болей. Затем они становятся материалом для ранжирования по частотности и силе эмоций. Постепенное извлечение помогает не зависеть от способности человека мгновенно сформулировать свои проблемы и увидеть те потребности, которые не лежат на поверхности.
После того как пользователь назвал проблему, Иван Замесин предлагает задать вопрос: «Расскажи последний раз, когда ты сталкивался с этой проблемой». Этот вопрос переводит разговор из области общих оценок в область фактов. Вместо абстрактного утверждения «у меня есть такая сложность» интервьюер получает возможность разобрать конкретное событие: когда оно произошло, что сделал человек, какие обстоятельства на него повлияли и чем всё закончилось.
Спикер подчёркивает, что такой вопрос нужен прежде всего для проверки того, существует ли проблема в реальном поведении и является ли она частотной. Если пользователь не может вспомнить недавний или подробно описываемый эпизод, это может указывать, что проблема скорее декларируется, чем регулярно влияет на его жизнь. Напротив, насыщенный деталями рассказ показывает, что ситуация действительно происходила и оставила след в опыте человека.
Позже Замесин возвращается к этому принципу на примере голосовых запросов в Chrome. Пользовательница утверждала, что пользуется голосовым поиском, но просьба показать действие выявила, что она лишь однажды увидела соответствующую возможность. Поэтому вопрос о последнем случае и просьба подробно воспроизвести сценарий помогают отделить обобщённое воспоминание от фактического повторяющегося поведения.
Иван Замесин рассматривает частотность как один из двух ключевых параметров для оценки болей. Вопрос о последнем столкновении с проблемой позволяет выяснить не только факт её существования, но и то, насколько регулярно она возникает. В дальнейшем интервьюер должен прямо уточнять, как часто пользователь попадает в подобную ситуацию.
Частотность важна для продуктовой приоритизации: единичный неприятный случай может не быть основанием для создания решения, тогда как регулярно повторяющаяся трудность даже при умеренной силе способна стать значимой. Спикер говорит, что после интервью у команды должны быть боли, упорядоченные в том числе по тому, как часто они проявляются у человека.
Проверка повторяемости нужна и на уровне сегмента. Позже в лекции Замесин уточняет, что инсайт нельзя считать частотным, если его назвали лишь один или два человека из десяти. Значимыми становятся проблемы, которые повторяются у большинства респондентов сегмента. Таким образом, исследователь проверяет частотность в двух масштабах: внутри опыта конкретного человека и между разными людьми, представляющими выбранную аудиторию.
После разбора последнего случая Иван Замесин предлагает неоднократно спрашивать пользователя: «Почему это было тяжело?» Этот вопрос позволяет выйти за пределы описания внешнего события и понять, в чём именно состояла субъективная сложность. Одна и та же ситуация может быть неудобной по совершенно разным причинам: из-за финансового риска, дефицита времени, потери контроля, зависимости от чужой поддержки или угрозы важному результату.
Спикер иллюстрирует это примером поездки на Яндекс.Драйве в аэропорт. Он не смог завершить аренду на крытой парковке из-за проблем с GPS, при этом до вылета оставалось около сорока пяти минут. Формально проблемой было невозможное завершение аренды, но реальная тяжесть состояла в риске продолжать платить за дорогой автомобиль в течение недели, в неопределённости относительно решения и в невозможности быстро получить поддержку.
Повторный вопрос «почему тяжело?» раскрывает причинную цепочку. В приведённом случае страх усиливался тем, что человек не понимал, лететь ли ему на самолёте или пытаться решить проблему на месте, и должен был выбирать между вылетом и риском значительных списаний. Такое углубление помогает команде не зафиксировать поверхностную формулировку боли, а понять её реальные последствия и мотиваторы.
Иван Замесин считает необходимым спрашивать пользователя, какую эмоцию он испытывал в проблемной ситуации. Эмоции здесь выступают не побочной деталью рассказа, а важным индикатором силы потребности. Рациональное описание процесса может скрывать, насколько сильно ситуация влияет на человека, тогда как эмоциональная реакция показывает её субъективную значимость.
В примере с Яндекс.Драйвом эмоциональным состоянием был страх, который спикер описывает как крайне сильный. Пользователь сталкивается не просто с технической ошибкой сервиса, а с паникой из-за возможного финансового ущерба, срочного вылета и отсутствия понятного способа получить помощь. Для продуктовой команды такое понимание меняет смысл проблемы: исправлять нужно не только геолокацию на парковке, но и ситуацию потери контроля в критический момент.
Выявление эмоций позволяет сравнивать разные потребности на общем основании. Некоторые неудобства могут быть частыми, но вызывать лишь слабое раздражение; другие возникают реже, но сопровождаются страхом, сильным разочарованием или потерей важного результата. Спикер предлагает фиксировать эти реакции системно, чтобы позже принимать решения не по громкости отдельных запросов, а по эмоциональной силе и повторяемости проблемы.
После выявления эмоции Иван Замесин предлагает попросить пользователя оценить её по десятибалльной шкале. В примере с арендой автомобиля страх оценивается на десять из десяти. Такая числовая оценка не отменяет качественного рассказа, а делает возможным сравнение разных болей между собой и их последующее ранжирование.
Спикер сопоставляет этот принцип с NPS: сильными считаются проблемы с эмоциональной оценкой выше семи. Если боль находится на уровне восьми, девяти или десяти, она рассматривается как кандидат на приоритетную продуктовую работу. В конце интервью команда должна иметь не просто коллекцию историй, а набор болей, для которых известны и частота возникновения, и сила эмоционального переживания.
Шкала служит практическим инструментом для перехода от интервью к решениям. Она помогает не путать умеренное неудобство с тяжёлой проблемой, за устранение которой пользователь может быть готов платить. При этом оценка должна рассматриваться вместе с конкретным рассказом о ситуации, иначе цифра останется оторванной от причин, контекста и реального поведения пользователя.
Иван Замесин описывает проблемное интервью как повторяющийся цикл, который нужно проходить много раз для каждой обнаруженной боли. После того как человек назвал проблему, интервьюер просит рассказать о последнем случае, выясняет причину сложности, спрашивает об эмоции и её силе. Затем этот же набор вопросов применяется к следующей проблеме или к новому слою уже обсуждаемой ситуации.
Принципиально важно не удовлетворяться первой формулировкой пользователя. Одно утверждение может скрывать несколько самостоятельных болей: техническую неисправность, финансовый риск, нехватку времени, отсутствие поддержки, необходимость принимать решение в условиях неопределённости. Циклическое уточнение даёт возможность разложить общий негативный опыт на его составные части и понять, какая из них имеет наибольшую ценность для будущего решения.
По оценке спикера, тридцати–сорока пяти минут такого интервью достаточно, чтобы выявить около десяти болей, по которым можно работать дальше. Этот результат не возникает из свободной беседы: он требует дисциплины интервьюера, который снова и снова возвращает разговор к реальным эпизодам, причинам трудности и эмоциональной реакции, не переключаясь преждевременно на обсуждение собственного продукта.
По завершении интервью Иван Замесин предлагает ранжировать выявленные боли по частотности. У каждой проблемы должно быть понятно, как регулярно она возникает в жизни или работе пользователя. Это помогает отделить редкий инцидент от устойчивого сценария, который постоянно требует времени, денег, внимания или эмоциональных усилий.
Частотность не должна оцениваться только по общей фразе пользователя. Она проверяется через конкретные эпизоды: когда ситуация была в последний раз, как часто она повторяется, в каких условиях возникает и как человек с ней справляется. В дальнейшем частотность подтверждается также повторением одного и того же инсайта у большинства представителей сегмента.
Ранжирование по частоте позволяет выбирать проблемы, для которых решение способно приносить ценность регулярно. Если боль возникает часто и одновременно вызывает сильную эмоцию, она становится особенно привлекательной для приоритизации. Менее частотные потребности не обязательно отбрасываются, но требуют сопоставления с их последствиями, эмоциональной силой и возможной ценностью для пользователя.
Второй осью ранжирования Иван Замесин называет силу эмоциональной боли. После того как у каждой проблемы есть оценка эмоции по шкале от одного до десяти, их можно расположить от слабых неудобств к наиболее тяжёлым переживаниям. В качестве примера спикер называет последовательность оценок восемь, девять, десять, то есть боли, которые пользователи воспринимают как действительно серьёзные.
Эмоциональная сила важна, потому что она показывает, насколько высока субъективная цена проблемы. Пользователь может сталкиваться с задачей не каждый день, но испытывать сильный страх, разочарование или напряжение, когда она возникает. Такая проблема потенциально создаёт готовность менять поведение, пробовать новый продукт и платить за устранение риска или неудобства.
Ранжирование не заменяет анализ частотности, а дополняет его. В результате интервьюер получает карту проблем, где можно сопоставить распространённость и интенсивность каждой боли. Это даёт основу для решения, с чего начинать работу: первыми должны рассматриваться потребности, которые одновременно повторяются и вызывают наиболее сильные негативные эмоции.
Иван Замесин предлагает простую эвристику для отбора проблем: всё, что оценивается выше семи баллов по эмоциональной силе, следует рассматривать как приоритет для работы. Проблемы с более низкой оценкой, по его словам, обычно не становятся первыми кандидатами на разработку, потому что пользователь не воспринимает их как достаточно тяжёлые.
Этот порог превращает качественное интервью в инструмент принятия продуктовых решений. Вместо того чтобы обсуждать все собранные пожелания на равных, команда может опереться на зафиксированную силу переживания. Если боль оценивается на восемь, девять или десять, это сигнал о высоком напряжении в пользовательском опыте и о вероятной ценности решения.
При этом спикер не утверждает, что оценка выше семи автоматически гарантирует успех продукта. Она является критерием первичной приоритизации вместе с частотностью, контекстом и последствиями проблемы. Но сама дисциплина измерения нужна, чтобы не инвестировать ресурсы в задачи, которые звучат заметно в разговорах, но на самом деле не имеют достаточной эмоциональной значимости для пользователя.
Иван Замесин делает оговорку к правилу о пороге эмоциональной боли: в массовом B2C с проблемами ниже семи баллов всё же могут работать. Это связано с тем, что массовые продукты способны создавать значимый эффект не только за счёт устранения сильной индивидуальной боли, но и за счёт очень широкого охвата пользователей, повторяемого поведения и работы с вниманием.
Ранее в лекции он приводит примеры массовых B2C-сервисов, где пользователь «платит» не прямыми деньгами, а временем и вниманием. В таком контексте слабое, но распространённое неудобство или небольшое улучшение опыта может иметь продуктовый смысл, если оно затрагивает большое число людей и влияет на их регулярное взаимодействие с сервисом.
Тем не менее исключение не отменяет необходимости измерять эмоциональную силу и частотность. Оно лишь означает, что для массового B2C критерии отбора не должны механически копировать логику продуктов с явно выраженной болью или B2B-экономикой. Слабый сигнал может быть важен, но его ценность должна подтверждаться масштабом, повторяемостью и последующей проверкой на продукте.
Иван Замесин предлагает оформлять результаты интервью в виде job stories. После разговора с пользователем команда должна получить не разрозненные цитаты и впечатления, а набор структурированно описанных потребностей. Спикер говорит, что по итогам одного интервью может быть сформировано около десяти таких историй, отражающих реальные пользовательские ситуации и боли.
В дальнейшем он поясняет, почему этот формат полезен: все потребности описываются на одном языке, поэтому их проще сопоставлять и взвешивать. Job story связывает контекст, задачу и желаемое изменение, а не фиксирует преждевременное решение в виде конкретной функции. Это защищает команду от смешения пользовательской проблемы и идеи о том, как её нужно исправить.
Единый формат особенно важен при обработке многих интервью. Он позволяет собрать повторяющиеся инсайты, отметить частотность, добавить силу боли или радости, а затем определить, какие истории заслуживают разработки. Таким образом, job stories становятся мостом между пользовательским исследованием и продуктовым бэклогом.
По логике Ивана Замесина, после ранжирования потребностей команда не должна пытаться одновременно исправить все обнаруженные проблемы. Первая задача — выбрать наиболее частотную и эмоционально сильную боль и начать работать с ней. Именно она имеет наибольший приоритет, поскольку сочетает распространённость в поведении пользователя с высокой субъективной значимостью.
Остальные выявленные job stories не пропадают. Спикер предлагает помещать их в бэклог и возвращаться к ним, когда появятся ресурсы и будет завершена работа над более важными задачами. Такой подход создаёт накопительный эффект от исследований: каждое интервью оставляет после себя не только текущую гипотезу, но и упорядоченный запас будущих направлений.
Ведение бэклога снижает риск реактивной разработки. Команда не обязана бросаться реализовывать каждую услышанную жалобу, но и не должна терять важные наблюдения. Потребности сохраняются вместе с информацией об их частотности и эмоциональной силе, что даёт возможность позднее пересмотреть приоритеты на более содержательной основе.
Иван Замесин выделяет несколько оснований, на которых может строиться продукт. Первое и наиболее понятное — painkiller: пользователь осознаёт, что у него есть боль, прямо сообщает о ней, а продукт предлагает избавление от этой боли. В такой ситуации связь между проблемой и ценностью решения относительно прозрачна: человеку плохо или трудно сейчас, и продукт обещает заметно улучшить его положение.
Второй вариант — неосознаваемая боль. Пользователь может давно привыкнуть к неудобству и перестать воспринимать его как проблему, хотя в его сценарии существует значительный потенциал для улучшения. Здесь задача исследователя сложнее: необходимо погрузиться в фактическое поведение, заметить костыли и ограничения, а затем понять, действительно ли устранение этой привычной трудности создаст ценность.
Замесин также говорит о возможности взять удачное решение у конкурента, сохранив то, что работает, и исправив его недостатки. Отдельную категорию составляют продукты, работающие на дофаминово-эндорфиновом цикле: новостные сервисы, социальные сети, Tinder, Instagram и другие массовые B2C-продукты. Их ценность не всегда состоит в устранении ясно сформулированной боли; они могут создавать удовольствие, вовлечённость, привычку и эмоциональное вознаграждение. В этом смысле delighter связан с созданием позитивного опыта, который трудно полностью проверить одними интервью.
Иван Замесин показывает, что в B2B и B2C различаются как характер потребностей, так и способы их проверки. В B2B боль часто можно связать с понятной экономикой: компания теряет деньги, время или результат, а предложенное решение способно дать измеримую выгоду. Если продукт помогает сэкономить существенную сумму, клиенту проще объяснить, почему он должен заплатить. Поэтому в B2B, по словам спикера, легче получать реальные обязательства, гарантийные письма, согласие на эксперимент или предоплату.
В B2C ситуация сложнее. Пользователь не всегда осознаёт свои KPI, а ценность может строиться на времени, внимании, удовольствии, социальной реакции или привычке. Особенно трудно проверять продукты на дофаминово-эндорфиновом цикле: человек не обязательно может достоверно рассказать в интервью, будет ли он регулярно возвращаться к продукту и какую эмоцию испытает при использовании. Для таких гипотез Замесин считает более необходимыми качественные high-fidelity-прототипы и MVP.
Однако базовый принцип сохраняется в обоих типах рынка: нужно изучать фактическое поведение и текущие альтернативы, а не спрашивать, какой продукт пользователь хотел бы получить. В B2B это может приводить к прямой продаже решения до разработки, а в B2C — к тестированию реального пользовательского опыта на прототипах, лендингах и первых версиях продукта.
Иван Замесин ставит практическую цель занятия: участники должны уйти с подготовленными сценариями собственных интервью. Для этого предлагается сначала в реальном времени собрать сценарий для вымышленного интервью, сформулировать гипотезы о предметной области и превратить их в вопросы. Сценарий нужен не как жёсткий опросник, а как карта, которая помогает системно исследовать пользователя и не пропустить важные детали.
Основой должен быть дефолтный проблемный скрипт: как человек решает потребность сейчас, каковы его затраты, что он считает успехом, что происходит при невозможности решить задачу, какие есть неудобства, когда проблема возникала в последний раз, почему она была тяжёлой и какую эмоцию вызвала. Затем этот скрипт дополняется вопросами, которые относятся к конкретным сегментам, сценариям, факторам выбора и предполагаемым точкам боли.
Спикер подчёркивает, что после первых интервью сценарий почти полностью переписывается. Первоначальная схема строится на предположениях команды, а реальные разговоры показывают, что пользовательский мир устроен сложнее: возникают неожиданные контексты, альтернативы, исключения и поведенческие костыли. Поэтому хороший сценарий должен быть живым инструментом, который регулярно меняется вслед за полученными фактами.
Иван Замесин планирует провести демо-интервью с одним из участников продолжительностью около тридцати–сорока пяти минут. Перед этим группа должна подготовить гипотезы и сценарий, а во время самого разговора — применить фреймворк углубления в проблемы: выяснить реальный случай, причины сложности, эмоции и их оценку. Практика предназначена для того, чтобы показать процесс custdev не в теории, а в работе.
Ожидаемый результат демо — доска с инсайтами, которые будут ранжированы по частотности и эмоциональной боли. То есть интервью не должно закончиться стенограммой или набором общих впечатлений; из него должны быть извлечены структурированные потребности, пригодные для дальнейшей продуктовой работы. Затем этот опыт должен помочь участникам подготовить сценарии уже для своих проектов.
Позднее Замесин отдельно говорит, что custdev на практике является простым инструментом, хотя вокруг него существует ощущение сложности. По его мнению, понять метод можно преимущественно через повторение: на своих тренингах он предлагает провести двенадцать–шестнадцать интервью. Страх перед нерезультативными респондентами, отказами или неловкостью он относит скорее к психологическим барьерам, чем к реальным основаниям не начинать исследование.
Иван Замесин описывает исследовательскую доску как итоговый артефакт практики custdev. На ней должны быть собраны инсайты из интервью, а не просто заметки о разговоре. Каждый инсайт получает характеристики, позволяющие сравнивать его с другими: насколько часто он встречается и насколько сильные эмоции вызывает у пользователей.
Позднее спикер конкретизирует этот процесс: повторяющиеся наблюдения выносятся в RealTimeBoard, размечаются по частотности, силе боли или радости и формулируются в терминах job stories. Такая визуализация помогает увидеть не отдельные истории респондентов, а структуру потребностей сегмента. Если одна и та же боль повторяется у большинства людей и сопровождается высокой эмоциональной оценкой, она становится заметным кандидатом на продуктовый приоритет.
Доска также превращает исследование в средство коллективной работы команды. Вместо того чтобы опираться на память интервьюера или спорить о субъективных впечатлениях, можно обсуждать зафиксированные потребности, их повторяемость и относительную важность. В результате появляется упорядоченный материал для выбора следующих экспериментов, прототипов и продуктовых требований.
Иван Замесин обосновывает свой подход практическим опытом проведения большого числа интервью и постоянного использования этого инструмента. Он упоминает работу над поиском картинок Яндекса, который называет одной из наиболее нагруженных вертикалей, а также создание интерфейса, который считает удачным. Этот опыт служит примером работы с крупным продуктом и массовой аудиторией.
Также спикер рассказывает, что работал над Chatfuel — конструктором ботов для Facebook Messenger. Он характеризует платформу как лидирующую и говорит, что около половины ботов были созданы и хостились на ней. В дальнейшем лекция использует Chatfuel как кейс исследования платёжных сценариев, сравнения ботов с email-рассылками и формирования цены относительно Mailchimp.
Третьим примером становится сервис подбора психотерапевтов Meta, которым Замесин занимается на момент лекции. Он связывает этот проект с личным опытом интенсивной психотерапии и желанием упростить путь для человека, который предполагает у себя депрессию или другую потребность в психологической помощи, но не понимает, что делать и к кому обращаться. В последующих кейсах Meta служит примером исследования пользовательской проблемы, ручной продажи до создания продукта и проверки монетизации на стороне психотерапевтов.
Иван Замесин пересказывает позицию представителей Y Combinator о ключевой ошибке основателей: они уделяют недостаточно внимания своим пользователям и клиентам. У предпринимателя возникает идея, которую он начинает развивать в одиночку — размышляет о продукте, строит инфраструктуру, создаёт приложения для разных платформ, — но не идёт разговаривать с теми, кто должен этим продуктом пользоваться.
Спикер передаёт мысль, что контакт с пользователями часто воспринимается как сложная часть работы, поскольку он связан с продажами, а продажи многим делать не нравится. Однако именно этот контакт позволяет заменить внутреннюю уверенность в идее проверкой реального спроса. Вместо построения сложного решения предлагается найти хотя бы одного человека с существующей проблемой, который будет готов заплатить за её решение, а затем искать больше таких людей.
Особенно опасным Замесин считает отрезание от реальной обратной связи. Пользователь может сообщить, что решение непонятно, слишком дорого, не решает нужную задачу или проигрывает альтернативам. Эти сигналы могут быть неприятными, но без них команда продолжает действовать вслепую. Поэтому недостаток общения с клиентами трактуется не как второстепенный методический недостаток, а как фундаментальная причина продуктовых ошибок.
Разработка продукта в изоляции, по изложению Ивана Замесина, начинается с того, что команда считает собственную идею верной и тратит значительное время на её реализацию без разговора с пользователями. Она может создать масштабную инфраструктуру, подготовить iOS- и Android-приложения, продумать множество деталей, но лишь после запуска обнаружить, что продукт не нужен, его купили немногие и первые пользователи быстро отказались от него.
Спикер отмечает психологическую причину такого поведения: выпускать несовершенное решение стыдно, а слышать негативную оценку тяжело. Поэтому команда может откладывать контакт с рынком, чтобы не столкнуться с тем, что созданный продукт плох, непонятен или не соответствует потребности. Но это избегание не устраняет проблему, а только увеличивает цену обратной связи.
В качестве альтернативы предлагается ранний и постоянный контакт с пользователями. Нужно показывать им продукт или прототип, выяснять, понятны ли действия, приемлема ли цена, зачем человеку менять текущий способ решения и как решение выглядит на фоне конкурентов. Такой контакт постепенно приближает команду к реальной потребности, улучшает вероятность покупок, retention и unit-экономику, тогда как изолированная разработка сохраняет только иллюзию попадания в цель.
Иван Замесин прямо связывает разговоры с пользователями и продажи. Он пересказывает мысль, что многие избегают общения с клиентами именно потому, что это фактически означает продавать: нужно предложить решение, услышать отказ, ответить на возражения и признать, что идея может быть слабой. Тем не менее именно готовность человека заплатить становится особенно сильным сигналом существования проблемы.
Спикер предлагает искать хотя бы одного пользователя, у которого есть реальная проблема и который готов оплатить её решение. После этого нужно искать других людей с аналогичной потребностью. Такой подход меняет смысл интервью: оно служит не сбором абстрактных пожеланий, а способом понять текущий опыт и подготовить ценностное предложение, которое можно проверить через реальное действие клиента.
Дальнейшая логика лекции строится на последовательности «изучить проблему — оформить решение в презентацию или MVP — предложить купить». Если пользователь не покупает, важно выяснить, почему именно: чего ему не хватило, что вызывает сомнение, какие условия нужно изменить. Возражение рассматривается как материал для следующей итерации продукта и продажи, а не как повод немедленно игнорировать пользователя или считать гипотезу доказанной.
По мнению Ивана Замесина, ранняя цель основателя — найти хотя бы одного человека с проблемой, который готов заплатить за решение. Такая продажа важнее благоприятного мнения о концепции, потому что она требует от пользователя реального обязательства. Если человек готов отдать деньги, это означает, что ценность решения для него достаточно велика, чтобы преодолеть инерцию, недоверие и существующие альтернативы.
Спикер добавляет, что преимущество есть у предпринимателя, который создаёт продукт для собственной проблемы: с самим собой он уже может провести первичный разговор и лучше понимает контекст. Однако этого недостаточно для подтверждения рынка. Нужно найти других людей, проверить сходство их ситуаций и убедиться, что потребность не является уникальной личной особенностью автора идеи.
В последующих примерах Замесин подтверждает этот принцип практикой. Для сервиса подбора психотерапевтов он прямо предлагал людям заплатить за ручной подбор специалиста ещё до создания полноценного продукта; деньги согласились дать восемь из двадцати опрошенных. В B2B он также приводит примеры, где готовность пройти эксперимент, дать гарантийное обязательство или оплатить MVP выступает более достоверным подтверждением спроса, чем словесное согласие с тем, что идея «интересная».
Иван Замесин, пересказывая позицию представителей Y Combinator, выделяет особое преимущество ситуации, когда основатель создаёт продукт для проблемы, знакомой ему лично. В этом случае у команды уже есть как минимум один доступный носитель проблемы — сам основатель. С ним можно «поговорить» как с пользователем: восстановить сценарий, понять обстоятельства, неудобства, мотивацию и последствия нерешённой потребности.
Личная вовлечённость не отменяет необходимости разговаривать с другими пользователями и проверять, насколько проблема распространена за пределами опыта самого создателя. Однако она даёт исходную точку: создатель не строит продукт исключительно из абстрактной идеи, а понимает реальный контекст потребности хотя бы на собственном примере. В логике лекции это снижает риск полной изоляции от пользователя на раннем этапе.
Иван Замесин подчёркивает, что работа с собственным продуктом психологически осложняется необходимостью выпускать несовершенные решения. Когда продукт создаётся для личной проблемы, основателю особенно трудно выпускать «плохое» или недоделанное: возникает стыд за качество результата и за то, что пользователь увидит недостатки решения.
По мнению спикера, эта эмоция может замедлять запуск. Вместо того чтобы быстро показать продукт реальным людям и получить обратную связь, команда рискует продолжать разработку в одиночестве, пытаясь довести решение до субъективного идеала. Однако в рамках customer development несовершенный релиз нужен именно как источник данных: только после контакта с пользователями становится понятно, что в продукте действительно требует исправления.
Иван Замесин описывает негативную обратную связь как неприятную, но необходимую часть продуктовой работы. Выпускать слабое или сырое решение трудно, потому что пользователи могут прямо сказать, что оно плохое. Для создателя это «суперстыдная» ситуация: приходится сталкиваться с критикой того, во что уже вложены время, силы и личная убеждённость.
При этом спикер связывает страх критики с более опасным поведением — отказом от контакта с реальными пользователями. Команда может не выпускать продукт, не разговаривать с клиентами и тем самым сохранять иллюзию ценности своей идеи. Но такая защита от неприятных эмоций лишает продукт главного источника обучения. В логике лекции полезнее быстро получить болезненный сигнал о недостатках решения, чем долго строить инфраструктуру и приложения без подтверждения потребности.
Негативная реакция пользователей рассматривается не как доказательство личной неудачи создателя, а как материал для дальнейшей проверки гипотезы. Если пользователь объясняет, что именно не работает, непонятно или не создаёт ценности, у команды появляется возможность изменить продукт, предложение или саму гипотезу сегмента.
Иван Замесин объясняет, что разговоры с пользователями начинаются с первоначальной гипотезы о сегментах. До первых интервью у команды есть лишь предварительное представление о том, кому может быть нужен продукт, какие у этих людей задачи и в чём может заключаться их проблема. Эта гипотеза нужна не потому, что она наверняка верна, а потому, что без неё невозможно выбрать первых респондентов и начать исследование рынка.
Спикер подчёркивает, что первое описание сегментов почти всегда оказывается неточным. Команда ещё не знает рынок в достаточной степени, поэтому её стартовые предположения строятся на ограниченных наблюдениях, собственных представлениях или поверхностной логике. Интервью нужны для того, чтобы заменить эти предположения наблюдениями о реальном опыте людей.
После первых разговоров формируется более содержательная картина: появляются новые признаки сегментов, становятся заметны различия между типами пользователей, их ролями, контекстами использования и готовностью платить. На этой основе можно выделить наиболее перспективные сегменты и продолжить исследование уже более сфокусированно.
По словам Ивана Замесина, неверная гипотеза сегмента — нормальный и ожидаемый результат исследования, а не повод считать customer development неудачным. Команда может предполагать, что существует определённая группа людей с конкретной проблемой, провести интервью и обнаружить, что у такого сегмента нет заявленной боли либо сама группа описана неправильно.
В такой ситуации гипотезу следует не защищать и не пытаться искусственно подтвердить, а выбросить и заменить следующей. Спикер формулирует это как последовательный процесс: была сформулирована гипотеза о сегменте и проблеме, проведены интервью, гипотеза не подтвердилась — значит, нужно зафиксировать инсайты, отказаться от этого направления и пойти проверять другое.
Он отмечает, что только в сравнительно редких случаях, примерно в 15–20% ситуаций, исходно выбранный сегмент оказывается правильным. Исключением могут быть случаи, когда команда уже хорошо знает рынок и запускает новую вертикаль в знакомой среде. В остальных случаях отказ от первых сегментных предположений является естественной частью движения к более точному пониманию покупателей.
Иван Замесин называет интервью с пользователями первым реальным изучением рынка. До общения с людьми рынок существует для команды преимущественно в виде гипотез: предполагаемых сегментов, болей, сценариев использования и ценности будущего продукта. Интервью позволяют проверить эти представления через конкретный опыт потенциальных клиентов.
В ходе первых разговоров команда получает не только подтверждение или опровержение идеи, но и более точное описание самого рынка. Может выясниться, что целевая аудитория устроена иначе, чем предполагалось; что решения принимают другие роли; что проблема существует лишь в отдельных контекстах; или что наиболее перспективный сегмент вообще не был включён в исходную гипотезу.
Спикер подчёркивает, что интервью нужно использовать для изучения проблем, а не для сбора готовых рецептов продукта. Их результатом становится понимание того, какие группы людей действительно испытывают значимую потребность, как они справляются с ней сейчас и почему существующие способы их не устраивают. Это знание становится основой для последующего выбора продукта, монетизации и способа продаж.
Иван Замесин формулирует последовательность работы так: сначала нужно идти к клиентам, а затем строить SaaS. Причина в том, что на старте команда обычно не знает, какие сегменты на самом деле существуют и у кого из них есть проблема, достаточно сильная для покупки решения.
Первые десять интервью, по его словам, часто меняют представление о сегментации. Команда может начинать с одной категории потенциальных клиентов, но в разговорах обнаружить, что реальная потребность сосредоточена у других людей, в другой роли или в другом контексте. Если построить SaaS до такого исследования, есть риск создать инфраструктурно сложный продукт для сегмента, который не нуждается в нём или не готов платить.
В этой логике разработка не должна опережать понимание клиента. Сначала требуется найти сегмент с подтверждённой проблемой, затем проверить готовность платить, и только после этого вкладываться в полноценное решение. Такой порядок помогает не тратить ресурсы на продукт, адресованный неверной аудитории.
Иван Замесин рекомендует слушать пользователей, когда они рассказывают о своих проблемах, но не воспринимать их предложения по реализации как готовое техническое задание. Пользователь способен точно описать неудобство, текущий способ действия, потери, ограничения и эмоции, однако не обязан знать, какое решение будет наиболее эффективным.
Спикер использует известную метафору о «более быстрой лошади». Если спрашивать пользователя, чего он хочет в рамках известного ему инструмента, он может предложить улучшение привычного способа. Но продуктовая команда располагает более широким набором возможностей: может использовать новые технологии, мобильные приложения, автоматизацию или другие средства, неизвестные пользователю.
Поэтому во время интервью важно докапываться до первопричины: что именно человек пытается сделать, в какой момент возникает трудность, почему она важна и как он решает её сейчас. Решение затем собирается специалистами на основе этой проблемы, а не копируется из случайного пожелания респондента.
Иван Замесин объясняет, что пользователи не владеют полным «инвентарём» возможных продуктовых решений. Они могут не знать, какие мобильные приложения можно создать, как применить технологию или как с помощью автоматизации изменить привычный процесс. Поэтому их предложения ограничены уже знакомыми им способами действия.
Это не означает, что мнение пользователя неважно. Напротив, пользователь является ключевым источником фактов о собственной потребности: он знает, что делает, с какими препятствиями сталкивается, какие ресурсы тратит и какую эмоциональную реакцию вызывает проблема. Ограничение касается именно конструирования решения, а не достоверности его опыта.
Роль продуктовой команды заключается в том, чтобы услышать проблему и самостоятельно собрать подходящее решение из доступных инструментов. В лекции это противопоставляется буквальному следованию пользовательским просьбам: ценность интервью заключается в раскрытии неудовлетворённой задачи, а не в голосовании за конкретную функцию.
После выявления предполагаемой проблемы Иван Замесин предлагает не начинать немедленно полноценную разработку, а сначала попробовать продать идею. Её можно оформить в презентацию или в простое предложение и обратиться к потенциальному клиенту с прямым вопросом о покупке. Если человек готов платить, это становится сильным сигналом, что проблема для него действительно значима.
Продажа до разработки переводит разговор из области общих симпатий в область реальных обязательств. Пользователь может положительно отнестись к идее или сказать, что продукт выглядит интересным, но готовность заплатить показывает более высокий уровень подтверждения спроса. Если покупки нет, полезно не ограничиваться отказом, а выяснить причины: чего не хватило в предложении, какая часть решения неубедительна, что мешает принять решение.
Полученные возражения используются для корректировки MVP или способа продажи. Затем обновлённое предложение показывается следующему человеку. Этот цикл продолжается либо до появления покупок, либо до накопления достаточно сильных сигналов, что гипотезу стоит закрыть.
Иван Замесин рассматривает презентацию, прототип и MVP как инструменты, с помощью которых гипотеза становится достаточно конкретной для проверки. Вместо создания полного продукта команда может показать идею в слайдах, собрать простую «наколеночную» версию или подготовить минимальный прототип, а затем предложить его пользователю или попытаться совершить продажу.
Если люди начинают покупать, следующим шагом становится создание MVP и получение обратной связи уже о конкретном решении. Если покупок нет, команда должна выяснить, почему предложение не сработало: неясна ли ценность, недостаточно ли функций, вызывает ли сомнения цена или вообще неправильно определена проблема. Таким образом, презентация и ранний прототип служат не декоративными материалами, а экспериментом над спросом.
Спикер также подчёркивает роль прототипов в дальнейшем развитии продукта. Даже отдельную функцию, стоимость которой в разработке может быть высокой, можно сначала показать ограниченному числу пользователей. Это позволяет убить, изменить или подтвердить гипотезу до того, как команда вложит значительные средства в реализацию.
Иван Замесин прямо говорит, что с первого раза не получается почти ни у кого. Команда может последовательно проверять несколько гипотез о сегментах и проблемах и каждый раз обнаруживать, что предполагаемой группы с такой болью не существует. По его позиции, это не аномалия, а обычная реальность поиска продукта.
Правильной реакцией на неподтверждённую гипотезу является фиксация полученных инсайтов и переход к следующей проверке. Необходимо признать, что выбранный сегмент не подходит, отказаться от него и сформулировать новую гипотезу, а не продолжать разработку только потому, что исходная идея кажется привлекательной.
Такой подход меняет отношение к ошибкам. Неудачная гипотеза становится относительно дешёвым результатом исследования, который уменьшает вероятность дорогой ошибки на этапе разработки. Главное — быстро узнавать, что предположение не работает, и не превращать его в многомесячный продуктовый проект.
Иван Замесин называет ориентиром около шести недель на поиск сегмента. Он подчёркивает, что это не признак медленной работы, а реальность, с которой приходится считаться: подходящая аудитория, существенная проблема и способ доступа к нужным людям обычно не находятся мгновенно.
В этот период команда может несколько раз менять гипотезы, проводить интервью с неподходящими респондентами, обнаруживать отсутствие боли и заново пересобирать направление поиска. Поэтому отсутствие результата с первой попытки не должно восприниматься как исключение или провал исследовательского процесса.
Позднее спикер расширяет этот ориентир: если аудитория неизвестна, на её изучение следует выделить примерно месяц-полтора. Первые две-три недели могут пройти почти без интервью либо с тяжёлым рекрутингом. Важно заранее заложить это время, а не ожидать немедленного подтверждения первоначальной идеи.
Иван Замесин описывает customer development как последовательное уточнение картины рынка. Сначала формируется гипотеза о сегменте и его проблеме, затем проводятся интервью, после которых исходное предположение уточняется, пересматривается либо полностью отбрасывается. На базе новых наблюдений создаётся следующая гипотеза и запускается очередной цикл общения с пользователями.
Итеративность необходима потому, что команда на старте видит лишь небольшую часть реальности. В представлении спикера рынок почти всегда сложнее первоначальной модели: реальные пользователи могут отличаться по мотивациям, ролям, способу принятия решения, обстоятельствам покупки и силе потребности. Поэтому сегментация не должна считаться раз и навсегда установленной до разговора с рынком.
Процесс продолжается до тех пор, пока не будет найден сегмент, который одновременно достаточно велик или интересен, доступен для команды, платёжеспособен и испытывает сильную проблему. Только после этого имеет смысл переходить к формированию решения, продажам и дальнейшей валидации. Даже после запуска итерации не прекращаются: новые интервью, прототипы и наблюдения уточняют продукт и его экономику.
Иван Замесин иллюстрирует путь к соответствию продукта рынку схемой, где команда в начале уверена, что понимает потребность клиента и попадёт своим продуктом точно в центр этой потребности. Она предполагает, что после запуска пользователи начнут покупать, экономика сойдётся, а масштабирование будет успешным. Однако в подавляющем большинстве случаев эта уверенность не соответствует реальности.
После запуска может оказаться, что продукт почти никто не покупает: появляются лишь единичные пользователи, которые вскоре отказываются от решения. При этом команде недоступна сама потребность в полном виде: до контакта с клиентами она существует скорее как воображаемая цель, чем как подтверждённое знание. Нулевой спрос или быстрый отток становятся сигналом, что первоначальное представление о проблеме и ценности было недостаточным.
Приближение к соответствию продукта рынку происходит через множество контактов с пользователями. Команда показывает продукт, спрашивает, как он воспринимается, получает замечания о понятности, цене и конкурентах, проводит UX-исследования и меняет MVP. Постепенно она лучше понимает потребность, продажи начинают появляться, а unit-экономика — сходиться. Спикер приводит оценку Дэвида Русенко: до момента, когда продукт начинают покупать, может потребоваться около 27 итераций.
По мнению Ивана Замесина, хорошая экономика продукта не возникает исключительно из первоначальной идеи. Она формируется по мере того, как команда проводит множество интервью, UX-исследований и итераций на MVP. Каждый из этих инструментов даёт отдельный тип обратной связи: интервью помогают понять потребность и контекст, UX-исследования — увидеть трудности во взаимодействии с продуктом, а MVP — проверить реальное поведение и покупки.
Спикер связывает этот процесс с ключевыми продуктовыми метриками. Через повторные проверки можно постепенно добиться того, чтобы пользователи не только начинали покупать, но и оставались в продукте; вслед за этим улучшаются retention, lifetime value и unit-экономика. До этого момента команда находится лишь в процессе приближения к реальной потребности клиента.
Важна именно регулярность обратной связи. Пользователь может сообщить, что не понимает, куда нажимать, не видит ценности, считает цену неподходящей или предпочитает решение конкурента. Такие сигналы не возникают внутри команды сами по себе. Только через систематические разговоры и проверки MVP можно увидеть, какие изменения действительно приближают продукт к работающей модели.
Иван Замесин показывает, что после запуска или демонстрации продукта пользовательская обратная связь быстро раскрывает препятствия к покупке. В качестве типичных реакций он приводит непонимание интерфейса — «непонятно, куда кликать», вопросы о стоимости и сомнения в том, зачем вообще покупать продукт, если у конкурента решение выглядит лучше.
Эти замечания важны тем, что переводят абстрактную гипотезу в конкретные причины отказа. Команда может узнать, что проблема не в самой потребности, а в способе её объяснения, в неочевидном пользовательском пути, в цене или в конкурентном сравнении. Без прямого контакта с пользователями эти причины могут оставаться незаметными.
Спикер рассматривает такую обратную связь как способ постепенно приблизиться к потребности клиента. После каждого разговора можно исправить продукт, интерфейс, ценностное предложение или коммерческие условия и затем снова показать решение следующему пользователю. В этом цикле обратная связь становится механизмом последовательного улучшения продукта, а не разовым комментарием после релиза.
Иван Замесин обращается к данным CB Insights, которые, по его описанию, собирают постмортемы стартапов — объяснения основателей и инвесторов о причинах закрытия компаний. В базе порядка трёх тысяч таких историй, а рейтинги причин регулярно пересматриваются на выборке постмортемов. Спикер использует эти данные как аргумент в пользу раннего и постоянного контакта с пользователями.
На первом месте среди причин провала он выделяет отсутствие потребности в продукте. Среди других упомянутых факторов — ошибки ценообразования, плохой продукт, слабый маркетинг, игнорирование покупателя и ситуация, когда продукт «нужен, но не сейчас». Все эти причины в изложении спикера прямо или косвенно связаны с недостатком качественной обратной связи от рынка.
Общий вывод состоит в том, что провалы редко сводятся только к качеству разработки. Команда может не знать, кому продаёт, какую проблему решает, сколько за решение готовы платить, почему пользователи не понимают продукт или почему время выхода не совпало с реальной потребностью рынка. Customer development призван получить эти сигналы до того, как цена ошибки станет слишком высокой.
Согласно приведённому Иваном Замесиным рейтингу CB Insights, отсутствие потребности в продукте занимает первое место среди причин провала стартапов. Это означает, что команда может создать решение, но не найти достаточно людей, для которых оно решает значимую и актуальную проблему.
Спикер связывает этот риск с работой в изоляции. Если продукт создаётся без интервью, продаж и регулярной проверки поведения пользователей, команда способна долго развивать идею, которая кажется убедительной только внутри неё самой. Первый контакт с рынком в таком случае происходит слишком поздно — после существенных затрат на разработку.
Профилактикой этой причины провала становится поиск сегмента с сильной потребностью до масштабной разработки. Нужно понять, как люди решают задачу сейчас, какие потери несут, насколько болезненна проблема и готовы ли они платить за более подходящий способ её решения.
Иван Замесин относит цену к числу значимых причин, по которым стартапы терпят неудачу. Он формулирует проблему ценообразования как незнание того, у кого, в какой момент, в каком объёме и по какой логике брать деньги. Цена не является отдельной технической настройкой: она зависит от конкретного сегмента, его текущих альтернатив, силы проблемы и ценности предлагаемого решения.
В рамках лекции ценообразование должно проверяться через разговоры с пользователями и продажи. Недостаточно решить внутри команды, что продукт «стоит столько-то»; необходимо выяснить, как клиент решает задачу сейчас, сколько уже тратит, какую экономическую или личную выгоду получит и готов ли подтвердить это оплатой.
Ошибка в цене может проявляться как в завышенной сумме, так и в неверной модели монетизации. Если команда не понимает контекст покупки и существующие расходы клиента, она рискует выбрать условия, при которых даже нужный продукт не будет приобретаться.
Иван Замесин связывает плохой продукт с отсутствием каналов обратной связи. Если команда не спрашивает пользователей, как им продукт, она не узнаёт, какие элементы вызывают отторжение, непонимание или отказ от использования. В результате продукт может оставаться слабым не потому, что его невозможно улучшить, а потому, что создатели не видят его недостатков глазами клиента.
В лекции под каналами обратной связи подразумеваются разговоры с пользователями, демонстрации MVP, UX-исследования и прямые вопросы о причинах отказа. Они позволяют получить конкретные сигналы: пользователь может не понимать интерфейс, не видеть выгоду, сталкиваться с неудобством в сценарии или уходить к конкуренту.
Спикер подчёркивает, что без таких сигналов команда не знает, из-за чего люди «отваливаются». Разработка становится самодостаточной деятельностью, а не процессом улучшения ценности для клиента. Поэтому разговоры с пользователями должны продолжаться и после создания MVP, а не завершаться с первым релизом.
Иван Замесин упоминает плохой маркетинг и игнорирование покупателя среди причин провала стартапов. В его интерпретации эти факторы тесно связаны с отсутствием контакта с рынком. Если команда не понимает своего клиента, его язык, мотивы, контекст покупки и причины выбора, ей трудно сделать понятное предложение и донести ценность продукта.
Игнорирование покупателя спикер называет особенно опасной ситуацией. Это крайний вариант отрыва от рынка: команда не просто плохо провела несколько интервью, а фактически отказывается признавать необходимость разговаривать с пользователями. Такое поведение лишает её данных и о продукте, и о коммуникации с рынком.
Маркетинговая проблема в этой логике не отделяется от продуктовой. Когда непонятны реальная боль, аудитория и ценность, нельзя надёжно определить, как формулировать предложение, какие аргументы использовать и почему клиент должен выбрать продукт. Поэтому customer development должен предшествовать масштабированию маркетинга.
Иван Замесин выделяет ситуацию «нужен, но не сейчас» как вежливую форму сообщения, что продукт не имеет актуального спроса в данный момент. Пользователь может признать идею в целом разумной, похвалить создателя и даже согласиться, что решение когда-нибудь пригодится. Но если потребность не срочная, это не становится основанием для покупки.
Спикер подчёркивает, что подобная реакция не должна интерпретироваться как полноценное подтверждение гипотезы. Фраза о будущем интересе может маскировать отсутствие достаточной боли или низкий приоритет задачи. Для продукта это означает, что рынок не готов платить сейчас, а значит, бизнес-модель не получает необходимого сигнала спроса.
Проверка своевременности потребности требует не общих одобрений, а наблюдения за текущим поведением и готовностью к оплате. Нужно понимать, что произойдёт, если пользователь не решит задачу, какие последствия он несёт и почему должен действовать именно в настоящем моменте.
Иван Замесин приводит оценку нескольких организаций и акселераторов, включая исследователей из Беркли, Стэнфорда и ассоциации Стива Бланка: трёхлетний рубеж переживает около 8% стартапов. Этот показатель используется в лекции как контекст для разговора о необходимости быстрых проверок и раннего получения обратной связи.
Низкая выживаемость показывает, что создание нового продукта связано с высокой неопределённостью. Команда может ошибиться в сегменте, потребности, цене, способе продаж, качестве продукта или моменте выхода на рынок. Если такие ошибки обнаруживаются только после длительной разработки, исправить ситуацию становится существенно сложнее и дороже.
Поэтому спикер предлагает не рассчитывать на точность первоначального замысла. Более жизнеспособной стратегией является серия дешёвых проверок: интервью, ранние продажи, простые MVP, работа с возражениями и количественное подтверждение спроса.
Иван Замесин называет серьёзной проблемой то, что первая обратная связь о продукте часто откладывается на месяцы. По его наблюдению из работы с предпринимателями, средний срок до релиза нередко составляет около года. Это означает, что команда может целый год инвестировать в идею, не зная, нужна ли она пользователям и готовы ли они ею пользоваться или платить за неё.
Чем позже приходит обратная связь, тем дороже она обходится. За время разработки накапливаются расходы на сотрудников, налоги, офис, процессы и сопутствующую инфраструктуру. Кроме финансовой стоимости увеличивается и цена изменения: чем больше построено вокруг неверной гипотезы, тем труднее отказаться от неё или радикально пересобрать продукт.
Спикер противопоставляет этому подход customer development, в котором время до получения сигнала сокращается с месяцев и лет до часов, дней или нескольких недель. Ранний разговор с пользователем и попытка продажи позволяют узнать о слабости гипотезы до масштабной разработки. Цель состоит не в исключении ошибок, а в том, чтобы каждая ошибка была дешёвой и давала полезное знание.
Чтобы показать стоимость поздней обратной связи, Иван Замесин предлагает пример стартапа, который год разрабатывает «гениальную идею» до первого контакта с рынком. В примере работают три разработчика с зарплатой около 100 тысяч рублей. С учётом налогов, офиса и других расходов первая обратная связь о продукте обходится примерно в 3,6 миллиона рублей.
Смысл расчёта не только в конкретной сумме, но и в логике затрат. Пока команда не показывает решение пользователям и не пытается продать его, она расходует ресурсы на гипотезу, которая может оказаться неверной. Если по итогам года выясняется, что потребности нет или сегмент выбран неправильно, все эти средства были потрачены до первого существенного сигнала.
Спикер противопоставляет такой сценарий интервью и ранней валидации. Вместо года разработки можно раньше поговорить с потенциальными клиентами, выявить отсутствие боли или получить возражения и изменить направление. Это уменьшает цену ошибки и позволяет быстрее перейти к следующей гипотезе.
Иван Замесин показывает, что в крупной компании цена поздней обратной связи становится ещё выше. Для запуска даже небольшого проекта обычно требуется не только разработка, но и участие множества ролей: продакт-менеджера, дизайнеров, QA, юристов, руководителей, специалистов по документации и маркетингу. Каждый из этих участников добавляет стоимость и замедляет движение к первому контакту с пользователем.
В приведённом примере десять человек работают над инициативой полгода, а стоимость такого периода оценивается примерно в 30 миллионов рублей. Спикер поясняет, что расчёт опирается не только на зарплаты, но и на повышающий коэффициент сопутствующих корпоративных затрат. Дополнительно упоминается необходимость согласований, подготовки маркетинговых материалов и других процедур.
Вывод состоит в том, что customer development особенно важен в среде с дорогой разработкой и сложными процессами. Чем больше ресурсов требуется для реализации фичи или нового направления, тем важнее проверить потребность и спрос до запуска полноценного корпоративного проекта.
Иван Замесин формулирует тезис, который связывает с практикой трекеров ФРИИ и Ильёй Красинским: девять из десяти гипотез проваливаются. Речь идёт о новых продуктовых решениях и функциях, которые команда ожидает сделать источником роста или выручки, но которые в итоге не создают ожидаемого эффекта.
Этот тезис меняет отношение к продуктовой работе. Если большинство гипотез с высокой вероятностью окажутся неверными, опасно вкладывать в каждую из них большие суммы и длительные циклы разработки. Неудача становится не исключительным событием, а базовым условием работы с неопределённостью.
Следовательно, задачей команды является не доказать, что каждая идея правильна, а быстро и дёшево выяснить, какие из них неверны. Интервью, прототипы, продажи и MVP позволяют последовательно отсеивать слабые направления, сохраняя ресурсы для тех гипотез, которые получают подтверждение от рынка.
В качестве иллюстрации Иван Замесин приводит пример Дениса Жаданова из Readdle, прозвучавший на Epic Growth Conference. На слайде компании было показано около сорока приложений, из которых успешными оказались только восемь. Спикер интерпретирует это как примерно 20-процентный уровень успеха продуктовых инициатив.
Этот пример подтверждает тезис о том, что большая часть продуктового портфеля не становится успешной. Даже у команды с опытом и большим количеством запусков результаты распределяются неравномерно: несколько решений дают эффект, а значительная часть не оправдывает ожиданий.
Для Ивана Замесина это аргумент в пользу системы частых экспериментов. Если успешными становятся не все проекты, то важно строить процесс так, чтобы неуспешные быстро выявлялись и не поглощали непропорционально много времени и денег. Customer development и ранняя валидация позволяют сделать портфель таких проверок менее затратным.
Иван Замесин различает две ситуации: перенос уже работающего решения из США или другого рынка и создание принципиально нового продукта. Когда команда переносит проверенную за рубежом модель, вероятность успеха, по его оценке, может быть выше — примерно около 50%. Продуктовая идея уже имеет аналог, который продемонстрировал спрос в другом контексте.
Однако даже в случае переноса нет полной гарантии. Новый рынок может отличаться по аудитории, её поведению, платёжеспособности, существующим альтернативам и условиям распространения продукта. Поэтому и такие гипотезы требуют проверки, хотя исходная неопределённость может быть ниже.
Если же команда делает не перенос, а действительно новое решение, вероятность ошибки возрастает: девять из десяти инвестиций в функции или продуктовые гипотезы могут не принести ожидаемых денег. В этом случае особенно важно не воспринимать первоначальную идею как доказанную и не тратить крупные суммы на реализацию без контакта с пользователями.
Иван Замесин использует метафору эволюционного обучения, чтобы объяснить ценность ошибок. Человек, впервые оказавшийся в саванне, наступает на колючку, испытывает боль, связывает её с визуальным образом и запоминает опасность. Аналогично, обнаружив съедобный банан, он получает положительное подкрепление и запоминает связь между объектом и приятным результатом.
При этом спикер утверждает, что негативное подкрепление действует примерно в десять раз сильнее позитивного. Ошибка, которая приводит к болезненному, но понятному последствию, может быстрее сформировать экспертизу, чем успех. Он связывает эту мысль с тезисом из книги «Тонкое искусство пофигизма»: чтобы стать сильным специалистом в некоторой области, необходимо совершить в ней много ошибок.
Для продуктовой работы это означает, что ошибки неизбежны и даже полезны, если их цена контролируема. Команда должна организовать процесс так, чтобы быстро получать негативный сигнал от рынка, понимать его причину и не повторять ту же ошибку в дорогой форме. Ценность customer development — в создании такого ускоренного цикла обучения.
Иван Замесин формулирует практическую цель: проверка каждой продуктовой гипотезы должна стоить не десятки миллионов рублей, а существенно меньше — условно десятки тысяч. Такая разница достигается не сокращением числа проверок, а изменением их формы: вместо полной разработки сначала проводятся интервью, показываются прототипы, проверяется спрос через простое предложение или раннюю продажу.
Спикер противопоставляет этому дорогой сценарий, в котором команда долго создаёт фичу, а затем только узнаёт, что она никому не нужна. Если большинство гипотез обречено не подтвердиться, то дорогостоящая разработка каждой из них становится нерациональной. Значительно выгоднее заранее получить основания для отказа, перерождения или уточнения идеи.
Удешевление проверки позволяет делать больше попыток и учиться быстрее. Ошибки не исчезают, но становятся менее разрушительными для бюджета и сроков. В результате команда может направлять серьёзные ресурсы только на те решения, которые уже получили хотя бы базовое качественное подтверждение.
Иван Замесин утверждает, что десять интервью почти всегда позволяют убить практически любую гипотезу, если она не имеет основания в реальной потребности. По его оценке, даже для дорогих специалистов проведение такой серии разговоров обычно укладывается примерно в 300 тысяч рублей. Это несопоставимо дешевле, чем год разработки или корпоративный проект с большой командой.
Смысл десяти интервью не в формальном подсчёте мнений, а в поиске повторяющихся признаков сильной проблемы. Если представители предполагаемого сегмента не рассказывают о нужной боли, не сталкиваются с ней регулярно, не испытывают значимых последствий и не демонстрируют готовность платить, гипотеза получает основание для закрытия.
Спикер рассматривает этот метод как способ быстро избежать крупных вложений в неверное направление. Серия интервью может не дать окончательного доказательства жизнеспособности продукта, но способна достаточно быстро показать, что команда исследует неподходящий сегмент или выдуманную потребность.
Иван Замесин разделяет работу над продуктом на пять крупных этапов. Сначала команда ищет сегмент с потребностью и проводит проблемные интервью, изучая, как пользователи решают задачу сейчас и какие неудобства испытывают. Это этап поиска проблемы, а не разработки готового решения.
После появления гипотезы решения предлагается оформить её в простую форму — слайды, примитивный MVP или другое минимальное представление — и провести решенческие интервью с продажей. Потенциальному клиенту предлагают купить решение; в случае отказа выясняют причины и используют возражения, чтобы изменить MVP или формулировку предложения. Цикл продолжается, пока не появятся покупки либо пока гипотеза не будет признана несостоятельной.
Далее следует качественная валидация решения, где особенно важно не ошибиться с аудиторией и количеством разговоров. Затем необходима количественная валидация: покупка трафика, проверка конверсии, retention и unit-экономики. Только наблюдение за реальными количественными показателями позволяет подтвердить, что решение не просто вызывает положительные реакции в интервью, а способно работать как продуктовый и бизнесовый механизм.
После этого создаётся MVP, и команда продолжает разговаривать с каждым пользователем, поскольку ошибки могут возникать на любом шаге — например, из-за непонятного лендинга или неочевидного призыва к действию. Отдельным этапом спикер выделяет проверку монетизации через решенческие интервью и ручные продажи. Когда ручные продажи начинают работать, их можно масштабировать в self-service-модель.
Финальная стадия — итеративное улучшение. Иван Замесин подчёркивает, что проверять можно не только целый продукт, но и каждую отдельную функцию. Прежде чем инвестировать в дорогую разработку, полезно поговорить с пользователями, показать прототип и либо закрыть гипотезу, либо изменить её, либо подтвердить необходимость. Так продукт развивается через последовательные дешёвые проверки, а не через дорогое производство непроверенных функций.
Иван Замесин описывает поиск сегмента с потребностью как первый этап продуктовой работы. На этом этапе ещё не следует строить полноценный продукт: задача состоит в том, чтобы установить, у каких именно людей или компаний есть проблема, как они с ней живут и насколько она значима. Для этого проводятся проблемные интервью, позволяющие изучить текущий опыт, альтернативы, частотность ситуаций и эмоциональную силу неудобства. Если исходная гипотеза о сегменте или его проблеме не подтверждается, её нужно отбросить и перейти к следующей, а не пытаться искусственно «доказать» первоначальную идею.
По мнению Ивана, первые гипотезы сегментов почти всегда оказываются ошибочными, потому что команда в начале ещё не знает рынок. Только разговоры с первыми пользователями позволяют увидеть настоящую структуру спроса: кто реально сталкивается с задачей, кто принимает решение, кто платит и для кого боль достаточно сильна. В качестве нормы он называет несколько недель поиска: подходящий сегмент не обязательно находится в первых интервью, а способ находить нужных респондентов тоже часто приходится искать отдельно.
Когда сегмент определён, его необходимо оценить по размеру, платёжеспособности, доступности и силе боли. Если удаётся найти сегмент, где потребность сильна, а люди готовы обсуждать и покупать решение, можно переходить к гипотезе решения и продаже
Иван Замесин называет проблемное интервью основным инструментом поиска потребности. Его цель — не получить одобрение будущей идеи и не спросить, купит ли человек продукт, а восстановить реальные факты о том, как пользователь решает задачу сейчас. Важно выяснить, какие способы уже используются, сколько они стоят в деньгах, времени или внимании, насколько человек ими доволен и какой результат считает успешным.
Центральная часть такого интервью строится вокруг конкретного прошлого опыта. Иван рекомендует не ограничиваться вопросом «У вас есть такая проблема?», поскольку человек может отвечать обобщённо, неточно или опираться на единичный случай. Вместо этого нужно просить рассказать о последнем эпизоде: когда проблема возникла, что именно происходило, почему ситуация оказалась сложной, какие действия предпринимались и какие эмоции возникли. Если собеседник не может детально восстановить недавний случай, это может означать, что проблема нечастотна или воспоминание основано на общем представлении, а не на реальном регулярном опыте.
Проблемное интервью также помогает ранжировать обнаруженные потребности. После разговора должны быть понятны частотность ситуации и сила эмоциональной реакции. Иван предлагает фиксировать несколько болей, формулировать их как job stories и в первую очередь работать с наиболее частотными и эмоционально сильными из них
После подтверждения сегмента и его проблемы Иван Замесин предлагает переходить к решенческому интервью. На этом этапе появляется конкретная гипотеза продукта: она может быть оформлена в виде слайдов, простого MVP, прототипа или даже ручной услуги. Задача интервью уже не сводится к изучению существующего опыта — пользователю предлагают решение и проверяют, готов ли он его приобрести.
Ключевой вопрос формулируется прямо: «Купи». Если человек соглашается, это становится сильным сигналом, что проблема действительно имеет ценность и предложенное решение выглядит достаточным. Если собеседник не покупает, отказ не должен восприниматься как абстрактный негативный отзыв. Его нужно разбирать: что именно не позволило принять решение, чего не хватило в продукте, предложении или способе продажи.
Иван подчёркивает, что решенческое интервью повторяется итеративно. Возражение одного потенциального клиента превращается в изменение MVP или коммерческого предложения, после чего обновлённая версия показывается следующему. Этот цикл продолжается до тех пор, пока продажи не начинают происходить, либо пока накопившиеся отказы не покажут, что гипотезу следует закрыть
Иван Замесин рассматривает ручную продажу как наиболее прямой способ проверить, существует ли спрос. До автоматизации, масштабирования и разработки сложного продукта нужно предложить человеку решение лично. Такая продажа может опираться на презентацию, прототип, обещание сделать услугу специально для клиента или простую «наколеночную» реализацию. Важен не уровень технологической готовности, а готовность клиента отдать деньги за устранение своей проблемы.
Если человеку действительно нужно решение, его согласие оплатить услугу или продукт становится существенно более сильным сигналом, чем положительный отзыв, интерес к идее или обещание пользоваться в будущем. Иван специально противопоставляет продажу гипотетическим вопросам о будущем поведении: люди могут говорить, что решение полезно, но реальное действие — платёж, гарантийное письмо, обязательство провести эксперимент — лучше показывает ценность предложения.
Ручной формат нужен и для обучения команды. Пока продукт ещё не стал self-service-сервисом, можно видеть реальные вопросы, сомнения и препятствия покупателей, оперативно менять предложение и понимать, за что именно они готовы платить. Лишь после появления продаж и устойчивого подтверждения спроса имеет смысл масштабировать процесс.
По подходу Ивана Замесина, отказ от покупки не завершает проверку гипотезы, а создаёт материал для следующей итерации. Если потенциальный клиент не покупает MVP, нужно не спорить и не убеждать его любой ценой, а выяснить причину: чего в предложении не хватило, что оказалось непонятно, какие риски остались и какое условие могло бы изменить решение. Такое возражение затем становится гипотезой для улучшения.
Иван предлагает чинить либо сам MVP, либо продажу. Иногда проблема действительно находится в функциональности: клиенту не хватает определённого свойства продукта. В других случаях причина может быть в том, как объяснена ценность, как оформлено предложение, насколько понятны цена и следующий шаг. После изменения команда приходит к следующему человеку с обновлённым предложением и снова просит купить.
При этом не следует бесконечно дорабатывать идею под каждое единичное замечание. Если люди с подтверждённой проблемой последовательно не покупают, а возражения не приводят к работающей версии предложения, это сигнал закрыть или пересобрать гипотезу. Цель процесса — не защитить первоначальную задумку, а достаточно быстро понять, появляется ли реальный спрос.
Иван Замесин выделяет качественную валидацию как этап после поиска сегмента и проблемного интервью. Она нужна, чтобы проверить: предложенное решение соответствует обнаруженной потребности или нет. На этом этапе команда показывает ценностное предложение, простой MVP либо прототип конкретным представителям сегмента, разговаривает с ними и проверяет реакцию через продажу или содержательную обратную связь.
Качественная валидация может быть ошибочной, если разговоры велись не с теми людьми или если выборка была слишком узкой. Поэтому её результат не равен окончательному доказательству жизнеспособности продукта. Однако она позволяет быстро отбросить слабые решения, уточнить ценность, обнаружить непонятные места и понять, какие изменения нужны ещё до масштабных вложений в разработку и трафик.
Иван подчёркивает, что на этом шаге полезно работать с каждым пользователем будущего MVP. Контакт с конкретным человеком позволяет увидеть детали, которые не проявляются в общих метриках: например, человек может не понять, куда нажимать на лендинге, не увидеть призыв к действию или иначе интерпретировать ценность продукта
После качественной проверки Иван Замесин рекомендует переходить к количественной валидации. Её смысл в том, чтобы не ограничиваться отдельными разговорами и ручными продажами, а проверить, работает ли решение на масштабе. Для этого нужно купить трафик, показать предложение большей аудитории либо использовать уже имеющиеся продуктовые поверхности — например, баннеры на крупном сервисе — и измерить фактическое поведение людей.
Количественная проверка нужна для подтверждения того, что продуктовая гипотеза не держится на нескольких удачных интервью. Команда должна увидеть конверсии, динамику удержания и экономику, а не только услышать, что отдельным пользователям идея кажется полезной. Пока такого подтверждения нет, нельзя уверенно считать, что найдено решение, способное устойчиво работать как бизнес.
Иван приводит пример Clean: после интервью о проблеме генеральной уборки команда не стала сразу создавать новую услугу. Сначала была сделана сегментированная email-рассылка, и повышенный CTR относительно обычных показателей стал количественным сигналом. Лишь после этого гипотезу решили развивать в продукт.
Иван Замесин считает, что успешная качественная реакция пользователей ещё не означает жизнеспособность продукта. До тех пор, пока не измерены конверсия, retention и unit-экономика, гипотеза остаётся неполностью проверенной. Конверсия показывает, переходят ли люди от знакомства с предложением к целевому действию; retention — возвращаются ли к продукту; unit-экономика — сходится ли модель на уровне привлечения и обслуживания пользователей.
Проверка должна идти через реальные каналы и реальные продуктовые сценарии. Можно купить трафик, разместить баннер или запустить MVP в существующей аудитории, чтобы увидеть фактическую воронку. Только после большого числа интервью, UX-исследований и итераций на MVP, по словам Ивана, команда постепенно приближается к ситуации, когда пользователи начинают покупать, а экономика становится рабочей.
Такие измерения защищают от ситуации, когда продукт кажется логичным его создателям, получает несколько одобрительных отзывов, но не удерживает пользователей либо требует несоразмерных затрат на привлечение и поддержку. Количественные показатели не отменяют интервью: они дополняют их и показывают, подтверждается ли качественный инсайт массовым поведением.
Иван Замесин рекомендует разговаривать с каждым пользователем MVP, поскольку ранняя версия продукта почти неизбежно содержит ошибки. Даже если команда уверена в ценности решения, препятствия могут возникать в самых простых элементах пользовательского пути: в структуре лендинга, понятности интерфейса, формулировке цены, механике оплаты или коммуникации после первого действия.
Разговор с пользователем нужен не для формального сбора удовлетворённости, а для разбора конкретного опыта. Следует выяснить, что человек пытался сделать, где остановился, что понял неправильно и почему не совершил ожидаемое действие. Иван отмечает, что без такого контакта команда часто не получает критически важную информацию: пользователь может не купить не потому, что ему не нужна ценность, а потому, что он не понял, куда кликнуть или что именно ему предлагают.
Постоянное общение с пользователями MVP помогает быстрее исправлять ошибки и не превращать предположения команды в дорогостоящие решения. По мере роста продукта тот же принцип сохраняется для новых фич, вертикалей, сценариев и изменений в монетизации.
В качестве простого примера Иван Замесин приводит лендинг, на котором call to action расположен вне первого экрана. Команда может не замечать этой проблемы, пока не поговорит с человеком, который не совершил покупку. В разговоре выясняется конкретная причина: пользователю было непонятно, куда нажимать. Такой сигнал нельзя получить, просто наблюдая отсутствие конверсии без последующего исследования.
Этот пример иллюстрирует более широкий принцип: пользовательский путь необходимо проверять вживую. Если человек не проходит нужный сценарий, нужно спросить, как он интерпретировал страницу, что искал, какие шаги ожидал увидеть и на каком моменте возникла неопределённость. Проблема может находиться не в самой продуктовой гипотезе, а в её представлении, навигации, призыве к действию или логике интерфейса.
По мнению Ивана, именно поэтому с каждым пользователем раннего MVP нужно разговаривать. Метрики фиксируют результат — например, низкую конверсию, — но не объясняют причину. Интервью превращает наблюдаемую проблему в конкретное изменение, которое можно проверить в следующей итерации.
Иван Замесин включает проверку монетизации в общий цикл решенческих интервью. Прежде чем устанавливать цену или выбирать схему оплаты, нужно вновь понять, что именно болит у человека, как он решает задачу сейчас и какие расходы уже несёт. Затем можно предложить конкретную модель оплаты и проверить её не в абстрактном опросе, а в разговоре, ориентированном на реальную продажу.
Примером служит Meta — сервис подбора психотерапевтов. Команда изучила положение молодых специалистов, которые получают клиентов через центры и платят этим центрам значительную долю дохода на протяжении всей работы с клиентом. На этом фоне комиссия за приведённого клиента, которую сначала считали высокой, оказалась приемлемой. Несколько интервью позволили установить, что допустима комиссия в размере одной стоимости занятия, а последующая проверка показала приемлемость и двух стоимостей занятия.
Этот подход показывает, что цена не определяется только внутренними ощущениями команды. Её нужно соотносить с текущими альтернативами пользователя, его затратами и создаваемой экономической выгодой. Проверка происходит через готовность принять конкретное коммерческое условие, а не через вопрос о том, «какую цену вы бы заплатили».
Иван Замесин предлагает сначала продавать вручную, а к self-service-модели переходить только после появления реальных продаж. В ручном режиме команда может сама объяснять ценность, адаптировать предложение, отвечать на вопросы, видеть возражения и проверять, готов ли человек действительно платить. Этот этап даёт понимание, что именно покупают пользователи и какие части процесса требуют доработки.
Если продажи начинают происходить, ручной способ можно масштабировать и переводить в самообслуживание. Однако автоматизация не должна предшествовать подтверждению спроса. Иначе есть риск вложить ресурсы в удобный, технологичный и масштабируемый путь для предложения, которое люди в действительности не хотят покупать.
Логика перехода особенно важна для новых продуктов и гипотез монетизации: сначала необходимо получить признаки того, что клиент принимает ценность и цену, а затем строить систему, позволяющую продавать без постоянного ручного участия команды
Иван Замесин призывает проверять каждую продуктовую фичу до того, как в неё будут вложены значительные ресурсы. Если разработка функции стоит миллионы рублей, неразумно сразу начинать реализацию, когда можно поговорить с десятью пользователями, показать им идею или прототип и быстро понять, есть ли у функции реальная ценность. По его оценке, такая предварительная валидация может стоить десятки или сотни тысяч рублей, но предотвращать инвестиции в большое число ненужных инициатив.
Фича после проверки может быть убита, изменена или подтверждена. Важен не сам факт проведения интервью, а готовность команды пересмотреть первоначальную идею в зависимости от полученных сигналов. Если пользователи не узнают в функции важную проблему, не понимают сценарий или не готовы пользоваться решением, это повод не запускать дорогую разработку в прежнем виде.
Иван подчёркивает, что эта практика применима и в уже работающем бизнесе. Для быстрых проверок можно поддерживать чат с лояльными пользователями, задавать им вопросы о будущих изменениях и получать ранние сигналы до попадания задачи в полноценный производственный цикл.
По мнению Ивана Замесина, прототип — это способ снизить стоимость проверки продуктовой идеи. Вместо полноценной реализации команда может показать пользователям визуальную или функциональную имитацию будущей фичи, обсудить сценарий использования и понять, решает ли она значимую задачу. Прототипы особенно полезны в связке с интервью: они помогают перевести разговор с уровня общих слов на уровень конкретного пользовательского действия.
Такой подход не гарантирует, что после релиза поведение будет полностью совпадать с реакцией на прототип. Однако он позволяет выявить явные недопонимания, неверные предположения о сценарии и отсутствие ценности до того, как будут потрачены ресурсы разработки. Если прототип показывает, что пользователь не видит смысла в функции или нуждается в другом результате, решение можно скорректировать значительно дешевле.
Иван связывает прототипирование с постоянной итеративной работой: сначала выясняется проблема, затем показывается решение, собирается обратная связь, вносятся изменения и только после этого продукт развивается дальше. Для эмоциональных массовых B2C-продуктов он отдельно отмечает необходимость качественных, high-fidelity-прототипов или MVP, поскольку интервью там дают менее однозначные сигналы.
Иван Замесин определяет customer development как получение у пользователей инсайтов, которые в идеале становятся нечестными преимуществами продукта. Эти инсайты извлекаются через интервью, MVP и структурированные эксперименты, затем превращаются в продуктовые решения. Смысл не в том, чтобы просто собрать мнения, а в том, чтобы найти важные детали пользовательской потребности, которые позволят продукту выиграть у альтернатив.
Инсайтом может быть сильная, частотная боль, неочевидный сценарий, привычный пользователю костыль, важная эмоция или условие, при котором человек готов платить. После обнаружения такие сведения должны быть применены в продукте: команда делает решение, которое точнее отвечает реальному опыту пользователя, чем существующие варианты.
Иван подчёркивает, что конкурентное преимущество может возникнуть не только из технологической уникальности. Оно может появиться из лучшего понимания потребности и способности устранить неудобство или дать заметное удовольствие. Custdev сокращает дистанцию между предположениями команды и действительным контекстом пользователя
Иван Замесин говорит, что у продукта всегда есть конкурент, и этим конкурентом необязательно является другой сервис. Конкурировать приходится также с привычкой, инерцией и отсутствием действия. Пользователь может продолжать делать всё по-старому, даже если существующий способ неудобен, либо вообще не решать задачу, потому что не воспринимает её как достаточно важную.
Поэтому продукт должен либо заметно устранять боль, либо давать настолько сильное удовольствие, чтобы человек захотел изменить текущее поведение и заплатить. Недостаточно создать просто «полезную» функцию: нужно преодолеть стоимость переключения, привычный процесс и безразличие к проблеме. Если неудобство слабое, человек часто останется на текущем способе, даже понимая преимущества альтернативы.
Этот тезис связан с различием painkiller и delighter. Painkiller работает, когда человек осознаёт сильную боль и ищет способ от неё избавиться. Delighter может создавать привлекательную эмоцию или новый опыт. В обоих случаях задача исследования — понять, достаточно ли сильна мотивация, чтобы пользователь изменил привычное действие.
Иван Замесин выделяет интервью и MVP как основные инструменты customer development. Интервью позволяют глубоко понять текущий опыт пользователя: что он делает, с какими сложностями сталкивается, какие эмоции испытывает, какие альтернативы использует и почему. MVP позволяет перейти от слов к реальному поведению: показать решение, запросить оплату, проверить конверсию и увидеть фактические препятствия.
Эти инструменты решают разные части задачи и работают сильнее вместе. Интервью помогают найти и сформулировать гипотезу, а MVP и продажи позволяют проверить, превращается ли обнаруженная потребность в спрос на конкретное решение. После запуска MVP разговоры с пользователями продолжаются, чтобы объяснить наблюдаемые метрики и улучшать продукт.
Опросы Иван тоже относит к возможным инструментам, но использует их с осторожностью. Он считает, что большинство опросов плохо спроектированы и не даёт рекомендации опираться на них как на основной способ проверки. Вместо этого он советует проводить интервью либо считать unit-экономику на несовершенных, но реальных MVP
Иван Замесин прямо говорит, что не любит опросы, поскольку, по его наблюдению, мало кто умеет проводить их качественно. В рамках его подхода опрос уступает интервью по глубине: он хуже позволяет восстановить конкретный контекст, уточнить детали, заметить противоречия и добраться до эмоции, стоящей за поведением пользователя.
Опрос также не заменяет реальное действие. Пользователь может выразить интерес к идее, но это не доказывает готовность покупать, менять привычный процесс или регулярно пользоваться продуктом. Для проверки таких вещей Иван предлагает не полагаться на декларации, а использовать продажу, MVP и расчёт фактической unit-экономики.
При этом в лекции опросы не объявляются полностью бесполезными. Они названы одним из возможных способов исследования наряду с интервью и MVP. Однако приоритет отдан методам, которые быстрее дают конкретный и проверяемый сигнал: разговору о прошлом опыте и наблюдению за поведением при реальном предложении.
Одним из центральных принципов Ивана Замесина является сокращение времени до обратной связи с месяцев и недель до часов. Он противопоставляет ранние интервью и дешёвые проверки традиционному пути, при котором команда долго разрабатывает продукт, а затем лишь после запуска узнаёт, что он не нужен пользователям или непонятен им.
По его расчётам, поздняя обратная связь обходится дорого. Год разработки небольшой командой может стоить миллионы рублей ещё до первого контакта с реальным спросом; в корпорации стоимость полугодовой работы десятков участников ещё выше. При высокой вероятности провала новых гипотез такая модель особенно рискованна. Напротив, серия интервью и простых проверок позволяет быстро убить слабую гипотезу или уточнить её до начала масштабных инвестиций.
Сокращение цикла обратной связи — это не разовое исследование перед запуском, а постоянный способ работы. Интервью, продажи, прототипы, MVP, количественные эксперименты и разговоры с каждым пользователем ранней версии должны регулярно давать новые сигналы и направлять следующую итерацию
Иван Замесин рассказывает о стартапере Алексее Дешевых, который работал в агентстве, запускавшем рекламные кампании у блогеров. Алексей предположил, что агентствам трудно подбирать блогеров для рекламных размещений, получил инвестиции и до разработки продукта решил провести интервью. За 12 разговоров удалось быстро уточнить сегмент: релевантными оказались рекламные агентства с достаточно крупными бюджетами, а собеседниками — лица, принимающие решения, например руководители агентств или маркетинга.
Исследование показало, что формулировка общей проблемы «подбор блогеров» слишком широка. Для части агентств подбор происходил неформально: коллеги обсуждали знакомых блогеров за бизнес-ланчем, выбирали тех, на кого сами подписаны, и не воспринимали процесс как сложность. Такая аудитория не видела существенной боли и не была готова платить за инструмент.
Более перспективный сценарий обнаружился вокруг региональных кампаний. При работе в Москве и Петербурге специалисты знают крупных блогеров, могут оценить их аудиторию и качество, но поиск блогеров в менее знакомых городах оказывается отдельной задачей. Однако и здесь интервью показали различие между исполнением и покупкой: руководитель мог просто передать эту задачу ассистенту и не считать её собственной критической болью. Кейс показывает необходимость исследовать не только сам процесс, но и того, кто испытывает неудобство, распоряжается бюджетом и готов принимать решение. ## 89. Поиск платёжеспособных ЛПР в B2B
В кейсе Алексея Дешевых Иван Замесин подчёркивает важность поиска не просто пользователей процесса, а платёжеспособных лиц, принимающих решения. Для продукта подбора блогеров такими собеседниками оказались руководители рекламных агентств и руководители маркетинга, которые отвечают за проведение кампаний, распоряжаются бюджетом и могут принять решение прямо в ходе разговора.
Интервью необходимо квалифицировать. В данном случае Иван выделяет два ключевых условия: достаточный рекламный бюджет и возможность принимать решение. Без этих условий мнение человека может быть полезно для понимания процесса, но не подтверждает способность сегмента купить продукт. Если задача делегирована ассистенту или исполнителю, неудобство может существовать на операционном уровне, но не быть достаточной причиной для оплаты со стороны руководителя.
Таким образом, в B2B поиск сегмента включает проверку организационной роли человека. Нужно понять, кто сталкивается с задачей, кто несёт последствия, кто контролирует деньги и кто может согласовать покупку. Только совпадение сильной боли, полномочий и бюджета делает интервью надёжным основанием для дальнейшей продажи.
Изначально Алексей Дешевых планировал брать около тысячи долларов в месяц за инструмент подбора блогеров. Иван Замесин использовал интервью, чтобы проверить не просто наличие неудобства, а готовность рекламных агентств платить такую сумму. Основной вопрос был построен вокруг текущего способа работы: как именно агентство подбирает блогеров для рекламной кампании.
Ответы показали, что в части привычных сценариев ценность инструмента недостаточна. Когда речь шла о крупных городах, специалисты сами были знакомы с нужными блогерами и могли выбирать их через личные наблюдения и профессиональные контакты. Если же поиск касался регионов, задача часто передавалась ассистенту. В обоих случаях руководитель не выражал настолько сильной личной боли, чтобы оплата тысячи долларов в месяц выглядела оправданной.
Кейс показывает, что нельзя выводить цену из сложности процесса, замеченной внутри индустрии. Необходимо проверить, насколько проблема существенна для покупателя, какой ущерб или риск она создаёт и готов ли ЛПР обменять деньги на её решение. Наличие ручной работы ещё не означает существования платёжеспособного спроса.
В истории о подборе блогеров Иван Замесин показывает разницу между неудобством человека, который делает работу, и болью того, кто покупает продукт. Подбор региональных блогеров действительно может быть трудоёмким: для кампаний вне Москвы и Петербурга нужно искать незнакомых людей, проверять качество аудитории и собирать информацию. Однако руководитель агентства может делегировать эту работу ассистенту и не воспринимать её как собственную проблему.
Если ЛПР отвечает, что не хочет иметь с задачей ничего общего и просто передаёт её дальше, это не подтверждает сильную покупательскую боль. Нагрузка существует, но она может лежать на исполнителе без права на бюджет или без достаточной мотивации добиваться нового инструмента. Следовательно, проблема не должна оцениваться только по тому, насколько неудобным кажется процесс со стороны.
По мнению Ивана, в B2B особенно важно разделять роли пользователя, исполнителя, инициатора и покупателя. Для продуктовой гипотезы значимо, у кого находится наиболее сильная боль, кто видит экономический эффект решения и кто способен оплатить его. Иначе команда может создать инструмент для операционной трудности, которая не превращается в продажи.
Иван Замесин рассказывает, что идея сервиса Meta возникла не из заранее подготовленной продуктовой концепции. Его заинтересовало, как люди вообще приходят к психотерапии, поскольку его собственный путь к ней был долгим и необычным. Чтобы изучить этот путь, он провёл 40 интервью за неделю.
После примерно 20 разговоров Иван увидел повторяющуюся проблему: люди, уже готовые обратиться к психотерапевту, не понимают, что им делать дальше и куда идти. Таким образом, потребность была не в абстрактной информации о психотерапии, а в помощи с конкретным переходом от готовности обратиться за помощью к выбору специалиста. После обнаружения этой проблемы он начал проверять её продажей, не дожидаясь создания полноценного сервиса.
Он предлагал подобрать психотерапевта в течение недели за деньги, называл разные суммы и в итоге пришёл к диапазону примерно трёх — трёх с половиной тысяч рублей. Восемь из двадцати собеседников были готовы отдать деньги прямо во время интервью. Иван не брал оплату, поскольку целью была проверка спроса, а не немедленная выручка. Полученный сигнал и причины отказов помогли перейти к созданию сайта, который, по его словам, начал нормально конвертировать.
Исследование Meta началось с изучения того, как люди приходят в психотерапию. Иван Замесин не стартовал с вопроса о будущем продукте и не спрашивал, нужен ли пользователям сервис подбора. Вместо этого он исследовал их реальный путь: как возникало понимание необходимости помощи, какие шаги предпринимались, где появлялись сомнения и что мешало перейти к работе со специалистом.
После первых двадцати интервью проявился устойчивый инсайт. Люди, которые уже созрели для обращения к психотерапевту, не знали, куда двигаться дальше. Им не хватало понятного маршрута и помощи в выборе. Это позволило сузить формулировку проблемы и перейти от общего интереса к психотерапии к проверяемой ценностной гипотезе: можно ли предложить пользователю платный подбор специалиста.
Кейс демонстрирует важность исследования пути, а не только конечного действия. Пользователь может быть мотивирован решить проблему, но останавливаться на промежуточном этапе из-за неопределённости, отсутствия знаний или сложности выбора. Именно этот барьер стал основой для последующей продажи и создания сервиса Meta.
Иван Замесин отмечает, что интенсивное проведение интервью может быть эмоционально тяжёлым, особенно если разговоры посвящены чувствительным личным темам. В процессе исследования пути к психотерапии он провёл 40 интервью за неделю, в отдельные дни — примерно по восемь. После третьего дня, по его словам, нагрузка оказалась настолько высокой, что он несколько дней не мог нормально работать и лежал без сил.
Причиной стала необходимость пропустить через себя большое количество личных историй. Иван описывает это как ситуацию, в которой эмпатия «вырубила» привычные системы защиты. Этот опыт не отменяет ценность интенсивного исследования: уже после 20 интервью была обнаружена значимая повторяющаяся проблема. Но он показывает, что темп и эмоциональная сложность разговоров необходимо учитывать при планировании работы.
В контексте лекции этот пример также подчёркивает ценность глубоких качественных интервью. Они дают не только рациональные ответы о процессе, но и доступ к тревогам, сомнениям и переживаниям людей. Однако сбор такой информации требует от интервьюера внимания к собственному ресурсу.
После выявления проблемы Иван Замесин не стал сначала создавать полноценный сервис Meta. Он начал напрямую предлагать услугу: подобрать человеку психотерапевта за неделю за определённую плату. В разговоре он просил деньги сразу и был готов оформить расписку, указывая свои паспортные данные и обязательство оказать услугу в установленный срок.
Такой формат позволил проверить не только интерес к идее, но и готовность человека принять конкретное предложение. Восемь из двадцати собеседников согласились заплатить. Когда они доставали деньги, Иван отказывался их брать, потому что исследовательская задача состояла в проверке спроса, а не в получении оплаты от конкретных респондентов. Тем не менее сам факт готовности оплатить услугу стал для него значимым подтверждением потребности.
Этот кейс иллюстрирует общий тезис Ивана: до создания продукта можно продавать будущую услугу вручную. Если у человека действительно есть проблема и он видит ценность решения, он может купить даже обещание выполнить работу, а не готовую цифровую платформу.
В кейсе Meta Иван Замесин проверял цену не через вопрос о предпочтительной стоимости, а через предложение реальной оплаты. Он называл разные суммы и в итоге остановился примерно на трёх — трёх с половиной тысячах рублей за подбор психотерапевта в течение недели. Проверка заключалась в том, готов ли человек в конкретной ситуации отдать деньги сейчас.
Такой подход позволяет отличить вежливый интерес от настоящей готовности платить. Пользователь может положительно оценивать идею подбора специалиста, но только действие с деньгами показывает, является ли ценность достаточно сильной. Восемь согласившихся из двадцати интервьюируемых дали сигнал, что услуга решает реальную проблему для части аудитории.
Иван также показывает, что цена может уточняться итеративно. В другом примере — с монетизацией Meta для психотерапевтов — исследование текущих альтернатив позволило поднять предполагаемую комиссию: оказалось, что специалисты уже платят посредникам больше. Следовательно, проверка цены должна учитывать и фактические платежи пользователя за существующие способы решения задачи.
Иван Замесин подчёркивает, что валидация строится не только на тех, кто согласился купить. В кейсе Meta восемь человек были готовы заплатить за подбор психотерапевта, а остальные объяснили, почему они отказались. Эти объяснения становятся частью материала для доработки предложения, уточнения сегмента, изменения цены или пересмотра ценности услуги.
Такой подход уже был сформулирован им в общей схеме решенческих интервью: если человек не покупает, нужно спросить, чего не хватило. Отказ — это не просто отрицательный результат; он позволяет увидеть барьер, который не заметен команде. В зависимости от ответа может потребоваться изменить продукт, условия оказания услуги, коммуникацию, способ демонстрации ценности или признать, что гипотеза не подходит для данного сегмента.
Важна последовательность действий: причина отказа не должна автоматически превращаться в дорогую фичу. Её нужно рассматривать как новую гипотезу и проверять в следующих разговорах. Если изменение приводит к росту продаж, команда получает подтверждение; если нет — продолжает искать другую формулировку решения или отказывается от направления.
Иван Замесин приводит ФРИИ как пример организации, где стартапы фактически заставляют заниматься двумя вещами: customer development и продажами. Сначала команда должна найти сегмент и его проблему, а затем, обнаружив подходящую связку, перейти к продаже. Эта последовательность не допускает долгой разработки в изоляции от рынка.
По словам Ивана, такой подход показывает, что ранняя продажа может быть очень простой. Достаточно провести проблемные интервью, собрать MVP в Google Docs и предложить клиенту решение. Он упоминает рекорд ФРИИ: за две недели команда прошла путь от гипотезы проблемы через интервью до первой продажи с конкурентным платежом в 15 тысяч рублей в неделю.
Этот пример используется как доказательство практической применимости подхода. Ценность custdev не в подготовке красивого исследовательского отчёта, а в ускорении перехода от неопределённой идеи к подтверждённой проблеме и платёжному сигналу. Если продажи не появляются, команда получает повод быстро изменить или закрыть гипотезу.
Иван Замесин рассказывает, что MVP не обязан быть полноценным цифровым продуктом. В практике ФРИИ гипотеза может быть проверена с помощью Google Docs: сначала проводится проблемное интервью, затем команда собирает минимальную форму решения в простой таблице или документе и продаёт её клиенту.
Смысл такого MVP заключается в проверке ценности, а не технического совершенства. Если клиенту действительно нужно решить задачу, он может согласиться на вручную организованный процесс, временную реализацию или простой рабочий артефакт. Это позволяет получить первую оплату без затрат на сложную инфраструктуру, интерфейсы и автоматизацию.
Пример с продажей за 15 тысяч рублей в неделю показывает, что даже примитивная форма продукта может быть достаточной для валидации. После получения платежа команда уже знает, что проверяет не абстрактное одобрение, а реальную готовность клиента оплачивать результат. Затем можно решать, какие части решения действительно стоит превращать в масштабируемый продукт.
Иван Замесин считает, что в B2B готовность платить часто проявляется легче, чем в B2C, если экономический эффект сформулирован понятно. Когда бизнес теряет миллион рублей на существующей проблеме, предложение заплатить сравнительно небольшую сумму за существенную экономию становится прозрачным. Он приводит логику: если клиент будет платить 50 тысяч рублей в год, но сэкономит 950 тысяч, ему ясно, за что отдавать деньги.
В B2B сильным сигналом могут быть не только деньги, но и гарантийное письмо, обязательство провести эксперимент или согласие выделить бюджет после готовности прототипа. Иван упоминает кейс рекламного инструмента, в котором продажей становился commitment — обязательство клиента открутить через сервис определённую сумму рекламного бюджета. Клиент соглашался провести эксперимент через две недели, потому что рассчитывал снизить CPO, то есть стоимость заказа.
Такие обязательства показывают, что решение встроено в измеримую экономику клиента. Когда связь между продуктом и снижением затрат, ростом выручки или улучшением важной метрики понятна, B2B-покупатель может быстрее согласиться на пилот, предпродажу или оплату.
Иван Замесин приводит пример предпродажи летнего лагеря, который он придумывал вместе с Валерием Коваленко и другими участниками. Идея заключалась в образовательном продукте с сильными преподавателями и темами стратегии, продаж и крупных изменений в бизнесе. До полноценной реализации программы её ценность была проверена непосредственно во время ужина.
Нескольким людям сразу предложили участие, и за вечер удалось продать мест на 60 тысяч рублей. Пять человек моментально перевели деньги. Для Ивана это стало иллюстрацией того, что предпродажа возможна не только в B2B-инструментах или сервисах с очевидной экономией, но и в образовательных продуктах: если людям действительно нужен результат или они видят большой потенциал, они готовы платить до создания финального продукта.
Кейс поддерживает общий принцип лекции: деньги или немедленное платёжное действие дают более сильный сигнал, чем интерес к концепции. Предпродажа помогает подтвердить спрос и одновременно понять, что ценность продукта была достаточно ясной для покупателей ещё до его запуска.
Иван Замесин признаёт, что продавать психологически трудно. Ранее в лекции он связывает это с нежеланием основателей выходить к пользователям: разговор с пользователем означает необходимость столкнуться с реальной реакцией, услышать отказ или критику и признать, что продукт может быть слабым. В его пересказе позиции представителей YC одна из главных ошибок основателей состоит именно в изоляции от клиентов и отказе от продаж.
На примерах Meta, ФРИИ и образовательного лагеря Иван призывает не бояться просить деньги. По его мнению, люди готовы платить, когда у них действительно болит или когда они видят большой потенциал. Если платить не готовы, это не обязательно личная неудача основателя: отказ становится проверяемым сигналом о том, что нужно изменить продукт, сегмент, ценность или условия предложения.
В B2C, по его замечанию, продавать сложнее, чем в B2B, поскольку ценность не всегда выражается в очевидной экономии. Но сложность продажи не является основанием откладывать её до готовности идеального продукта. Напротив, раннее предложение купить помогает быстрее получить честную обратную связь и не тратить ресурсы на гипотезы, которые рынок не подтверждает.
Иван Замесин отмечает, что в B2B продажи и получение подтверждений спроса обычно происходят проще, чем в B2C. Причина в прозрачной экономике для клиента: если бизнес понимает, что из-за существующей проблемы теряет значимую сумму или, напротив, сможет заметно снизить затраты, ему легче принять решение об эксперименте с новым продуктом.
По словам Замесина, продажа должна опираться не на абстрактный интерес к продукту, а на понятную выгоду. Если стартап показывает, что клиент теряет, например, миллион рублей, а предлагаемое решение стоит существенно меньше и позволяет устранить большую часть потерь, ценность становится очевидной. В такой ситуации разговор с потенциальным клиентом может быстро перейти от исследования проблемы к договорённости о платном пилоте или обязательстве провести тест.
В качестве примера он приводит проект в области рекламных кампаний. Клиенту предлагают прототип инструмента и обещают подготовить его в течение двух недель, после чего спрашивают, готов ли он провести эксперимент. Ответ положительный, поскольку у клиента есть измеримая цель — снизить CPO, то есть стоимость заказа. Для B2B это сильный сигнал: решение связывается с конкретной метрикой бизнеса, а не с общим впечатлением от идеи.
При этом Замесин подчёркивает, что B2B-клиенту не обязательно сразу продавать полностью готовый продукт. Достаточно сформулировать проблему, показать направление решения и согласовать последующий эксперимент. Если бизнес видит экономический эффект на близкой дистанции, он готов двигаться дальше ещё до полноценной разработки.
Иван Замесин рассматривает не только оплату, но и формальные обязательства клиента как сильный признак реального спроса. В B2B-коммуникации таким сигналом может быть гарантийное письмо, обязательство провести эксперимент, согласие выделить бюджет или подтверждение будущей закупки при выполнении оговорённых условий.
Логика состоит в том, что бизнесу проще зафиксировать намерение, когда ценность понятна, но продукт ещё не полностью создан. Если компания понимает, что новый инструмент способен улучшить ключевую экономическую метрику, она может подтвердить готовность протестировать его после выхода прототипа. Это отличается от вежливой положительной реакции на интервью: клиент не просто говорит, что идея интересна, а принимает на себя действие или обязательство.
Замесин приводит пример из рекламных технологий: потенциальному клиенту показывают прототип и предлагают через две недели провести эксперимент. Клиент соглашается, поскольку ожидает снижения стоимости заказа. Такое согласие на пилот выступает проверкой того, что проблема не выдумана, а ценность решения достаточно велика для практического шага со стороны клиента.
Гарантийные письма и подобные договорённости особенно важны на ранней стадии. Они позволяют не строить продукт в изоляции, а получить предварительное подтверждение того, что конкретный сегмент действительно готов включиться в работу с решением. Для Замесина это один из способов сократить расстояние между гипотезой и реальным рыночным сигналом.
Иван Замесин прямо противопоставляет B2B и B2C: в B2C продавать сложнее. В B2B решение часто оправдывается измеримой экономикой — снижением затрат, ростом выручки, улучшением CPO или устранением очевидных потерь. В B2C такой расчёт не всегда доступен: пользователь может испытывать неудобство, но не считать его достаточной причиной для покупки.
Для B2C важно отличать заявленный интерес от реальной готовности платить. Пользователь может сказать, что продукт ему нравится, что он «попробовал бы» или что функция выглядит полезной, но такие слова не равны покупке. Поэтому Замесин ранее в лекции предлагает проверять спрос через фактическое действие: продажу, предоплату, использование MVP или иной наблюдаемый выбор человека.
Сложность B2C также связана с тем, что многие продукты опираются не на явную рациональную боль, а на эмоции, привычки, удовольствие и дофаминово-эндорфиновый цикл. Для таких решений интервью и прямые вопросы о будущем поведении дают ограниченно надёжные результаты. Пользователь не всегда способен объяснить, будет ли он возвращаться к продукту, как часто станет им пользоваться и готов ли платить.
В результате для массового B2C более значимыми становятся качественный прототип, MVP, поведенческие показатели и количественная проверка. По мнению Замесина, в B2C сложнее получить столь же прямой сигнал, как в B2B, где клиент может сразу увидеть финансовую отдачу и формально согласиться на пилот.
Иван Замесин приводит кейс компании, которая вместе со стартап-направлением ФРИИ пыталась найти платящий сегмент в США. Российский рынок уже был понятен: целевой аудиторией были маркетологи, работающие с определёнными рекламными бюджетами. Команда предположила, что в США подходящий сегмент будет таким же, и начала искать именно этих людей.
Однако исходная гипотеза не дала быстрого результата. На протяжении примерно четырёх недель команда пыталась получить интервью, но фактически не получала их. Этот случай иллюстрирует, что перенос уже работающей сегментации с одного рынка на другой не гарантирует успеха: даже при сходстве ролей и задач могут отличаться каналы коммуникации, привычки, ожидания и организационные детали.
Первые интервью появились лишь случайно к концу четвёртой недели. Именно в этих разговорах команда обнаружила две причины низкого отклика, не связанные непосредственно с основной продуктовой гипотезой. Во-первых, для потенциальных респондентов способ оплаты через PayPal выглядел недоверительно: они прямо сказали, что воспринимают PayPal как подозрительный вариант. Во-вторых, предложенная компенсация в 30 долларов не соответствовала стоимости часа нужных специалистов.
После исправления этих деталей интервью начали проводиться с высокой скоростью — до восьми в день. За следующие две недели команда сделала несколько предпродаж, выяснила значимые особенности сегмента и перешла к созданию MVP. Кейс показывает, что поиск сегмента на новом рынке включает не только проверку того, «кому болит», но и адаптацию всей механики доступа к этим людям.
В кейсе поиска сегмента в США Иван Замесин рассказывает, что команда использовала несколько каналов рекрутинга. Она писала потенциальным респондентам в LinkedIn, отправляла письма по электронной почте и использовала платные способы привлечения людей на интервью. Несмотря на активность в разных каналах, в первые недели это не дало результата: интервью не назначались.
Этот пример нужен Замесину, чтобы показать: набор респондентов, особенно в B2B и на незнакомом зарубежном рынке, сам по себе является отдельной исследовательской задачей. Нельзя предполагать, что достаточно определить целевой сегмент и отправить сообщения в привычных каналах. Даже если гипотеза о роли или размере бюджета выглядит логично, способ достучаться до нужных людей может оказаться неверным.
После случайно состоявшихся первых интервью команда получила обратную связь о причинах низкого отклика. Проблема была не только в содержании приглашения или выборе канала, но и в условиях участия: недоверии к предложенному платёжному механизму и недостаточном размере вознаграждения. Когда эти факторы были изменены, существующие каналы начали работать значительно эффективнее.
Замесин делает из этого практический вывод: поиск респондентов не следует считать технической формальностью. Первые недели могут уйти именно на то, чтобы найти жизнеспособный способ рекрутинга, особенно если речь идёт о сложном B2B-сегменте или клиентах в другой стране.
В американском кейсе команда предлагала респондентам оплату за интервью через PayPal. Когда несколько потенциальных участников всё же пришли на разговор, они указали, что такой способ расчёта вызывает недоверие. По их словам, PayPal воспринимался как «скам», то есть подозрительный или ненадёжный способ получить деньги.
Для Замесина это пример того, как, казалось бы, второстепенная операционная деталь может блокировать исследование целиком. До исправления способа оплаты команда не могла наладить поток интервью, хотя использовала LinkedIn, email и платные каналы. После замены PayPal рекрутинг заработал: стали появляться интервью, а затем их количество выросло до восьми в день.
Смысл примера не в универсальной оценке конкретного платёжного сервиса, а в необходимости проверять, соответствует ли механика вознаграждения ожиданиям аудитории на конкретном рынке. Если респондент не доверяет способу оплаты, обещанная компенсация не мотивирует его участвовать, поскольку сама выплата кажется сомнительной или неудобной.
Таким образом, способ расчёта является частью пользовательского опыта респондента. При поиске людей на интервью он способен влиять на конверсию не меньше, чем текст приглашения, выбранная социальная сеть или размер компенсации.
Иван Замесин рассказывает, что в кейсе поиска B2B-сегмента в США команда предлагала 30 долларов за интервью. Когда первые потенциальные респонденты всё же дали обратную связь, они прямо объяснили, что эта сумма слишком мала: их рабочий час стоил дороже, и для участия требовалась компенсация хотя бы в 50 долларов.
После повышения вознаграждения вместе с изменением способа оплаты команда получила резкий рост числа интервью — до восьми в день. Этот результат показывает, что размер компенсации должен соотноситься не с внутренним бюджетом исследовательской команды, а с ценой времени конкретного сегмента. Особенно это актуально для профессиональной B2B-аудитории, где респондентами могут быть специалисты и лица, принимающие решения.
Компенсация в этом случае выступает не просто благодарностью за участие. Она устраняет барьер, связанный с альтернативной стоимостью времени человека. Если нужный респондент считает, что разговор отвлечёт его от работы, сумма должна быть достаточно значимой, чтобы участие выглядело рациональным.
Замесин связывает этот вывод с более широкой мыслью о том, что доступ к сегменту редко находится с первого раза. Условия рекрутинга, включая размер выплаты, нужно рассматривать как гипотезы и менять на основании обратной связи от первых доступных людей.
По словам Ивана Замесина, поиск первых сегментов часто занимает заметное время, и это нормально. В приведённом зарубежном кейсе на первые интервью ушло около четырёх недель, хотя команда с самого начала предпринимала активные действия: писала в LinkedIn, отправляла письма и использовала платные способы привлечения респондентов.
Замесин подчёркивает, что особенно сложно искать людей в B2B. Целевая аудитория может быть узкой, занятой, находиться в другой стране и не реагировать на стандартные приглашения. Поэтому отсутствие интервью на раннем этапе не доказывает автоматически, что гипотеза о сегменте неверна: возможно, команда ещё не нашла работающий канал доступа или корректные условия участия.
В кейсе поворот произошёл только после нескольких случайно проведённых разговоров. Они позволили обнаружить конкретные барьеры: недоверие к PayPal и недостаточную компенсацию за время. После их устранения рекрутинг резко ускорился, а команда смогла за две недели провести серию интервью и сделать несколько предпродаж.
Главный вывод Замесина состоит в необходимости заранее запастись терпением. Поиск сегмента и способа находить респондентов — это не мгновенный шаг перед интервью, а самостоятельный итеративный процесс. Нужно продолжать пробовать, собирать обратную связь о самом процессе рекрутинга и корректировать механику до появления устойчивого потока разговоров.
Иван Замесин приводит кейс сервиса уборки Clean как пример того, как качественное исследование может помочь улучшить retention. У компании уже был сегмент с хорошими показателями lifetime value и ARPU, однако пользователи заказывали уборку нерегулярно. Между двумя заказами могло проходить около полутора месяцев, что ограничивало повторное использование сервиса.
Команда решила не начинать с разработки новой функции, а поговорить с клиентами и понять их фактический сценарий. В ходе двадцати интервью начала регулярно звучать формулировка «генеральная уборка». Повторяемость этого понятия стала основанием для дальнейшего исследования: команда вернулась к нему, чтобы выяснить, что именно пользователи вкладывают в этот сценарий и почему он связан с нерегулярными заказами.
Выяснилось, что пользователи воспринимали Clean преимущественно как сервис поддерживающей уборки. Когда квартира постепенно становилась слишком грязной, клиент не заказывал услугу, а сам проводил большую генеральную уборку. После этого через несколько недель снова мог заказать поддерживающую уборку, затем забыть о сервисе и повторить тот же цикл.
Таким образом, причиной низкой регулярности было не отсутствие интереса к сервису в целом, а разрыв между фактической потребностью пользователя и тем, как он воспринимал продукт. Исследование позволило выделить отдельную ценность — генеральную уборку — и рассмотреть её как способ сделать использование сервиса более системным и повысить retention.
В кейсе Clean потребность в генеральной уборке не была сформулирована командой заранее как центральная продуктовая гипотеза. Она проявилась во время интервью: после примерно двадцати разговоров пользователи начали повторять выражение «генеральная уборка». Замесин обращает внимание на сам факт повторяемости: повторяющийся язык клиентов становится сигналом, что за ним может стоять массовый сценарий или недостающая часть продукта.
Дальнейшее исследование показало, что клиенты относили сервис Clean к поддерживающей уборке. Такая уборка помогала поддерживать порядок, но не решала ситуацию, когда квартира уже заметно запущена. В этот момент пользователь засучивал рукава и самостоятельно проводил интенсивную генеральную уборку, после чего лишь через несколько недель возвращался к поддерживающей услуге.
В результате возникал цикл: квартира загрязняется, пользователь делает всё сам, затем ненадолго пользуется поддерживающей уборкой, перестаёт заказывать её, снова накапливает беспорядок и повторяет самостоятельную генеральную уборку. Для сервиса это означало длительные паузы между заказами, хотя у клиента в действительности существовала регулярная потребность в разных видах уборки.
Выявленная потребность заключалась не просто в добавлении нового названия услуги. Она показывала, что пользователю нужен другой входной сценарий в сервис в момент сильного загрязнения квартиры. Предложение генеральной уборки могло помочь закрыть этот сценарий и сократить разрыв между редкими заказами поддерживающей уборки.
После интервью и обсуждения потребности в генеральной уборке команда Clean не сразу приступила к полноценной разработке. По рассказу Ивана Замесина, сначала гипотезу решили проверить через email-рассылку. Это позволило быстро и сравнительно дёшево проверить интерес к новой услуге у существующей аудитории.
Рассылку отправили сегментированной группе пользователей и по-разному взвешивали предложение на разных клиентах. Такой подход соответствовал общей логике лекции: до серьёзных инвестиций в разработку необходимо получить наблюдаемый сигнал от рынка. В данном случае сигналом должно было стать не высказывание пользователя в интервью, а его реакция на конкретное предложение.
Результаты рассылки оказались заметно сильнее обычных показателей: CTR был на три–четыре процентных пункта выше, чем стандартные open rate и CTR в сопоставимых письмах. Для команды это стало количественным подтверждением того, что гипотеза, возникшая в интервью, имеет поведенческое основание среди реальных клиентов.
После этого Clean перешёл к созданию услуги генеральной уборки. Кейс демонстрирует последовательность, которую продвигает Замесин: качественные интервью помогают обнаружить сценарий и сформировать гипотезу, а простой MVP-формат — в данном случае рассылка — позволяет проверить реакцию аудитории до масштабной продуктовой реализации.
В истории Clean Иван Замесин показывает, как CTR может использоваться для количественной проверки продуктовой гипотезы. Интервью позволили команде предположить, что клиентам важна генеральная уборка, однако сами по себе двадцать разговоров не были достаточным основанием для уверенности в масштабе спроса. Поэтому команда сформулировала предложение и проверила его через email-рассылку.
Критерием стал отклик получателей на письмо. Показатель CTR оказался на три–четыре процентных пункта выше, чем обычные метрики открытия и переходов для подобных рассылок. Именно сравнение с базовым уровнем сделало результат содержательным: команда увидела, что предложение вызывает более сильную реакцию, чем типичная коммуникация с тем же сегментом.
Замесин использует этот пример, чтобы разделить качественную и количественную валидацию. Качественное исследование помогло понять пользовательский контекст: Clean воспринимается как поддерживающая уборка, тогда как генеральную пользователь вынужден делать сам. Количественный тест через рассылку показал, что эта найденная потребность не ограничивается отдельными интервью и может быть востребована более широкой аудиторией.
Высокий CTR не заменяет последующую оценку экономики и поведения пользователей, но в рамках кейса он выступил достаточным ранним сигналом для запуска новой услуги. Важна именно связка: гипотеза, основанная на наблюдениях за реальным опытом клиентов, проверяется конкретным действием пользователей.
Иван Замесин рассказывает о монетизации сервиса Meta, который подбирает психотерапевтов. Сервис берёт с терапевта комиссию за приведённого клиента, однако команда изначально не знала, какой размер комиссии будет приемлемым. Вместо того чтобы выбирать цену только по внутренним предположениям, она провела несколько интервью с психотерапевтами.
В разговорах удалось понять ситуацию молодых специалистов, которым необходимо набирать клиентскую базу. У них ещё нет сформированного имени, репутации, потока рекомендаций и независимого способа привлечения клиентов. Поэтому они приходят в центры, работают от имени центра и платят существенную долю выручки за каждого приведённого клиента.
Этот анализ изменил восприятие возможной цены Meta. Первоначально одна комиссия, равная стоимости одного занятия, казалась команде большой суммой: если сервис приводит клиента, терапевту предлагалось заплатить примерно три тысячи рублей за это привлечение. Однако текущая альтернатива для терапевта оказалась значительно дороже в долгосрочном выражении.
На следующем шаге команда проверила гипотезу о комиссии в размере уже двух стоимостей занятия. По словам Замесина, терапевты восприняли это нормально. Кейс иллюстрирует, что корректный прайсинг нельзя выводить только из ощущения «дорого» или «дёшево»: необходимо исследовать, как пользователь решает задачу сейчас и какие затраты уже несёт в альтернативных каналах.
В кейсе Meta Иван Замесин показывает, что при изучении монетизации необходимо выяснять не только желаемую цену нового продукта, но и то, какими альтернативами пользователь уже пользуется. Для молодых психотерапевтов альтернативой сервису подбора клиентов были специализированные центры, через которые они получали первых клиентов.
Эти центры приводили клиентов и взамен удерживали около 50% стоимости каждого занятия на протяжении всего жизненного цикла такого клиента. Замесин приводит пример: если занятие стоит 2,5–3 тысячи рублей, терапевт может отдавать центру примерно 1,25–1,5 тысячи рублей с каждой сессии. Поскольку клиент продолжает терапию долго, суммарные расходы специалиста становятся значительными.
При этом терапевты соглашаются на такие условия не потому, что считают их выгодными сами по себе, а потому что у них нет полноценной альтернативы. У молодого специалиста отсутствуют узнаваемость, рекомендации и устойчивый независимый поток обращений. Значит, его текущая задача — не просто минимизировать разовый платёж, а получить доступ к клиентам, без которых практика не может вырасти.
Именно сопоставление с этим сценарием позволило Meta изменить гипотезу о цене. Комиссия за одного приведённого клиента выглядела приемлемо не в вакууме, а в сравнении с тем, сколько терапевт теряет в существующем решении. По логике Замесина, такой анализ текущих способов решения потребности помогает обнаружить реальную ценность продукта и избежать занижения цены из-за неподтверждённых опасений.
Meta планировала брать с психотерапевтов комиссию за клиента, которого привёл сервис. Иван Замесин объясняет, что на первом этапе команда опасалась, что комиссия размером в стоимость одного занятия окажется слишком высокой. В качестве условного примера называлась плата около трёх тысяч рублей за клиента, с которым терапевт затем будет работать.
Интервью с терапевтами показали, что это опасение не учитывало существующую экономику рынка. Молодые специалисты уже отдавали центрам около половины стоимости каждой сессии с привлечённым клиентом. По сравнению с этой регулярной и длительной выплатой единоразовая комиссия Meta выглядела не чрезмерной, а вполне оправданной.
После этого команда не остановилась на первоначальной цене. Уже на следующей неделе была проверена гипотеза о комиссии размером в две стоимости занятия. Согласно рассказу Замесина, терапевты приняли и этот вариант как нормальный. Это стало основанием считать, что сервис может брать более высокую комиссию, чем команда предполагала изначально.
Кейс подчёркивает важность проверки цены через реальные разговоры о текущем опыте и альтернативах. Не следует полагаться на собственное ощущение стоимости продукта. Нужно понять, за что пользователь платит сегодня, сколько он в итоге отдаёт и почему продолжает пользоваться существующим решением. Только после этого можно формулировать и тестировать размер комиссии.
Иван Замесин рассказывает, что Chatfuel, конструктор ботов для Facebook Messenger, долгое время был бесплатным. Низкий порог входа был нужен по двум причинам: в 2016 году рынок ещё не понимал, зачем нужны боты, а команде требовалось привлечь много пользователей и посмотреть, какие сценарии действительно начинают работать.
Стратегия состояла в том, чтобы позволить людям создавать ботов, наблюдать за практикой и затем сфокусироваться на успешных кейсах. Когда к осени 2016 года стало понятнее, какие применения приживаются, команда начала исследовать пользователей. Наиболее значимым оказался сегмент маркетологов, использовавших ботов для воспроизведения триггерных email-рассылок.
Замесин подчёркивает, что ценность была найдена не в самом факте создания бота, а в конкретном бизнес-сценарии. Маркетологи привлекали лида в бот, затем с помощью аргументов, социальной валидации и коммуникации о ценности подводили его к покупке. Это была знакомая бизнесу модель, уже существовавшая в email-маркетинге, но с существенно иными показателями взаимодействия.
После выявления сценария команда проводила интервью о том, как именно пользователи применяют продукт, а затем изучала принципы ценообразования у экспертов и начинала продавать. По мнению Замесина, это позволило перейти от бесплатного инструмента без ясной модели монетизации к понятному платёжному сценарию, в котором клиент видит измеримый результат.
В Chatfuel команда обнаружила, что маркетологи используют Messenger-ботов как аналог триггерных email-рассылок. В email-маркетинге пользователь сначала привлекается как лид, а затем получает последовательность сообщений: аргументы, социальное доказательство и объяснение ценности продукта. Цель такой цепочки — довести лида до покупки.
Тот же сценарий стал воспроизводиться в ботах. Маркетолог покупает пользователя для бота, например примерно за один доллар, а затем использует диалоговый канал для дальнейшей коммуникации и продажи. По словам Ивана Замесина, для команд это был понятный и уже знакомый способ применения нового инструмента: они не изобретали совершенно новый процесс, а переносили в Messenger работающую механику из email.
Важным стало то, что боты давали более высокую вовлечённость. Замесин описывает их как канал, в котором показатели открытия и переходов значительно превосходят email. Благодаря этому привычная модель лидогенерации и прогрева становилась экономически интереснее: при сопоставимых затратах на привлечение можно было получить больше взаимодействий и выше вероятность продажи.
Именно этот сценарий сформировал основу платёжной ценности Chatfuel. Команда не просто продавала возможность собрать бота, а связывала продукт с задачей маркетологов — превращать купленных лидов в клиентов с лучшей конверсией.
Иван Замесин сравнивает показатели email-рассылок и Messenger-ботов на примере маркетинговой воронки. В email-канале открываемость и CTR измеряются процентами; по его словам, даже хорошие показатели открытий находятся примерно в диапазоне 10–20%, а переходы также остаются сравнительно низкими.
В ботах ситуация, по его описанию, отличается радикально. Open rate может доходить до 90%, а CTR — до 60%. Это означает, что пользователь значительно чаще видит сообщение и реагирует на него. Поэтому бот может стать более эффективным инструментом для той же задачи, которую раньше решали через email-цепочки.
Замесин приводит упрощённую экономическую модель: маркетолог может купить пользователя в бот примерно за доллар и продать ему продукт. Если в email конверсия в покупку условно составляет около 5%, то в боте она может достигать 30%. При таких различиях в поведении канала меняется и готовность бизнеса платить за инструмент.
Для Chatfuel эти данные были не просто красивой характеристикой продукта. Они объясняли, почему пользователи описывали сервис фразой «мы используем вас как Mailchimp», но одновременно получали существенно более высокий результат. Сравнение конверсий стало частью основания для поиска модели монетизации и выбора цены относительно привычного для рынка email-инструмента.
После того как Chatfuel обнаружил работающий сценарий применения ботов, команда не стала назначать цену только на основании собственных представлений. По словам Ивана Замесина, были проведены многочисленные интервью с экспертами, чтобы понять, по каким принципам ценообразование устроено в бизнесах, похожих на Chatfuel.
Затем начались непосредственные продажи. В процессе разговоров команда выясняла, как клиенты описывают использование продукта. Пользователи регулярно говорили, что применяют Chatfuel «как Mailchimp». Эта повторяющаяся формулировка дала важную рыночную опору: у клиентов уже существовал знакомый класс решений и понятный ориентир цены.
Однако сходство сценария не означало равенства ценности. Chatfuel использовали для той же задачи маркетинговых цепочек, но показатели вовлечения и конверсии были выше, чем в email. Следовательно, продукт мог обосновывать цену не только через аналогию с Mailchimp, но и через более сильный результат для бизнеса.
Замесин показывает, что B2B-прайсинг нужно исследовать одновременно в трёх плоскостях: как клиент решает задачу сейчас, какие альтернативы он использует и какую экономическую отдачу получает от нового решения. Интервью с экспертами и реальные продажи позволили команде не строить модель цены отвлечённо, а соотнести её с привычными для рынка инструментами и фактической ценностью Chatfuel.
В ходе продаж Chatfuel команда постоянно слышала от клиентов формулировку: «Мы используем вас как Mailchimp». Иван Замесин интерпретирует это как важный сигнал для ценообразования. Mailchimp был понятной альтернативой и ориентиром: пользователи уже платили за email-маркетинг, а Chatfuel решал аналогичную задачу — выстраивал триггерную коммуникацию с лидами и помогал доводить их до покупки.
При этом Замесин подчёркивает, что конверсия в ботах была значительно выше, чем в email. Из этого можно было бы сделать вывод, что Chatfuel должен стоить дороже Mailchimp, поскольку приносит лучший бизнес-результат. Однако команда выбрала более осторожный вариант и назначила цену немного ниже.
Причиной была психологическая и рыночная чувствительность к стоимости. Замесин говорит, что есть инструменты, за которые клиентам особенно болезненно платить, и среди них называет Slack, Mailchimp и Intercom. Поэтому подход Chatfuel заключался в следующем: быть дешевле привычного, уже воспринимаемого как дорогой альтернативного инструмента, но одновременно предлагать результат в несколько раз эффективнее.
Такое позиционирование объединяло понятность и выгоду. Клиент видел знакомый сценарий использования, сравнивал продукт с уже известным Mailchimp, но получал аргумент в пользу перехода — более высокую эффективность при немного меньшей цене. Эта логика была подтверждена продажами и стала основой для дальнейшего масштабирования.
После того как Chatfuel определил платёжный сценарий, исследовал принципы прайсинга и выбрал позиционирование относительно Mailchimp, команда перешла к реальным продажам. Иван Замесин говорит, что продажи начали происходить легко, а цикл сделки оказался очень коротким.
Короткий цикл был важен не сам по себе. Он показывал, что продуктовая ценность и цена понятны клиентам, а возражения не требуют длительного обучения рынка или многомесячных согласований. Пользователи уже знали, как применять продукт, потому что воспринимали его как более эффективную альтернативу привычному инструменту email-маркетинга.
Получив этот сигнал, команда не стала бесконечно продолжать ручную проверку в том же масштабе. По словам Замесина, она просто начала масштабировать найденную историю. Это соответствует общей логике лекции: сначала выявить сегмент и боль, затем подтвердить готовность платить, проверить решение и монетизацию, а после появления устойчивых продаж переходить к масштабированию.
Кейс показывает, что масштабировать следует не на основании интереса к идее или отдельных положительных интервью, а после сочетания нескольких признаков: понятного сценария использования, убедимой ценности для клиента, проверенной цены, реальных продаж и короткого цикла сделки.
Иван Замесин рекомендует проверять даже небольшие продуктовые изменения до их широкого внедрения. В качестве простого примера он рассказывает о повышении цены в Meta. Вместо масштабного исследования команда быстро обратилась к лояльным пользователям: шести психотерапевтам в общем чате и ещё трём в личной переписке.
Все опрошенные дали положительный сигнал, который Замесин описывает как «green light». После этого цена была повышена, а unit-экономика продукта сразу улучшилась. В данном случае не утверждается, что короткий опрос полностью заменяет все виды проверки, но он показан как быстрый и практичный способ снизить неопределённость перед решением.
Для Замесина ценность такого подхода в скорости обратной связи. Команде не нужно строить сложную модель в отрыве от клиентов или долго ждать результатов после изменения. У лояльной аудитории можно быстро выяснить, воспринимается ли планируемая цена как приемлемая, и уже затем делать следующий шаг.
Этот пример продолжает тезис о том, что проверять стоит каждую значимую гипотезу — не только новую большую функцию, но и изменение цены. Даже несколько прямых контактов с людьми, уже знакомыми с продуктом, могут дать основания для более уверенного решения и улучшения экономики.
Иван Замесин утверждает, что customer development не заканчивается в момент появления работающего бизнеса. Когда продукт уже запущен, его всё равно необходимо постоянно улучшать через разговоры с пользователями, тестирование прототипов, анализ MVP и проверку unit-экономики.
Он призывает проверять каждую «божью фичу» до того, как инвестировать в неё значительные ресурсы. Для этого можно создать чат с лояльными пользователями и регулярно задавать им вопросы: нужна ли предполагаемая функция, как они решают соответствующую задачу сейчас, вызывает ли идея интерес и какие возражения возникают. Такой канал позволяет получать быстрые сигналы без ожидания длительного цикла разработки.
Постоянное интервьюирование нужно не только для поиска проблем, но и для проверки монетизации, продуктовых изменений и новых сценариев. Пример с повышением цены у Meta показывает, как небольшая серия разговоров с терапевтами помогла принять решение и улучшить unit-экономику. Аналогично можно проверять будущие функции и направления развития продукта.
Смысл подхода в том, чтобы не допускать возвращения к разработке в изоляции. Даже работающий продукт может тратить время команды на ненужные изменения, если решения принимаются только по внутренним представлениям. Регулярный контакт с пользователями помогает сохранять связь между тем, что строится, и тем, что действительно нужно или ценно сегменту.
Иван Замесин описывает создание новой вертикали как повторение всего цикла customer development, а не как автоматическое расширение уже работающего продукта. Если компания хочет выйти в новый сегмент или новую предметную область, ей снова нужно искать аудиторию, исследовать её опыт, находить сильную боль и проверять, существует ли готовность платить за решение.
В качестве ориентира он возвращается к примеру Clean: при работе с новой потребностью команда проводит интервью, ищет сегменты и продолжает исследование до тех пор, пока не найдёт людей с выраженной проблемой. Лишь после этого можно переходить к созданию решения, прототипам, MVP и количественной проверке.
Замесин подчёркивает, что наличие успешного текущего продукта не гарантирует понимания следующего рынка. Новая вертикаль может иметь другую аудиторию, иную мотивацию, отличающиеся альтернативы и собственные сценарии использования. Поэтому прежние выводы нельзя просто переносить без проверки.
После появления сильной боли и подтверждённого сегмента процесс продолжается: создаются прототипы, с пользователями MVP постоянно разговаривают, проверяется unit-экономика, а продукт итеративно улучшается. Таким образом, расширение рассматривается как новый исследовательский цикл, а не как простое добавление очередной функции.
Иван Замесин называет первым основанием для продукта ситуацию, в которой пользователь ясно осознаёт свою проблему и прямо говорит: «У меня это болит». Такой продукт он относит к painkiller: решение устраняет конкретную боль, которую человек уже замечает в своей жизни или работе.
В этом случае связь между проблемой и ценностью продукта относительно проста. Пользователь понимает, что ему неудобно, дорого, страшно, долго или рискованно жить с существующим способом решения задачи. Если новый продукт снимает эту боль, его легче объяснить, проверить через интервью и продать.
Для исследования painkiller-продукта центральное значение имеет разговор о текущем опыте. Нужно выяснить, как человек решает потребность сейчас, когда проблема возникала в последний раз, почему ситуация была тяжёлой, какие эмоции он испытывал и насколько сильными они были. Замесин предлагает приоритизировать боли по частотности и эмоциональной силе, поскольку за сильную и регулярно возникающую проблему пользователь с большей вероятностью будет готов платить.
Явная боль отличается от абстрактного пожелания тем, что она уже встроена в реальные действия человека. Пользователь не просто предлагает идею для продукта, а описывает существующие потери, неудобства и обходные пути. Именно такие наблюдаемые проблемы Замесин считает наиболее надёжной основой для продуктового решения.
Вторым основанием для продукта Иван Замесин называет ситуацию, когда у человека есть боль, но он к ней привык и поэтому не осознаёт её как проблему. Пользователь может регулярно сталкиваться с неудобством, тратить лишнее время или использовать костыли, но считать это неизбежной частью процесса.
Для продукта это означает, что недостаточно спросить человека в лоб, чего ему не хватает. Он может ответить, что всё нормально, потому что уже адаптировался к текущему способу работы. Поэтому Замесин предлагает погружаться в подробности последнего реального сценария: что именно происходило, какие шаги выполнялись, где возникали сложности и какие эмоции сопровождали ситуацию.
Через детали такого опыта можно заметить боль, которую сам пользователь не сформулировал. В лекции эту логику иллюстрируют примеры пользовательских костылей и сложных сценариев: человек может совершать лишние действия, ошибаться или испытывать дискомфорт, но не называть это отдельной проблемой, пока интервьюер не попросит подробно восстановить конкретный случай.
Задача продукта в этом случае — не навязать человеку искусственную потребность, а обнаружить существующее неудобство, ставшее привычным. Если решение заметно улучшает сценарий, пользователь может осознать ценность уже после того, как увидит альтернативный способ действия.
Третьим основанием для создания продукта Иван Замесин называет возможность взять удачное решение у конкурента и улучшить его слабые стороны. Речь идёт не о слепом копировании, а о наблюдении за тем, что уже работает в другом продукте или контексте, с последующей адаптацией к собственной задаче.
Эта логика связана с примером из лекции о трейлерах и интервью Юрия Дудя. В начале интервью используются короткие эмоциональные фрагменты, чтобы показать зрителю, что он получит дальше, и удержать его внимание. По словам Замесина, этот приём был взят из трейлеров фильмов, где первые секунды также концентрируют яркие образы, эмоции и события.
Такой перенос может стать важной деталью продуктового сценария, хотя пользователь не обязательно сформулирует её как потребность. Команда видит, что паттерн работает в одной сфере, и проверяет, может ли он повысить результат в другой. Важно, что гипотеза всё равно требует валидации: наличие работающего решения у конкурента не гарантирует, что оно сработает для иной аудитории или задачи.
Замесин рассматривает этот подход как один из источников продуктовых инсайтов наряду с явными и неосознаваемыми болями. Конкурент может показать уже найденный механизм создания ценности, но задача команды — понять, какую проблему он решает, что можно улучшить и как проверить результат на собственном продукте.
Помимо трёх оснований, связанных с болью или заимствованием работающих решений, Иван Замесин выделяет ещё одну группу продуктов — сервисы, построенные на дофаминово-эндорфиновом цикле. К ним он относит массовые B2C-продукты: Яндекс Дзен, Яндекс Новости, новостные сайты, Tinder, Facebook и Instagram.
В таких продуктах пользовательская ценность часто не выражается через осознаваемую проблему, которую можно рационально описать на интервью. Человек возвращается в сервис не потому, что сформулировал задачу вроде «мне необходимо решить такую-то боль», а потому что продукт запускает повторяющееся эмоциональное поведение, связанное с ожиданием награды, интересом, признанием, новизной или сексуальным влечением.
Замесин подчёркивает, что это наиболее сложная категория для customer development. Можно попытаться понять, какие эмоции испытывает человек при похожих действиях, но напрямую и надёжно исследовать будущую эмоциональную реакцию на ещё несуществующий продукт трудно. Интервью в такой ситуации дают скорее косвенные ориентиры, чем однозначное подтверждение.
Поэтому продукты на дофаминово-эндорфиновом цикле требуют особенно осторожной проверки через качественные реалистичные прототипы и MVP. По словам Замесина, у него был опыт работы с двумя такими B2C-направлениями, и оба случая были тяжёлыми: интервью давали сигналы, но не позволяли с уверенностью предсказать будущую реакцию рынка.
Иван Замесин объясняет механику массовых B2C-продуктов через повторяющийся цикл ожидания и получения награды. Он использует образ «однорукого бандита» дома — холодильника. Вечером человек может быть голоден и помнить, что когда-то в холодильнике был эклер. Эта память и ожидание заставляют его встать с дивана и проверить холодильник, даже если рациональных оснований полагать, что там появилось что-то новое, нет.
Если еды не оказывается, через некоторое время человек всё равно может пойти проверять снова. Замесин описывает это как иррациональный, но биологически закреплённый механизм: дофамин подталкивает к действию и поиску возможной награды. Когда награда находится — например, эклер действительно оказывается в холодильнике, — возникает приятное переживание, которое связывается с действием.
По его словам, дофаминово-эндорфиновый цикл помогает закреплять новые паттерны поведения, прежде всего связанные с выживанием и продолжением рода. Массовые цифровые сервисы могут опираться на похожую механику: пользователь возвращается за новой порцией информации, подтверждением социального принятия, романтическим контактом или иной эмоциональной наградой.
Для продукта это означает, что привычка создаётся не только полезностью функции. Она формируется через повторение цикла «ожидание — действие — потенциальная награда». Однако именно поэтому такой сценарий сложно исследовать только с помощью вопросов: человек может не осознавать, почему возвращается, и не суметь достоверно спрогнозировать своё поведение.
В объяснении Ивана Замесина дофамин и эндорфины выполняют разные роли в пользовательском поведении. Дофамин связан с побуждением к действию и ожиданием потенциальной награды. Он заставляет человека подняться с дивана и проверить холодильник: вдруг там есть что-то вкусное. Даже при отсутствии логического основания для повторной проверки сам механизм поиска поддерживает активность.
Эндорфин, согласно приведённому объяснению, связан с переживанием награды. Когда человек находит эклер и съедает его, ему становится приятно. Это эмоциональное подкрепление делает связь между действием и положительным результатом более устойчивой.
Замесин говорит, что такой цикл нужен для закрепления новых моделей поведения, особенно связанных с базовыми задачами выживания и продолжения рода. В цифровых продуктах похожая механика может поддерживать возвращаемость: пользователь ожидает увидеть новости, получить социальное подтверждение, встретить потенциального партнёра или испытать другой вид эмоционального вознаграждения.
Для исследователя это создаёт проблему: поведение строится не только на рационально осознаваемой боли или пользе. Человек может не суметь объяснить собственный мотив, а его ответ на вопрос о будущем использовании будет ненадёжным. Поэтому Замесин связывает изучение таких продуктов с наблюдением за эмоциями при похожих действиях и обязательной проверкой на реалистичных прототипах или MVP.
Иван Замесин относит Tinder, Instagram, Facebook, Яндекс Дзен, Яндекс Новости и другие новостные сайты к продуктам, работающим преимущественно через дофаминово-эндорфиновый цикл. В отличие от B2B-инструментов, где ценность можно выразить в деньгах, экономии времени или снижении конкретной бизнес-метрики, здесь поведение пользователя часто строится на эмоциях и повторяющейся тяге к новой награде.
Tinder, по формулировке Замесина, работает на сексуальном влечении. Instagram он связывает с подтверждением собственного существования и ощущением принятия со стороны других людей. Новостные и контентные сервисы создают цикл ожидания нового материала, эмоциональной реакции и возвращения за следующей порцией информации.
Эти примеры важны, потому что в них не всегда присутствует сильная и явная боль. Если человек не сможет зайти в Tinder в конкретный день, ничего критического может не произойти, хотя пользователь всё равно будет испытывать неудовлетворённость. Поэтому для таких сервисов сложно использовать те же критерии, что для painkiller-продуктов, где проблему можно оценить по тяжести последствий и силе негативной эмоции.
Замесин не отрицает ценность customer development для массового B2C, но подчёркивает его ограничения. Разговоры могут помочь понять текущие эмоции и похожие сценарии, однако решение о жизнеспособности продукта должно опираться на реальный опыт взаимодействия с качественным прототипом или MVP.
Иван Замесин считает, что для продуктов, основанных на дофаминово-эндорфиновом цикле, интервью дают ограниченную и неоднозначную информацию. Можно спросить пользователя, какие эмоции он переживает при похожих действиях, но нельзя напрямую и надёжно извлечь из разговора ответ на вопрос, будет ли человек испытывать нужные эмоции от нового продукта и сформирует ли он привычку пользоваться им.
Проблема связана с природой таких сервисов. Пользователь может не осознавать реальные причины своего поведения, а его возвращаемость определяется не рациональной формулировкой потребности, а ожиданием награды, новизной, социальным подтверждением или влечением. Поэтому вопрос «будете ли вы этим пользоваться?» не даёт устойчивого прогноза.
Замесин упоминает два собственных опыта работы с B2C-продуктами на подобных механиках. Оба были тяжёлыми: проведённые исследования дали много сигналов, но не позволили получить однозначное подтверждение гипотезы. Это отличает эмоциональный B2C от ситуаций с ясной бизнес-болью, где готовность клиента к оплате или пилоту может быть сильным доказательством спроса.
Следовательно, интервью здесь полезны скорее для изучения контекста, текущих эмоциональных реакций и сценариев поведения. Но они не должны восприниматься как финальная проверка. Реальная валидация требует дать человеку возможность взаимодействовать с продуктом и наблюдать, вызывает ли он нужную реакцию на практике.
По мнению Ивана Замесина, гипотезы о продуктах на дофаминово-эндорфиновом цикле необходимо проверять прежде всего на high-fidelity-прототипах и качественных MVP. Под high-fidelity он подразумевает достаточно реалистичный опыт взаимодействия, при котором пользователь способен испытать эмоции, близкие к тем, на которых строится будущий продукт.
Замесин подчёркивает, что всё, что происходит до такого прототипа, остаётся в значительной степени надеждой. Команда может предполагать, что при определённом интерфейсе, механике или контенте человек испытает интерес, удовольствие, ощущение принятия или желание вернуться. Но до реального взаимодействия это нельзя подтвердить с той же уверенностью, с какой в B2B можно подтвердить ценность через экономический расчёт и готовность платить.
Качественный MVP нужен, чтобы заменить рассуждения о будущем поведении наблюдением за фактической реакцией. Пользователь не просто рассказывает, что ему может понравиться, а проходит через сценарий, где может возникнуть или не возникнуть эмоциональное вовлечение. Такой тест становится основным источником сигнала для массового B2C.
Эта позиция продолжает общий принцип лекции: сокращать время до обратной связи и проверять гипотезы до больших инвестиций. Но для эмоциональных B2C-продуктов форма проверки должна быть более реалистичной, поскольку простого проблемного интервью недостаточно для оценки будущей привычки и возвратного поведения.
Иван Замесин рекомендует, если аудитория и сегменты ещё не понятны, сознательно выделить на их исследование примерно месяц или полтора. Он предупреждает, что качественно изучать неизвестный рынок параллельно с обычной продуктовой операционкой трудно: поиск сегмента, рекрутинг и проведение интервью требуют отдельного фокуса.
В первые две–три недели может не быть интервью вовсе либо они могут проходить тяжело. Это не следует воспринимать как аномалию или немедленное доказательство бесперспективности продукта. На раннем этапе команда ещё не понимает рынок, не знает, какие сегменты наиболее перспективны, и может не иметь работающего способа находить нужных людей.
Особенно затруднённым этот процесс становится в сложном B2B или при работе с клиентами в другой стране. Нужно не только сформулировать сегментную гипотезу, но и найти доступ к людям, добиться ответа, подобрать подходящие условия разговора и получить достаточное число повторяющихся наблюдений.
Замесин призывает заранее принять эту реальность и не пытаться ускорить исследование за счёт его пропуска. Выделенное время необходимо, чтобы перебрать и перевзвесить гипотезы сегментов, найти людей с сильной потребностью и только затем переходить к решенческим интервью, продажам, прототипам и MVP.
Иван Замесин подчёркивает, что при работе с незнакомой аудиторией поиск подходящего сегмента и доступных респондентов нельзя считать быстрым побочным процессом. Если команда ещё не знает пользователей, их контекст и способы выхода на них, на исследование стоит сознательно выделить от одного до полутора месяцев. По его мнению, пытаться качественно проводить такую работу параллельно с обычной продуктовой операционкой сложно: поиск сегмента и понимание рынка требуют отдельного внимания.
Он предлагает заранее принять, что первые две-три недели могут оказаться малорезультативными. Интервью могут вообще не состояться, идти редко или быть тяжёлыми в организации. Это особенно характерно для сложных B2B-сегментов и ситуаций, когда нужно искать респондентов, например, среди клиентов на зарубежном рынке. Неудачи на старте не означают, что гипотеза или метод исследования неверны: сначала необходимо подобрать сам сегмент и рабочий канал рекрутинга.
Иван Замесин ссылается на позицию Ильи Красинского: менее ста интервью — это мало. Он не формулирует это число как универсальную жёсткую норму для любого исследования, но поддерживает общий принцип: количество разговоров должно расти вместе со сложностью изучаемой потребности и дистанцией между исследователем и аудиторией.
Чем менее знакома команде сама проблема и чем сильнее целевая аудитория отличается от исследователя, тем больше интервью требуется. В качестве особенно сложных случаев Замесин называет работу с возрастной аудиторией и тем более с детьми. Здесь нельзя уверенно переносить на пользователей собственный опыт, интуицию и привычные сценарии, поэтому для понимания реальных потребностей нужно собрать существенно больше фактов и повторяющихся наблюдений.
Когда ещё непонятно, кого именно следует интервьюировать, Иван Замесин предлагает сначала сформулировать несколько гипотез о возможных сегментах. Затем эти гипотезы необходимо ранжировать, а не исследовать аудитории случайно или одновременно без приоритета. В основе ранжирования лежат важные для продукта характеристики сегмента.
Обычно Замесин предлагает оценивать размер сегмента, его платёжеспособность и потенциальную силу боли. Сегмент становится более перспективным, если в нём достаточно людей, они способны платить за решение и при этом испытывают существенную проблему. Такой подход помогает не подменять исследование хаотичным набором интервью, а начинать с аудиторий, в которых выше вероятность найти значимую и коммерчески жизнеспособную потребность.
Иван Замесин уточняет, что ранжировать сегменты следует не только через силу боли. Этот критерий подходит для painkiller-продуктов, то есть решений, устраняющих понятную пользователю проблему. Однако существуют и продукты типа delighter, ценность которых строится не на снятии выраженной боли, а на потенциально сильной положительной эмоции, удовольствии или новом привлекательном опыте.
В таком случае вместо потенциальной силы боли нужно оценивать потенциальный «кайф» от создаваемого delighter. Логика приоритизации при этом сохраняется: команда формирует гипотезы, сравнивает сегменты и выбирает те, где продукт может принести наиболее сильную и массовую ценность. Тем самым модель не ограничивается только поиском страдания пользователя, а допускает проверку гипотез о значимом позитивном опыте.
По словам Ивана Замесина, исходное ранжирование сегментов — лишь рабочая гипотеза, а не окончательный выбор рынка. Обычно в топ попадает один или два сегмента, которые кажутся наиболее привлекательными по размеру, платёжеспособности и силе предполагаемой боли либо ценности delighter. Именно с них следует начинать интервью.
После первой серии разговоров этот приоритет почти неизбежно меняется. Интервью дают данные о реальном опыте пользователей, их мотивации, ограничениях и проблемах, поэтому первоначальный список сегментов нужно перевзвесить. Затем исследование повторяется уже для обновлённого топа. Такой цикл позволяет постепенно отказаться от неверных представлений о рынке и сузить фокус до сегмента, который действительно обладает наиболее сильной и перспективной потребностью.
Иван Замесин описывает момент, когда сегмент можно считать приоритетным для дальнейшей работы. Команда должна понимать, что он достаточно велик, платёжеспособен и относительно доступен для выхода на него. Кроме того, у него должна быть сильная боль. Если в ходе исследования не находятся сегменты с такой же или большей болью либо с сопоставимой болью, но существенно большим потенциалом, найденный сегмент становится рабочей основой для следующего этапа.
Только после этого предлагается придумывать решение. Далее необходимо проводить решенческие интервью, совмещённые с продажей: показать или описать ценностное предложение и проверить, готов ли пользователь купить. Таким образом, разработка решения должна следовать за подтверждением сегмента и проблемы, а не предшествовать им.
Иван Замесин отдельно выделяет ABCD-сегментацию как важный инструмент для продуктов, у которых уже есть пользователи и клиенты. Он подчёркивает, что этот подход не предназначен для первоначального поиска сегмента при создании нового продукта. Его задача другая: понять, на какой части существующей аудитории следует сфокусироваться, чтобы получить максимальный рост.
Продукт уже естественным образом сегментирует пришедших к нему клиентов: одни покупают быстро и много, другие требуют значительных усилий, третьи почти не приносят выручки. ABCD-сегментация помогает увидеть различия в качестве клиентов через их поведение, цикл сделки, выручку, потребность в поддержке и способность удерживаться в продукте. По оценке Замесина, этот инструмент будет полезен подавляющему большинству аудитории — он называет цифру в 98%.
По определению Ивана Замесина, A-сегмент состоит из клиентов с сильной потребностью в продукте. Они покупают быстро, покупают много, а их цикл сделки остаётся очень коротким. Такие клиенты не требуют постоянных напоминаний о себе и почти не создают нагрузки ни на поддержку, ни на sales-support.
Это наиболее качественная аудитория с точки зрения экономики и операционной эффективности. Потребность здесь уже совпадает с продуктом достаточно хорошо: пользователю не нужно долго объяснять ценность, преодолевать массу возражений или сопровождать его вручную. Поэтому A-сегмент является естественным кандидатом на концентрацию сильных продуктовых, маркетинговых и клиентских ресурсов.
Иван Замесин характеризует B-сегмент как аудиторию, у которой тоже есть высокая потребность и готовность платить, но путь к покупке уже не настолько прямой, как у A-сегмента. У таких клиентов появляются возражения и дополнительные условия: они могут говорить, что продукт станет по-настоящему ценным, если добавить определённую возможность или устранить конкретное ограничение.
Из-за этих возражений цикл сделки становится средним по длительности, а сами клиенты начинают чаще обращаться к команде. Однако B-сегмент по-прежнему остаётся ценным: его представители готовы платить, их потребность достаточно сильна, а запросы могут указывать на направления улучшения продукта. Замесин включает этот сегмент в число ключевых наряду с A-сегментом.
C-сегмент, по описанию Ивана Замесина, состоит из клиентов, которым продукт нужен слабо. Они задают много вопросов, создают значительную нагрузку на поддержку и продажи, при этом долго принимают решение о покупке. Их цикл сделки оказывается длинным, а оплата — небольшой.
Даже если такие пользователи становятся клиентами, они быстро отваливаются. В результате команда может тратить на них непропорционально много времени, но получать слабую выручку и низкое удержание. Замесин использует этот сегмент как пример аудитории, чьи громкие и частые запросы способны отвлечь продукт от более ценных пользователей.
По версии Ивана Замесина, D-сегмент создаёт наиболее неблагоприятное сочетание для бизнеса: эти пользователи сильно нагружают поддержку, но не покупают продукт. То есть команда несёт операционные расходы на коммуникацию, объяснения и обработку запросов, не получая сопоставимой выручки.
Отличие D-сегмента от C-сегмента состоит в том, что C-клиенты хотя бы платят, пусть и мало, долго выбирают и быстро уходят. D-клиенты не совершают покупку вовсе. Поэтому работа с ними особенно рискованна, если команда воспринимает интенсивность их обращений как признак высокой продуктовой ценности запроса.
Иван Замесин рассказывает, что ABCD-подход подтверждался на данных стартапов, проходивших через акселератор, а также в обзвонах клиентов, которые проводились с его командами и клиентами. Согласно этому наблюдению, около 80% денег приносят A- и B-сегменты. При этом на обслуживание и работу с ними команда тратит лишь около 20% своего времени.
Этот разрыв показывает, что наиболее прибыльные клиенты не обязательно являются самыми заметными в ежедневной операционной работе. Напротив, они покупают быстрее, реже требуют ручного сопровождения и не создают постоянного потока обращений. Поэтому их вклад в выручку может быть существенно выше их видимой доли в коммуникациях с командой.
На фоне того, что A- и B-сегменты дают около 80% денег, Иван Замесин отмечает противоположный перекос в распределении продуктовых усилий. По его оценке, лишь около 20% фич создаётся для A- и B-сегментов, тогда как около 80% фич, внимания и энергии команды уходит на C- и D-сегменты.
Проблема состоит не только в неэффективном расходовании ресурсов, но и в стратегическом смещении продукта. Команда начинает улучшать продукт преимущественно для клиентов с низкой потребностью, слабой экономикой и высокой стоимостью обслуживания. В результате она недоинвестирует в аудиторию, которая уже демонстрирует сильный спрос, готовность платить и потенциал дальнейшего роста.
Иван Замесин объясняет дисбаланс в пользу C- и D-сегментов человеческой реактивностью. Он формулирует это как «Monkey see, monkey do»: команда видит заметный запрос в support — и сразу превращает его в задачу в Jira. Частое обращение начинает казаться сигналом, что проблема важна для всех, хотя на деле оно может исходить от малодоходного или неплатящего сегмента.
По мнению Замесина, люди естественно концентрируются на том, что находится в поле внимания. Если пользователь настойчиво жалуется, если запрос неоднократно всплывает в поддержке или руководитель говорит, что проблему уже пора решить, команда склонна взяться за неё без проверки того, для какого сегмента создаётся ценность. Так появляются функции, которые могут быть нужны главным образом C- и D-клиентам и не усиливают основную экономику продукта.
В качестве практического вывода Иван Замесин предлагает сначала определить, кто относится к A-, B-, C- и D-сегментам, а затем осознанно распределить ресурсы. Сильных сотрудников следует фокусировать на работе с A- и B-сегментами — клиентами с высокой потребностью, ценностью для бизнеса и готовностью платить.
Такой фокус означает, что продуктовые, маркетинговые и клиентские решения нужно принимать прежде всего в интересах наиболее перспективной аудитории. Это не просто рекомендация больше общаться с лучшими клиентами: речь идёт о приоритетном использовании сильной экспертизы команды там, где она может поддержать высокий доход, короткий цикл сделки, удержание и дальнейшее развитие ценных сегментов.
Иван Замесин призывает не направлять сильных сотрудников на обслуживание C- и D-сегментов. Если представители этих групп обращаются с просьбой сделать функцию, команда может поблагодарить за обратную связь, но не обязана немедленно брать запрос в работу. Спикер иронично предлагает отвечать, что функция будет сделана «в Q4 2028», подчёркивая необходимость сознательно ограничивать приоритет таких требований.
Этот подход основан на различии между видимой активностью клиента и его бизнес-ценностью. Частые обращения, длинные обсуждения и настойчивые пожелания не должны автоматически превращаться в продуктовые инвестиции. Ограничение вложений позволяет не расходовать ресурсы на клиентов с низкой готовностью платить, слабой потребностью или отсутствием покупки.
Иван Замесин предлагает закрепить фокус на наиболее ценной аудитории не только в продуктовой разработке, но и в маркетинговых целях. Маркетингу следует ставить KPI по привлечению именно A- и B-сегментов, а не оценивать работу исключительно общими объёмами лидов, регистраций или клиентов.
Логика заключается в том, что широкое привлечение аудитории без учёта качества может увеличить долю C- и D-сегментов, которые перегружают поддержку и продажи, но не дают адекватной выручки. Напротив, целевой поиск клиентов, похожих на A и B, должен увеличить долю пользователей с сильной потребностью, быстрым циклом покупки и высокой ценностью для продукта.
Иван Замесин делает оговорку: в массовом B2C или массовом B2B нельзя всегда полностью отказаться от работы с C- и D-сегментами. Эти пользователи могут составлять большую часть общей аудитории, и бизнесу необходимо поддерживать для них базовый продуктовый опыт. Однако взаимодействие с ними следует максимально автоматизировать.
Автоматизация нужна для того, чтобы не расходовать на малодоходные группы дорогой человеческий труд. Продукт должен позволять им самостоятельно решать типовые задачи без постоянного привлечения продаж и поддержки. Это сохраняет возможность работать с массовой аудиторией, но не позволяет её операционной стоимости вытеснить фокус на более ценных A- и B-клиентах.
Для массового B2C и массового B2B Иван Замесин рекомендует убирать live-продажи и live-support для сегментов, которые не создают достаточной ценности. Он приводит пример Trello: в сервисе нет live-чата, поскольку, по его словам, 99% клиентов не платят. Если бы такая аудитория могла постоянно обращаться в живую поддержку, операционная команда просто не выдержала бы нагрузки.
Этот пример показывает, что доступность персонального сервиса не должна быть стандартом для всех категорий пользователей. При большом числе неплатящих или низкодоходных клиентов человеческая поддержка способна разрушить экономику. Поэтому для таких сегментов нужен продуктовый и автоматизированный путь обслуживания, а не постоянное индивидуальное сопровождение.
Иван Замесин приводит пример сервиса, который он называет, вероятно, Kids-Auto: это модель, похожая на Uber для перевозки детей от родителей на кружки и обратно. У сервиса возникла проблема с исполнителями — нянями, которые доставляли детей. Они отказывались от заказов, из-за чего не сходилась unit-экономика.
Команда провела сегментацию как среди нянь-исполнителей, так и среди клиентов. Кейс демонстрирует, что проблемы продукта не всегда нужно решать одинаково для всех участников платформы. Вместо общего наращивания базы исполнителей или клиентов можно выявить группы, которые создают основную ценность либо, напротив, формируют ключевое ограничение в операционной модели.
В кейсе сервиса доставки детей сегментация показала, что небольшая доля нянь отвечает примерно за 80% выполненных заказов. Это наблюдение изменило подход команды к проблеме отказов: вместо попытки удержать всех исполнителей она отказалась от остальных нянь и стала нанимать новых, похожих на тех, кто уже стабильно выполнял основную часть заказов.
По словам Ивана Замесина, после такого изменения проблема с отказами полностью ушла. Кейс иллюстрирует, что полезно сегментировать не только покупателей, но и исполнителей. Наиболее активные и надёжные участники supply-стороны могут иметь общий профиль, который стоит использовать как критерий отбора и найма.
После сегментации клиентов сервис доставки детей обнаружил чёткие различия по уровню годового дохода. Иван Замесин говорит, что значимая аудитория дифференцировалась по уровню дохода от 300 тысяч и выше. Также клиенты, по его словам, концентрировались в четырёх сегментах географии, среди которых он называет западный, северо-западный и центральный районы.
На основе этих наблюдений команда изменила таргетинг. Вместо широкого привлечения пользователей она стала точнее ориентироваться на людей с нужным уровнем дохода и в подходящих локациях. После корректировки таргетинга, по словам Замесина, показатели сервиса сразу улучшились. Пример показывает, как поведенческая и экономическая сегментация может напрямую менять настройки привлечения клиентов.
Иван Замесин предлагает начинать практическую ABCD-сегментацию с аналитики и формирования двух клиентских списков. Первый список нужно ранжировать по количеству обращений в поддержку: сверху будут пользователи с максимальным числом запросов, снизу — с минимальным. Это позволяет увидеть, кто создаёт основную операционную нагрузку.
Второй список следует ранжировать по выбранному показателю ценности для бизнеса. Это может быть средняя выручка, средний чек, максимальный retention, lifetime value или общая сумма заработка на клиенте. Сопоставление этих двух измерений — нагрузки и ценности — создаёт основу для различения A-, B-, C- и D-сегментов и помогает не принимать активность в support за признак качественного клиента.
Для оценки ценности клиентов Иван Замесин предлагает использовать те показатели, которые наиболее важны конкретному бизнесу. В качестве вариантов он называет среднюю выручку, средний чек, retention, lifetime value и сумму денег, которую компания зарабатывает на клиенте. Эти показатели помогают выстроить пользователей от наиболее до наименее ценных.
Такое ранжирование не должно существовать отдельно от оценки нагрузки на команду. Его смысл — сопоставить доходность и качество поведения клиента с количеством обращений, сложностью обслуживания и длительностью цикла сделки. Благодаря этому можно увидеть аудитории, которые приносят много денег с минимальными затратами, и отделить их от групп, которые требуют много внимания, но плохо окупаются.
После подготовки ранжированных списков Иван Замесин рекомендует переходить к непосредственному изучению клиентов. Нужно прокликивать их профили, использовать доступные данные, смотреть страницы во «ВКонтакте» или Facebook, а также проводить обзвоны и опросы. Задача состоит в том, чтобы увидеть пользователей не только как строки в аналитической таблице, но и как реальные группы с общими признаками.
По словам Замесина, закономерность при таком подходе находится очень быстро. В профилях, поведении, географии, социальном контексте или сценариях использования могут проявиться отличия между прибыльными и проблемными сегментами. При этом он не раскрывает собственные примеры из-за NDA, но подчёркивает сам принцип: количественное ранжирование должно дополняться качественным изучением людей.
Иван Замесин разделяет ситуацию поиска сегмента и ситуацию, когда сегмент уже известен. Если команда понимает, с какой аудиторией работает, ей не нужно заново искать всех возможных пользователей. Следует находить просто репрезентативных людей из этого сегмента — тех, чьи опыт и контекст соответствуют изучаемой группе.
Минимальной стартовой выборкой он называет примерно десять человек. Этого количества достаточно не для статистического доказательства каждой гипотезы, а для проверки повторяемости наблюдений. Если на десяти интервью не начинают повторяться одни и те же инсайты, это может означать, что выбранный сегмент не обладает явной общей болью или в нём не найден очевидный значимый паттерн.
По мнению Ивана Замесина, интервью нужно проводить в таком количестве, чтобы на них начали повторяться инсайты. Повторяемость важнее единичных ярких историй: если из десяти собеседников только один или два сообщают о проблеме, это ещё не делает её частотной для всего сегмента.
Если после десяти интервью инсайты не повторяются, Замесин предлагает рассматривать это как сигнал. Возможно, в сегменте нет выраженной общей боли, либо исследователь пока не нашёл тот тип наблюдения, который объединяет пользователей. Поэтому выборку и сценарий исследования следует рассматривать не как формальную процедуру с заранее заданным числом разговоров, а как способ обнаружить устойчивые повторяющиеся паттерны.
Иван Замесин отмечает, что сценарий интервью после первых разговоров почти полностью переписывается. Первоначальный скрипт всегда строится на гипотезах команды, однако после выхода к реальным пользователям выясняется, что реальный мир устроен иначе, чем представлялось до исследования.
Поэтому сценарий не должен восприниматься как окончательный опросник. После первой серии интервью следует пересмотреть вопросы, добавить новые детали контекста, убрать неработающие предположения и сформулировать новые гипотезы. Затем команда снова общается с пользователями и суммирует инсайты. В такой итеративности и заключается практический цикл custdev: сценарий развивается вместе с пониманием сегмента и его опыта.
Иван Замесин считает custdev простым инструментом, вокруг которого почему-то существует стигма сложности. По его словам, главное препятствие часто не методологическое, а психологическое. Поэтому на своих тренингах он не ограничивается объяснениями, а заставляет участников провести двенадцать-шестнадцать интервью: через непосредственное действие становится понятно, что разговоры с пользователями выполнимы.
Он описывает типичные внутренние отговорки: кажется, что респонденты будут нерезультативными, что они не захотят говорить или что неясно, зачем им тратить время на интервью. Замесин интерпретирует такие мысли как попытку мозга отговорить человека от некомфортного действия. Его практическая рекомендация проста: не затягивать из-за этих барьеров, а идти и проводить интервью.
Иван Замесин формулирует ключевое ограничение customer development: из интервью можно извлекать факты и только факты. К ним относятся текущие способы решения задачи, реальный опыт пользователя, его действия или бездействие, мотивирующие эмоции, причины этих эмоций и их сила.
При этом он подчёркивает, что из интервью нельзя надёжно получить предположения о будущем. Вопросы о будущей покупке, будущем поведении или будущей дисциплине дают ответ, который формируется в настоящем состоянии человека, а не достоверный прогноз. Поэтому исследования должны быть привязаны к конкретным прошлым событиям, наблюдаемым действиям и подробностям реального опыта, а не к обещаниям пользователя.
По объяснению Ивана Замесина, отвечая на вопрос о будущем, человек говорит из своего текущего эмоционального состояния. Он не обязательно намеренно обманывает исследователя, но его ответ отражает то, что он чувствует и думает сейчас, а не то, как он действительно поведёт себя в другом контексте и в другое время.
Из-за этого обещания вроде «я буду пользоваться», «я куплю» или «я начну делать это регулярно» нельзя считать достаточным доказательством спроса. Для custdev важнее выяснить, как пользователь действовал в конкретной ситуации, когда проблема возникала в последний раз, что он тогда делал, почему это было трудно и какие эмоции испытывал. Именно такой разговор позволяет отличить реальную потребность от текущего желания выглядеть последовательным или мотивированным.
Иван Замесин связывает ненадёжность прогнозов с работой текущего эмоционального состояния. Он спрашивает: что человеку в данный момент «говорит лимбический мозг»? Решения нередко принимаются не после рационального расчёта долгосрочной пользы, а под влиянием актуального страха, дискомфорта, надежды или желания изменить себя.
Поэтому интервьюер должен учитывать, что заявленное намерение может быть вызвано эмоцией настоящего момента. Человек способен искренне хотеть решить проблему сейчас, но в будущем, когда изменится контекст и исчезнет первоначальный эмоциональный импульс, поступить иначе. Эта особенность делает факты прошлого поведения значительно надёжнее разговоров о гипотетическом будущем.
Иван Замесин иллюстрирует ненадёжность будущих обещаний примером покупки абонемента в спортзал. По его словам, человек покупает его не потому, что тщательно рассчитал будущую регулярность тренировок, пользу для здоровья, изменения в работе сердца или рост выносливости. Решение может быть вызвано текущим переживанием при взгляде в зеркало: страхом из-за внешности и ощущением, что с нынешним телом «ничего не светит».
Однако уже послезавтра, когда нужно будет встать в шесть утра ради беговой дорожки, сработает другой контекст: будильник будет отложен ещё на два часа. Пример показывает, что намерение, сформированное в момент страха или неудовлетворённости собой, не равно будущему поведению. Поэтому нельзя строить продуктовые выводы только на вопросах о том, что пользователь собирается делать.
Иван Замесин называет целью интервью поиск инсайтов, но уточняет, что значимым является не любой отдельный ответ. В первую очередь нужна частотная боль: если из десяти человек об одной проблеме говорят только один или два, это нечастотный инсайт. Для вывода о массовости проблемы необходимо, чтобы она повторялась у восьми, девяти или десяти респондентов из десяти.
Частотность применима не только к боли. Повторяющимся инсайтом может быть потенциальный delighter — сценарий, в котором пользователи способны испытывать сильную положительную эмоцию, — либо важная деталь пользовательского пути. Однако в любом случае ценность наблюдения определяется тем, насколько устойчиво оно встречается у представителей сегмента, а не выразительностью одной отдельной истории.
Иван Замесин формулирует цель проблемного интервью как поиск инсайтов, а не сбор абстрактных мнений о продукте. Инсайтом может быть частотная боль: ситуация, в которой человеку регулярно трудно, неудобно, страшно, обидно или иным образом эмоционально тяжело. Чтобы считать такую боль значимой, недостаточно услышать её от одного собеседника: она должна повторяться у большинства представителей изучаемого сегмента.
Второй тип инсайта — потенциально частотный delighter, то есть возможность дать пользователю заметную положительную эмоцию, удовольствие или облегчение. Замесин подчёркивает, что исследовать стоит не только раздражение и страдание: в некоторых сценариях продукт может расти за счёт сильного позитивного эффекта. При этом радость, как и боль, нужно проверять через реальный пользовательский опыт и оценивать по силе эмоции.
Третий тип — важная деталь сценария. Она может не быть осознанной потребностью и не формулироваться пользователем как проблема. Однако такая деталь способна подсказать сильное продуктовое решение: показать, как формируется внимание, что влияет на выбор, в какой момент пользователь понимает ценность и что помогает ему продолжить действие. Замесин приводит пример человека, который вынужден вставать в шесть утра: он может описывать это как «некомфортно, но иначе никак», однако отказ вставать так рано ради работы показывает потенциально сильную точку для улучшения сценария.
Таким образом, в ходе интервью важно искать не только прямые жалобы, но и повторяющиеся позитивные ожидания, а также контекстные наблюдения, которые могут стать основой для продукта. Инсайтом считается не просто интересная реплика, а повторяемый сигнал о боли, желаемом опыте или важном устройстве пользовательского поведения.
Иван Замесин объясняет важность сценарных деталей на примере интервью Юрия Дудя. В начале роликов Дудь показывает короткую, примерно десятисекундную нарезку ярких вопросов и ответов. Её задача — сразу объяснить зрителю, что его ждёт дальше, какие эмоции он может получить и почему стоит продолжать смотреть длинное интервью.
По мнению Замесина, этот приём не является уникальным изобретением конкретного автора: он заимствован из трейлеров к фильмам. В трейлерах первые секунды обычно содержат узнаваемых актёров, эмоциональные эпизоды, взрывы, спецэффекты, музыку или другое сильное обещание будущего опыта. Зрителю заранее показывают концентрированный сигнал ценности, который должен вовлечь его в дальнейший просмотр.
Этот пример иллюстрирует перенос продуктового паттерна между разными контекстами. Если механизм удерживает внимание в трейлерах, его можно проверить в другом продукте — например, в формате интервью. Замесин предлагает не копировать решение механически, а замечать, где уже работает определённый сценарный принцип, и рассматривать его как гипотезу: возможно, аналогичный приём сработает и в собственном продукте.
Ценность такого наблюдения состоит в том, что оно не обязательно выражается пользователем словами. Человек может не сказать: «Мне нужна предварительная эмоциональная нарезка, чтобы я начал смотреть видео». Но исследователь может обнаружить паттерн в поведении успешного продукта и проверить, повышает ли он конверсию в просмотр или длительное использование в другом сценарии.
Иван Замесин призывает исследовать не только одну явно названную проблему, а максимально широкий набор деталей пользовательского сценария. Он сравнивает интервью с исследованием карты в игре Diablo: карта закрыта «туманом войны», а ценный сундук может находиться в ещё неоткрытой части пространства. Игрок не останавливается после первого найденного участка, а обходит карту так, чтобы не оставить неисследованных зон.
По той же логике интервьюер не должен ограничиваться базовым вопросом о проблеме. Пользователь может не вспомнить важную сложность сразу, не считать её проблемой или считать привычный обходной путь нормой. Поэтому задача интервью — пройти по различным этапам действия, условиям, участникам, каналам, исключениям и нестандартным ситуациям, чтобы повысить вероятность обнаружить скрытые точки неудобства и ценные детали опыта.
Замесин подчёркивает, что вопросы должны охватывать не только основной путь пользователя, но и всё, что происходит вокруг него: как человек начинает действие, с кем взаимодействует, как принимает решение, где фиксирует информацию, что делает при сбоях, какие использует альтернативы и костыли. Именно в таких деталях могут находиться потребности, которые не были заявлены в начале разговора.
Этот подход позволяет превращать интервью в последовательное картирование реального опыта. Чем больше существенных зон сценария исследовано, тем меньше вероятность, что команда построит продукт вокруг самой очевидной, но не самой важной части пользовательской задачи.
Иван Замесин отмечает, что команда, составляющая сценарий интервью, почти неизбежно исходит из ограниченной модели мира. Она думает, что исследует понятную, заранее устроенную систему — по его метафоре, игру с известными правилами, картой «десять на десять» и фиксированным набором объектов. Однако при выходе к реальным людям оказывается, что пользовательский мир устроен значительно сложнее и содержит неожиданные элементы.
В его формулировке исследователь может думать, что перед ним простая карта, а в реальности обнаружить «котиков и единорожек», многомерное пространство и изменяющиеся условия. Метафора описывает разрыв между первоначальными предположениями команды и фактическими сценариями поведения. Пользователи действуют не так, как это представлялось изнутри продукта, используют непривычные комбинации инструментов, сталкиваются с исключениями и принимают решения под влиянием факторов, которые заранее не были учтены.
Из этого следует практический вывод: сценарий интервью не может быть окончательным до первых разговоров с пользователями. После первых интервью его необходимо переписывать, добавляя найденные контексты, новые сегменты, варианты поведения и точки потенциальных проблем. Исследование не подтверждает заранее нарисованную карту, а постепенно заменяет её более реалистичной моделью пользовательского опыта.
Иван Замесин рекомендует всегда начинать с дефолтного проблемного скрипта. Его ядро — прямой вопрос о неудобствах и болях: что человеку трудно, что вызывает проблемы, с чем приходится справляться. Такой вопрос задаёт направление разговору, но сам по себе редко даёт достаточный материал: пользователь может назвать лишь несколько очевидных трудностей или сначала ответить, что в целом всё нормально.
После обнаружения проблемы интервьюер должен многократно углубляться в неё через один и тот же цикл уточнений. Нужно попросить рассказать о последнем конкретном случае, когда человек столкнулся с этой ситуацией. Далее следует выяснить, почему эпизод был тяжёлым, какую эмоцию испытал пользователь и насколько она была сильна по десятибалльной шкале. Вопрос о последнем случае нужен не для формального примера, а для проверки реальности и частотности проблемы. Если человек может подробно восстановить недавний эпизод, описать обстоятельства, действия и последствия, это сильнее подтверждает существование проблемы. Если же он говорит о сложности в общем виде, но не может вспомнить, когда она происходила, инсайт оказывается сомнительным или редким.
Замесин предлагает задавать эти уточняющие вопросы «по кругу», пока не будет понятен фактический опыт человека и эмоциональная цена проблемы. В результате интервьюер получает не декларацию «мне это не нравится», а связку из контекста, конкретного события, причин трудности, пережитой эмоции и её силы. Именно такой материал можно затем сравнивать между интервью и превращать в продуктовые требования.
После базового проблемного скрипта Иван Замесин предлагает добавлять вопросы, которые отражают гипотезы о сегментах, сценариях и потенциальных источниках инсайтов. Дефолтный набор вопросов нельзя считать достаточным: он помогает раскрыть уже названные боли, но не гарантирует, что пользователь вспомнит все существенные обстоятельства своего опыта.
Сначала необходимо выделить сегменты людей, которых планируется интервьюировать. Замесин объясняет, что у разных сегментов могут различаться мотивации, привычки, последовательность действий, факторы покупки и детали использования продукта. Поэтому нельзя ожидать, что один и тот же сценарий интервью одинаково хорошо раскроет опыт всех групп.
Затем нужно вынести в отдельную гипотезу все факторы, которые могут влиять на поведение человека и на его решение о покупке, а также все детали сценария, где потенциально может скрываться инсайт. Эти гипотезы превращаются в конкретные вопросы. Вместо общего разговора о продукте интервьюер исследует отдельные зоны: как человек действует в типичной ситуации, что делает в нестандартном случае, какие способы использует, чем доволен, где сталкивается с неудобством и какие условия меняют его поведение.
Такой расширенный сценарий не заменяет проблемный скрипт, а дополняет его. Для каждого нового блока интервьюер всё равно возвращается к базовым вопросам: когда это было в последний раз, что происходило, почему оказалось сложно, какие эмоции возникли и насколько они сильны. Благодаря этому интервью не превращается в сбор поверхностных мнений, а остаётся исследованием конкретного опыта.
На вопрос слушателя о том, как отличить реальный опыт пользователя от сконструированного воспоминания, Иван Замесин предлагает простую практику: попросить человека показать, что он делал. Вместо того чтобы принимать на веру фразу «я часто пользуюсь этой функцией» или «недавно сталкивался с такой ситуацией», следует попросить повторить действия или подробно восстановить последний случай.
По мнению Замесина, если человек не может объяснить эпизод в деталях, это ставит под сомнение то, что событие действительно происходило так, как он его описывает. Важна не попытка уличить респондента во лжи, а проверка фактической опоры его слов. Пользователь может быть искренне уверен в своём ответе, но его память может хранить обобщённое представление вместо серии реальных повторяющихся действий.
Просьба показать действие возвращает разговор к наблюдаемому поведению. Она помогает увидеть интерфейс, последовательность кликов, возникающие препятствия и реальные обходные пути. Если показать действие невозможно, полезно попросить рассказать о последнем эпизоде пошагово: где человек был, что хотел сделать, что увидел, как отреагировал и чем всё закончилось.
Такой приём снижает риск строить продуктовую гипотезу на общих утверждениях пользователя. Для custdev важнее не то, что респондент считает типичным для себя, а то, что он может подтвердить конкретным и детализированным опытом.
Иван Замесин показывает ненадёжность обобщённых воспоминаний на примере интервью о голосовых запросах в поисковой строке Chrome. Во время интервью женщина уверенно говорила, что пользуется голосовым поиском на десктопе. Это казалось важным наблюдением: если такие запросы действительно распространены, команда могла бы учитывать целый дополнительный сценарий поведения.
Однако, когда Замесин попросил показать, как именно это происходит, выяснилось, что женщина открыла Chrome, увидела значок микрофона, разрешила доступ к микрофону и выполнила запрос. Браузер запрашивает это разрешение только один раз. По факту она не воспроизводила описываемое действие регулярно, но хранила в памяти обобщённую картину: однажды она увидела функцию, использовала её и затем стала считать, что это её обычный способ поиска.
В ответ на вопрос слушателя Замесин подчёркивает, что такая ситуация не означает намеренной лжи. Человек не пытается обмануть исследователя — он просто так запомнил собственный опыт. Память способна склеивать единичный эпизод, знание о функции и представление о себе в одну убедительную историю о регулярном поведении.
Для интервьюера это означает необходимость осторожно относиться к заявлениям о привычках и частоте использования. Слова пользователя нужно проверять конкретным последним случаем, просьбой показать действие и детальным восстановлением контекста. Иначе можно принять единичный опыт за устойчивый сценарий и ошибочно оценить значимость потребности.
Иван Замесин называет вопрос «расскажите последний раз, когда вы сталкивались с этой сложностью» важной лакмусовой проверкой. Пользователь может в общем виде согласиться, что у него есть проблема, но это ещё не означает, что проблема регулярно возникает и влияет на его поведение. Конкретный последний случай позволяет отделить реальный, свежий опыт от смутного или единичного воспоминания.
Детализация должна затрагивать не только дату или период, но и ход события. Нужно выяснить, что именно пользователь пытался сделать, где находился, какие шаги предпринял, в какой момент возникла трудность, почему она оказалась значимой и что было дальше. Чем подробнее человек восстанавливает эпизод, тем больше оснований считать рассказ фактическим материалом для исследования.
Если респондент не способен описать конкретную ситуацию, отвечает расплывчато или вспоминает случай, произошедший давно, это не обязательно означает, что он сознательно вводит интервьюера в заблуждение. Однако такой ответ показывает, что проблема может быть нечастотной, несущественной или существующей скорее в представлении человека, чем в его регулярной практике.
Замесин связывает эту проверку и с оценкой частотности. Даже если пользователь говорит, что что-то «болит», отсутствие недавнего и детального примера снижает ценность инсайта. Напротив, конкретные эпизоды позволяют понять, насколько часто ситуация повторяется и достаточно ли сильна, чтобы продукт имел смысл строить вокруг её решения.
Иван Замесин напоминает, что пользователь не обязан сразу вспомнить и назвать все свои проблемы. В начале разговора человек может описать лишь очевидные неудобства или заявить, что у него всё в порядке. Поэтому интервьюер должен не ждать готового списка болей, а погружать собеседника в разные части реального сценария.
Такое погружение означает последовательное исследование действий пользователя: как он начинает задачу, что делает далее, какие каналы использует, с кем взаимодействует, как реагирует на нетипичные ситуации и какие решения применяет в случае сложностей. При обсуждении конкретных деталей памяти человека активизируются: он вспоминает эпизоды, которые не пришли бы в голову при прямом вопросе «что у вас болит?».
Замесин связывает этот подход с задачей найти «сундук» на неизведанной карте. Важная проблема может располагаться не в основном сценарии, а в редком исключении, в передаче задачи другому человеку, в переходе между сервисами, в изменении условий или в необходимости пользоваться обходным решением. Исследователь должен целенаправленно проходить эти зоны, а не ограничиваться первым полученным ответом.
Каждая найденная деталь затем проверяется тем же проблемным циклом: когда это случалось, что именно было трудно, какие эмоции возникли и какова их сила. Благодаря этому погружение в сценарий позволяет находить не случайные особенности поведения, а потенциально значимые и подтверждаемые пользовательские потребности.
Иван Замесин предлагает перед интервью отдельно фиксировать гипотезы о факторах, которые могут влиять на поведение пользователя и на принятие решения о покупке. Эти факторы не ограничиваются прямой потребностью: на действия человека могут влиять его роль, тип задач, формат взаимодействия с другими людьми, привычные инструменты, условия использования, степень занятости и особенности конкретного сценария.
Важная причина выделять такие факторы — различия между сегментами. Разные группы пользователей могут иметь разные мотивации и действовать совершенно по-разному даже при работе с одним и тем же продуктом. Поэтому интервьюер должен заранее предположить, где могут проходить эти различия, а затем проверить их вопросами о реальном опыте.
Замесин предлагает выносить на доску все детали сценария и потенциальные точки инсайтов. Это помогает не держать исследовательскую модель только в голове и не пропускать важные направления разговора. Для каждой выделенной зоны формулируются вопросы, которые должны показать, как именно фактор влияет на действия человека, на возникающие проблемы и на выбор решения.
Таким образом, анализ факторов нужен не для подтверждения первоначальных догадок, а для расширения поля исследования. После первых интервью гипотезы о влияющих условиях должны пересматриваться: часть факторов окажется несущественной, а часть неожиданных обстоятельств станет ключом к пониманию поведения и спроса.
Иван Замесин разбирает на собственном примере, как он исследовал использование календарных приложений. Исходной гипотезой были пользователи, у которых календарь заполнен более чем наполовину. Он предположил, что у таких людей должно быть много взаимодействий с календарём и, следовательно, больше потенциальных проблем, потребностей и нестандартных сценариев.
Исследование не ограничивалось общей оценкой календаря. Замесин выделил разные группы пользователей и разложил их поведение на отдельные зоны: использование Calendly, планирование встреч с командой, согласование встреч с внешними людьми, разные типы событий, общение в мессенджерах и почте, работу в других часовых поясах, нетипичные события и индивидуальные способы организации информации.
Каждая зона рассматривалась как источник возможных инсайтов. Например, Calendly мог вызывать проблемы, приносить конкретную радость или использоваться в неожиданных сценариях. Встречи могли отличаться в зависимости от числа участников, личного или удалённого формата, способа согласования и необходимости координировать людей из разных городов и часовых поясов.
На примере календарей Замесин показывает, что качественное исследование не сводится к вопросу «нравится ли вам приложение?». Необходимо описать карту задач, найти различия в поведении, заметить костыли и исключения, а затем через конкретные эпизоды определить, какие из них действительно частотны и эмоционально значимы.
В исследовании календарей Иван Замесин выделил два первоначальных сегмента: пользователей Calendly и людей, которые этим сервисом не пользуются. Calendly он описывает как интерфейс поверх календаря: человек отправляет ссылку, другой участник видит доступные слоты, выбирает время, после чего событие автоматически появляется в календарях обеих сторон.
Такое разделение было гипотезой о различающемся поведении. Замесин предположил, что пользователи Calendly и непользователи могут сталкиваться с разными задачами, проблемами и способами договориться о времени. Использование или неиспользование конкретного инструмента становится не просто характеристикой аудитории, а основанием для отдельных исследовательских вопросов.
Для пользователей Calendly важно было выяснить, есть ли у них сложности с сервисом, что именно они в нём любят, в каких ситуациях получают наибольшую пользу и как используют инструмент на практике. Для непользователей необходимо было понять, как они решают ту же задачу без Calendly, какие альтернативы применяют и что мешает им использовать подобный способ организации встреч.
Этот пример показывает, что сегментация в интервью помогает не смешивать разные пользовательские контексты. Вместо усреднённого взгляда на «людей, которые пользуются календарём» исследователь получает возможность увидеть, как наличие конкретного инструмента меняет сценарий, привычки, ожидания и потенциальные боли.
Иван Замесин выделяет работу в разных таймзонах как отдельную зону для исследования календарных сценариев. Он предполагает, что поездки в другой часовой пояс и договорённости между людьми из разных регионов могут создавать специфические проблемы, которые не проявляются в обычном расписании внутри одного города.
По его словам, при изучении этой темы обнаружилось много сложностей. Особенно болезненным оказывается согласование встречи между несколькими участниками, находящимися в разных часовых поясах. Пользователю приходится учитывать местное время каждого человека, искать пересечение доступных слотов и не ошибиться в переводе времени.
Замесин приводит пример встречи между участниками из Москвы, Сан-Франциско и Тегерана. В таком случае задача согласования времени становится крайне сложной. Он оценивает эту зону как «больно десять из десяти»: это не небольшое неудобство, а ситуация, где обычные способы организации встреч могут перестать работать.
Смысл примера в том, что часовые пояса нельзя рассматривать как второстепенную техническую деталь. Для части пользователей они формируют самостоятельный сценарий с высокой эмоциональной ценой. Если такой сценарий повторяется у значимой части сегмента, он может стать основанием для приоритетного продуктового решения.
В исследовании календарей Иван Замесин рекомендует не ограничиваться регулярными и очевидными событиями. Отдельно нужно изучать нетипичные встречи, исключения, необычные способы использования календаря и ситуации, когда стандартная логика продукта не покрывает потребность пользователя.
Он отмечает, что в календарных продуктах у людей может быть множество «странных» сценариев и костылей. Пользователь не всегда воспринимает их как проблему: он уже адаптировался, придумал обходное действие и встроил его в повседневную работу. Однако для исследователя такие обходные пути особенно ценны, потому что они показывают расхождение между реальной задачей человека и возможностями существующего инструмента.
Нетипичные события могут раскрывать скрытые потребности лучше, чем вопросы о типовом использовании. Если пользователь вынужден дублировать записи, передавать данные через другой канал, вручную пересчитывать время или придумывать особую схему доступа к информации, это указывает на недостаток текущего решения либо на значимую особенность сценария.
Замесин использует этот подход для поиска продуктовых возможностей: нужно спрашивать не только «какие события вы обычно создаёте», но и какие случаи выбиваются из нормы, что в них происходит и как человек справляется. Именно такие детали помогают находить новые требования к продукту, которые не появятся в стандартном описании пользовательского пути.
Иван Замесин приводит конкретный пример календарного костыля. Когда предприниматель или сотрудник команды готовится к встрече с коллегой, он может захотеть сохранить заметки к разговору. Однако основной календарь является общим: участники могут видеть содержание события, и в нём нельзя безопасно оставить приватные комментарии.
В ответ пользователи создают отдельное личное событие на тот же временной слот, что и реальная встреча. Первое событие содержит приглашение и общую информацию для участников, а второе существует только для самого пользователя и используется как место для личных заметок. В календаре оказывается два события, наложенных друг на друга.
Замесин называет это суперкостылём. Он показывает, что пользователь решает задачу подготовки к встрече с помощью функциональности, которая изначально не предназначалась для приватных заметок. Такой сценарий важен не только как единичная странность: он раскрывает потребность разделить публичную и личную информацию, сохраняя её в контексте конкретного времени и конкретной встречи.
Этот пример иллюстрирует ценность исследования реальных действий. Если спросить лишь о том, пользуется ли человек календарём, подобная деталь может не появиться. Но при разборе подготовки к встречам, доступности данных для коллег и личных способов организации работы становится виден обходной путь, который потенциально может стать основой для продуктового улучшения.
Иван Замесин выделяет координацию встречи между несколькими часовыми поясами как один из наиболее болезненных календарных сценариев. В обычной ситуации пользователь может быстро предложить время или посмотреть занятость другого человека. Но при участии людей из разных регионов нужно одновременно учитывать различие во времени, рабочие часы, уже занятые слоты и удобство для всех участников.
Пример с Москвой, Сан-Франциско и Тегераном показывает, что эта задача становится практически неразрешимой привычными средствами. Пользователь должен вручную сопоставлять разные локальные времена и искать редкое пересечение, не допустив ошибки. Такая нагрузка особенно велика, если встреча важна, участников несколько, а свободных окон немного.
Замесин подчёркивает высокую эмоциональную силу этой проблемы: она оценивается как боль «десять из десяти». Это означает, что речь идёт не просто о лишнем действии, а о сценарии, который вызывает сильное напряжение и может быть значимым основанием для продукта.
Для исследования важно выяснять конкретные обстоятельства: как пользователи договариваются о времени, какие каналы используют, где ошибаются, как проверяют доступность и что происходит, если согласование не удаётся. Эти детали позволяют понять не только наличие боли, но и возможные направления решения.
Иван Замесин предлагает преобразовывать каждую гипотезу о сегменте, факторе поведения или детали сценария в конкретные вопросы интервью. Недостаточно зафиксировать на доске, что у пользователей могут быть проблемы с Calendly, встречами в других часовых поясах или нетипичными событиями. Эти предположения должны стать поводом для разговора о фактическом опыте.
На примере Calendly Замесин формулирует вопросы, которые могут раскрыть разные стороны сценария: есть ли проблемы с инструментом, нравится ли он пользователю, за что именно он его ценит, в какие моменты испытывает наибольшую радость, как и в каких ситуациях применяет сервис, какие типы событий через него создаёт. Такие вопросы не предполагают единственного правильного ответа, а открывают пространство для рассказа о действиях и эмоциях.
Далее к каждому ответу применяется базовая логика проблемного интервью. Если пользователь упоминает сложность или особенно удачный опыт, интервьюер уточняет последний эпизод, причины, последствия, эмоции и интенсивность переживания. Так гипотеза перестаёт быть догадкой команды и превращается в проверяемый вопрос о реальном поведении.
Этот подход делает сценарий интервью управляемым, но не жёстким. У исследователя есть карта предполагаемых зон, однако в процессе разговора он может добавлять новые вопросы, если пользователь раскрывает неожиданный сценарий, обходной путь или фактор, который не был предусмотрен изначально.
Иван Замесин предлагает прикладную статистическую эвристику, которая помогает оценивать, можно ли считать найденный в качественных интервью инсайт распространённым в сегменте. Задача состоит не в том, чтобы доказать точный процент пользователей, а в том, чтобы с определённой уверенностью понять, встречается ли инсайт хотя бы у большинства.
Он описывает этот подход как перевёрнутую задачу о подбрасывании монетки. Исследователь наблюдает, сколько раз один и тот же сигнал повторяется у разных респондентов, и на основании этого решает, достаточно ли оснований экстраполировать вывод на всю выборку. Замесин подчёркивает, что единичная яркая история не означает частотности. Даже если один пользователь очень эмоционально описал проблему, она может быть редкой и нехарактерной для сегмента. Поэтому инсайты необходимо фиксировать по каждому интервью и отмечать, сколько раз они повторились.
Эвристика нужна для дисциплины в работе с качественными данными. Она помогает не выдавать интересный частный случай за массовую потребность и, наоборот, увидеть, когда повторяемость стала достаточно высокой, чтобы переходить к приоритизации, формулированию job story и проверке продуктового решения.
Иван Замесин приводит конкретные пороги для проверки частотности инсайтов. Если на первых шести интервью один и тот же инсайт прозвучал шесть раз, то с вероятностью около 80% можно предположить, что он есть более чем у половины всей выборки. В этом случае инсайт можно считать достаточно сильным кандидатом на дальнейшую работу.
Если из шести человек инсайт подтвердили только пять, Замесин предлагает не делать вывод сразу, а увеличить выборку до восьми интервью и проверить, подтвердится ли сигнал ещё у двух респондентов. Такая логика помогает не отбрасывать перспективную гипотезу из-за одного неподтверждения, но и не считать её массовой преждевременно.
Дальнейшая контрольная точка — двадцать интервью. По формулировке Замесина, если из двадцати участников инсайт назвали меньше тринадцати, то с вероятностью 80% он не преодолевает порог большинства в сегменте. Если же он был подтверждён тринадцатью или большим числом людей, можно с той же вероятностью считать, что инсайт присутствует у большинства.
Замесин характеризует этот метод как наиболее доступную аппроксимацию качественных интервью на всю аудиторию. Он не заменяет полноценное количественное исследование, но позволяет сделать процесс custdev более строгим: команда понимает, какие сигналы повторяются достаточно часто, а какие остаются отдельными случаями.
После серии интервью Иван Замесин рекомендует выносить каждый найденный инсайт на доску и явно отмечать его частотность. Нужно зафиксировать, сколько респондентов подтвердили конкретную боль, положительный опыт или сценарную деталь, а затем определить, перешёл ли инсайт порог большинства.
Такая разметка защищает команду от выбора задач на основе самого эмоционального, громкого или свежего рассказа. Пользовательская история может быть убедительной, но без повторяемости неясно, характерна ли она для сегмента. Напротив, даже сравнительно слабая боль может заслуживать внимания, если она систематически возникает у большинства пользователей.
Замесин предлагает оценивать частотность не интуитивно, а по результатам серий интервью. Для этого важно вести записи, переносить наблюдения в общую структуру и сопоставлять ответы разных людей. Инсайт в итоге получает понятный статус: он либо характерен для большинства, либо пока не подтверждён как массовый.
Частотность становится одним из двух основных измерений для дальнейшего выбора продуктовых приоритетов. Второе измерение — сила боли или радости. Только сочетание распространённости и эмоциональной значимости позволяет понять, какие пользовательские потребности стоит решать в первую очередь.
Помимо частотности Иван Замесин предлагает размечать инсайты по силе эмоциональной реакции. В интервью необходимо выяснять, какую эмоцию пользователь испытал в конкретной ситуации, и просить оценить её по шкале от одного до десяти. Это позволяет сравнивать разные проблемы и положительные сценарии не только по словам, но и по субъективной интенсивности переживания.
В качестве примеров он называет радость на шесть из десяти, страх на восемь из десяти и разочарование на семь из десяти. Важен не конкретный тип эмоции, а её сила и связь с определённым действием или препятствием. Пользователь может испытывать не только раздражение, но и тревогу, страх, обиду, облегчение, удовольствие или радость — всё это материал для оценки продуктовой ценности.
Эмоциональная шкала позволяет отделить лёгкое неудобство от проблемы, которая создаёт серьёзный риск или сильное напряжение. Аналогично она помогает отличить просто приятную функцию от delighter, который действительно даёт заметный положительный эффект. В сочетании с частотностью такая оценка становится основой для ранжирования пользовательских потребностей.
Замесин подчёркивает, что оценку нужно получать не как абстрактное мнение о продукте, а после разбора конкретного эпизода. Тогда число на шкале связано с реальной ситуацией, её последствиями и действиями пользователя, а не с общей симпатией или антипатией к сервису.
Иван Замесин настоятельно рекомендует описывать найденные потребности в формате job story. Такой формат создаёт единый язык для фиксации инсайтов: боли, желаемые результаты и контексты использования записываются сопоставимым образом, а не в виде разрозненных цитат, идей функций или субъективных заметок команды.
Главное преимущество job story, по его словам, состоит в однозначности трактовки. Когда разные потребности описаны в одной структуре, их проще сравнивать между собой. Команда меньше рискует по-разному понимать формулировки вроде «пользователю нужен удобный календарь» или «надо улучшить организацию встреч», потому что внимание переносится на конкретную задачу и условия её возникновения.
Единый формат также позволяет соединить два вида разметки: частотность и эмоциональную силу. Каждая job story может быть связана с тем, у какой доли людей она проявляется и насколько сильную боль или радость она вызывает. После этого потребности можно ранжировать и выбирать, какие из них становятся первоочередными продуктовыми задачами.
В интерпретации Замесина job story — это не готовое решение и не описание фичи. Она фиксирует пользовательскую потребность, с которой затем можно работать: искать подходящее продуктовое решение, проверять его через прототип или MVP и оценивать, действительно ли оно уменьшает боль или усиливает желаемый опыт.
На примере исследования календарей Иван Замесин показывает, как результаты интервью превращаются в набор сопоставимых потребностей. На доске возникает несколько групп job stories: часть из них касается возможности быстро делиться свободными слотами, часть — предотвращения пропущенных встреч, часть — перегруженного расписания и отсутствия свободного времени. Не все найденные проблемы имеют одинаковую ценность. Например, потребность быстро поделиться слотами оказывается очень частотной, но эмоциональная сила боли оценивается примерно в четыре балла из десяти. Люди регулярно сталкиваются с этой задачей, однако она не вызывает настолько сильного напряжения, чтобы автоматически считать её главным приоритетом или ожидать высокой готовности платить.
Одновременно были обнаружены две существенно более острые проблемы, оценённые примерно в девять баллов из десяти. Одна связана с риском пропустить встречу, назначенную на необычное время или в нестандартном месте. Другая — с ситуацией, когда календарь заполнен встречами «стык в стык» и у человека не остаётся свободных слотов.
Кейс показывает, как интервьюер может перейти от множества отдельных историй к продуктовой карте потребностей. После фиксации в формате job story, оценки частотности и эмоциональной силы становится видно, какие сценарии являются фоновыми неудобствами, а какие несут высокий риск и заслуживают первоочередного решения.
Иван Замесин выделяет как одну из самых сильных календарных болей риск не прийти на встречу, которая выбивается из привычного распорядка. Пользователь может каждый день приезжать на работу к определённому времени и привыкнуть к стабильной рутине. Если одна важная встреча назначена раньше, в другом месте или в необычном контексте, привычный сценарий может сработать против него.
В приведённом примере человек обычно приезжает на работу на Льва Толстого к десяти утра, но встреча назначена на девять часов в центре. Он приезжает в привычное место и только затем видит множество сообщений с вопросом, где он находится. Ошибка возникает не из-за отсутствия события в календаре, а потому, что календарь недостаточно явно поддержал пользователя в нестандартной ситуации.
Замесин оценивает эту боль как очень сильную — около девяти из десяти. Сценарий опасен тем, что последствия могут выходить далеко за пределы неудобства: пропущенная встреча способна повлиять на отношения с важным собеседником, сделку, партнёрство или получение инвестиций.
Этот пример показывает ценность исследования не только типовых действий, но и исключений. Пользователь может быть вполне удовлетворён календарём в стандартной рабочей неделе, однако один редкий, но критичный сценарий создаёт настолько высокую эмоциональную и деловую цену, что становится приоритетной продуктовой возможностью.
Иван Замесин подчёркивает серьёзность сценария с пропущенными или неправильно организованными встречами конкретными последствиями из интервью. На двух интервью пользователи рассказали, что из-за календарной ошибки им не дали инвестиции либо они потеряли важного партнёра. Эти истории переводят проблему из категории обычной организационной небрежности в категорию рисков с высокой деловой ценой.
Ключевым становится не просто факт пропуска события, а цена результата. Пользователь может лишиться возможности договориться с инвестором, потерять доверие партнёра или сорвать критически важную коммуникацию. Поэтому эмоциональная оценка такой ситуации высока: речь идёт о тревоге, напряжении и возможном ущербе, который несоразмерен с внешне простой задачей управления расписанием.
Замесин использует этот пример, чтобы показать, почему необходимо докапываться до последствий и эмоций. Если ограничиться фразой «иногда я пропускаю встречи», проблема может показаться второстепенной. Но вопрос «почему это тяжело?» раскрывает, что за одним пропущенным событием могут стоять потерянные инвестиции или отношения с ключевым партнёром.
Для приоритизации важно учитывать именно такую связку: конкретный сценарий, его повторяемость, сила эмоциональной боли и последствия для пользователя. Она делает потребность кандидатом на дорогое и значимое решение, а не просто пунктом в общем списке пожеланий к календарю.
Второй сильной болью в исследовании календарей Иван Замесин называет ситуацию, когда расписание пользователя полностью забито встречами «стык в стык». Человек обнаруживает, что в календаре нет ни одного свободного слота: каждая задача и встреча стоят вплотную друг к другу, без времени на переход, подготовку, отдых или непредвиденные обстоятельства.
Эта проблема отличается от простой занятости. Речь идёт о состоянии, когда пользователь теряет возможность управлять своим временем и не замечает накопления перегрузки до тех пор, пока календарь уже не оставляет пространства для действий. Такое расписание повышает риск опозданий, пропусков, плохой подготовки к встречам и общего ощущения потери контроля.
Замесин относит эту потребность к числу суперболей с оценкой примерно девять из десяти. Высокая сила эмоции показывает, что пользователи воспринимают отсутствие свободных слотов не как косметическое неудобство интерфейса, а как серьёзную проблему в организации работы и жизни.
Этот сценарий важен для продуктового анализа, поскольку он может быть неочевиден при поверхностном изучении календаря. Функция создания событий может работать корректно, но сам продукт не помогает пользователю увидеть критическую плотность расписания или предотвратить ситуацию, в которой времени между обязательствами больше не остаётся.
Иван Замесин предлагает ранжировать найденные потребности одновременно по двум критериям: частотности и силе эмоциональной боли или радости. Частотность показывает, насколько широко сценарий распространён внутри сегмента, а эмоциональная оценка — насколько значимым он является для конкретного пользователя. Один показатель без другого недостаточен для выбора продуктового приоритета.
Потребность может быть очень распространённой, но вызывать слабое неудобство. Примером служит быстрое предоставление свободных слотов: эта задача встречается часто, однако оценка боли находится примерно на уровне четырёх из десяти. И наоборот, сильная проблема может проявляться не у каждого, но иметь настолько тяжёлые последствия, что заслуживает отдельной проверки и внимания.
В календарном кейсе две боли с интенсивностью около девяти из десяти — риск пропустить нестандартную встречу и отсутствие свободных слотов в переполненном расписании — оказываются существенно выше других наблюдений. После такой разметки их можно легко отличить от менее значимых потребностей и поставить в начало продуктового бэклога.
По формулировке Замесина, первыми нужно брать в работу самые частотные и наиболее болезненные потребности. Это превращает результаты интервью в практическое решение о последовательности разработки: команда не делает фичи по случайным пожеланиям, а выбирает задачи, где вероятнее всего создаст заметную ценность для значимой доли пользователей.
Иван Замесин связывает силу пользовательской боли с потенциальной готовностью платить за её устранение. В календарном кейсе две наиболее сильные проблемы — пропуск критически важных встреч и отсутствие свободных слотов в переполненном расписании — оцениваются как настолько серьёзные, что пользователи, по его словам, могут быть готовы платить за их решение достаточно много.
Логика состоит в том, что высокая эмоциональная оценка обычно отражает значимые последствия для человека. Если ошибка в календаре способна привести к пропуску важной встречи, потере партнёра или инвестиций, ценность предотвращения этой ошибки становится значительно выше, чем ценность устранения небольшого повседневного неудобства.
При этом сама по себе частотность ещё не гарантирует монетизацию. Регулярная, но слабая боль может быть полезна для улучшения продукта, но не обязательно станет основанием для оплаты. Поэтому Замесин предлагает сопоставлять распространённость сценария с интенсивностью переживания: сильная и повторяющаяся боль является более перспективной для создания платного решения.
Таким образом, оценка эмоций в интервью служит не только для общего понимания пользовательского опыта. Она помогает предположить, какие потребности способны стать источником реальной экономической ценности, а какие скорее останутся улучшениями, не определяющими готовность клиента платить.
Иван Замесин рекомендует не пытаться немедленно придумать окончательное продуктовое решение сразу после серии интервью. После разговора нужно зафиксировать инсайты, а затем дать себе время «переспать» с ними. Он советует буквально завершить работу, лечь спать и вернуться к материалу позже.
По его словам, новые нейронные связи и неожиданные продуктовые идеи часто появляются в состоянии расслабления — в душе, на следующий день или после отдыха. Это означает, что обработка интервью не исчерпывается механическим переносом цитат на доску и ранжированием болей. Важна пауза, в которой наблюдения могут соединиться в новое понимание пользовательской потребности.
Такой подход особенно полезен после того, как инсайты уже структурированы: отмечены по частотности, силе эмоции и описаны в формате job story. Отдых не заменяет анализа, но помогает перейти от набора фактов о проблемах к более цельной продуктовой гипотезе о том, что именно можно создать для их решения.
