Управление продуктом.
От проблемы до проверенного выпуска.

00 · Карточка продукта

Сначала собрать продукт в одном месте

Разрозненные страницы о функциях, ценах и планах не дают команде общей версии правды.

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

Учебный пример: Производитель. Продуктовый контур включает не только сам товар, но и структуру каталога, экономику единицы (полная себестоимость с доставкой, таможней и хранением — отпускная цена) и каналы продаж. Если базовая товарная единица — сменный блок, а не устройство, то разовая продажа не окупает привлечение. Архитектура каталога пересобирается: малые и семейные наборы, подписка. Без единой карточки команда тратит бюджет на разовые продажи с убытком.

Семь разделов карточки

1. Клиент и задача. Проверяемая группа, событие поиска, проблема, нынешняя альтернатива, участники решения, для кого продукт не предназначен.
2. Обещание и доказательства. Какое изменение получает клиент, чем продукт отличается, какие факты это подтверждают, какие условия и исключения действуют.
3. Принципы и основные сценарии. Какие правила нельзя нарушать; кто и в какой последовательности выполняет главные задачи; где участвует человек, автоматизация и поддержка.
4. Возможности и состояние. Для каждой функции: выпущена и проверена, выпущена с ограничением, разрабатывается, исследуется или отклонена. Рядом — версия, источник, владелец и дата проверки.
5. Показатели. Главный результат продукта, начало получения пользы, удержание, время до первой пользы и использование ключевых возможностей. У каждого показателя есть формула, единица, период, источник, исключения и защитные показатели.
6. Деньги и эксплуатация. Тарифы и правила их применения, выручка и прямые затраты, поддержка, интеграции, данные, безопасность, доступность, зависимость от поставщиков и способ прекращения работы.
7. Текущие инициативы. Проблема, исходный уровень, цель, доступная мощность, ответственный, состояние, зависимости, ближайшее доказательство и дата решения — продолжить, изменить, выпустить или остановить.

Услугу можно упаковать как продукт, только если результат повторяем

Большая папка файлов не является продуктом. Продукт появляется там, где у клиента есть конкретный результат, понятный порядок получения пользы, критерии готовности и предсказуемая поддержка. Если каждый раз всё собирается заново, это всё ещё индивидуальная услуга — её можно продавать честно, но не стоит обещать как готовую систему.

Как собрать и поддерживать

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

01 · Проблема

Не начинать с выбранного решения

Фраза «нужно приложение, бот или ИИ» описывает форму, а не задачу человека.

Как отделить проблему от любимой идеи

1. Замените название функции на наблюдаемую ситуацию человека.
2. Восстановите, что он делает сейчас и почему нынешний способ его не устраивает.
3. Проверьте частоту, тяжесть и число людей, которые действительно могут столкнуться с задачей.
4. Свяжите последствие с поведением или деньгами, не придумывая причинность.
5. Запишите другие объяснения и случаи, когда проблема не возникает.
6. Отложите выбор решения до главы об альтернативах.

Учебный пример: Производитель. «Нужно продавать больше фильтров для душа» — готовая форма. Проблема звучит так: «Вода вымывает искусственный пигмент, разрушает кератин и сушит кожу из-за остаточного хлора». Клиент тратит сотни единиц валюты на уход в салоне, а затем смывает его агрессивной водой. Мы продаём не устройство, а нулевой шаг ухода за волосами. Фильтр защищает репутацию мастера и результат окрашивания.

02 · Исследование

Собрать поведение, а не голоса за новую функцию

Вопрос «пользовались бы?» создаёт намерение без цены и контекста.

1. Выбрать реальное событие и людей, которые его пережили.
2. Спросить о последнем случае, действиях, обходных путях, цене и результате.
3. Собрать данные использования, обращения в поддержку и причины несостоявшихся продаж.
4. Хранить ссылки на исходные фрагменты и противоречия.
5. Вымышленные портреты использовать только для подготовки вопросов.

Соберите четыре вида свидетельств

До синтеза задайте правило включения, сохраните состав выборки, дословные фрагменты, отрицательные случаи и версию продукта. Пять упоминаний не превращаются в «100% пользователей». Частота запроса не равна охвату, тяжести, готовности платить или приоритету разработки.

От одного интервью к проверяемой продуктовой гипотезе

1. Сохраните единичный случай. Обезличьте имя и компанию; зафиксируйте роль, событие, последовательность действий, нынешний обходной путь, задержку, последствие и дословные фрагменты с адресами.
2. Сформулируйте наблюдение узко. Например: «редкий участник процесса уходит в привычный мессенджер, потому что там быстрее выполнить одно действие». Это ещё не доказательство массовой потребности.
3. Соберите таблицу свидетельств. Для каждого разговора сохраните группу, контекст, действие, препятствие, желаемый результат, противоречие и связь с поведением.
4. Проверьте повторяемость. Посчитайте случаи только среди людей, которые могли столкнуться с задачей. Найдите тех, кому нынешний путь подходит или кто решает задачу иначе.
5. Сопоставьте со следами поведения. Входы в систему, время до действия, пропущенные ответы, переходы в другой канал, обращения, потерянные случаи и возврат.
6. Оцените влияние. Какая задержка, потеря качества, нагрузка, отказ, уход или деньги действительно наблюдались? Не приписывайте результат конкретной причине без проверки.
7. Сформулируйте несколько решений. Это может быть контекстная ссылка, более понятное уведомление, упрощённый экран, мобильный путь, изменение процесса или помощь человека. Интервью не выбирает функцию автоматически.
8. Проведите малую проверку. Выберите группу, основной и защитные показатели, срок, условие остановки и действие после результата.

Исследование ищет не подтверждение идеи, а причину от неё отказаться

Разговор, в котором автор рассказывает о задуманном и спрашивает мнение, почти всегда заканчивается одобрением: собеседнику неловко возражать, и он ничем не рискует.

Полезный разговор устроен наоборот — человек рассказывает о своём последнем случае, а автор молчит о замысле до конца встречи. Это неудобно и это единственное, что даёт пригодный материал.

Обходной путь ценнее жалобы

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

Там, где обхода нет, задача либо не важна, либо терпима. Это самая быстрая проверка серьёзности проблемы из всех доступных.

Тех, кому нынешний порядок подходит, ищут специально

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

Их отсутствие в материале — не признак единодушия, а признак того, что их не искали. Отрицательные случаи сохраняют наравне с подтверждающими.

Исследование без названного заранее правила прекращения продолжается бесконечно

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

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

Проверяйте арифметику ярких цитат до отчёта. Полтора часа — заметная потеря рабочего времени, но это не треть обычного восьмичасового дня. Неточная метафора участника сохраняется как дословная речь, а расчёт влияния делается отдельно по зафиксированному количеству случаев и времени.

Как собрать доказательную карту проблем из разных источников

Разговоры, обращения, опрос и продуктовые события имеют разные основания. Их нельзя сложить в одну колонку процентов. Для каждой строки сохраните собственный знаменатель и право на вывод.

