Жизненный цикл продукта: зрелость, каннибализация, депрекация и закрытие

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

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

1. Жизненный цикл: не метафора, а измеримая форма

1.1. Откуда берётся S-кривая

Рост через распространение (люди узнают друг от друга, отделы копируют соседей) при конечном рынке даёт логистическую динамику. Пусть N — потолок сегмента, x(t) — сколько уже принято:

dx/dt = r · x · (1 − x/N)

Скорость роста пропорциональна и числу уже принявших (есть кому рассказывать), и остатку рынка (есть кому рассказывать). Отсюда S-образная кривая: медленный старт, почти линейный рост, насыщение. Похожую форму даёт и модель диффузии инноваций Роджерса (новаторы → ранние последователи → раннее большинство → позднее большинство → отстающие), и модель Басса, которая разделяет вклад рекламы и «сарафана».

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

1.2. Оценка потолка по своим данным

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

def logistic_ceiling(x0: float, x1: float, x2: float) -> dict:
    """Оценка потолка логистического роста по трём равноотстоящим точкам.

    Для логистики величина y = 1/x удовлетворяет линейному рекуррентному
    соотношению, откуда потолок восстанавливается в замкнутой форме:
        N = (x1^2 * (x0 + x2) - 2 * x0 * x1 * x2) / (x1^2 - x0 * x2)
    Это классический приём оценки (метод трёх точек, Родс, 1940).

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

    Время: O(1), память: O(1).
    """
    denom = x1 * x1 - x0 * x2
    if abs(denom) < 1e-9:
        return {"ceiling": None, "note": "рост ещё почти экспоненциальный, потолок не виден"}
    ceiling = (x1 * x1 * (x0 + x2) - 2 * x0 * x1 * x2) / denom
    stage = (
        "ранний рост" if x2 < 0.3 * ceiling
        else "активный рост" if x2 < 0.7 * ceiling
        else "насыщение"
    )
    return {"ceiling": round(ceiling), "current": round(x2),
            "share_of_ceiling": round(x2 / ceiling, 2), "stage": stage}


# Активные аккаунты по кварталам: 1 200 → 2 300 → 3 600
print(logistic_ceiling(1200, 2300, 3600))
# {'ceiling': 6255, 'current': 3600, 'share_of_ceiling': 0.58, 'stage': 'активный рост'}

# Год спустя: 4 900 → 5 500 → 5 800
print(logistic_ceiling(4900, 5500, 5800))
# {'ceiling': 6118, 'current': 5800, 'share_of_ceiling': 0.95, 'stage': 'насыщение'}

Второй расчёт — сигнал к разговору не о том, «как ускорить рост», а о том, «какой следующий сегмент или продукт». При этом потолок N не абсолютен: он относится к текущей комбинации сегмент × канал × цена. Меняете любую из трёх — получаете другую кривую. Именно поэтому оценка потолка и работа с рынком из https://courses.digitable.life/post/product-management/09-market-and-competition/ — один и тот же разговор.

1.3. Признаки зрелости, которые видно раньше выручки

Выручка — запаздывающий индикатор; к моменту, когда упала она, реагировать поздно. Опережающие признаки:

2. Что делать в зрелости

2.1. Четыре стратегии и их цена

