{"id":14284,"url":"\/distributions\/14284\/click?bit=1&hash=82a231c769d1e10ea56c30ae286f090fbb4a445600cfa9e05037db7a74b1dda9","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0430\u043d\u0446\u044b \u0441 \u0441\u043e\u0431\u0430\u043a\u0430\u043c\u0438","buttonText":"","imageUuid":""}

Почему «покастдевить» не работает?

JTBD-исследование включает серию глубинных интервью с клиентом”, — начал я как-то очередной блок Jobs To Be Done курса. И тут же был прерван участниками: “Так мы кастдевим, то же самое делаем!”.

Уточнил, что бы это значило. Оказалось, “покастдевить” — это некий долгий разговор, когда говорят обо всем [выходит, что ни о чем], без структуры и фреймворка.

Клиент фантазирует – вы воспринимаете это за чистую монету. Или хуже: это все вам рассказывает еще и потенциальный клиент.

В общем, молодцы, что “кастдевите”, только это:

  • не CustDev, потому что у него есть своя механика.
  • не Jobs To Be Done, потому что вы беседуете с клиентом по наитию, без шаблона вопросов и без понимания, что из этого выйдет, как структурировать результаты и как их потом применить.

CustDev

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

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

В целом, на этом этапе развития клиента — просто «покасдевить» и классический CustDev приведут к одному и тому же результату.

Почему я применяю и рекомендую Jobs To Be Done

Вы говорите строго по шаблону вопросов, обязательно с действующими клиентами, которые демонстрируют целевое поведение.

[Про целевое поведение почитайте здесь]

В процессе JTBD-интервью вы получаете спектр конкретных, а не потенциальных “болей” — задач и подзадач (в терминологии JTBD) , с которыми сталкивался реальный, а не потенциальный клиент.

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

Фокусируйтесь на результате, который хочет получить ваш клиент, не погружайтесь в фантазии.

Приведу два наглядных примера.

Наглядный кейс №1. Распутыватель для проводов.

“Постоянно путаются провода наушников. Бесит, это еще мягко сказано” — исходный контекст. Покастдевили с клиентами, углубились в проблему, поискали решение => сделали распутыватель для проводов… Не зашло! Почему? Не надо делать, ориентируясь на пожелания и фантазии клиента. Создавайте продукт, ориентируясь на результат, который клиент хочет получить. Что сделали с помощью Jobs To Be Done? Беспроводные наушники.

Наглядный кейс №2. Такси.

С целью улучшить сервис такси, кастдевили пассажиров. Знаете, о чем они говорили? Их главной болью было найти наличку для расчета. Фокусируясь на этой «боли» запускались стартапы. А что сделал Uber с помощью Jobs To Be Done? Определил основную задачу клиента — “Быть мобильным в городе”. Выяснил все «боли» — мелкие задачи, из которых состоит «Быть мобильным в городе» и закрыл все подзадачи оптом.

Уловили суть Jobs To Be Done?

P. S. Не все готовы распрощаться с CustDev, а тем более с желанием «покастдевить». Понимаю. Дело добровольное:)

0
Комментарии
-3 комментариев
Раскрывать всегда