Кто на самом деле изобрёл Jobs-to-be-Done
В продуктовом мире принято считать, что JTBD — это Клейтон Кристенсен. «Milkshake case», «Competing Against Luck» (2016), Harvard Business School. Но хронология говорит другое.
Tony Ulwick начал разрабатывать Outcome-Driven Innovation (ODI) в 1991 году. В 1999 он опубликовал первую академическую статью. В 2002 — статью в Harvard Business Review «Turn Customer Input into Innovation». Кристенсен, прочитав её, пригласил Улвика в HBS как guest lecturer. Термин «jobs-to-be-done» Кристенсен популяризировал, но сама идея — что инновация должна начинаться с результатов, которые хочет получить клиент, — принадлежит Улвику.
Это не академический спор. Различие принципиально для практики: Кристенсен создал метафору (hiring a product). Улвик создал математику (Opportunity Score, Desired Outcome Statements, Job Map). Метафора вдохновляет. Математика принимает решения.
Desired Outcome Statements: формат, который убирает субъективность
Центральная единица ODI — Desired Outcome Statement. Это не «потребность», не «хотелка», не «feature request». Это формализованное описание результата, которого пользователь хочет достичь.
Формат:
{Направление} + {метрика} + {объект контроля} + {контекстный уточнитель}
| Компонент | Правила | Примеры |
|---|---|---|
| Направление | Всегда «minimize» или «increase». Никогда «improve», «better», «optimize» — они субъективны | Minimize, Increase |
| Метрика | Измеримая величина: time, likelihood, number, amount, frequency | the time, the likelihood, the number of |
| Объект контроля | То, на что пользователь влияет | errors in the report, steps to complete |
| Контекст | Когда/где/при каких условиях | when working with large datasets, during peak hours |
Примеры правильных Desired Outcome Statements:
- «Minimize the time it takes to identify the root cause of a production incident»
- «Increase the likelihood that the quarterly forecast reflects actual revenue within ±10%»
- «Minimize the number of manual steps required to onboard a new team member»
- «Increase the likelihood that high-priority bugs are caught before release»
Примеры НЕПРАВИЛЬНЫХ (типичные ошибки):
- «Make the dashboard better» — нет направления, нет метрики, субъективно
- «Add dark mode» — это solution, не outcome. ODI работает с outcomes
- «Users should be happier» — не измеримо, не actionable
- «Improve reporting» — «improve» = субъективное направление
Объём: Улвик рекомендует 50-150 Desired Outcome Statements на каждый Primary Demand (L2 в терминах Product DNA). Это может казаться избыточным, но именно этот объём обеспечивает достаточную гранулярность для количественной приоритизации.
Job Map: 8 универсальных шагов
Улвик формализовал процесс выполнения любой «работы» в 8 шагов. Каждый шаг — это этап, через который проходит пользователь, выполняя Primary Demand:
| # | Шаг | Вопрос | Пример (управление проектом) |
|---|---|---|---|
| 1 | Define | Что нужно сделать? Какие цели? | «Определить scope проекта и критерии успеха» |
| 2 | Locate | Где найти нужные ресурсы/данные? | «Найти подходящих специалистов для команды» |
| 3 | Prepare | Как подготовиться к выполнению? | «Настроить рабочее пространство, шаблоны, инструменты» |
| 4 | Confirm | Всё ли готово? Правильные ли входные данные? | «Проверить, что requirements согласованы со стейкхолдерами» |
| 5 | Execute | Как выполнить основную работу? | «Управлять задачами, сроками, зависимостями» |
| 6 | Monitor | Как контролировать процесс? | «Отслеживать прогресс, выявлять блокеры» |
| 7 | Modify | Как адаптироваться при изменениях? | «Перераспределить ресурсы при изменении приоритетов» |
| 8 | Conclude | Как завершить и зафиксировать результат? | «Провести retrospective, документировать lessons learned» |
Каждый шаг генерирует 5-20 Desired Outcome Statements. 8 шагов × 10 outcomes = 80 statements — середина рекомендованного диапазона.
Связь с Product DNA: Job Map = Demand Steps (L3) в Demand Architecture (Strand 3). Но Product DNA расширяет модель: L3 шаги связаны типизированными рёбрами графа (sequence, enables, conflicts, amplifies), что позволяет находить bottleneck-и и elimination opportunities.
Opportunity Score: формула
Центральная формула ODI, которая превращает субъективную приоритизацию в количественную:
Opportunity Score = Importance + max(Importance - Satisfaction, 0)
| Параметр | Что измеряет | Как собирать | Шкала |
|---|---|---|---|
| Importance | Насколько важен этот outcome для пользователя | Опрос: «Насколько важно для вас [desired outcome]?» | 1-10 (или 1-5, с пересчётом) |
| Satisfaction | Насколько хорошо текущее решение удовлетворяет этот outcome | Опрос: «Насколько вы удовлетворены текущим решением для [desired outcome]?» | 1-10 (или 1-5, с пересчётом) |
Интерпретация Opportunity Score (шкала 1-10):
| Score | Статус | Стратегия |
|---|---|---|
| ≥ 15 | Extremely underserved | Build NOW. Это ваша главная возможность. Пользователям критично важно, и ничто не решает это хорошо |
| 12-14 | Underserved | Strong opportunity. Вторая очередь после ≥15 |
| 10-11 | Appropriately served | Table stakes. Решение существует, улучшение даёт marginal value. Не дифференциатор |
| < 10 | Overserved | Simplify или eliminate. Текущие решения делают больше, чем нужно. Opportunity = упростить и удешевить |
Почему формула работает
Обратите внимание на max(Importance - Satisfaction, 0). Это не просто разница. Это усечённая разница: если Satisfaction ≥ Importance, второе слагаемое = 0. Почему?
Потому что over-satisfaction (Satisfaction > Importance) не создаёт opportunity для улучшения. Если пользователю outcome важен на 4, а текущее решение удовлетворяет на 8 — нет смысла инвестировать в «ещё лучшее» решение. Пользователь не заплатит за улучшение того, что и так хорошо.
Но Importance всегда учитывается: даже при высокой Satisfaction, если Importance = 10, Score = 10 (table stakes). Потому что важный outcome, даже удовлетворённый, нельзя игнорировать — его надо хотя бы поддерживать.
Визуализация: Opportunity Landscape
Все Desired Outcomes наносятся на двумерный график:
- X-ось: Satisfaction (1-10)
- Y-ось: Importance (1-10)
- Диагональ: линия «appropriately served» (Importance = Satisfaction)
Outcomes выше диагонали — underserved (opportunity). Ниже — overserved (potential simplification). Расстояние от диагонали = size of opportunity.
Этот график — ODI-эквивалент Strategy Canvas из Blue Ocean Strategy (Kim & Mauborgne, 2005). Но вместо субъективных «факторов конкуренции» — количественно измеренные outcomes.
Количественная сегментация через ODI
Одна из самых мощных (и недооценённых) возможностей ODI — сегментация на основе паттернов важности.
Традиционная сегментация: демография, размер компании, индустрия. ODI-сегментация: кластеры людей, которые считают важными одинаковые outcomes.
Процесс:
- Собрать Importance ratings для 80-150 outcomes от 180-600 респондентов
- Провести кластерный анализ (k-means или hierarchical clustering) по Importance vectors
- Получить 3-8 сегментов, каждый из которых имеет уникальный набор «важных» outcomes
- Для каждого сегмента рассчитать Opportunity Score отдельно
- Результат: каждый сегмент = уникальный Opportunity Landscape
Минимальная выборка: Улвик рекомендует 180-600 респондентов на сегмент для статистической валидности. Это делает ODI более ресурсоёмким, чем качественный JTBD (5-20 интервью), но и значительно более точным для приоритизации.
В Product DNA ODI-сегменты интегрируются в Strand 4 (Market Topology) через Segment Fit Score: каждый ODI-сегмент оценивается по 10 факторам привлекательности и получает числовой рейтинг A/B/C/D/X.
ODI и Product DNA: Demand Architecture integration
ODI — не альтернатива Product DNA. Это один из инструментов, который формирует данные для Strand 3 (Demand Architecture) и Strand 5C (Execution Criteria):
| ODI-компонент | Product DNA-эквивалент | Как интегрируется |
|---|---|---|
| Core Job | L2: Primary Demand | ODI формулирует job statement → Product DNA добавляет Core Drive (L0), Life Outcome (L1), и 8 Demand Types |
| Job Map (8 шагов) | L3: Demand Steps | ODI даёт шаги → Product DNA связывает их типизированными рёбрами (sequence, enables, conflicts) |
| Desired Outcomes | Strand 5C: Execution Criteria (Layer 1 — Discovery) | Desired Outcomes = критерии, по которым пользователь судит, хорошо ли выполнен каждый L3-шаг |
| Opportunity Score | Strand 5C: Layer 4 — Prioritization | Opportunity Score ранжирует outcomes → Product DNA добавляет Segment Fit × Frequency Weight |
| ODI-сегменты | Strand 4: Market Topology | ODI-кластеры → Segment Fit Score → A/B/C/D/X classification |
Product DNA расширение: Weighted Opportunity = Opportunity × Segment_Size × Segment_Fit_Score. Улвик взвешивает по importance. Product DNA взвешивает по importance × рыночная привлекательность × частота.
Case Study: Cordis Corporation (1992)
Первый коммерческий кейс ODI — и, возможно, самый впечатляющий.
Контекст:
Cordis Corporation — производитель ангиопластических баллонных катетеров. Доля рынка: ~1%. Рынок доминировали 3 крупных игрока. Cordis наняла Улвика для анализа.
ODI-процесс:
- Интервью с кардиологами (интервенционными). Выявлено 75 Desired Outcome Statements для core job «restore blood flow in coronary arteries»
- Опрос 200+ кардиологов: Importance и Satisfaction для каждого outcome
- Идентификация 14 underserved outcomes (Opportunity Score ≥ 12)
- Ключевой инсайт: самые underserved outcomes были связаны не с основной функцией (раскрытие стеноза), а с шагами Monitor и Modify (контроль позиции, адаптация при осложнениях)
Результат:
Cordis разработала новый катетер, фокусируясь на 14 underserved outcomes. Доля рынка выросла с ~1% до 20%+ за 2 года. Не потому что катетер «лучше раскрывал стеноз» (это все делали одинаково). А потому что он решал outcomes, которые конкуренты игнорировали: мониторинг позиции в реальном времени, адаптация при нестандартной анатомии, минимизация repetitive catheter exchanges.
Lesson: конкуренты оптимизировали step 5 (Execute). Cordis нашла opportunity в steps 6-7 (Monitor, Modify). Job Map + Opportunity Score показали то, что интуиция не видела.
ODI vs другие методы приоритизации
| Метод | Что измеряет | Размер выборки | Субъективность | Когда использовать |
|---|---|---|---|---|
| RICE | Reach × Impact × Confidence / Effort | Оценки команды | Высокая (Impact и Confidence — догадки) | Быстрая приоритизация внутри спринта |
| MoSCoW | Must/Should/Could/Won't | Мнение стейкхолдеров | Очень высокая (политика) | Scope negotiation с бизнесом |
| Kano | Тип качества (Must-be/Attractive/etc.) | 50-200 | Средняя (парные вопросы снижают bias) | Классификация фич по типу влияния |
| ODI | Importance + Satisfaction → Opportunity Score | 180-600 на сегмент | Низкая (количественные данные) | Стратегическая приоритизация и сегментация |
ODI — самый ресурсоёмкий метод, но и самый точный. Для стартапов на ранней стадии (pre-PMF) обычно достаточно качественного JTBD + Kano. Для scale-up и enterprise — ODI даёт количественную базу для многомиллионных инвестиционных решений.
Ограничения ODI: что формула не видит
- Latent Demands (L6): ODI спрашивает о существующих outcomes. Outcomes, которые пользователь не может представить (L6 Latent Demands в Product DNA), не попадают в опрос. Для их обнаружения нужен качественный research
- Emotional layer: Desired Outcome Statements intentionally объективны («minimize time», «increase likelihood»). Emotional Destination (Strand 1 Product DNA) — subjectiven и не покрывается ODI
- Temporal dynamics: Importance и Satisfaction — snapshot. Завтра Kano-decay превратит Attractive outcome в Must-be, и Opportunity Score изменится. ODI не моделирует эту динамику
- Competitive response: Если конкурент закроет underserved outcome через 6 месяцев — ваш Opportunity Score обнулится. ODI не учитывает скорость конкурентного ответа
Практическое применение: ODI за 4 недели
- Неделя 1: Качественные интервью (10-15). Цель — не статистика, а каталог Desired Outcomes. Job Map → 8 шагов → outcomes. Результат: 50-150 outcome statements
- Неделя 2: Дизайн опроса. Каждый outcome → 2 вопроса (Importance + Satisfaction). Рандомизация порядка. Пилот на 20 респондентах → чистка формулировок
- Неделя 3: Массовый опрос. 180-600 респондентов. Каналы: email-база, UserTesting, Respondent.io. Стоимость: $3000-15000 в зависимости от аудитории
- Неделя 4: Анализ. Opportunity Score для каждого outcome. Кластерный анализ → сегменты. Opportunity Landscape визуализация. Топ-10 underserved outcomes → product roadmap
Математика вместо интуиции
«Companies fail at innovation not because of a lack of ideas, but because they lack a process for identifying which outcomes are underserved» — Tony Ulwick, Jobs to Be Done: Theory to Practice (2016)
Улвик создал то, чего не хватало JTBD-мира: количественный метод. Desired Outcome Statements убирают субъективность формулировок. Opportunity Score убирает субъективность приоритизации. Job Map убирает субъективность в определении scope. А количественная сегментация убирает субъективность в выборе целевой аудитории.
Формула простая. Дисциплина — сложная. 50-150 outcomes, 180-600 респондентов, кластерный анализ. Это не «проведём 5 интервью и всё поймём». Это инженерный подход к пониманию рынка. И именно поэтому Cordis забрала 20% рынка у трёх доминирующих игроков.
Связанные статьи: Kano Model → Feature Priority Matrix → Product DNA vs JTBD → 19 Data Points
AI CPO рассчитывает Opportunity Score для каждого outcome вашего продукта автоматически. Попробуйте бесплатно → aicpo.ru