JTBD для вайбкодинг-идеи: как сформулировать продукт через задачу пользователя

JTBD для вайбкодинг-идеи - это способ проверить продукт до разработки: не гадать, что понравится рынку, а понять, какую работу пользователь наймет ваш сервис делать. Формула Jobs To Be Done звучит так: когда я [ситуация], я хочу [мотивация], чтобы [результат]. Если формула для вашей идеи не собирается за пять минут, значит открывать Cursor или Claude Code еще рано. Дальше в статье: сама формула на вайбкодинг-примерах, три части job, реальные кейсы вроде PayPal и Uber Eats и три вопроса для JTBD-интервью, которые можно задать уже сегодня.

JTBD (Jobs To Be Done) переводит вайбкодинг-идею в формулу «когда я [ситуация], хочу [мотивация], чтобы [результат]» и показывает, наймет ли пользователь продукт вообще. У любой job три части: функциональная, личная эмоциональная и социальная. Дальше - формула на примерах, разбор PayPal, Uber Eats и Peloton, три вопроса для интервью и чеклист перед стартом сборки.

Что такое JTBD и почему это не просто «изучить аудиторию»?

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

Теодор Левитт, профессор Гарвардской школы бизнеса, говорил примерно так: людям не нужна дрель, им нужно отверстие в стене. Клейтон Кристенсен развил эту мысль в теорию Jobs To Be Done: клиенты не покупают продукт, они нанимают его на работу. Для вайбкодинг-идеи это меняет порядок действий.

Обычный подход звучит так: беру нишу, смотрю на конкурентов, добавляю фичи получше. JTBD переворачивает вопрос. Смотрите не на нишу, а на работу, которую человек делает руками, в Excel, в блокноте или через три разных приложения сразу. Если вы вайбкодите заметки для фрилансеров, вашим конкурентом может быть не другое приложение заметок, а голосовые сообщения себе в Telegram. Это и есть работа, за которую идет борьба.

Как звучит формула JTBD для вайбкодинг-идеи?

Формула JTBD - «когда я [ситуация], хочу [мотивация], чтобы [результат]». Заполните три скобки для своей идеи, и сразу станет видно, есть тут реальная работа или это фантазия про удобный интерфейс.

Формула родом из книги Кристенсена Competing Against Luck. Она работает как фильтр: если ситуацию и результат можно описать в одном предложении, продукт вероятно решает настоящую проблему. Если получается только «хочу удобное приложение для X» без ситуации, для вайбкодинг-идеи это тревожный звонок.

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

Максим: «Продукт выполняет конкретную задачу для человека. Решает проблему в моменте. Сколько людей, сколько профессий - столько и продуктов. В каждой профессии минимум 50 разных задач, на которые можно создать микропродукт.»

Из каких трех частей состоит job пользователя?

У любой job три слоя: функциональный (что нужно сделать), личный эмоциональный (что почувствовать) и социальный (как выглядеть перед другими). Продукт, который закрывает все три, выигрывает у того, что закрывает только первый.

Christensen Institute описывает jobs theory именно через эти три измерения. Два человека могут решать одну функциональную задачу «выучить английский» совершенно по-разному: один идет в разговорный клуб ради статуса среди коллег, второй ставит приложение, чтобы не тревожиться перед созвоном с иностранным клиентом.

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

Как провести JTBD-интервью до того, как открыть IDE?

Три вопроса вытаскивают реальную job за 15-20 минут разговора: что человек делал вручную в последний раз, что раздражает в процессе больше всего и как он поймет, что решение сработало.

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

Раз: расскажите, когда последний раз делали [задачу] вручную. Два: что раздражает в этом процессе больше всего. Три: если бы решение появилось, как бы вы поняли, что оно работает. Три-пять таких разговоров с реальными людьми стоят дороже любого промпта для автозаполнения формы. И дешевле недели вайбкодинга продукта, который никто не наймет.

Как JTBD выглядит на реальных продуктах?

PayPal наняли на мгновенный перевод денег, Uber Eats - на еду без похода из дома, Peloton - на спорт с людьми без похода в зал. Ни один из этих продуктов не выиграл бы, если бы решал только «быстрее» или «дешевле».

По легенде о JTBD, Генри Форд не спрашивал людей, что построить. Он понял, что реальная job - быстрее добраться из точки А в точку Б, а не более резвая лошадь. Автомобиль победил не потому, что был лошадью получше, а потому что закрыл ту же job другим способом.

Ни один из этих продуктов не выигрывал в категории «больше фич». Они выигрывали в категории «точнее закрыли job». Для вайбкодинг-идеи это главный ориентир перед первым промптом в редакторе.

Как AI ускоряет JTBD-исследование перед вайбкодингом?

AI-чат берет на себя ресерч рынка и черновик PRD до того, как вы откроете редактор кода: спросите про боли аудитории, соберите скриншоты конкурентов, оформите требования - и только потом стройте.

В разборе кейса «от идеи до продукта за 18 минут» связка выглядит именно так: сначала AI для ресерча рынка и PRD, потом билдер для сборки MVP. Правило простое: мусор на входе - мусор на выходе, расплывчатая идея дает расплывчатый продукт, сколько бы итераций вы ни сделали.

