Почему продукт не продаётся: доказательный postmortem

Почему честный разбор начинается с отказа от красивой истории

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

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

Входной шлюз: что нужно получить до начала кейса

Группа	Минимальный пакет	Что проверяет редакция
Продукт	Версия, предложение, цена, ограничения, даты запуска и изменений	Что именно продавалось в каждый период
Воронка	События аналитики, определения, часовой пояс, охват, сырые агрегаты	Сопоставимы ли числители и знаменатели
Коммерция	CRM, заказы, оплаты, возвраты, отмены, причины потерь	Отличается ли заявка от полученного дохода
Привлечение	Каналы, расходы, креативы, атрибуция, посадочные страницы	Какие воздействия можно связать с периодами
Качественные данные	Реальные интервью и обращения с согласиями и контекстом	Что пользователи делали и говорили фактически
Хронология	Решения команды, изменения продукта, сбои, поставки, поддержка	Что предшествовало изменению показателей
Права	Владение материалами, режим конфиденциальности, разрешение на публикацию	Что можно цитировать и раскрывать

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

Шаг 1. Дайте проверяемое определение провала

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

Запишите плановый критерий так, как он существовал до результата. Если его не было, не конструируйте задним числом «обещанный KPI». Пометьте, что исходный критерий отсутствовал, и используйте нейтральное описание наблюдаемого результата. Отдельно укажите, кто принимал решение об остановке и какие ограничения — деньги, срок, риск, договор — на него влияли.

Шаг 2. Соберите хронологию без причинных ярлыков

Лента событий начинается до запуска и заканчивается после решения. В неё входят изменения цены, аудитории, предложения, каналов, поставки, команды, аналитики и продукта. Запись «после редизайна продажи упали» пока является последовательностью во времени, а не доказательством причины. Каждое событие получает источник и уровень уверенности.

Дата/период	Наблюдаемое событие	Источник	Что изменилось	Уверенность
[дата]	[факт без оценки]	[выгрузка/документ/интервью]	[предложение, канал, продукт, операция]	A / B / C
[дата]	[факт без оценки]	[первичный артефакт]	[измеримый объект]	A / B / C
[дата]	[решение команды]	[протокол или подтверждённое интервью]	[ожидаемый механизм]	A / B / C

Уровень A означает первичный датированный артефакт, B — согласованные косвенные источники, C — воспоминание или неподтверждённую интерпретацию. Категория не делает факт истинным автоматически, но показывает читателю предел уверенности. Конфликтующие версии остаются рядом до разрешения; неудобная запись не удаляется ради связного сюжета.

Шаг 3. Постройте воронку с согласованными знаменателями

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

Переход	Числитель	Знаменатель	Проверка
Увидел → заинтересовался	[событие намерения]	[валидный охват]	Дедупликация и боты
Заинтересовался → начал действие	[начало заявки/корзины]	[одна когорта интереса]	Единые определения событий
Начал → оплатил	[подтверждённая оплата]	[валидное начало]	Отмены, тесты, дубли
Оплатил → получил ценность	[активация/доставка]	[оплаченная когорта]	Возвраты и недоставка
Получил → остался	[повтор/удержание]	[дозревшая когорта]	Достаточное окно наблюдения

Если событие изменило определение во время проекта, ряды разделяются. Если часть канала не размечена, это ограничение, а не нулевая эффективность. Если CRM и платежи расходятся, сначала проводится сверка. Разбор не должен компенсировать плохую телеметрию точными на вид процентами.

Шаг 4. Проверьте шесть зон вместо одного виновника

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

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

Шаг 5. Матрица гипотез и опровергающих фактов

Гипотеза	Если верна, ожидаем	Факты за	Факты против	Следующая проверка
[H1]	[наблюдаемый паттерн]	[ссылки на артефакты]	[несовместимые наблюдения]	[безопасный тест]
[H2]	[другой паттерн]	[артефакты]	[контрдоказательства]	[проверка с владельцем]
[H3]	[альтернатива]	[артефакты]	[контрдоказательства]	[минимальное новое наблюдение]

Для каждой гипотезы задайте механизм: как именно фактор мог изменить результат. Затем ищите не только подтверждение, но и данные, при которых гипотеза должна быть отвергнута. Если несколько объяснений одинаково совместимы с фактами, итогом остаётся неопределённость. Нельзя превращать её в уверенную причину ради сильного заголовка.

Причина должна объяснять наблюдаемый паттерн, предшествовать ему, выдерживать альтернативы и опираться на надёжные источники. Симптом — это то, что увидели: низкая оплата, возвраты, длинная очередь. Условие — контекст: сезон, ограниченный бюджет, один поставщик. Действие — решение команды. Эти категории полезно держать раздельно.

Шаг 6. Разберите решения без поиска виноватого

Postmortem оценивает доступную на тот момент информацию, ограничения и систему принятия решений. Формулировка «менеджер не понял рынок» почти не помогает. Полезнее: не было владельца исследования, критерий запуска не требовал подтверждённых интервью, а отрицательные сигналы не попадали на еженедельный обзор. Такое описание позволяет изменить процесс.

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

Шаг 7. Превратите выводы в проверяемые изменения

Вывод	Изменение	Владелец	Срок	Доказательство эффекта
[подтверждённая причина/условие]	[конкретный контроль или эксперимент]	[роль]	[дата]	[метрика и источник]
[пробел данных]	[новое событие или сверка]	[роль]	[дата]	[протокол качества]
[ошибка решения]	[изменение gate или review]	[роль]	[дата]	[следующий кейс применения]

Действие «лучше изучать рынок» непроверяемо. Укажите, какой артефакт обязателен перед следующим запуском: пять наблюдений по определённому сегменту, сверенная воронка, протокол ценового теста или критерий остановки. Для каждого действия нужен владелец и дата повторной оценки. Иначе postmortem останется литературой.

Шаблон итогового документа

Статус доказательств и право публикации.
Нейтральное описание продукта, версии, периода и решения.
Определение провала и исходный критерий успеха.
Хронология с источниками и уверенностью.
Согласованная воронка и ограничения данных.
Конкурирующие гипотезы с опровергающими фактами.
Причины, условия и симптомы раздельно.
Решения команды в контексте доступной информации.
Корректирующие действия, владельцы и проверка.
Неразрешённые конфликты, редакционные вырезки и юридическая граница.

Редакционная и правовая проверка перед публикацией

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

Числа в тексте должны вести к source registry: выгрузка, период, определение и способ расчёта. Цитата требует реального источника и согласия, если оно необходимо. Снимок экрана не заменяет проверку системы. Анонимизация должна исключать повторную идентификацию через сочетание дат, отрасли, суммы и редких событий.

Что можно сделать сейчас

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