Учебный пример: B2B сегмент и скрытая мотивация. В исследовании каналов выяснилось, что продукт продаётся через салоны красоты, но аргумент «полезно вашим клиентам» — слаб. Наблюдение: мастера теряют повторные записи, потому что вода портит окрашивание. Решение: дать мастеру бесплатный набор для личного использования (чтобы сам почувствовал разницу), полка на ресепшене для импульсной покупки и карта с кодом «ваш мастер рекомендует» для пассивного дохода. То же с клиниками по пересадке волос — наш продукт становится нулевым шагом их послеоперационного протокола для защиты результата.

03 · Альтернативы

Проверить самый дешёвый способ выполнить задачу

Отдельное приложение и встроенная модель часто не являются первым разумным вариантом.

1. Опишите вариант «ничего не строить» и стоимость нынешнего порядка.
2. Найдите изменение процесса, которое устраняет причину без новой системы.
3. Сделайте ручную услугу или простой образец и проверьте, нужен ли результат.
4. Только затем сравнивайте автоматизацию, готовый внешний продукт, встраивание и собственную разработку.
5. Для каждого варианта посчитайте не только создание, но и поддержку, обучение, ошибки, данные, прекращение использования и переход на замену.

Сначала выясняют, почему задача вообще возникает

Большая часть повторяющейся ручной работы существует не потому, что её нельзя автоматизировать, а потому, что раньше кто-то принял решение, создавшее эту работу. Устранение причины снимает задачу целиком, а не ускоряет её.

Поэтому разбор начинают не с выбора инструмента, а с вопроса, что произойдёт, если перестать делать это совсем. Иногда ответ — ничего, и это самый дешёвый из всех вариантов.

Ручное выполнение — законный первый вариант, а не временный костыль

Выполнить задачу руками для небольшого числа случаев позволяет увидеть настоящие правила, исключения и объём — то, что при проектировании обычно угадывают.

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

Постоянная стоимость решает чаще, чем стоимость создания

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

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

Стоимость выхода оценивают до входа, потому что потом её не с чем сравнивать

Любое решение когда-нибудь придётся заменить. Вопрос не в том, случится ли это, а в том, сколько будет стоить уход и что придётся оставить.

Практически это три вещи: можно ли забрать данные в пригодном виде, кому принадлежат настройки и наработки, и сколько времени займёт переход. Ответы легко получить до договора и почти невозможно — после.

Зависимость от поставщика возникает через данные и привычки, а не через договор

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

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

Правила и разбор неструктурированного материала — разные задачи, и смешивать их дорого

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

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

Вариант, требующий изменения чужого поведения, считают дороже на цену этого изменения

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

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

Сравнение имеет смысл только при одинаковых критериях и одинаковой честности оценок

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

Помогает простое правило: каждый вариант описывает тот, кто в нём заинтересован, а критерии и их формулировки фиксируют до сбора оценок.

Решить: сделать самим, взять готовое или начать с временного поставщика

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

1. Зафиксируйте вопрос решения, причину срочности, владельца и дату. Угроза ухода клиента, ход конкурента и срок инвестора остаются утверждениями до проверки.
2. Соберите реальные варианты: ручной порядок, улучшение процесса, готовое решение, собственная разработка и поэтапное сочетание.
3. Для каждого варианта посчитайте срок до полезного результата, полную стоимость владения, доступных людей, зависимости, цену ошибки и условия прекращения.
4. Проверьте поставщика: качество на контрольных примерах, защита, договор, место обработки, доступ, хранение, удаление, обучение на переданных данных, изменение условий, выгрузка и помощь при выходе.
5. Если выбран поэтапный путь, отделите продукт от конкретного поставщика: единый внутренний интерфейс, журнал версий, переносимый формат данных, запасной ручной порядок и дата решения о продолжении.
6. Начните с ограниченной группы. Заранее определите основной и защитные показатели, минимально полезный эффект, срок наблюдения, условие остановки, способ возврата и человека, который принимает решение после проверки.

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

04 · Краткое описание продукта

Связать проблему, решение и риск

Одна страница должна позволить отклонить идею до дорогой разработки.

Одна страница — ограничение, а не пожелание к объёму

Требование уместить решение на странице заставляет отделить подтверждённое от правдоподобного. Длинный документ этого не требует и потому позволяет спрятать пробел за объяснением.

Если страница не заполняется, это результат: значит, идея ещё не описана достаточно, чтобы по ней принимать решение. Расширять шаблон в этот момент — худшее из возможных действий.

Документ пишут ради отказа, а не ради согласования

Бриф, написанный для того, чтобы получить одобрение, устроен как аргумент: в нём сильные стороны и мягкие оговорки. Проверить по такому тексту ничего нельзя.

Полезный бриф устроен иначе — он облегчает отклонение идеи. Самая ценная страница та, после которой работу не начали, потому что дорогая разработка не состоялась.

Допущение, не помеченное допущением, через месяц становится фактом

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

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

Сначала называют требуемое решение и человека, который его принимает

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

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

Вариант «ничего не менять» — обязательная строка, а не формальность

Без него сравнение идёт между предложенной работой и воображаемым идеалом, и предложение всегда выигрывает. Стоимость бездействия при этом не оценивается.

Описание того, что произойдёт при сохранении нынешнего порядка, иногда показывает, что проблема терпимая. Это законный исход разбора, а не его провал.

Что осознанно не входит в версию — самая полезная строка документа

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

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

Защитный показатель нужен там, где основной можно улучшить вредным способом

Почти любая цель достижима за счёт чего-то другого: скорость — за счёт качества, объём обращений — за счёт их пригодности, экономия — за счёт нагрузки на людей.

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

Условие остановки формулируют до начала, потому что потом его формулировать некому

Запущенная работа создаёт собственную инерцию: вложенное время становится доводом за продолжение независимо от результатов.

Признак, при котором работу прекращают, записанный до старта, — единственная защита от этого. Он должен быть наблюдаемым, а не оценочным, иначе спор пойдёт о толковании.

Согласование с владельцем данных и правовой проверкой ставят до разработки, а не перед выпуском

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

Тот же вопрос, заданный на странице описания, стоит одного разговора. Ранняя проверка не замедляет работу — она перемещает неизбежное обсуждение туда, где оно дёшево.

Описание живёт ровно до следующего изменения фактов

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

Дата пересмотра и признак, при котором пересмотр происходит раньше срока, стоят двух строк. Без них документ незаметно превращается из рабочего в исторический.

Одобрение помощников не заменяет согласия тех, кто отвечает за работу

Спросить проще всего у доброжелательных людей, и они почти всегда поддерживают идею: им не придётся менять свой порядок работы.

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

«Конкурент уже сделал» — не довод, а повод выяснить основание

Чужое решение видно снаружи, а его причины, ограничения и итог — нет. Копирование переносит к себе чужие допущения вместе с чужими ошибками.

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

Как пользоваться одной страницей

1. Автор собирает только подтверждённое и явно маркирует допущения.
2. Исследователь проверяет проблему и связь с исходными наблюдениями.
3. Разработчик или подрядчик оценивает сложность, зависимости и эксплуатацию.
4. Безопасность, юрист и владелец данных проверяют затронутые права и риски.
5. Коммерческий владелец сравнивает варианты, стоимость и доступную мощность.
6. Человек с полномочиями принимает одно решение: исследовать дальше, проверить малым способом, строить, купить или отказаться.