1. Углубление в текущем сегменте. Больше ценности тем же клиентам: расширение сценариев, повышение цены за счёт ценности (https://courses.digitable.life/post/product-management/07-pricing-and-growth/). Дёшево, но потолок виден.
2. Новый сегмент со старым продуктом. Соседняя отрасль, другая страна, другой размер компаний. Требует работы из https://courses.digitable.life/post/product-management/09-market-and-competition/: сегмент, ICP, канал, цена.
3. Новый продукт для старых клиентов. Максимальная синергия по каналу и доверию — самая частая рабочая ставка зрелых компаний.
4. Новый продукт для нового сегмента. Самая рискованная клетка; фактически новый стартап внутри компании, и относиться к нему нужно так же (гейты из https://courses.digitable.life/post/product-management/05-mvp-and-experiments/).

2.2. Вторая S-кривая: когда начинать

Правило, известное как «прыжок на вторую кривую» (Чарльз Хэнди): следующую кривую начинают, пока первая ещё растёт — примерно на 60–70% пути к потолку. Причина арифметическая: новая ставка требует денег и внимания, а они есть только пока старый продукт зарабатывает. Если ждать спада, инвестировать станет не из чего, и компания начнёт резать расходы вместо строительства нового.

Организационная сложность в том, что в этот момент все данные говорят против: первая кривая растёт, метрики хорошие, а новая ставка выглядит маленькой и убыточной. Отсюда практика явного разделения бюджета (правило 70/20/10 из https://courses.digitable.life/post/product-management/04-strategy-and-roadmap/) и отдельной оценки H3-ставок — по обучению, а не по выручке.

2.3. Каннибализация: съедать себя осознанно

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

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

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

3. Инвентаризация функций

3.1. Факт, с которым живут все продукты

Доля функций, которыми почти никто не пользуется, в зрелых продуктах велика: измерения Pendo по телеметрии сотен B2B-приложений дают около 80% функций, используемых редко или никогда (Pendo, «The 2019 Feature Adoption Report»). Более ранние наблюдения Standish Group по заказным системам дают близкую картину. Числа спорны в деталях, но порядок устойчив: хвост длинный.

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

3.2. Карта функций

Ось Y здесь принципиальна. Соблазн — удалять всё, чем редко пользуются; но «права на уровне строк» используют 5% аккаунтов, и это те самые enterprise-клиенты, без которых выручки не будет (https://courses.digitable.life/post/product-management/11-b2b-and-enterprise/). Правильный критерий удаления — низкое использование И низкий вклад в удержание/выручку, причём вклад проверяют по деньгам, а не по мнению.

3.3. Стоимость владения функцией

from dataclasses import dataclass


@dataclass(frozen=True)
class Feature:
    name: str
    users_30d: int              # уникальные пользователи за 30 дней
    accounts_30d: int           # уникальные аккаунты
    blocked_arr: float          # выручка, которая уйдёт, если функцию убрать
    support_tickets_year: int
    dev_weeks_year: float       # поддержка, дефекты, миграции
    ui_complexity: float        # 0..1 — сколько «шума» добавляет остальным


def feature_tco(f: Feature, week_cost: float = 250_000,
                ticket_cost: float = 1_500, ui_tax_year: float = 400_000) -> dict:
    """Годовая стоимость владения функцией против удерживаемой ею выручки.

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

    Время: O(1), память: O(1).
    """
    cost = (f.dev_weeks_year * week_cost
            + f.support_tickets_year * ticket_cost
            + f.ui_complexity * ui_tax_year)
    ratio = f.blocked_arr / cost if cost else float("inf")
    if f.blocked_arr == 0 and f.users_30d < 10:
        verdict = "удалять"
    elif ratio < 1:
        verdict = "упростить или удалить"
    elif ratio < 3:
        verdict = "держать, не развивать"
    else:
        verdict = "ядро"
    return {"feature": f.name, "cost_year": round(cost),
            "blocked_arr": round(f.blocked_arr), "ratio": round(ratio, 2),
            "verdict": verdict}


catalog = [
    Feature("Права на уровне строк", 340, 14, 26_000_000, 40, 1.5, 0.10),
    Feature("Экспорт в XML",         6,   3,  0,          22, 0.8, 0.05),
    Feature("Второй язык",           90,  7,  1_200_000,  15, 2.0, 0.25),
]
for f in catalog:
    print(feature_tco(f))
# {'feature': 'Права на уровне строк', 'cost_year': 477500, 'blocked_arr': 26000000, 'ratio': 54.45, 'verdict': 'ядро'}
# {'feature': 'Экспорт в XML',         'cost_year': 253000, 'blocked_arr': 0,        'ratio': 0.0,   'verdict': 'удалять'}
# {'feature': 'Второй язык',           'cost_year': 622500, 'blocked_arr': 1200000,  'ratio': 1.93,  'verdict': 'держать, не развивать'}

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

4. Депрекация функции

4.1. Жизненный цикл функции

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

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

• Сроки уведомления, зависящие от типа: API и интеграции — 6–12 месяцев; функция интерфейса — 1–3 месяца; экспериментальная функция — можно сразу, если это было объявлено при включении.
• Каналы уведомления: письмо администраторам аккаунта, баннер в самом месте функции, запись в changelog, ответ API с заголовком-предупреждением, обзвон крупных клиентов.
• Что предлагается взамен: путь миграции с инструкцией и, желательно, инструментом. «Удаляем, разбирайтесь сами» — самый дорогой способ сэкономить.
• Что с данными: экспорт, срок хранения, что удаляется безвозвратно.
• Исключения: как получить продление и до какого предела.

Для API-контрактов действует отдельная дисциплина версионирования и совместимости — она разобрана в https://courses.digitable.life/post/architecture-patterns/07-api-styles/ и https://courses.digitable.life/post/software-distribution/11-updates-and-versions/.

4.3. План депрекации

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

4.4. Метрики депрекации

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

5. Закрытие продукта

5.1. Как принимается решение

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

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

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

5.2. Чек-лист выхода

1. Обязательства. Что написано в договорах и оферте: сроки уведомления, возвраты, гарантированное время доступа к данным. Юридическая проверка — до объявления, не после.
2. Данные клиентов. Экспорт в понятном формате, срок доступности, срок удаления, ответ на вопрос «а что с нашей историей».
3. Замена. Куда переходить: ваш другой продукт, партнёр, конкурент. Честно указать конкурента, если замены у вас нет, — дешевле, чем испорченная репутация.
4. Сроки. Дата остановки регистраций, дата остановки биллинга, дата отключения, дата удаления данных. Биллинг останавливают первым — брать деньги за закрывающийся сервис нельзя.
5. Коммуникация. Прямое письмо каждому клиенту (не только баннер), объяснение причины без тумана, персональный контакт для крупных.
6. Люди. Что будет с командой — сообщается внутри до внешнего объявления.
7. Инфраструктура. План остановки: домены, платежи, интеграции, ключи, резервные копии, счета в облаке.

5.3. Что отличает хорошее закрытие от плохого

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

Хорошее закрытие: длинный срок, персональные уведомления, работающий экспорт, помощь с миграцией, иногда — открытие кода или передача проекта сообществу. Показательный контрпример из индустрии — закрытие Google Reader (2013): объявление за три месяца, при этом продукт был встроен в рабочие процессы тысяч людей; история до сих пор используется как аргумент «зачем полагаться на чужой сервис». Это долгая репутационная цена за короткое операционное решение.

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

• Регулярная инвентаризация функций (раз в полгода): использование, стоимость владения, вердикт. Из неё рождается очередь на удаление — и она конкурирует за ёмкость на общих основаниях.
• Бюджет на удаление: фиксированная доля ёмкости (5–10%) на упрощение и депрекацию. Без квоты удаление всегда проигрывает новой функции.
• Политика депрекации как публичный документ — особенно если у вас есть API. Клиенты должны знать правила заранее.
• Флаги с датой смерти. Каждый флаг раскатки (https://courses.digitable.life/post/product-management/10-go-to-market-and-launch/) имеет владельца и срок; просроченные флаги попадают в отчёт.
• Ревизия ставок раз в квартал: какие продукты и направления живы, какие в спаде, где вторая кривая. Связано с портфелем из https://courses.digitable.life/post/product-management/04-strategy-and-roadmap/.

Инженерная сторона того же разговора — управление техническим долгом и эволюция системы: https://courses.digitable.life/post/engineering-leadership/10-tech-debt/ и https://courses.digitable.life/post/sdlc-and-career/07-support-and-techdebt/.

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

• Читать плато как провал команды. Насыщение заложено в динамике рынка; давление «расти в том же сегменте» сжигает людей и не работает.
• Начинать вторую кривую поздно. Когда выручка уже падает, денег на новую ставку нет.
• Бояться каннибализации. Не съедите себя вы — съест конкурент, и без вашего контроля.
• Удалять по использованию, не глядя на выручку. Функция для 5% аккаунтов может держать половину денег.
• Депрекация без пути миграции. Это не удаление функции, а удаление клиента.
• Слишком короткий срок для API. Интеграции живут годами; полгода — практический минимум.
• Не считать высвобожденное время. Без этой цифры удаление выглядит как каприз и всегда проигрывает приоритизацию.
• Тихое закрытие. Экономит неделю коммуникации и стоит годы доверия.

8. Мини-итог

• Замедление роста описывается логистикой и предсказуемо: потолок оценивается по своим данным, и он относится к паре «сегмент × канал × цена».
• Признаки зрелости видны раньше выручки: растущий CAC, отсутствие новых сценариев, рост доли поддержки, удлинение цикла сделки.
• Вторую S-кривую начинают на 60–70% пути к потолку — когда деньги и время ещё есть; это требует отдельного бюджета и отдельных критериев оценки.
• Каннибализировать себя осознанно лучше, чем быть каннибализированным; решение считают на трёхлетнем горизонте.
• В зрелом продукте большая часть функций почти не используется, и каждая стоит денег ежегодно. Решение об удалении принимают по паре «использование × удерживаемая выручка», а не по одной оси.
• У депрекации должна быть записанная политика: сроки, каналы, замена, судьба данных, исключения. Brownout помогает тем, кто не читает писем.
• Закрытие продукта — инвестиционное решение; его качество измеряется тем, что происходит с доверием к следующему вашему продукту.

Источники

• Everett Rogers, «Diffusion of Innovations» — классическая модель принятия новинок: https://www.simonandschuster.com/books/Diffusion-of-Innovations-5th-Edition/Everett-M-Rogers/9780743222099
• Frank Bass, «A New Product Growth for Model Consumer Durables» (1969) — количественная модель диффузии: https://pubsonline.informs.org/doi/10.1287/mnsc.15.5.215
• Charles Handy, «The Second Curve» (2015) — про переход на новую кривую до спада: https://www.penguin.co.uk/books/181139/the-second-curve-by-handy-charles/9781847941329
• Pendo, «Feature Adoption Report» — измерения использования функций в B2B-продуктах: https://www.pendo.io/resources/the-2019-feature-adoption-report/
• Google Cloud, «Deprecation Policy» — пример публичной политики депрекации: https://cloud.google.com/terms/deprecation
• Stripe API versioning — пример совместимости без вынужденных миграций: https://docs.stripe.com/api/versioning
• Clayton Christensen, «The Innovator’s Dilemma» — почему зрелые компании не идут в новую кривую: https://claytonchristensen.com/books/the-innovators-dilemma/

Что дальше

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

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