Мне тут подсказали, что я неосознанно себя зафреймил и поэтому постоянно прихожу в тупик по поводу использования JTBD.

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

Второй момент. Существуют прям отдельные школы JTBD. Первая школа определяет Job Story как прогресс, а другая как активность.

Определение Job Story как прогресс помогает нам понять, те самые описываемые в теории, 4 движимые силы («толчок», «притяжение», «переживания» и «привычки») и контекст, в котором всё это происходит. Это всё даёт нам верхнеуровневое понимание о том что и когда с пользователем происходит, без привязи к каким-то маленьким решениям.

Определение Job Story как активность говорит о том, что мы делаем продукт для решения конкретных микро-задач, чтобы сделать процесс выполнения работы быстрым и удобным.

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

По итогу теперь я могу выделить для себя несколько вариантов использования JTBD:

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

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

JTBD + CJM

Изучил подробнее метод Анны Матвеевой с объединением JTBD и CJM, а также снова перечитал статью Джеймса Томаса про подключение Desired Outcomes к Job Stories. На самом деле оба пришли практический к одному и тому же.

Сходства:
– Выделяется большая Job Stories и она декомпозируется на составные, если это требуется;
– Job Stories расписываются с помощью ориентированного графа с набором необходимых данных;
– Во всех ориентированных графах присутствует Desired Outcomes.

Отличия:
– Анна явно не предлагает выделять Core и Growth JobStories;
– Джеймс явно не предлагает строить CJM;
– Джеймс предлагает создавать интересный суммаризирующий артефакт для команды «Jobs map».

Адаптация на адаптации

Из адаптаций Анны и Джеймса я слепил черновик своей адаптации, которую можно увидеть в обложке поста. Такая адаптация подойдёт не всем, может она и мне не подойдёт, это только черновик. Такая адаптация создаётся под определённый проект, на котором хочется обкатать знания.

На всякий случай объясню то что вы видите на обложке.

1. У продукта, который я хочу заисследовать, есть определённый набор больших Job Stories. Короче, верхнеуровнего то ради чего в принципе будут использовать продукт. Это Core Functional Job.

2. Core Functional Job слишком большие, чтобы на основе них генерировать какие-то решения, поэтому их нужно декомпозировать на составные, т.е. Core Job Stories (MVP) и Growth Job Stories. Core JS первыми берутся в исследования, а Growth JS идут в беклог и достаются из него когда обработаны все Core JS.

3. Чтобы качественно происследовать JS и получить данные, которые помогут сгенерировать решения, строится CJM и(или) UJM. Первая исследует продвижение человека по JS как покупателя (customer), а вторая как пользователя (user).

У меня есть большие сомнения в нужности этапов для Core Functional Job и разделении JS на CJM и UJM, возможно, можно всё сразу учесть в одном артефакте.

Тестирование продуктовых гипотез

Вписался в курс WNBL по исследованиям и сразу получил пачку статей и книг для подготовки. В одном из предоставленных материалов по прототипам привели в пример очень крутое выступление 7-ми летней давности, кажется, от продакта Михаила Високовского.

В выступлении Михаил рассказывал как команда Яндекс Навигатора тестировала продуктовые гипотезы. Самое интересное в этом выступлении сами способы тестирования.

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

Сейчас такие тесты делают очень редко, либо просто про них перестали рассказывать, не часто теперь встречаю такие кейсы.

После просмотра доклада зашёл в нынешнее представление Навигатора (Яндекс Карты). Интересно как некоторые гипотезы озвученные в том докладе развились и сейчас работают в приложении.

Ссылка на выступление

Теперь наконец-то заживём?

Config 2025

Cursor в Figma? А зачем? Дизайнеры не поймут, а у разработчиков другие игрушки.

Config 2025

Ладно, норм. Спасибо, Дилан.

Summary config.new

Config 2025

А я дальше в спячку.

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

PS: Подрезал наблюдение у Denis Abdullin