Учебный пример: Трекер первых 30 дней. Запуск начинается с перевода допущений в подтверждённые факты. В первую неделю устанавливается правило блокирующего приоритета: критические задачи (расчёт полной себестоимости, выгрузка истории продаж за 12 месяцев) блокируют все остальные активности. Если задача сорвана — работа останавливается до её решения. Без реальной стоимости единицы товара и понимания маржи нельзя запускать платный трафик. План первых 30 дней требует, чтобы юнит-экономика считалась не на модели, а на реальных данных.

Четыре фильтра перед решением «делаем»

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

Копируемый одностраничный документ

Документ заполняется фактами и явными пробелами, а не правдоподобными числами. Фраза «конкурент уже запустил» сама по себе не создаёт срочность. Нужно показать, какую подтверждённую задачу клиента это меняет, сколько стоит ожидание и почему выбранная работа важнее альтернатив.

Отзывы помощников в разных ролях не считаются независимыми экспертными заключениями. Они помогают найти вопросы, но окончательные подтверждения дают реальные владельцы функций. У каждой цифры на странице остаются источник, дата и статус: факт, оценка, сценарий или цель.

Для такой функции одностраничного брифа недостаточно: к нему прикладывают заполненный лист допуска системы, которая оценивает людей →. Без него открытые вопросы о критериях, смещении, данных, объяснении, пересмотре и остановке не считаются «рисками на потом» — решение остаётся на стадии исследования.

05 · Требования

Описать поведение и ошибки, а не список экранов

Критерий приёмки должен быть проверяем без чтения мыслей автора.

Требование проверяет посторонний человек, иначе оно не требование

Формулировка, понятная только тому, кто участвовал в обсуждении, на приёмке толкуется заново. Спор идёт не о работе, а о том, что имелось в виду.

Рабочая проверка простая: может ли человек, не бывший на встречах, однозначно сказать «выполнено» или «нет». Если не может, требование нужно переписать, а не пояснить устно.

Неверные входные данные описывают наравне с правильным путём

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

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

Что не входит в версию, пишут в самом требовании

Границу, оставленную в переписке или в чьей-то памяти, восстанавливают в момент спора и каждый раз в свою пользу.

Перечень исключённого рядом с требованием превращает расширение в заметное решение. Он же защищает исполнителя от претензии за то, о чём не договаривались.

Требование, у которого нет проверяющего и срока, не выполняется вовремя

Готовая, но никем не принятая работа остаётся в подвешенном состоянии и незаметно расходует срок. Ответственность за это обычно не назначена.

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

• Обычный успешный путь и неверные входные данные.
• Права и рабочие роли.
• Пустое состояние, загрузка, ошибка и отсутствие связи.
• Защита, хранение и удаление данных.
• Доступность для людей с ограничениями и работа на телефоне.
• История действий и данные для поддержки.
• Критерии приёмки и то, чего в версии не будет.

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

Учебный пример: Требования к ценообразованию. Вместо «сделать скидку на сайте» — «Система убирает вечную скидку с одиночной товарной единицы, возвращая честную базовую цену. Скидки применяются только при выборе набора (3 или 6 единиц) или оформлении подписки. Это повышает средний чек, так как одиночная продажа становится невыгодной. В корзине всегда работает прозрачная рассрочка платежа, а при покупке набора маржа покрывает стоимость привлечения».

Проверить макет до того, как красивый экран станет дорогой ошибкой

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

1. Начните с реальной задачи и ролей, а не с любимого вида экрана. «Так делают конкуренты» даёт вариант для проверки, но не обосновывает выбор.
2. Перечислите все состояния: загрузка, пусто, мало и много записей, длинное имя, нет изображения, нет права, ошибка, потеря связи, частичное выполнение и восстановление.
3. Проверьте, какие личные сведения действительно нужны на карточке. Контакты, резюме, документы и свободные заметки показываются только тем, кому они нужны для работы; каждый просмотр и изменение подчиняются ролям и журналу.
4. Для перемещения перетаскиванием дайте клавиатурный способ: выбрать объект, выбрать этап, подтвердить. Фокус остаётся заметным и после действия переходит в понятное место.
5. Опасное массовое действие показывает количество и объекты, предупреждает о последствиях, требует подтверждения и по возможности допускает отмену. При частичной ошибке видно, что выполнено, а что нет.
6. Проведите технический опыт на реальном ожидаемом объёме и пользовательскую проверку с представителями нужной роли. Отдельно зафиксируйте нерешённые вопросы мобильного вида.
7. Не обещайте влияние на удержание или деньги из оценки дизайна. Запишите гипотезу, исходный показатель, группу, защитные показатели и способ проверки после ограниченного выпуска.

Провести техническую проверку до начала дорогой разработки

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

1. Нарисуйте фактическую схему нынешнего решения и отдельно — предлагаемого. Не скрывайте ручные действия и таблицы.
2. Для каждого звена запишите вход, выход, владельца, чувствительность данных, ограничение и поведение при сбое.
3. Посчитайте не только создание: добавьте размещение, платные сервисы, наблюдение, поддержку, исправления, обучение, перенос и выход.
4. Проверьте три режима: обычный день, ожидаемый пик и рост в несколько раз. Множитель выбирают по реальному плану, а не автоматически.
5. Составьте перечень угроз и дорогих ошибок. Для каждой укажите предотвращение, обнаружение, ответ и восстановление.
6. Проведите проверку с реальным разработчиком, специалистом по безопасности или владельцем инфраструктуры, если есть авторизация, платежи, чувствительные данные, высокая нагрузка либо существенный ущерб от сбоя.
7. Закончите одним решением: принять; принять при перечисленных условиях; переделать; проверить малым способом; купить готовое; отказаться. Рядом — ответственный и дата повторной проверки.

06 · Приоритет

Оценивать не громкость запроса, а ценность решения

План развития не должен автоматически копировать конкурента или желание самого настойчивого клиента.

1. Сначала отсекайте обязательные работы по безопасности, закону, серьёзным сбоям и уже данным обещаниям.
2. Для остальных сравнивайте не число просьб, а охват, тяжесть и ценность решения.
3. Проверяйте связь со стратегическим диагнозом: хорошая идея вне выбранного фокуса может подождать.
4. Оценивайте полную стоимость, доступных людей и зависимости, а не только часы разработки.
5. Учитывайте уверенность и стоимость следующего знания: слабую гипотезу дешевле проверить, чем сразу строить.
6. Запишите, какая работа не будет сделана из-за этого выбора.

Как провести разбор очереди задач и закончить его решением

