Как клиенты оценивают 'хорошо' и 'плохо': 6-слойная модель критериев исполнения

«Нормально» — это не критерий качества

Product manager спрашивает пользователя: «Как вам продукт?» Ответ: «Нормально.» Что это значит? Что продукт идеально решает задачу? Что он терпим? Что пользователь не нашёл альтернативу?

«Нормально» не содержит информации, потому что вопрос не содержит структуры. Клиент оценивает качество не абстрактно — он оценивает конкретные аспекты исполнения конкретной задачи. «Медленно генерируется отчёт» — это конкретный критерий (Speed). «Непонятно, как интерпретировать результат» — это конкретный критерий (Confidence). «Слишком много ручных шагов» — это конкретный критерий (Effort).

Product DNA Section 5C формализует процесс: от обнаружения критериев до непрерывного мониторинга — через 6 слоёв.

6 слоёв Execution Criteria Architecture

#	Слой	Вопрос, на который отвечает	Метод	Выход
1	Discovery	Что значит «хорошо выполнено»?	Ulwick desired outcome statements	50-150 outcomes per Primary Demand
2	Classification	Какого ТИПА этот стандарт?	Kano Model survey	Must-be / One-dimensional / Attractive tag
3	Meta-dimensions	В какой КАТЕГОРИИ качества?	SERVQUAL-adapted taxonomy	Category tag per outcome
4	Prioritization	Какие критерии важнее ВСЕГО?	ODI Opportunity Scoring	Opportunity landscape map
5	Operationalization	Как ПРОВЕРИТЬ?	BDD Given/When/Then + QFD mapping	Acceptance criteria per feature
6	Monitoring	Мы всё ещё соответствуем?	CSAT (outcome) + CES (process) per criterion	Ongoing quality tracking

Каждый слой строится на выходе предыдущего. Нельзя классифицировать (слой 2) без обнаружения (слой 1). Нельзя приоритизировать (слой 4) без классификации (слой 2) и категоризации (слой 3).

Слой 1: Discovery — Ulwick Desired Outcome Statements

Tony Ulwick (Outcome-Driven Innovation, 1991-2016) формализовал способ описания того, что клиент считает «хорошим исполнением». Формат:

{Направление} + {метрика} + {объект контроля} + {контекстуальный уточнитель}

Правила:

• Направление: всегда «minimize» или «increase». Никогда не субъективное «improve» или «better» — они не измеримы.
• Метрика: время, вероятность, количество, частота, стоимость — что-то, что можно измерить.
• Объект контроля: что именно клиент пытается изменить.
• Контекст: когда, где, при каких условиях.

Примеры:

Плохо сформулировано	Хорошо (Ulwick format)
«Быстрее делать отчёты»	«Minimize the time it takes to generate a competitive analysis report from collected data»
«Точнее определять сегменты»	«Increase the likelihood that segment classification reflects actual buyer behavior patterns»
«Проще добавлять данные»	«Minimize the number of manual steps required to import interview transcript into the system»
«Лучше визуализация»	«Minimize the effort required to share artifact with non-technical stakeholders in a presentable format»

Объём: для каждого Primary Demand (L2 в Product DNA Demand Architecture) нужно 50-150 desired outcome statements, организованных по Demand Steps (L3). Это кажется избыточным — до тех пор, пока вы не поймёте, что каждый outcome = один потенциальный competitive differentiator.

Как собирать outcomes

1. Возьмите одну Primary Demand (L2) и разбейте на Demand Steps (L3)
2. Для каждого Demand Step проведите 5-10 интервью с вопросом: «Когда вы делаете [шаг], что может пойти не так? Что занимает больше всего времени? Что разочаровывает?»
3. Каждый ответ переформулируйте в Ulwick format (direction + metric + object + context)
4. Deduplicate и группируйте — обычно сходится к 50-150 уникальным outcomes

Слой 2: Classification — Kano Model (1984)

Noriaki Kano предложил классификацию, которая объясняет, почему некоторые функции вызывают восторг, а другие — только раздражение при отсутствии:

Категория Kano	Если реализовано	Если НЕ реализовано	Пример
Must-be (базовые)	Нейтральная реакция — «ну, это же очевидно»	Сильное неудовлетворение — «это вообще как?!»	Продукт загружается за <3 секунды. Данные не теряются. Авторизация работает.
One-dimensional (линейные)	Удовлетворение пропорционально реализации	Неудовлетворение пропорционально отсутствию	Скорость генерации отчёта: чем быстрее, тем довольнее. Чем медленнее, тем злее.
Attractive (восхищающие)	Восторг — «вау, я не ожидал!»	Нейтральная реакция — не знал, что это возможно	AI автоматически связывает факты из разных интервью в паттерн. Неожиданно, но ценно.

Temporal decay: A → O → M

Критический инсайт Kano: категории деградируют со временем. То, что вчера было Attractive (восторг), завтра становится One-dimensional (ожидание), послезавтра — Must-be (минимум).

Реальный пример: в 2015 году real-time collaboration в документах (Google Docs) была Attractive. В 2020 — One-dimensional (Notion, Coda тоже это делали). В 2025 — Must-be (любой инструмент без real-time collaboration воспринимается как сломанный).

Практическое следствие: регулярно пересматривайте Kano-классификацию. Функции, которые год назад вызывали восторг, сейчас могут быть table stakes.

Как проводить Kano survey

Для каждого outcome — пара вопросов:

1. Functional: «Если продукт [делает X], как вы к этому отнесётесь?» (Нравится / Ожидаю / Нейтрально / Терплю / Не нравится)
2. Dysfunctional: «Если продукт НЕ [делает X], как вы к этому отнесётесь?» (те же варианты)

Комбинация ответов определяет категорию. Например: «Нравится» + «Не нравится» = One-dimensional. «Нравится» + «Нейтрально» = Attractive. «Нейтрально» + «Не нравится» = Must-be.

Слой 3: Meta-dimensions — 6 измерений качества

Parasuraman, Zeithaml и Berry (1985/1988) создали SERVQUAL — модель 5 измерений качества сервиса. Product DNA адаптирует её для продуктовых критериев:

#	Измерение	Вопрос	Пример outcome
QD1	Accuracy	Правильный ли результат?	«Increase the likelihood that extracted facts match interview content»
QD2	Speed	Как быстро?	«Minimize the time from data upload to first insight»
QD3	Confidence	Можно ли доверять результату?	«Increase the likelihood that recommendations are evidence-based»
QD4	Fit	Подходит ли под мой контекст?	«Minimize irrelevant recommendations for my industry/segment»
QD5	Presentation	Удобно ли использовать результат?	«Minimize the effort to share artifact with stakeholders»
QD6	Effort	Сколько усилий от меня потребовалось?	«Minimize manual data entry during onboarding»

Каждый desired outcome (из слоя 1) получает тег одного или нескольких meta-dimensions. Это позволяет анализировать, в каком аспекте качества продукт силён, а в каком — слаб.

Типичный паттерн для AI-продуктов: высокий Speed (QD2) + низкий Accuracy (QD1) + очень низкий Confidence (QD3). Пользователь получает результат быстро, но не уверен в его правильности. Приоритет: поднять Accuracy и Confidence, а не ускорять Speed ещё больше.

Слой 4: Prioritization — ODI Opportunity Scoring

Tony Ulwick разработал формулу, которая объективно определяет, какие outcomes представляют наибольшую возможность:

Opportunity Score = Importance + max(Importance - Satisfaction, 0)

Где:

• Importance — насколько критичен этот outcome для клиента (survey, шкала 1-10)
• Satisfaction — насколько хорошо текущие решения удовлетворяют этот outcome (survey, шкала 1-10)

Интерпретация:

Opportunity Score	Статус	Действие
≥ 12	Underserved — сильная возможность	Build now. Клиенты считают это важным, но ни одно решение не справляется
10-12	Appropriately served — table stakes	Maintain. Не дифференциатор, но необходимость
< 10	Overserved — возможность упрощения	Reduce или eliminate. Клиенты не ценят текущий уровень — можно упростить

Kano overlay для ODI

