Не готовые ответы на любой случай, а способы задавать вопросы, связывать наблюдения и выбирать, что проверить дальше.
Этот индекс собран из моей практики и письменных интервью. Последовательность зависит от ситуации: иногда начинаю с пути пользователя, иногда — с аналитики или предпосылки, заложенной в продукт.
Начинаю CJM с события, после которого человек стал искать решение. Затем восстанавливаю запрос, точки контакта, действия и причины выбора.
Граница: процедура организует исследование и обсуждение. Она сама по себе не доказывает причину и не гарантирует бизнес-результат.
Отчёт показывает число, но не всегда объясняет причину. Сверяю источники, путь пользователя, конверсии, периоды и усилия.
Граница: процедура организует исследование и обсуждение. Она сама по себе не доказывает причину и не гарантирует бизнес-результат.
Ищу возможность взглянуть на задачу через другую отрасль или шаг продуктовой архитектуры. Аналогия помогает поставить вопрос, но не доказывает вывод.
Граница: процедура организует исследование и обсуждение. Она сама по себе не доказывает причину и не гарантирует бизнес-результат.
Сначала опираюсь на то, что собеседнику понятно, затем добавляю одну новую связь. 90/10 — личный ориентир объяснения, не научная норма.
Граница: процедура организует исследование и обсуждение. Она сама по себе не доказывает причину и не гарантирует бизнес-результат.
Фиксирую выбор, его основания, следующий тест и наблюдение, при котором команда вернётся к решению.
Граница: процедура организует исследование и обсуждение. Она сама по себе не доказывает причину и не гарантирует бизнес-результат.
Ищу, чего человеку не хватает для решения: нужного сценария, сведений или возможности изучить продукт.
Граница: процедура организует исследование и обсуждение. Она сама по себе не доказывает причину и не гарантирует бизнес-результат.
В PaperSpell исследовал, какой следующий полезный шаг может появиться после первого документа. Влияние пилота на удержание пока не подтверждено.
Контекст продуктовой гипотезы →
Граница: процедура организует исследование и обсуждение. Она сама по себе не доказывает причину и не гарантирует бизнес-результат.
В одном e-commerce проекте команда вместе с клиентом около двух недель пыталась разобраться с логикой динамических цен и скидок. Я предложил отступить на шаг и посмотреть на архитектуру решения. Выяснилось, что ограничение было заложено при планировании блока и мешало следующим доработкам.
Этот эпизод не означает, что каждый сбой нужно искать в архитектуре. Он показывает, почему после долгого безрезультатного исправления полезно проверить исходную постановку.
Как проверять альтернативное объяснение → · Вопросы о выборе и стратегии →
Это редакционное обобщение интервью о практике, а не обязательная последовательность каждого проекта.