1. До встречи соберите карточки. Для каждой работы: проблема и доказательство; причина срочности; ожидаемая ценность или предотвращённый риск; оценка размера и уверенность; зависимости; нужные роли; критерий приёмки.
2. Определите уровни срочности словами. Например: немедленная обязанность из-за безопасности или закона; обязательство текущего цикла; кандидат при наличии мощности; исследование; «не сейчас». Обозначения вроде «нулевой приоритет» нельзя использовать без такого определения.
3. Проверьте доказательства. Фраза «блокирует крупных клиентов» получает список затронутых сделок, этап, сумму под риском, частоту, источник и другое объяснение. Если доказательств нет, это вопрос для исследования, а не высший приоритет.
4. Разведите исследование и создание. Не обещайте разработку до проверки проблемы, если сама потребность ещё неизвестна. У исследования тоже есть результат, владелец и срок решения.
5. Сведите оценки к одной единице. Уточните, что входит в размер, кто оценивал и с какой уверенностью. Если один документ говорит «восемь единиц», а другой — «пять недель», работу останавливают до согласования границ, состава команды и зависимостей.
6. Посчитайте доступную мощность. Люди и время минус поддержка, обязательные работы, отпуска и резерв на непредвиденное. Сумма выбранных задач не должна превышать мощность только потому, что встреча закончилась.
7. Проверьте зависимости и порядок. Данные, дизайн, исследование, договор, интеграция, решение руководителя и найм могут сдвинуть начало. Зависимость получает владельца и дату.
8. Назначьте состояние. Обязались; вариант при освобождении мощности; исследуем; не сейчас; отказались. Для «не сейчас» укажите причину и условие возврата, иначе задача будет всплывать на каждой встрече.
9. Зафиксируйте цену выбора. Какая другая работа не будет сделана, какой риск принят и кто имеет полномочия принять его.
10. Закройте протокол. У каждой принятой работы есть владелец, ближайшая дата, критерий готовности и следующая точка решения. Неназначенная задача не считается принятой.

Одинаковая итоговая оценка не означает одинаковое решение. Матрица делает спор видимым; человек с полномочиями выбирает ставку и принимает цену отказа. Запрос крупного клиента не становится приоритетом автоматически, но его влияние на выручку и отношения должно быть явно учтено.

07 · План развития

Разделить исследование, обязательство и далёкое намерение

Дата в презентации не становится обещанием без людей, времени и снятых зависимостей.

Стройте план вокруг проблем, результатов и проверок, а не списка функций на даты. У каждой строки есть состояние, владелец решения, зависимость, доступная мощность, риск и дата следующего пересмотра. Переход в «обязались» происходит только после согласования границ и ресурсов.

1. Соберите темы из выбранной стратегии и обязательных рисков.
2. Разделите исследование, маленькую проверку, разработку, выпуск и измерение.
3. Проверьте мощность команды и критические зависимости.
4. Сформулируйте внешнюю коммуникацию без обещаний функций, которые ещё только исследуются.
5. При изменении фактов пересмотрите состояние и сохраните причину.

План развития существует ради отказов, а не ради списка обещаний

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

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

Дата без снятой зависимости — это не срок, а надежда

Строка становится обязательством не тогда, когда её утвердили, а тогда, когда названы люди, время и всё, от чего она зависит вне команды.

Зависимость от другого подразделения, поставщика или согласования — самая частая причина сдвига. Названная заранее, она перестаёт быть неожиданностью и становится предметом договорённости.

Мощность считают по тому, что осталось после обязательной работы

Планирование от полного объёма времени обречено: поддержка, исправления, ответы на вопросы и обязательные требования забирают заметную часть и не исчезают.

Реалистичный план строится на остатке. Он выглядит скромнее и выполняется, а это единственное, чем план полезен.

Изменение состояния строки сохраняют вместе с причиной

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

Сохранённая причина превращает историю плана в источник выводов: через несколько циклов видно, какие оценки систематически ошибочны и в какую сторону.

Стратегическая схема показывает решение, но не заменяет его основания

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

1. Сформулируйте один вопрос, решение и аудиторию схемы.
2. Для каждого узла, работы, даты, цели и положения укажите источник, состояние, владельца, дату и уверенность.
3. Сначала соберите редактируемую таблицу или схему из текста и связей. Растровое изображение используйте только как представление: генератор может исказить подписи, стрелки и координаты.
4. Попросите владельцев предметной области проверить содержание, а аудиторию — понятность без устного объяснения.
5. При изменении исходного реестра выпустите новую версию всех зависимых схем и сохраните прежнюю.

07А · Цикл продуктового анализа

От разрыва в данных до решения после выпуска

Красивый процент не является решением, пока не проверены данные, экономика, качество результата и цена ошибки.

Фаза 1. Найти и подтвердить проблему

1. Сформулируйте решение, которое предстоит принять, и срок. Не начинайте с просьбы «найти что-нибудь интересное».
2. Сохраните неизменный исходник и паспорт выгрузки: событие, единица счёта, период, версия продукта, фильтры, исключения и ответственный.
3. Разложите путь на наблюдаемые события, посчитайте абсолюты, переходы и время между шагами. Общий разрыв ещё не объясняет причину.
4. Проследите реальные случаи и свяжите участок с обращениями, разговорами и текущим обходным способом. Отделите наблюдение от гипотезы.
5. Назовите затронутую группу и проверьте знаменатель: сколько людей действительно могли столкнуться с шагом.

Фаза 2. Оценить вариант до разработки

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

Годовая выручка активированного клиента не является его пожизненной ценностью. Для пожизненной ценности нужны удержание по периодам, валовая маржа, стоимость обслуживания и выбранный горизонт; при длинном горизонте учитывают стоимость денег во времени. Окупаемость считают по чистому или валовому вкладу после затрат, а годовую повторяющуюся выручку показывают отдельно.

Фаза 3. Спроектировать проверку до просмотра результата

1. Запишите гипотезу, единицу распределения, способ назначения, основной показатель, минимально полезный эффект и срок.
2. Заранее назовите группы, для которых ожидается различие, и основание. После просмотра общего результата нельзя перебирать десятки срезов в поиске победы.
3. Добавьте защитные показатели: качество, удержание, ошибки, жалобы, стоимость поддержки, неравный вред и нагрузку.
4. Определите действия при успехе, неопределённости, вреде и внутреннем противоречии данных.
5. Зафиксируйте число проверяемых показателей и срезов. При множественных проверках примените подходящую поправку и профильную статистическую проверку.

Фаза 4. Проверить данные раньше вывода

• Размеры групп и срезов сходятся с общим числом. Если при заявленных 500 наблюдениях части дают 517, анализ останавливается до исправления.
• Нет дублей, невозможных дат, смешанных единиц, незрелых наблюдений и тихо удалённых строк.
• Распределение между вариантами сопоставимо по заранее важным признакам; отклонения объяснены.
• События интерфейса доходят до отчёта и сверяются с независимым источником.

При заранее выбранном пороге 0,05 значение вероятности случайного результата 0,06 не проходит этот порог. Это не доказывает отсутствия эффекта, но не даёт права назвать результат статистически подтверждённым. Покажите оценку эффекта, интервал неопределённости, размер выборки и ограничения.

Фаза 5. Прочитать результат и принять решение

1. Сначала покажите общий результат и защитные показатели, затем заранее заданные группы.
2. Проверьте, действительно ли эффект различается между группами, а не просто оказался значимым в одной и незначимым в другой.
3. Любой новый срез после просмотра данных пометьте как разведочный и проверьте на новой выборке.
4. Выберите: расширять постепенно, исправить и повторить, продолжить наблюдение или остановить. Полное включение не следует автоматически из одного удачного среза.
5. После выпуска наблюдайте тот же основной результат, защитные показатели, стоимость и обращения; назначьте дату окончательного решения.

08 · Проверка гипотезы

Проверить решение до полного внедрения

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

