Часть 3. Как бизнесу заниматься инновациями —#nbsp;без лаборатории, большого бюджета и#nbsp;иллюзий

Один из самых полезных инструментов для бизнеса — Jobs To Be Done, или JTBD. Эту аббревиатуру можно перевести как «задачи, которые клиент хочет решить». Смысл в том, что человек покупает продукт не ради набора характеристик. Он выбирает его, чтобы справиться с конкретной жизненной или рабочей ситуацией.

Покупатель дрели, как принято говорить, покупает не дрель, а отверстие в стене. Но и это не конечная цель: ему нужно повесить полку, завершить ремонт, сделать дом удобнее, почувствовать, что дело наконец сдвинулось с места.

Чем лучше компания понимает этот контекст, тем больше у неё возможностей создать полезный продукт или сервис.

Возьмём кофе. Его можно описать так: «Мы продаём качественные кофейные зёрна». Это описание продукта. Но его можно увидеть иначе:

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

У задачи клиента почти всегда есть три измерения:

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

Чтобы сформулировать задачу, можно использовать простую конструкцию:
Когда я ___, мне нужно ___, чтобы ___, но мне мешает ___.

Например:

Из такого описания может появиться не один продукт, а целая система решений: шаблоны, экспресс-аудит, конструктор презентаций, консультация, сопровождение, подписка на готовые материалы.

Чтобы понять реальную задачу клиента, лучше спрашивать не «Каких функций вам не хватает?», а:

• В какой ситуации вы начали искать решение?
• Что стало последней каплей или поводом к покупке?
• Как вы справлялись раньше?
• Что вас не устраивало в прежнем способе?
• Каким вы представляете идеальный результат?
• Почему вы можете не перейти на новое решение?
• Что должно произойти, чтобы вы вернулись или порекомендовали нас?

Такие вопросы дают гораздо больше, чем стандартный опрос об удовлетворённости.

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

Более рациональный путь — начать с MVP, минимально жизнеспособной версии продукта. Это самый простой формат, в котором можно проверить ключевую гипотезу с реальными клиентами.

MVP — не «недоделанный продукт» и не попытка сэкономить на качестве. Это способ узнать, нужна ли идея рынку, до того как бизнес вложит в неё значительные деньги.

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

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

Главный вопрос такого теста должен быть конкретным:

До начала теста важно определить, что считать успехом. Например:

• 30 заявок за неделю;
• 10 оплаченных предзаказов;
• не менее половины покупателей готовы повторить заказ;
• не менее 70% тестировщиков понимают ценность предложения без дополнительного объяснения;
• экономика теста не выходит за заранее установленный предел.

Не стоит ограничиваться вопросом «Вам нравится эта идея?». Гораздо честнее отвечают действия: человек оставил заявку, выбрал вариант, оплатил, вернулся, привёл коллегу, порекомендовал продукт или отказался от привычной альтернативы.

Если тест не сработал, это не повод объявлять проект провалом. Возможно, проблема недостаточно значима, выбран неверный сегмент, предложение сформулировано неясно, цена не соответствует ценности или формат требует доработки. Быстрый неудачный тест часто полезнее, чем полгода работы над продуктом, который никому не нужен.