Jobs to be done и User story в продукте простыми словами

Jobs to be Done (JTBD) и User Stories — два популярных подхода к описанию пользовательских потребностей в продуктовой разработке. Хотя они часто рассматриваются как альтернативы, на практике эти методы отлично дополняют друг друга. Разберем, в чем их различия, когда использовать каждый из них и как они могут работать вместе.

Jobs to be Done (Работа для выполнения) — это теория о поведении пользователей, которая помогает понять, как и почему люди принимают решение о первой покупке. С помощью JTBD мы можем делать прогнозы о том, какой продукт будет востребован на рынке, а какой — нет.

Смысл теории в том, что люди не покупают продукты, а «нанимают» их для выполнения определенных задач.

Я покупаю газонокосилку не потому, что мне нужна газонокосилка. Мне нужен красивый газон, а в более широком смысле — красивый двор, чтобы все соседки охали и ахали, проходя мимо моего сада.

Теория «работ» предполагает, что глобальная цель каждого человека — стать лучше, и продукт должен помочь в этом.

Подход отличается от Cusdev’а или создания персон. Вместо того, чтобы придумывать собирательный образ целевой аудитории и выяснять, как пользователь использует продукт, теория «работ» помогает исследовать пользовательские инсайты и трудности.

Неважно, как люди используют продукты, важно, зачем они их приобрели. Каждый человек перед покупкой любого продукта испытывает момент внутренней борьбы (Struggle Moment). JTBD помогает выяснить, что за момент это был. При этом теория не исключает использования других методов исследования. Данные по аудитории могут накладываться на JTBD и становиться еще полезнее. Ведь вы будете знать не только кто ваши потенциальные клиенты, но и почему они покупают у вас.

Каждый час в мире открывается около 11 тысяч стартапов — это более 100 миллионов в год. 90% из них ждет провал. Почему? По мнению Fortune, ключевая причина: «они создают продукты, которые никому не нужны».

С помощью теории «Работ», мы можем узнать, что движет людьми в момент принятия решения о покупке, а значит у нас есть возможность создавать такие продукты, которые будут лучше отвечать на внутренние запросы клиентов.

Цель JTBD — понять, почему пользователи покупали продукты в прошлом и спрогнозировать, будут ли они покупать в будущем

Ключевые принципы JTBD:

Формат JTBD: "Когда [ситуация], я хочу [исход], чтобы [выгода/эмоция]"

Грубо говоря, теория «работ» помогает подобраться как можно ближе к истинным желаниям пользователя и исходя из этих желаний создавать такие продукты, которые с большей вероятностью будут востребованы на рынке.

Нужно изучить JTBD, если вы хотите:

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

У Jobs To Be Done нет ограничений по области применения или по роли использующего: он будет полезен топ-менеджеру в девелоперской компании, дизайнеру мобильного приложения и фотографу на фрилансе.

JTBD можно применить даже к планированию жизни и карьеры. Главное, не слепо следовать инструкциям, а учитывать, какие из инструментов привлечения подойдут именно вам.

В 2002 году Apple продала 376 тысяч iPod. В 2008 продажи достигли отметки в 55 миллионов. iPod был признан одним из самых успешных и быстрорастущих продуктов в мире. Однако в 2004 году Apple начала разработку другого девайса, который должен был «убить» iPod — iPhone.

Почему компания решилась на такой шаг? В 2004 году продажи iPod росли, не было причин, почему они могут упасть (и дальнейшие 4 года это подтвердили).

Но в Apple понимали: рост не может продолжаться вечно. Можно было наслаждаться лидерством и ждать, пока на смену MP3-плеерам придет новая технология, и кто-то другой захватит рынок. А можно было сыграть на опережение и взять контроль в свои руки.

Для многих компаний такое мышление нетипично. Кроме того, в Apple еще ничего не знали про разработку телефонов и должны были с нуля построить процесс. Вместо того, чтобы радоваться растущим доходам и добавлять новые функции к iPod, они подумали — почему бы нам не сделать что-то новое и не добавить iPod к нему? Как мы сейчас видим, они приняли правильное решение.

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

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

Есть несколько факторов, которые надо учитывать в процессе расстановки приоритетов:

Какой бы путь вы ни выбрали, Jobs To Be Done — полезный фреймворк, который поможет не потеряться в данных и понять, чего действительно хотят люди.

Как писал Питер Друкер: «Клиент редко покупает то, что бизнес ему продает».

Не фокусируйтесь на своем продукте или на решении — фокусируйтесь на «работах» (проблемах пользователя) и помогайте пользователю переводить их из статуса «надо сделать» (to be done) в «сделано» (done) — и делать его жизнь немного проще и комфортнее

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

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

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

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

В примере выше это шаг 3. Можно влезть и раньше: например, если пользователь обычно встает в 7 утра, а уже 12 вечера, и телефон активен, приложение отправит напоминание: «Не хотите ли поставить будильник и пойти спать?».

Можно развить эту мысль и дальше: предложить пользователю следить за пульсом и активностью, и на основе этих данных рекомендовать ему лучшее время, чтобы пойти спать (а заодно и будить его в лучшее время для подъема). Нужно ли это? Испытывает ли пользователь «боль», соответствующую масштабам исследований и разработки? Это должна понять и решить продуктовая команда.

User Stories — это метод описания требований в Agile-разработке, который фокусируется на ценности для конечного пользователя. Этот подход помогает команде разработки понять, что нужно построить и почему это важно.

Ключевые принципы User Stories:

Формат User Story: "Как [роль], я хочу [действие], чтобы [выгода]"

Пример: "Как водитель, я хочу видеть время в пути до дома, чтобы планировать свой маршрут"

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

Цель персон — создать эмпатию у команды, особенно у тех, кто не общается с пользователями. Цель подхода user story — напоминать вам, кто ваш пользователь, и помогать принимать решения, ориентированные на привлечение пользователя.

Это очень полезный инструмент, если вы:

На примере Uber кажется, что здесь точно есть две конкретные персоны: водитель и пассажир. На самом же деле, эта характеристика — лишь часть контекста: в зависимости от ситуации водитель может оказаться на месте пассажира, и наоборот. Мы думаем не о том, что разнит наших пользователей, а что их объединяет. Таким образом, то, что мы делаем, получает больший охват.

Jobs to be Done и User Stories не конкурируют друг с другом — они решают разные задачи на разных уровнях продуктовой разработки. JTBD помогает понять "почему" и "когда", а User Stories фокусируются на "что" и "как".

Эффективная продуктовая команда использует JTBD для стратегического понимания пользователей и рыночных возможностей, а затем переводит эти инсайты в конкретные User Stories для планирования и разработки. Такой подход обеспечивает как глубокое понимание пользователей, так и практичность в реализации продуктовых решений.

Начните с изучения Jobs to be Done ваших пользователей, а затем используйте User Stories как инструмент для воплощения этого понимания в конкретные продуктовые фичи.