Выберите самый дешёвый надёжный способ проверки

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

1. Запишите причинное предположение и другое объяснение.
2. Выберите главный показатель до просмотра результата.
3. Добавьте защитные показатели: качество, жалобы, ошибки, неравный вред, стоимость поддержки.
4. Опишите распределение, период, размер, исключения и незавершённые наблюдения.
5. Заранее определите действия при успехе, вреде и неопределённости.
6. После проверки покажите исходные количества, неопределённость и отклонения от плана.

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

09 · Выпуск

Готово для показа не равно готово для пользователя

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

1. Проверка приёмки, безопасности и защиты данных.
2. Доступность, устройства и браузеры.
3. События аналитики и панели показателей.
4. Перенос, заполнение прошлых данных и сверка.
5. Инструкции для поддержки и ответственный за серьёзные проблемы.
6. Включение для ограниченной группы.
7. Наблюдение и способ возврата.
8. Сообщение о выпуске с известными ограничениями.

До, во время и после включения

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

03а · Масштабируемая поставка

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

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

Сначала назовите, что именно покупают у вас лично

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

Выберите настоящую модель поставки

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

До выхода владельца соберите стандарт результата

1. Обещание. Какое наблюдаемое изменение получает клиент, при каких исходных условиях и чего продукт не гарантирует.
2. Вход. Какие данные, навыки, материалы, доступы и действия нужны от клиента до начала.
3. Метод. Последовательность шагов, контрольные точки, примеры хорошего результата и типовые ошибки.
4. Развилки. Что команда решает сама, когда останавливается и какой случай передаёт старшему специалисту.
5. Приёмка. Кто, когда и по каким признакам проверяет работу; как фиксируются ошибка, переделка и итог.
6. Обучение команды. Теория, наблюдение за работой, пробный случай, проверка на контрольных примерах и допуск к клиентам.
7. Обратная связь. Где собираются вопросы клиентов, решения по исключениям и изменения стандарта.

Посчитайте не «пассивный доход», а полную стоимость поставки

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

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

Компенсируйте уменьшение личного контакта реальной ценностью

Имя владельца может открыть первую продажу, но не заменяет предоставление. По мере уменьшения личного участия должны расти ясность метода, удобство сервиса, доказательность результата и надёжность поддержки. Покупателю заранее говорят, с кем он будет работать, какую квалификацию имеют эти люди, что проверяет владелец и что не проверяет.

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

Встройте личную работу в лестницу, а не ставьте рядом как дешёвую замену

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

Проведите испытание автономности

1. Передайте один обычный случай по новому стандарту и не вмешивайтесь до заранее названной точки проверки.
2. Запишите каждое вмешательство владельца: почему понадобилось, чего не было в инструкции, полномочиях, навыке или запасе времени.
3. Исправьте систему, обучите другого человека и повторите испытание на новом случае.
4. Проведите не меньше трёх полных циклов, включая ошибку, возврат или нестандартный вопрос.
5. Сравните результат, срок, себестоимость, нагрузку поддержки, жалобы и повторные покупки с прежней моделью.

10 · Показатели

Построить систему показателей, которая подсказывает решение

Панель нужна не для наблюдения за красивыми графиками. Она должна показать, получил ли клиент ценность, за счёт чего изменился результат и что делать ответственному человеку.

Шаг 1. Выберите главный показатель создаваемой ценности

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

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

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

Шаг 2. Соберите дерево причин, а не плоский список

1. Верхний уровень: результат для клиента и результат для бизнеса.
2. Уровень причин: привлечение подходящих клиентов, первое получение пользы, повторное использование, удержание, оплата и рекомендации — только те блоки, которые относятся к вашей модели.
3. Рабочий уровень: действия, на которые команда способна влиять на этой неделе: время до первой пользы, доля завершивших ключевой шаг, ошибки, просроченные действия и использование важной возможности.
4. Защитный уровень: жалобы, возвраты, ошибки, стоимость поддержки, перегрузка, нежелательный вред и ухудшение результата для отдельных групп.

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

Шаг 3. Зафиксируйте определения и путь данных

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

Сначала устраните противоречия между показателями

Два похожих процента нельзя ставить рядом, пока не согласованы база и период. Например, если ежемесячно остаются активными 88% одинаково определённых клиентов, это означает примерно 12% потери за месяц. Одновременно заявленная потеря 4,5% за квартал не может описывать ту же самую группу и то же событие. Возможны разные основания: в одном месте считают активность, в другом отмену подписки; в одном — клиентов, в другом — выручку; различаются даты, исключения или группы. До решения расхождение нужно объяснить, а не усреднить.

1. Поставьте рядом формулы, исходные количества, события и периоды обоих показателей.
2. Проверьте единицу наблюдения: клиент, договор, пользователь, вакансия или рубль.
3. Сверьте продуктовые события с оплатами, возвратами и договорным статусом.
4. Найдите первый период и первую запись, где источники расходятся.
5. Исправьте данные или разведите два разных смысла разными названиями.
6. Только после сверки обсуждайте причину и действие.

Панель должна сама ловить невозможные числа

Если последовательность названа воронкой одной группы, количество на каждом следующем шаге не может увеличиться. Учебная цепочка «550 регистраций → 407 созданных вакансий → 298 добавивших кандидатов → 127 начавших проверку → 209 закрывших вакансию» нарушает это правило. Возможны разные периоды, разные единицы, повторные события или ошибка. До сверки это не воронка и не основание для решения.

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

Шаг 4. Сравнивайте группы одинакового возраста

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

1. Назовите событие входа в группу и период набора.
2. Покажите исходное число участников, а не только процент.
3. На каждой контрольной точке покажите и количество, и долю от исходной группы.
4. Не сравнивайте незавершённое окно с завершённым; помечайте малую выборку.
5. Разделяйте заранее выбранные группы и случайно найденные разрезы.
6. После наблюдаемой связи проверяйте другие объяснения: состав клиентов, цена, канал, сезон, обучение и изменение продукта.

Проверяйте и порядок величин. Если средняя годовая оплата около трёх тысяч рублей, а ценность одного клиента указана как 313 600 рублей, число нельзя принимать без формулы: нужны срок жизни, маржинальный доход, расширение оплаты, скидки, возвраты и состав группы. Разница более чем в сто годовых оплат может оказаться другой валютой, масштабом в тысячах, накоплением по компании вместо пользователя или простой ошибкой.

Шаг 5. Сделайте разные представления для разных решений

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

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

Шаг 6. Переведите наблюдение в действие

1. До открытия панели запишите вопрос и возможные решения: продолжить, исправить, проверить, остановить или перераспределить ресурс.
2. Сначала проверьте свежесть, полноту и изменение определения. Затем смотрите общий результат и защитные показатели.
3. Найдите первый уровень дерева, где появилось отклонение, и только после этого углубляйтесь в рабочие показатели.
4. Сформулируйте наблюдение без причинности: «доля первого полезного действия ниже исходного уровня», а не «новое обучение не работает».
5. Если изменение необычное, сначала проверьте загрузку данных, дубли, пропуски, изменение определения, состав групп, сезон и внешнее событие.
6. Назначьте проверку причины, действие, владельца, дату и показатель, по которому будет принято следующее решение.

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