Свежий кейс на YouTube показывает три этапа. Сначала AI-ресерч рынка: чем недовольны пользователи существующих решений, какие пробелы в функционале. Дальше AI собирает Product Requirement Document - документ с болями, метриками и списком экранов. И только на третьем шаге в дело идет билдер: Base44, который Wix купил в 2025 году, или связка Cursor и Claude Code, если нужен контроль над кодом. Без первого шага третий превращается в дорогую генерацию красивого, но никому не нужного интерфейса.

Какие ошибки чаще всего убивают JTBD-анализ у вайбкодеров?

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

JTBD не заменяет данные о спросе и не гарантирует, что 300 клиентов найдутся сами. Метод отвечает на вопрос «какую работу решает продукт», а не на вопрос «сколько людей готовы платить» - это отдельное исследование юнит-экономики, и его никто не отменял.

Первая ошибка - формулировать job из своей головы, а не из разговора с живым человеком. Вторая - принимать «хочу удобное приложение» за job, хотя это уже готовое решение, а не задача. Третья - тестировать идею на друзьях-вайбкодерах, которые ответят вежливо, а не на целевой аудитории. Четвертая, о ней часто забывают: JTBD показывает, что нанять, но не считает, сколько за это заплатят.

Что сделать перед тем как открыть Cursor или Claude Code?

Пять шагов от job к первому промпту: сформулировать формулу, проверить три компонента, провести 3-5 интервью, собрать короткий PRD и только потом выбрать инструмент под сборку.

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

Шаг 1: соберите формулу job в одно предложение.

Шаг 2: распишите функциональную, личную и социальную часть по таблице выше.

Шаг 3: проведите 3-5 интервью по трем вопросам.

Шаг 4: оформите короткий PRD, пусть даже на одну страницу.

Шаг 5: выберите инструмент под задачу - Cursor и Claude Code для контроля над кодом, Windsurf или Lovable, если нужен быстрый визуальный билд.

Стоит ли тратить время на JTBD перед вайбкодингом

Формула, три компонента и три вопроса - это максимум час подготовки. Взамен вы получаете фильтр, который отсеивает слабые идеи до того, как в них вложено время в IDE, а не после релиза с нулевыми метриками.

JTBD не гарантирует успех идеи. Он гарантирует, что вы строите ради конкретной работы человека, а не ради красивого интерфейса. Дальше решение за вами: собрать формулу за вечер или собрать продукт за неделю и узнать про job постфактум, из нулевых цифр в аналитике.

Если формула JTBD для вашей идеи уже готова, следующий шаг - выбрать инструмент под сборку. Загляните в каталог AI-инструментов VibeCoderz: там честные обзоры Cursor, Claude Code, Windsurf и Lovable с плюсами и минусами. А если нужна помощь с формулировкой job и стратегией запуска, запишитесь на консультацию к Максиму.

Глоссарий

• JTBD (Jobs To Be Done) - подход к продукту, при котором пользователь «нанимает» сервис для выполнения конкретной работы, а не покупает набор функций.
• Job story - формулировка вида «когда я..., я хочу..., чтобы...», основа JTBD-анализа.
• Функциональная job - практическая задача, которую нужно решить буквально: посчитать, отправить, найти.
• Эмоциональная job - то, что человек хочет почувствовать в процессе или после: спокойствие, уверенность.
• Социальная job - как решение выглядит для окружающих: статус, репутация, вовлеченность.
• PRD (Product Requirement Document) - краткий документ с описанием job, метрик и экранов продукта, на основе которого AI собирает MVP.
• MVP - минимальная версия продукта, которая закрывает job без лишнего функционала.

Вопросы о JTBD для вайбкодинг-идеи

Чем JTBD отличается от портрета целевой аудитории?

Портрет аудитории описывает человека: возраст, профессию, доход. JTBD описывает ситуацию и задачу, а не человека. Один и тот же человек в разных ситуациях нанимает разные продукты на разные job, поэтому демография сама по себе не объясняет выбор именно вашего сервиса.

Можно ли применить JTBD без реальных интервью?

Технически можно набросать гипотезу job по своему опыту, но это гипотеза, а не JTBD-анализ. Метод работает на реальных историях людей: что они делали в прошлый раз, а не что они думают, будто сделают в будущем.

Сколько интервью нужно для вайбкодинг-идеи?

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

JTBD подходит только для новых продуктов?

Нет, метод так же работает для доработки существующей вайбкодинг-идеи. Если метрики просели, часто дело не в интерфейсе, а в том, что продукт перестал закрывать job лучше конкурентов, включая офлайн-привычки пользователя.

Как JTBD связан с MVP в вайбкодинге?

JTBD определяет, что должно попасть в MVP в первую очередь: функционал, который закрывает job, а не тот, что проще всего собрать за вечер. Без JTBD MVP часто получается технически рабочим, но никому не нужным.

Работает ли формула JTBD для B2B-идей?

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

Что делать, если формула JTBD не складывается?

Значит идея пока описывает решение, а не job. Вернитесь к вопросу «что человек делает вручную сейчас» и постройте формулу от этого действия, а не от названия будущего приложения.

Обновлено: июль 2026