Комбинирование ODI scoring с Kano classification даёт более точную приоритизацию:

• Must-be + Satisfaction < 4 → CRITICAL. Базовое ожидание не выполнено. Это не opportunity — это системная ошибка. Чинить немедленно.
• One-dimensional + high Opportunity Score → PRIMARY build target. Линейная зависимость: чем лучше сделаете, тем довольнее клиент. Максимальный ROI на усилия.
• Attractive + any score → Не появится в опросах (клиенты не знают, что это возможно). Требует qualitative discovery: наблюдение, customer development, competitor analysis.

Минимальная выборка: Ulwick рекомендует n ≥ 180 респондентов на сегмент для статистической валидности ODI scoring. Для ранних стадий (pre-PMF) достаточно 30-50 — но с пометкой, что confidence ниже.

Слой 5: Operationalization — BDD Given/When/Then

Dan North (2006) предложил Behavior-Driven Development как способ перевести бизнес-требования в проверяемые спецификации. Product DNA использует BDD для операционализации desired outcomes:

Desired Outcome	BDD Specification
«Minimize the time it takes to generate a competitive analysis»	Given project has ≥ 10 facts collected When user clicks "Generate Competitive Analysis" Then artifact is generated within 30 seconds And artifact contains ≥ 5 competitive dimensions
«Increase the likelihood that extracted facts match interview content»	Given user sends message with factual content When FactExtractorService processes the message Then ≥ 80% of extracted facts are semantically accurate And no hallucinated facts appear in output
«Minimize manual data entry during onboarding»	Given new user creates first project When user describes their niche in 2-3 sentences Then system auto-populates project context And user enters ≤ 3 manual inputs to start working

Каждая BDD-спецификация — это acceptance criterion для разработки. Инженер видит не абстрактное «сделать быстрее», а конкретное «≤ 30 секунд, ≥ 5 dimensions». QA проверяет не «работает ли», а «соответствует ли Given/When/Then».

QFD mapping: outcome → feature → spec

Quality Function Deployment (Akao, 1990) — методика трансляции клиентских требований в технические характеристики. В Product DNA:

1. Outcome (что клиент хочет) → Feature (что мы строим) → Spec (как мы проверяем)
2. Одна feature может покрывать несколько outcomes
3. Один outcome может требовать несколько features
4. Матрица QFD показывает coverage: какие outcomes покрыты, какие — нет

Слой 6: Monitoring — CSAT + CES per criterion

После запуска нужен непрерывный мониторинг. Два инструмента:

Инструмент	Что измеряет	Формат	Когда использовать
CSAT (Customer Satisfaction Score)	Удовлетворённость результатом (outcome quality)	«Насколько вы довольны [конкретным outcome]?» (1-5 или 1-7)	После завершения core action. Привязан к конкретному outcome, а не к продукту в целом
CES (Customer Effort Score)	Усилие, затраченное на процесс (execution quality)	«Насколько легко было [выполнить задачу]?» (1-7)	После каждого Demand Step (L3). Dixon et al. (2010) доказали: CES — лучший предиктор loyalty, чем NPS

Dixon, Freeman и Toman (2010) в исследовании для HBR показали, что снижение усилий клиента (CES) — более сильный предиктор лояльности, чем повышение удовлетворения (CSAT). Проще говоря: сделать проще важнее, чем сделать приятнее.

Пример: PM-инструмент — 15 outcomes через все 6 слоёв

Рассмотрим конкретный пример для инструмента управления проектами. Primary Demand (L2): «Когда начинается новый спринт, спланировать работу команды так, чтобы приоритетные задачи были выполнены в срок.»

Слой 1: Discovery — 15 outcomes (выборка)