Тревога — это не произвольное красное число

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

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

11 · Обращения пользователей

Обращение становится доказательством только после разметки

Самая громкая жалоба не всегда означает массовую проблему.

1. Свести обращения из всех каналов и удалить дубли.
2. Разметить задачу, серьёзность, частоту, группу, временный обход и итог.
3. Связать с версией продукта и событием.
4. Отделить просьбу пользователя от лежащей под ней проблемы.
5. Назначить ответственного и решение.
6. Ответить пользователю и проверить, повторяется ли проблема.

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

Если обращение сообщает о медленной работе или техническом сбое

1. Обезличьте сообщение. Контакты и содержимое рабочих данных не копируют в общую задачу без необходимости и разрешения.
2. Запишите воспроизводимую конфигурацию. Устройство, система, браузер или приложение, версия продукта, размер данных, число этапов, сеть, точные действия, наблюдаемое время и вложение.
3. Воспроизведите и измерьте распределение. Одного времени загрузки недостаточно. Сохраните медиану, 95-й и 99-й процентили, число попыток, ошибки и условия испытания. Процентиль показывает границу, быстрее которой завершилась соответствующая доля попыток.
4. Разделите путь по времени. Сохраните сетевую трассировку и серверные записи: ожидание ответа, получение данных, обработка на сервере, запросы к хранилищу, переданный объём, построение элементов в браузере и реакция при прокрутке. Предположение «рисуем все карточки сразу» не считается причиной до измерения.
5. Задайте допустимую границу. До исправления согласуйте размер набора, устройство, сеть, число одновременных пользователей, допустимые медиану и медленную границу, долю ошибок и бюджет ресурсов. «Стало быстрее» без этих условий не является приёмкой.
6. Проведите нагрузочную и пограничную проверку. Проверьте наборы меньше, на уровне и больше проблемного объёма, обычную и пиковую одновременную работу, медленную сеть, слабое устройство и продолжительную сессию. Изменение не должно ускорять один экран ценой ошибок, памяти или деградации других путей.
7. Определите охват. Сколько аккаунтов и пользователей могли столкнуться, сколько действительно столкнулось, какая выручка и какие обязательства затронуты.
8. Назначьте серьёзность по правилам. Учитывайте невозможность выполнить задачу, потерю данных, безопасность, доступный обход, число затронутых и договорное время реакции.
9. Свяжите обращение с работой разработки. Причина, задача, владелец, зависимость, состояние и критерий исправления. Предварительная дата не называется обещанием выпуска.
10. Дайте проверенный временный порядок. Он должен реально уменьшать вред, иметь ограничения и дату следующего сообщения клиенту.
11. Выпускайте поэтапно. Сначала ограниченная группа, затем наблюдение за временем, ошибками и ресурсами. Заранее задайте условие остановки и проверенный способ вернуть прежнюю версию.
12. После изменения повторите тот же сценарий. Сравните распределение времени, ошибки и опыт пользователя; наблюдайте после выпуска и попросите автора обращения подтвердить результат на исходной конфигурации.

Если при выгрузке портятся даты, числа или разделители

Фраза «в Excel неправильная дата» ещё не позволяет воспроизвести ошибку. Один и тот же файл может открываться по-разному из-за формата выгрузки, региональных настроек системы и табличного редактора. Поэтому поддержка сначала сохраняет точный вход и условия, а не сразу обещает исправление.

1. Попросите безопасный образец. Нужны исходное значение в продукте, одна обезличенная строка выгрузки и снимок того, как она открылась. Полную клиентскую базу в задачу разработки не прикладывают.
2. Запишите среду. Операционная система, название и версия табличного редактора, язык и регион, часовой пояс, формат файла — например, CSV или XLSX — и способ открытия: двойным щелчком, через импорт или другим путём.
3. Разделите три значения. Сохраните дату и время в исходной системе, фактический текст внутри файла и то, что показал редактор. Так становится видно, испортила значение выгрузка или программа неверно истолковала корректный файл.
4. Запишите точные действия. Какой отчёт выбран, какие фильтры и период заданы, какая кнопка нажата, какой файл получен и что наблюдал человек. Рядом укажите ожидаемый вид и правило, на котором он основан.
5. Проверьте несколько условий. Даты до и после смены месяца и года, время около полуночи, пустое значение, разные региональные настройки, разрешённые версии редактора, CSV и XLSX. Для CSV отдельно проверяют кодировку и разделитель столбцов.
6. Сформулируйте критерий исправления. Внутри файла остаётся правильное однозначное значение; поддерживаемые редакторы открывают его по документированному правилу; часовой пояс не сдвигает дату; прежние варианты выгрузки не ломаются.
7. Выпустите изменение управляемо. Сохраните набор контрольных файлов, проведите повторную проверку, предусмотрите возврат к прошлой версии, обновите справку и сообщите, кого касается изменение. После выпуска попросите автора обращения повторить исходный сценарий и зафиксируйте подтверждение.

Если один крупный клиент требует функцию и угрожает уйти

1. Сохраните запрос дословно, но отделите просьбу «сделайте приложение» от задачи: какое действие человек не может выполнить сейчас и при каких обстоятельствах.
2. Проверьте нынешний путь, доступный обход, серьёзность, частоту, число пользователей и дату решения о продлении.
3. Найдите похожие случаи и посчитайте долю среди аккаунтов, которые могли столкнуться, а не число сообщений само по себе.
4. Сравните исправление нынешнего мобильного пути, изменение процесса, ограниченную версию и отдельное приложение по пользе, сроку и стоимости.
5. Ответьте клиенту тем, что известно сейчас: признанная проблема, временный порядок, ответственная сторона и дата следующего обновления. Не обещайте дату выпуска до принятого обязательства.
6. На разборе учтите риск выручки и отношений, но не превращайте размер клиента в автоматический приказ всей команде.

Даже если 17 из 20 строк учебного опроса отвечают «да», это только 85% этой неизвестно как собранной таблицы. Без текста вопроса, способа приглашения, доли ответивших, удаления дублей, исходной выгрузки и поправки на состав аудитории число не описывает рынок. Поле «высокий приоритет» также ничего не значит без правила, по которому оно назначено.

Не расширяйте просьбу перенести данные до автоматической оценки людей

В учебном обращении клиент просил при импорте резюме автоматически переносить опыт, образование и навыки в карточку. В следующем документе эта просьба без нового исследования превратилась в оценку соответствия, балл, ранжирование и объяснение, почему человек «подходит или не подходит». Это не развитие одного требования, а переход к другому продукту, который способен повлиять на доступ человека к работе.

Сначала восстановите исходный запрос: какие поля вводятся вручную, какая доля документов импортируется, сколько секунд занимает одно поле и весь документ, что исправляют после импорта, какой временный порядок действует сейчас и какой минимальный результат действительно повлияет на решение о продлении. Арифметика должна сходиться. Например, 500–800 документов по две-три минуты — это примерно 17–40 человеко-часов, а не два-три часа на всю команду. Расхождение не доказывает ложь клиента: оно показывает, что неизвестны единица измерения, доля ручной работы или способ замера.

