# Jobs to Be Done в B2B — теория и столкновение с реальностью За 14 лет в промышленном B2B я использовал JTBD как рабочий инструмент интервью, а не как лозунг с конференции. Разница чувствуется сразу, как только пытаешься применить методику не к покупателю молочного коктейля, а к закупке промышленной оснастки, где решение проходит через инженера, снабженца и директора, и у каждого — свой критерий «сделки состоялась». ## Теория Концепцию в её нынешнем виде запустил Клейтон Кристенсен [историей про молочный коктейль](https://hbswk.hbs.edu/item/clay-christensens-milkshake-marketing) в McDonald's. Компания улучшала вкус коктейля по всем правилам маркетинга — гуще, слаще, с кусочками фруктов — и продажи не двигались. Разгадка нашлась, когда исследователь встал у входа в ресторан в 7 утра: сорок процентов коктейлей покупали в одиночку, до открытия, и уносили с собой в машину. Коктейль «нанимали» не как десерт, а как занятие для скучной дороги на работу и способ дотянуть до обеда — он не пачкал руки, долго не заканчивался и помещался в подстаканник. Днём тот же продукт «нанимали» на совершенно другую работу — как повод для родителя почувствовать себя внимательным к ребёнку. Кристенсен изложил идею в [«Competing Against Luck»](https://www.christenseninstitute.org/books/competing-against-luck/) (2016): люди не покупают продукты — они нанимают их для прогресса, который хотят совершить в конкретных обстоятельствах, и это верно и для потребителей, и для организаций. Параллельно с Кристенсеном развивалась другая ветка теории. Тони Ульвик работал над методом ещё с 1990 года в IBM и в 1999-м показал свои наработки Кристенсену — тот включил их в «The Innovator's Solution» (2003). Но Ульвик довёл идею до другого полюса: его Outcome-Driven Innovation описывает «работу» не как прогресс, а как устойчивую последовательность действий — восемь шагов от «определить» до «завершить», — а внутри каждого шага заказчик формулирует измеримую метрику успеха («минимизировать время, необходимое для…»). В [«Jobs to Be Done: Theory to Practice»](https://jobs-to-be-done-book.com/) (2016) Ульвик собирает 50–150 таких метрик на рынок, считает по ним важность и удовлетворённость и по формуле «важность + (важность − удовлетворённость)» получает приоритет для разработки. Это статистика, а не история одного клиента, и именно поэтому метод хорошо ложится на процессы, которые уже существуют и которые можно измерить. Третий полюс — [Боб Моэста](https://www.lennysnewsletter.com/p/the-ultimate-guide-to-jtbd-bob-moesta), соавтор Кристенсена по ранним исследованиям, а затем основатель отдельной практики «продаж со стороны спроса». Его метод — не наблюдение и не опрос по метрикам, а интервью с теми, кто недавно переключился с одного решения на другое: что не устраивало в старом, что подтолкнуло искать новое, чего боялись при переходе и что жалко было терять. Он называет это четырьмя силами прогресса — толчок, притяжение, тревога и привычка — и настаивает, что «жаловаться — не то же самое, что переключиться»: спрашивать нужно не тех, кто ноет, а тех, кто уже что-то сделал. Различие между школами не терминологическое. Ульвик и его сторонники называют эту работу Jobs-As-Activities: люди хотят подстричь газон, и задача продукта — помочь сделать это за меньшее число проходов и с меньшим шумом. Кристенсен, Моэста и теоретик Алан Клемент называют свою версию Jobs-As-Progress: человек не хочет стричь газон, он хочет жить в доме, который выглядит ухоженным, и наймёт для этого что угодно — от службы стрижки до искусственного покрытия. Активность в этой модели — только средство, а не цель, и потому анализ действия без контекста, в котором оно происходит, ничего не объясняет — спор двух школ подробно разобран у [Алана Клемента](https://archive.is/JQWzm). Обе школы называют себя JTBD, обе дают результаты в практике — но задают разные вопросы и требуют разных исследовательских процедур: смешивать интервью-переключение и количественный опрос по метрикам в одном заходе значит получить данные, которые не отвечают ни на один из вопросов. ## Столкновение с реальностью B2B Все три автора строили теорию на потребителе, который сам покупает и сам пользуется продуктом. В промышленном B2B этого человека нет. Есть цепочка ролей, и «работу» у каждой роли — свою. Инженер на производстве нанимает решение, чтобы закрыть техническое требование и не отвечать потом за отказ на площадке. Снабженец нанимает то же решение по другой работе — пройти тендерную процедуру, не выйти за бюджет и не создать риска для себя лично, если контракт окажется неудачным. Директор нанимает решение по третьей работе — снизить риск всей сделки и получить обоснование перед своим руководством или советом. Продукт, который отлично закрывает функциональную работу инженера, может провалиться на этапе снабженца просто потому, что у того другая метрика успеха и другая тревога. Это ровно та многосубъектность, о которой пишет литература по B2B-закупочным комитетам: экономический покупатель считает не характеристики, а риск невозврата инвестиций, технический эксперт — совместимость и соответствие требованиям, конечный пользователь — насколько решение впишется в его ежедневную рутину, и любой из них может заблокировать сделку, даже если остальные в восторге. В [[CustDev конструкций в Узбекистане]] это проявилось буквально: конечным «нанимателем» быстровозводимых конструкций были не собственники будущих объектов, а архитектурные бюро — посредническое звено, которое формулирует техническое задание и выбирает поставщика от имени заказчика. Гайд интервью пришлось строить не вокруг вопроса «нужна ли вам конструкция», а вокруг того, какую работу бюро выполняет для своего клиента и что должно случиться, чтобы оно включило конкретное решение в проект. Через месяц похожая логика повторилась в [[Кастдев-гайды для рынка Бразилии]] — там пять целевых организаций получили пять разных персонализированных гайдов, потому что попытка задать один универсальный опросник игнорировала бы то, что у производственной компании и у дистрибьютора внутри одной отрасли разная работа, ради которой они рассматривают продукт. История с Индией показала это же расхождение с другой стороны — со стороны продаж, а не исследования. В [[B2B-переговоры с производителями Индии]] крупный заказчик запросил визит на площадку и NDA раньше, чем появился финальный оффер — спрос на функциональную работу подтвердился быстро. Но когда полтора года спустя дошло до [[Win-Loss-анализ продаж в Индии]], выяснилось, что почти половина сделок из сорока лидов срывалась, и почти треть отказов была управляемой внутренней причиной — то есть не расхождением по цене или продукту, а тем, что предложение не закрывало работу конкретной роли в цепочке принятия решения на нужном для неё языке. Разбор причин потерь по сути и есть post-mortem версия JTBD-интервью: не «почему клиент не купил», а «какую работу мы не закрыли и для кого именно из тех, кто участвовал в решении». [[Клиентское интервью по продукту БПЛА]] подтверждает третий слой этой же проблемы — критерии выбора, зафиксированные в интервью с одним респондентом, ложатся в карту продукта только с пометкой, чью именно работу они описывают. В промышленном B2B нельзя взять один комплект критериев на весь цикл сделки: то, что важно инженеру на этапе технической оценки, почти никогда не совпадает с тем, что важно директору на этапе подписания. Практический вывод из всего этого не в том, чтобы выбрать одну школу JTBD и держаться её теоретической чистоты. Для промышленного продукта интервью по методу Моэсты — реконструкция момента переключения — хорошо вскрывает, почему инженер или снабженец вообще начали искать альтернативу действующему поставщику. Но дальше это нужно раскладывать не на одну работу, а на карту работ по ролям в закупочной цепочке, и для каждой роли отдельно проверять, какое обещание продукта на неё действует. Общая работа компании-заказчика — часто фикция; реальны только работы конкретных людей, чьё «да» нужно собрать по очереди. ## Мои кейсы по теме - [[CustDev конструкций в Узбекистане]] - [[Кастдев-гайды для рынка Бразилии]] - [[B2B-переговоры с производителями Индии]] - [[Клиентское интервью по продукту БПЛА]] **Практический разбор по теме:** [[CustDev в B2B — как проверить, готов ли клиент платить]] ## Связаться Если у вас похожая задача — обсудим ваш продукт: [[email protected]](mailto:[email protected]), Telegram [@falcolupus](https://t.me/falcolupus) или [MAX](https://max.ru/u/f9LHodD0cOJd5VFHyaG9k7YpP7BW9s55ZYkjWX6P8j51xBYS3XgDfnOxz3U). Работаю удалённо в любом часовом поясе.