#	Desired Outcome (Ulwick format)
1	Minimize the time it takes to prioritize backlog items for the upcoming sprint
2	Increase the likelihood that sprint capacity matches actual team availability
3	Minimize the number of tasks that carry over to the next sprint
4	Increase the likelihood that dependencies between tasks are identified before sprint start
5	Minimize the effort to communicate sprint plan to stakeholders
6	Increase the likelihood that the most critical bugs are addressed in each sprint
7	Minimize the time spent in sprint planning meetings
8	Increase the likelihood that team members understand their assigned tasks without clarification
9	Minimize the number of mid-sprint scope changes
10	Increase the accuracy of effort estimates for planned tasks
11	Minimize the time to identify blocked tasks during sprint execution
12	Increase the likelihood that sprint retrospective insights are actionable
13	Minimize the effort to track sprint progress in real-time
14	Increase the confidence that velocity trends reflect actual team performance
15	Minimize the number of manual status updates required from team members

Слой 2-3: Classification + Meta-dimensions

#	Kano	Meta-dimension	Комментарий
1	One-dimensional	Speed	Чем быстрее приоритизация, тем довольнее. Прямая зависимость
2	Must-be	Accuracy	Если capacity не совпадает — sprint fails. Базовое ожидание
3	One-dimensional	Accuracy	Carryover — прямой индикатор качества планирования
4	Attractive → One-dimensional	Accuracy	Автоматическое определение зависимостей — пока ещё wow, скоро будет ожидание
5	One-dimensional	Effort, Presentation	Чем проще поделиться планом, тем довольнее
8	Must-be	Fit	Если задачи непонятны без доп. вопросов — базовая ошибка UX
10	Attractive	Accuracy, Confidence	AI-based estimation — пока wow-фактор
11	One-dimensional	Speed	Real-time blocker detection — линейная ценность
15	Must-be → killer	Effort	Ручные обновления статуса — главная боль команд. Автоматизация = must

Слой 4: ODI Prioritization

#	Importance	Satisfaction	Opportunity Score	Приоритет
1 (prioritize backlog)	9	4	9 + 5 = 14	Underserved — build now
2 (capacity match)	8	6	8 + 2 = 10	Table stakes — maintain
3 (minimize carryover)	9	3	9 + 6 = 15	Extremely underserved — top priority
4 (dependencies)	7	3	7 + 4 = 11	Underserved — good opportunity
10 (estimate accuracy)	8	2	8 + 6 = 14	Underserved — build now
15 (minimize manual updates)	9	2	9 + 7 = 16	Extremely underserved — top priority

Результат: #15 (минимизация ручных обновлений) и #3 (сокращение carryover) — два highest-opportunity outcomes. Это конкретные targets для дифференциации. Не «сделать лучше Jira», а «решить две конкретные underserved потребности».

Слой 5: Operationalization (примеры)

Outcome #15 → BDD:

Given team member moves task to "In Progress" in the board
When task status changes
Then sprint dashboard updates automatically within 5 seconds
And no additional status update action is required from team member
And stakeholders see updated progress without refreshing page

Outcome #3 → BDD:

Given sprint contains 20 tasks with estimated effort
When system detects velocity vs remaining work mismatch at sprint midpoint
Then system alerts PM with specific tasks at risk of carryover
And suggests re-prioritization options ranked by impact

Слой 6: Monitoring

После релиза — per-outcome CSAT + CES:

• Outcome #15: CES survey после каждого sprint → «Насколько легко было отслеживать прогресс?» (1-7)
• Outcome #3: CSAT survey в конце спринта → «Насколько вы довольны тем, как система помогла завершить запланированные задачи?» (1-5)

Практическое применение: пошаговый процесс

1. Определите Primary Demand (L2) и разбейте на Demand Steps (L3)
2. Для каждого L3 соберите outcomes (5-10 интервью, переформулируйте в Ulwick format)
3. Проведите Kano survey (минимум 30 респондентов) → тегируйте каждый outcome
4. Присвойте meta-dimensions (QD1-QD6) каждому outcome
5. Проведите ODI survey (Importance + Satisfaction) → рассчитайте Opportunity Scores
6. Для top-3 outcomes напишите BDD specs
7. После релиза — настройте CSAT + CES мониторинг per outcome

Связанные материалы: 7 слоёв Product DNA · 26 Evidence Points → 26 Evidence Points · Feature Priority Matrix · ABCDX-сегментация

AI CPO автоматически формулирует desired outcomes из ваших данных и рассчитывает Opportunity Scores → aicpo.ru