1. Свяжите каждое предложение решения с точной строкой обращения или новым подтверждённым исследованием.
2. Зафиксируйте стоимость договора, дату решения о продлении, участников выбора, фактическое использование и владельца отношений.
3. Проверьте количество похожих запросов по исходным карточкам, аккаунтам, периоду и доступной базе. Число без ссылки и знаменателя не сообщают клиенту как факт.
4. Не называйте полугодие, бета-версию или место в плане обязательством, пока срок, объём и ответственный не подтверждены владельцем продукта.
5. Если рассматривается оценка людей, откройте отдельный лист допуска системы →; просьба об импорте его не заменяет.

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

1. Не выдавайте обход за выпущенную возможность продукта. Назовите, что именно он временно решает, чего не решает и когда команда вернётся с обновлением.
2. Число «у нас ещё 23 похожих запроса» проверьте: удалите дубли, посчитайте затронутые аккаунты, версию, период и число клиентов, которые вообще могли столкнуться. Количество обращений без знаменателя не определяет приоритет.
3. До подключения внешней автоматизации проверьте, какие данные она передаёт, где они хранятся, кто получает доступ, есть ли допустимое основание обработки, журнал ошибок и способ немедленно отключить связку.
4. Назначьте владельца временного решения, порядок поддержки, проверку доставки и дату удаления или замены. Обход без владельца быстро превращается в незаметную постоянную систему.
5. Предложите человеку понятный выбор: пользоваться безопасным временным порядком, дождаться решения или отказаться. Не обещайте срок встроенной функции, пока команда не приняла обязательство.

Еженедельная сводка поддержки: от сообщений к управленческому решению

1. Зафиксируйте период, каналы и полный объём: все обращения, уникальные обращения после удаления дублей, аккаунты и активные аккаунты, которые могли столкнуться.
2. Не смешивайте тикеты, интервью, отзывы и заметки продавцов в одну частоту. Сохраните тип источника и отдельный знаменатель; объединять можно только вывод с указанием оснований.
3. Для каждой темы покажите обращения, уникальные аккаунты, долю среди возможных, сегмент, этап жизни клиента, версию продукта, повторные обращения и дословные обезличенные примеры.
4. Разделите симптом, задачу пользователя, просьбу о функции, предполагаемую причину и подтверждённую причину. Несколько похожих просьб ещё не доказывают одно решение.
5. Оцените серьёзность, блокировку работы, безопасный временный порядок, деньги под риском и обязательства. Риск ухода подтверждается словами или поведением клиента, а не раздражённым тоном, который приписала модель.
6. Свяжите тему с действующей задачей, решением или отказом. Укажите владельца, состояние, срок следующего обновления и что уже сообщили клиентам.
7. На следующей неделе проверьте движение: новых и повторных случаев, охват после изменения, качество обхода и обратную связь затронутых людей.

Разобранный учебный набор обращений

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

Средний заявленный срок решения — 3,03 дня, но без распределения активных аккаунтов нельзя заключать, что компаниям определённого размера труднее: 177 обращений группы 51–200 сотрудников ещё не являются повышенной частотой. Нужен знаменатель — число активных аккаунтов этой группы, которые проходили соответствующий шаг в той же версии.

1. Проверить событие и точный экран, на котором человек остановился.
2. Воспроизвести путь и посмотреть разрешённые записи сессий или провести короткие разговоры.
3. Посчитать частоту на активный аккаунт, версию, этап и канал.
4. Назначить владельца интерфейса или интеграции и передать поддержке проверенный временный порядок.
5. После изменения сравнить обращения, прохождение шага, время до первой пользы, ошибки и удержание.

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

12 · Ежемесячный разбор продукта

Решить, а не просто обновить состояние

Разбор связывает исследование, выполненную работу и результат для пользователя.

Разбор без принятого решения — это отчёт, и он не меняет ничего

Встреча, закончившаяся обменом состоянием дел, оставляет ощущение работы и не производит выбора. Через месяц обсуждают то же самое.

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

Запись «решение не принято» — полноценный результат, а не признание неудачи

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

Зафиксированная неопределённость с указанием, чего не хватает и кто это принесёт, превращает паузу в задачу. Без такой записи пауза длится до следующего кризиса.

Остановленные работы называют вслух, иначе они продолжаются

Задача, о которой перестали говорить, обычно не прекращается: кто-то продолжает её делать, ожидая, что она ещё нужна.

Явное закрытие с указанием причины освобождает время и снимает обиду. Тихое сворачивание даёт обратный эффект — люди перестают вкладываться и в новые работы.

Цифра без определения и периода спорна сильнее, чем отсутствие цифры

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

Определение, период и источник рядом с числом снимают это за одну строку. Там, где измерения нет, честнее написать «не измеряли», чем подставить правдоподобную оценку.

Как собрать решения из нескольких встреч

1. Сохраните исходные заметки отдельно. Каждую строку пометьте: наблюдаемый факт, дословная реплика, гипотеза, идея, принятое решение или задача.
2. Числовые утверждения вынесите в реестр проверки: формулировка, кто сказал, источник, период, определение, ответственный и срок подтверждения.
3. Сведите противоречия между встречами: разные цели, сроки, оценки клиента, технические зависимости и ожидания руководителей.
4. Для каждой инициативы укажите связанную проблему или цель, ожидаемый результат, доказательство, доступную мощность, зависимость и цену отказа от других работ.
5. Если решения не было, прямо запишите «решение не принято» и дату следующей точки. Фраза руководителя «хочу поднять приоритет» не равна утверждённому обязательству.
6. Только после явного решения обновите план развития и задачи. У каждой задачи остаются владелец, срок, зависимость и критерий готовности.

Не превращайте весь протокол в список задач

Одна реплика может одновременно содержать наблюдение и предположение, но в реестре их разделяют. Иначе «люди тратят 40% времени» после пересказа превращается в вымышленное число часов, а идея руководителя — в обязательство команды.

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

Дополнение для постепенного выпуска

Порядок встречи

1. Вернитесь к решениям прошлого разбора и проверьте обязательства.
2. Покажите изменение результата для пользователей и бизнеса, а также защитные показатели.
3. Разберите новые доказательства, серьёзные обращения и неизвестное.
4. Сравните доступную мощность с действующими обязательствами.
5. Примите решения по каждому спорному пункту: продолжить, проверить, исправить, отложить или остановить.
6. Запишите владельца, срок, критерий готовности и дату следующей проверки.

Раз в рабочий цикл проверяйте сам процесс

Отдельно от продуктовых приоритетов проведите короткий разбор работы команды. Соберите, что помогло, что помешало, какие идеи появились и какое одно улучшение процесса будет проверено. Маршрут улучшения: наблюдение → доказательство → влияние → системная причина → небольшая проверка → владелец → срок → критерий готовности → результат на следующем разборе.

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

Новый продукт

Выбрать формат продукта под задачу и способ поддержки

Один и тот же навык можно упаковать по-разному. Формат выбирают не по моде, а по глубине изменения, нужной обратной связи и доступной мощности автора.

Формат определяется не темой, а тем, что человек должен сделать по-другому

Одно и то же знание можно передать текстом, встречей или сопровождением. Выбор между ними решает не объём материала, а глубина требуемого изменения: узнать, применить один раз или перестроить привычный порядок работы.

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

