Go-to-market и запуск: от позиционирования до раскатки

Есть распространённое заблуждение, что запуск — это день, когда код оказался в проде и вышел пост в блоге. На практике день релиза почти ничего не решает: продукты умирают не от того, что их плохо анонсировали, а от того, что не был построен повторяемый способ находить клиента и доводить его до ценности. Это и есть go-to-market (GTM).

Предыдущая статья (https://courses.digitable.life/post/product-management/09-market-and-competition/) закончилась на позиционировании: кому мы продаём и чем отличаемся. Эта — про то, как это утверждение превращается в поток клиентов и как выпустить изменение так, чтобы узнать правду о нём, а не про эффект новизны.

1. GTM и запуск: две разные вещи

1.1. Что входит в GTM

GTM — это ответ на шесть вопросов, и все шесть обязаны быть согласованы между собой:

Несогласованность в любой паре ломает всю конструкцию. Классические примеры: цена 2 млн ₽ в год при self-serve-канале (никто не платит такие деньги картой без разговора); сложный продукт, продаваемый через performance-рекламу (CAC не окупается, потому что цикл сделки — три месяца); дешёвый продукт с продажей через личные встречи (менеджер стоит дороже, чем приносит).

Правило согласованности: стоимость привлечения и обслуживания клиента должна быть на порядок меньше того, что он платит. Отсюда грубый ориентир: чек до 50 тыс. ₽/год — только self-serve; 50–500 тыс. — self-serve плюс sales-assist; выше — продажа с людьми.

1.2. Релиз, запуск и раскатка — три разных события

• Раскатка (rollout) — техническое: код доходит до пользователей, обычно постепенно и под флагом. Владелец — команда разработки. Метрики — ошибки, латентность, SLO (https://courses.digitable.life/post/sre/02-sli-slo/).
• Релиз — момент, когда функциональность доступна всем в целевом сегменте. Владелец — продакт.
• Запуск (launch) — коммерческое: об изменении узнают те, кому оно нужно, продажи умеют его продавать, поддержка умеет его поддерживать, а маркетинг умеет о нём говорить.

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

Самая частая ошибка — запуск без раскатки: громкий анонс одновременно с включением фичи на 100% аудитории. Тогда любой дефект встречает максимальное число людей, откат публичен и болезнен, а измерить эффект нельзя — нет контрольной группы.

2. Уровни запуска: не всё заслуживает пресс-релиза

Если каждое изменение сопровождать полным набором активностей, команда захлебнётся, а аудитория перестанет реагировать. Поэтому запуски делят на уровни (tier). Практическая шкала:

Здоровое распределение: T1 — 1–2 раза в год, T2 — раз в квартал-два на сегмент, всё остальное T3. Обязательный минимум одинаков для всех уровней и невелик: запись в changelog, обновлённая документация, предупреждённая поддержка. Нарушение этого минимума стоит дороже любого пропущенного пресс-релиза: пользователь, который встретил незнакомый экран, а поддержка о нём не знает, теряет доверие к продукту целиком.

3. Сообщение: из позиционирования в слова

3.1. Иерархия сообщений

Позиционирование (https://courses.digitable.life/post/product-management/09-market-and-competition/) — это внутреннее решение о том, с кем вас сравнивают. Сообщение — внешний текст. Между ними нужен один переход:

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

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

3.2. PR/FAQ: писать пресс-релиз до разработки

Практика Amazon «working backwards»: до начала работы пишется вымышленный пресс-релиз о готовом продукте плюс FAQ — внешний (что спросит клиент) и внутренний (что спросит команда). Документ на 1,5 страницы, без жаргона, с конкретными выгодами и цитатой клиента, которой ещё нет.

Ценность приёма не в тексте, а в фальсифицируемости: если пресс-релиз получается скучным или его невозможно написать без слов «инновационная платформа», значит ценность не сформулирована, и это выяснилось до того, как потрачен квартал. Хорошее описание практики — у Colin Bryar и Bill Carr в «Working Backwards» (2021).

Структура, которая работает:

1. Заголовок и подзаголовок — что и для кого, без превосходных степеней.
2. Абзац проблемы — на языке клиента, с описанием, как он живёт сейчас.
3. Абзац решения — что именно меняется, конкретно.
4. Цитата клиента — какую фразу он должен будет сказать, чтобы запуск считался успешным.
5. Как начать — первый шаг, реалистичный по времени.
6. FAQ — включая неудобные вопросы: цена, миграция, безопасность, чего продукт не делает.

3.3. Типичные дефекты сообщения

• Список фич вместо следствий. «Поддержка row-level security» → «руководитель филиала видит только свои магазины, юрлицо не спорит с безопасностью».
• Обещание, которое продукт не выполняет за первую неделю. Разрыв между обещанием и первым опытом — главный источник раннего оттока.
• Сообщение для всех. Универсальный текст не цепляет никого; лучше три текста под три сегмента, чем один «средний».
• Внутренний язык. Названия внутренних модулей, аббревиатуры и метафоры архитектуры в тексте для клиента — верный признак того, что писал не тот человек.

4. Каналы и их экономика

4.1. Типология

Каналы принципиально различаются по трём свойствам: стоимость привлечения (CAC), ёмкость (сколько клиентов в месяц он способен дать) и время до первого результата (реклама — дни, контент и партнёры — кварталы). Продуктовые и контентные каналы дают компаунд-эффект, но медленно; платные включаются мгновенно, но перестают работать в день, когда кончается бюджет.

Подробно о механике продуктовых циклов роста — в https://courses.digitable.life/post/product-management/07-pricing-and-growth/; о каналах дистрибуции софта (маркетплейсы, реселлеры, сторы) — в https://courses.digitable.life/post/software-distribution/08-channels/; базовые приёмы продвижения без маркетолога — в https://courses.digitable.life/post/business/08-marketing-basics/.

4.2. Убывающая отдача и распределение бюджета

Ключевой факт, который ломает наивное планирование: CAC растёт с объёмом. Первые 100 клиентов из канала дешёвые (самая горячая аудитория), следующие 100 — дороже. Разумная аппроксимация: стоимость привлечения n-го клиента растёт по степенному закону, а число клиентов от бюджета описывается вогнутой функцией:

clients(budget) = k · budget^α ,  где 0 < α < 1

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

from dataclasses import dataclass


@dataclass(frozen=True)
class Channel:
    name: str
    k: float        # масштаб: сколько клиентов даёт единичный бюджет
    alpha: float    # 0<alpha<1 — чем меньше, тем быстрее насыщается
    cap: float      # ёмкость канала за период, ₽ (больше просто некуда тратить)


def clients(ch: Channel, budget: float) -> float:
    """Вогнутая кривая отдачи канала."""
    return ch.k * min(budget, ch.cap) ** ch.alpha


def allocate(channels: list[Channel], total: float, step: float) -> dict:
    """Жадное распределение бюджета шагами по step.

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

    Время: O((total/step) * |channels|), память: O(|channels|).
    """
    spend = {ch.name: 0.0 for ch in channels}
    left = total
    while left >= step:
        best, best_gain = None, 0.0
        for ch in channels:
            cur = spend[ch.name]
            gain = clients(ch, cur + step) - clients(ch, cur)
            if gain > best_gain:
                best, best_gain = ch, gain
        if best is None:          # все каналы упёрлись в потолок
            break
        spend[best.name] += step
        left -= step

    got = {n: round(clients(next(c for c in channels if c.name == n), b), 1)
           for n, b in spend.items()}
    total_clients = sum(got.values())
    return {
        "spend": {n: round(b) for n, b in spend.items()},
        "clients": got,
        "blended_cac": round((total - left) / total_clients) if total_clients else None,
    }


plan = allocate(
    [
        Channel("Performance", k=0.9,  alpha=0.62, cap=3_000_000),
        Channel("Контент",     k=0.25, alpha=0.85, cap=2_000_000),
        Channel("Партнёры",    k=2.4,  alpha=0.45, cap=1_200_000),
    ],
    total=4_000_000,
    step=100_000,
)
print(plan)
# {'spend': {'Performance': 1900000, 'Контент': 900000, 'Партнёры': 1200000},
#  'clients': {'Performance': 8078.6, 'Контент': 4959.9, 'Партнёры': 1470.9},
#  'blended_cac': 273}

Что показывает результат. Партнёрский канал самый эффективный на рубль, но его ёмкость мала — он выбирается целиком и упирается в потолок. Контент с высоким alpha насыщается медленно, но стартует дорого. Performance забирает остаток. Смешанный CAC — единственное число, которое можно сравнивать с юнит-экономикой (https://courses.digitable.life/post/product-management/02-metrics/).

Оговорки, без которых модель вредна:

• Параметры k и alpha не известны заранее — они оцениваются по факту, по 2–3 точкам на канал. До этого модель годится только как язык для разговора.
• Каналы взаимодействуют: контент поднимает конверсию платного трафика, а партнёры приводят клиентов, которые пришли бы и сами (каннибализация). Атрибуция врёт всегда.
• Отдача нестационарна: аукцион дорожает, площадка меняет правила, партнёр меняет приоритеты. Пересчитывать нужно ежеквартально.
• CAC без учёта удержания бессмыслен: канал с CAC 200 ₽ и оттоком 60% в первый месяц хуже канала с CAC 800 ₽ и удержанием 85%.

4.3. Как выбирать канал на старте

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

5. Раскатка: кольцами и под флагом

5.1. Кольца

Каждое кольцо отвечает на свой вопрос, и это важно: не «работает ли код», а что именно мы узнаём.

Механика флагов, канареечных выкладок и безопасного отката — инженерная часть, она подробно разобрана в https://courses.digitable.life/post/devops/04-cd-and-release-strategies/ и https://courses.digitable.life/post/sre/13-release-safety/. Продакту важны две вещи: флаг должен уметь выключаться без релиза, и у каждого флага должен быть срок жизни — иначе через год в коде живут сотни мёртвых веток.

5.2. Бета — это не «релиз с оправданием»

Три правила, которые отличают полезную бету от вредной:

1. Участники набраны осознанно — из ICP, а не «кто откликнулся». Иначе обратная связь придёт от энтузиастов, которые прощают всё и не платят.
2. Есть контракт ожиданий: что может ломаться, как сообщать о проблемах, когда закончится, что будет с данными после. Особенно важно, если бета платная или условно платная.
3. Есть критерий выхода, записанный заранее. «Посмотрим, как пойдёт» гарантирует, что бета продлится вечно: без критерия всегда найдётся причина ещё подождать.

6. План запуска и координация

6.1. Кто что делает

Обратите внимание на две стрелки, которые чаще всего забывают: юристы (изменение оферты, тарифов, состава обрабатываемых данных требует времени и иногда предварительного уведомления клиентов — см. https://courses.digitable.life/post/security/15-privacy-and-compliance/) и поддержка (её нужно обучить до анонса, а не после первой волны обращений).

6.2. Календарь

Две вещи, которые видно только на таком календаре: обучение людей идёт параллельно эксперименту (иначе к анонсу продажи не готовы), а обзор результатов стоит через шесть недель после анонса — раньше смотреть бессмысленно (раздел 8).

7. Готовность: Go / No-Go

Список проверок перед включением. Он намеренно короткий — длинные чек-листы не читают:

Продукт. Основной сценарий проходится без подсказок; известные дефекты записаны и оценены; флаг выключается без релиза; данные не теряются при откате.

Данные. События размечены и проверены на бете; дашборд запуска существует и показывает осмысленные числа; guardrail-метрики выбраны заранее (https://courses.digitable.life/post/product-management/08-analytics-and-decisions/).

Люди. Поддержка знает, что меняется и как отвечать; продажи умеют показывать; есть один дежурный продакт на первые три дня.

Документы. Справка и changelog обновлены; оферта и тарифы согласованы; уведомления отправлены в требуемые сроки.

Отход. Записан критерий отката (например: «ошибка оформления заказа выросла больше чем на 0,5 процентного пункта — выключаем») и известно, кто принимает это решение в выходной.

Формула решения: No-Go по умолчанию. Запуск состоится, если каждый ответственный сказал «да»; молчание — это «нет». Это дешёвая практика, которая экономит очень дорогие откаты.

8. Метрики запуска: как не перепутать всплеск с результатом

8.1. Форма кривой

Первые дни после анонса — это измерение любопытства, а не спроса. Всплеск создают письмо, пост и внутренние ссылки; он спадает за 1–3 недели. Реальный результат — уровень плато относительно базовой линии. Практическое правило: окно оценки начинается не раньше чем через две недели после анонса и длится не меньше двух недель.

Отдельная ловушка — эффект новизны в экспериментах: пользователи трогают новое просто потому, что оно новое, и краткосрочный тест показывает завышенный эффект. Симметричная ловушка — эффект первичности: привычные пользователи сначала работают медленнее, потому что интерфейс изменился, и тест показывает заниженный эффект. Обе разбираются в https://courses.digitable.life/post/product-management/05-mvp-and-experiments/; лечение одно — достаточная длительность и сравнение эффекта в первую и последнюю неделю теста.

8.2. Что считать

def launch_scorecard(daily: list[dict], baseline_days: int = 14, window_start: int = 14) -> dict:
    """Сводка запуска: всплеск, плато и прирост к базовой линии.

    daily: [{'day': -14..N, 'users': int, 'activated': int}, ...]
           отрицательные дни — до анонса (базовая линия), 0 — день анонса.

    Время: O(|daily|), память: O(1).
    """
    base = [d for d in daily if -baseline_days <= d["day"] < 0]
    spike = [d for d in daily if 0 <= d["day"] < 7]
    plateau = [d for d in daily if d["day"] >= window_start]

    def avg(rows, key):
        return sum(r[key] for r in rows) / len(rows) if rows else 0.0

    base_users, plateau_users = avg(base, "users"), avg(plateau, "users")
    return {
        "base_users_day": round(base_users, 1),
        "spike_peak": max((d["users"] for d in spike), default=0),
        "plateau_users_day": round(plateau_users, 1),
        "lift_vs_base": round(plateau_users / base_users - 1, 3) if base_users else None,
        # доля тех, кто дошёл до ценности, важнее числа заглянувших
        "activation_rate_plateau": round(avg(plateau, "activated") / plateau_users, 3)
        if plateau_users else None,
    }


# Показательный пример: пик в 6 раз выше базы, а плато — всего +12%.
# Такой запуск считается неуспешным, хотя «в день анонса всё горело».

Набор метрик, который стоит смотреть в этом порядке:

1. Guardrails — ошибки, латентность, конверсия ключевого сценария, обращения в поддержку. Если они пробиты, остальное неважно.
2. Достижимость — сколько людей из целевого сегмента вообще узнали (охват канала).
3. Пробное использование — сколько попробовало.
4. Активация — сколько дошло до ценности (определение — из https://courses.digitable.life/post/product-management/02-metrics/).
5. Удержание фичи — сколько вернулось на 2-й и 4-й неделе. Это и есть ответ на вопрос «нужно ли это было».
6. Влияние на деньги — конверсия в платящих, апгрейды, отток.

Первые три метрики измеряют качество запуска, последние три — качество продукта. Их регулярно путают, и из-за этого делают неверные выводы: слабый анонс списывают на плохую фичу и наоборот.

8.3. Когда объявлять результат

Заранее, до анонса, запишите три числа: что считаем успехом, что — провалом, и когда смотрим. Формулировка вида «плато активации ≥ 25% от целевого сегмента на 4-й неделе; ниже 10% — сворачиваем инвестиции» экономит месяцы споров. Без записанного заранее критерия любой результат объявляется успехом задним числом — этот механизм в https://courses.digitable.life/post/product-management/08-analytics-and-decisions/ разбирается как HARKing.

9. Если запуск не сработал

Провал запуска — норма, а не катастрофа: доля успешных изменений в зрелых продуктах невелика (https://courses.digitable.life/post/product-management/00-overview/). Важно отделить причины, потому что лечение у них разное:

Отдельно стоит провести постмортем запуска — по тем же правилам, что и разбор инцидентов: без поиска виноватых, с фиксацией системных причин и одним-двумя изменениями в процессе (формат — https://courses.digitable.life/post/technical-writing/06-postmortem/).

10. Как это выглядит в проде

• Календарь запусков на квартал, где видно уровни (T1/T2/T3) и загрузку маркетинга и поддержки — без него все команды планируют T1 на один и тот же месяц.
• Шаблон запуска в трекере: чек-лист готовности, ответственные, ссылки на дашборд и флаг.
• Единая точка правды по сообщению: один документ, из которого маркетинг, продажи и продукт берут формулировки. Расхождение формулировок между лендингом и скриптом продаж — типичный источник «обещали не то».
• Регулярный (раз в 6 недель) обзор запусков: что запускали, что дало плато, какие уроки. Это единственный способ научиться запускать лучше — обратная связь по запускам иначе не замыкается.

11. Типичные ошибки

• Считать успехом день анонса. Пик всплеска не коррелирует с итоговым плато.
• Запускать всё как T1. Аудитория выгорает, команда выгорает, сигнал теряется.
• Не готовить поддержку. Дешевле всего предотвратить, дороже всего чинить.
• Раскатывать на 100% сразу. Теряется и безопасность, и возможность измерить.
• Оставлять флаги навсегда. Флаг без владельца и срока — это техдолг и источник инцидентов.
• Оценивать канал по CAC без удержания. Дешёвый трафик, который не остаётся, — это расход.
• Обещать в анонсе то, чего нет. Возврат к «через месяц допилим» разрушает доверие быстрее, чем отсутствие фичи.
• Не записывать критерий успеха заранее. Тогда результат всегда «в целом позитивный».

12. Мини-итог

• GTM — согласованность шести вещей: сегмент, сообщение, канал, цена, процесс продажи, доведение до ценности. Ломается любая пара — ломается всё.
• Раскатка, релиз и запуск — три разных события с разными владельцами и метриками; совмещать их в одну дату вредно.
• Уровни запуска экономят внимание: T1 редко, T2 регулярно, T3 по умолчанию, но обязательный минимум (changelog, справка, поддержка) — всегда.
• Каналы различаются CAC, ёмкостью и временем отклика; из-за убывающей отдачи бюджет распределяют по предельной стоимости клиента, а не «весь в самый дешёвый».
• Кольцевая раскатка с флагом отвечает на разные вопросы на каждом кольце и позволяет откатиться без релиза.
• Метрики запуска читают по плато, а не по всплеску; критерий успеха записывают до анонса.
• Провалившийся запуск диагностируется по этапу воронки: узнали → попробовали → дошли → вернулись → заплатили. Лечение разное на каждом этапе.

Источники

• Colin Bryar, Bill Carr, «Working Backwards» (2021) — PR/FAQ и практика Amazon: https://www.workingbackwards.com/
• Martin Fowler, «Feature Toggles (aka Feature Flags)» — типы флагов и их жизненный цикл: https://martinfowler.com/articles/feature-toggles.html
• Google SRE Book, «Canarying Releases» — безопасная раскатка: https://sre.google/workbook/canarying-releases/
• Andrew Chen, «The Cold Start Problem» (2021) — про запуск сетевых продуктов и ёмкость каналов: https://www.coldstart.com/
• Kohavi, Tang, Xu, «Trustworthy Online Controlled Experiments» (2020) — эффект новизны и длительность измерения: https://experimentguide.com/
• Amazon Working Backwards Press Release, разбор Ian McAllister: https://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management

Что дальше

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

B2B и enterprise: покупатель — не пользователь