Обратная связь — самая дорогая часть любого формата

Материалы производятся один раз, а ответы на вопросы требуются каждый раз заново и зависят от числа участников. Именно эта часть чаще всего обрушивает продукт, который до продажи выглядел посильным.

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

Одна и та же тема в разных форматах — это разные продукты, а не разные цены

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

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

Регулярный формат обязывает сильнее разового

Клуб, сообщество или подписка продают не содержание встречи, а уверенность в том, что встречи продолжатся. Пропуск ритма ломает продукт быстрее слабого содержания.

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

Критерий окончания нужен даже там, где продукт бесконечен

Без названного признака завершения участник не понимает, получил ли он обещанное, и остаётся с ощущением незаконченности независимо от объёма работы.

В длящихся форматах роль критерия играет промежуточный результат периода: что человек должен уметь или иметь к концу цикла. Это же даёт основание для разговора о продлении.

Продолжение закладывают в формат заранее, а не придумывают после первого запуска

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

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

Создание продукта

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

Обучающий продукт — это не набор файлов, а маршрут из исходной точки в результат. Каждый этап должен подтверждать, что этот маршрут реален.

1. Определите область компетентности. Ответьте, в чём вы сильны, за чем к вам уже приходят и какую задачу готовы решать.
2. Опишите аудиторию и запрос. Кому нужно знание, что у этих людей болит и какой результат им нужен; проверьте, есть ли такие люди среди текущей аудитории.
3. Выберите формат. Для навыка с демонстрацией подойдёт видео или мастер-класс, для сложной системы — обучение с практикой, для быстрой задачи — чек-лист или руководство.
4. Изучите рынок. Сравните содержание, объём, формат, цену, сильные и слабые стороны аналогов; найдите пространство для отличия.
5. Сформулируйте ценность. Одним предложением назовите проблему и наблюдаемый результат после применения продукта.
6. Подготовьте содержание. Составьте план, запишите уроки или вебинар, оформите материалы; проверьте звук, изображение, структуру и язык редактором.
7. Упакуйте продукт. Сделайте внешнюю подачу (страница, презентация, файл) и внутреннюю структуру (название, программа, преимущества, ограничения) в едином стиле.
8. Обоснуйте цену. Свяжите её с результатом, объёмом поддержки и рыночным контекстом; не занижайте цену из страха, но не обещайте невозможного.

Продуктовая линейка

Строить следующий продукт из следующего запроса клиента

Линейка — это не случайный набор услуг. Каждый следующий продукт углубляет результат предыдущего и помогает прийти к финансовой цели.

1. Начните с одного пути. Опишите исходный запрос клиента и результат первого продукта. Не распыляйтесь на темы, которые не связаны общим клиентом и задачей.
2. Выберите ступени. Вводный продукт или марафон даёт базу и помогает проверить спрос; основной продукт даёт полный результат; клуб или подписка поддерживает внедрение и обновление знаний.
3. Предугадывайте следующий запрос. После каждого результата спросите: что клиенту понадобится сделать дальше, какая новая трудность возникнет и какой продукт честно её решает.
4. Свяжите линейку с экономикой. Проверьте, сколько продаж каждого уровня нужно для финансовой цели, и не пытайтесь закрыть её количеством нереалистичных разовых консультаций.
5. Проверяйте переход. Фиксируйте, кто перешёл на следующую ступень, почему отказался и какие условия поддержки или формата нужно изменить.

19 · Продуктовая инженерия и Advanced JTBD

Продуктовая инженерия на базе ИИ-скиллов и единого репозитория контекста: методология Advanced JTBD, аудит конверсии и продукты, продающие сами себя

Как проектировать продукты, которые продают сами себя: переход от разрозненных задач к единому репозиторию контекста компании, набор ИИ-скиллов для прожарки лендингов и требований, методология Advanced JTBD и устранение разрыва между маркетингом и разработкой.

Большинство продуктовых и маркетинговых команд функционируют в состоянии хронического разрыва: разработчики строят функции, которые считают технически сложными, а маркетологи пытаются продать их рынку через бесконечные тесты креативов и посадочных страниц. Когда воронка не окупается, а стоимость лида взлетает, команда винит рекламу. Однако фундаментальная причина в 90–95% случаев лежит на самом первом шаге: ошибка в выборе клиентского сегмента и непонимание истинной работы (Job to Be Done), ради которой продукт нанимают.

Методология Advanced JTBD: отказ от демографии и Jobs как единица мотивации

В методологии современной продуктовой инженерии (школа Aurora) сегментация аудитории никогда не проводится по формальным социально-демографическим признакам (пол, возраст, география или число сотрудников в B2B):

• Принцип однородности задач: Сегмент — это группа людей с похожим набором задач (работ) в схожих жизненных или деловых обстоятельствах. Продукт конкурирует не со сферами бизнеса, а за выполнение конкретных работ клиента.
• Определение Job: Работа — это единица мотивации в мозге человека. Человек не способен достоверно оценить свои абстрактные потребности (сознание не имеет прямого доступа к бессознательным драйверам психики), но мозг всегда формулирует цель глаголом неопределенной формы («купить авиабилеты», «прожарить лендинг», «сократить кассовый разрыв»).
• Оцифрованные критерии успеха: У каждой работы есть измеримые параметры приемки. Например, в задаче покупки семейного перелета критерии успеха — уложиться в бюджет до 200 000 ₽, иметь пересадку менее 90 минут и получить гарантированные места рядом. Знание этих критериев превращает копирайтинг и сборку продукта из угадывания в точную инженерию.
• Матрица отбора Core Job по 10 факторам: Размер сегмента, платежеспособность, средний бюджет на выполнение задачи, острота конкуренции, способность компании создать кратную добавочную ценность, наличие прямых каналов привлечения. Опора на эту матрицу позволила, например, команде JetBrains с языком Kotlin вырасти на 11% на зрелом глобальном рынке исключительно за счет перефокусировки на правильный целевой сегмент.

Единый репозиторий контекста компании (Company Context)

В 2026 году ключевой точкой роста эффективности бизнеса стало понимание: современные большие языковые модели голодны не до сложных промптов, а до глубокого и чистого контекста компании. Развертывание локального репозитория контекста (с синхронизацией через Git) кардинально меняет работу продуктовой команды:

Пакет специализированных ИИ-скиллов в среде разработки

Вместо хаотичных диалогов в браузерных чатах продуктовая команда подключает специализированные алгоритмизированные скиллы внутри профессионального редактора (Claude Code / Codex / Cursor):

Создание «самопродающегося» продукта

Продукт начинает «продавать сам себя», когда между коммуникацией на посадочной странице и реальным функционалом устранено трение. Если заголовок первого экрана и демонстрация ценности 1-в-1 совпадают с формулировкой работы в мозге клиента в момент наступления триггерного события, посетитель мгновенно узнает свою ситуацию. Конверсия посадочной страницы увеличивается в 2–3 раза без расширения бюджета на трафик, поскольку реклама привлекает аудиторию, для которой ценностное предложение является естественным решением.

Глава подготовлена по материалам методологии создания продуктов Aurora Advanced JTBD, практики продуктовых скиллов в Claude Code/Codex и анализа архитектур командных репозиториев контекста 2026 года.