Два продукта, одна дорожная карта: как заметить расхождение раньше

Как это выглядит

Обычно всё начинается с roadmap, который на бумаге выглядит очень эффективно. Команда выпускает продукт из одной кодовой базы, одного backlog и одного набора release notes. Но приходят две группы покупателей с разными причинами купить, и в итоге они на самом деле видят не один и тот же продукт.

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

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

Sales тоже быстро это чувствует. Один потенциальный клиент хочет быстрый self-serve trial и простой месячный тариф. Другой хочет долгий цикл покупки, проверку безопасности, особые условия и обещания по пунктам roadmap, которые пока звучат расплывчато. Когда sales снова и снова просит исключения, чтобы закрыть сделки, это часто не проблема сообщения, а конфликт покупателей.

Support слышит разделение совсем прямо. Один новый клиент спрашивает: «Как начать уже сегодня?» Другой спрашивает: «Как это встроить в структуру нашей команды и в процесс согласований?» Когда onboarding, документация и звонки в support всё время уходят в два очень разных сценария, рынок уже разделился, даже если команда ещё не сказала этого вслух.

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

Где трещины появляются первыми

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

Pricing часто даёт самый ранний сигнал. Одной группе нужны простые seat, предсказуемые лимиты и быстрое согласование. Другой нужны индивидуальные условия, проверка безопасности или pricing, зависящий от использования. Если команда навязывает одну модель pricing обеим группам, одна сторона чувствует переплату, а другая — что её потребности не учли.

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

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

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

Некоторые признаки повторяются снова и снова. Одна и та же функция для одного покупателя «слишком простая», а для другого — «слишком сложная». Sales всё чаще просит индивидуальные пакеты. В support начинают расти разные группы тикетов, связанные с разными задачами. Customer success начинает отслеживать разные определения успеха для разных аккаунтов.

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

Сравните покупателей рядом

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

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

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

Обратите внимание на разницу между тем, кто подписывает контракт, и тем, кто пользуется продуктом. Если в одной группе это один и тот же человек, а в другой — руководитель покупает для команды, ваш sales motion сразу меняется. Демо, onboarding, pricing и support начинают тянуть в разные стороны.

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

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

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

Как проверить разделение

Начинайте с данных, а не с мнений. Возьмите последние 15–20 успешных и неуспешных сделок и разложите их по типу покупателя. Оставьте всё простым: кто купил, кто отказался, что им было нужно в первую очередь и что заблокировало сделку.

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

Посмотрите на работу вокруг продукта

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

Ищите кластеры. Небольшие команды могут просить скорость, шаблоны и меньше шагов. Крупные команды — права доступа, audit trail и больше помощи во время запуска. Когда один и тот же код обслуживает обе группы, нагрузка на support начинает делиться ещё до того, как это признает оргструктура.

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

Поставьте эти пути рядом. Если одна группа закрывается после короткого демо, а другой нужны проверка безопасности, индивидуальный pricing и несколько follow-up, это уже не один чистый sales motion.

Сравните стоимость того, чтобы удерживать каждого покупателя довольным

Теперь проверьте, сколько времени уходит на настройку, обучение и работу на продлении для каждой группы. Считайте часы, а не ощущения. Если группе A хватает 30 минут на setup, а группе B нужны две недели onboarding, эта разница важна. Если одна группа продлевается тихо, а другой каждый квартал нужен большой объём работы по аккаунту, это тоже важно.

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

Хорошая проверка заканчивается простым ответом: оставить один продукт с более чётким позиционированием или намеренно разделить опыт. Опытный Fractional CTO обычно может провести такой аудит за неделю, потому что подсказки уже лежат в sales notes, очередях support и работе по onboarding.

Что можно оставить общим

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

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

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

Здесь хорошо работает простое правило. Оставляйте что-то общим, если обе стороны без споров приняли бы одно и то же поведение. Разделяйте это, если sales стал бы продавать это по-разному, если onboarding требует других вариантов настройки или обучения, или если support нужен другой сценарий ответа на тот же вопрос.

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

Backlog должен следовать этой реальности. Оставляйте один общий backlog только для работы, которая явно помогает обеим сторонам. Исправления общих ошибок туда относятся. Туда же входят работы по производительности, базовые обновления безопасности и внутренние инструменты, которые используют оба сценария. Но если задача полезна только одному типу покупателя, убирайте её из общего потока. Иначе более сильный sales motion будет постоянно побеждать, а второй продукт постепенно начнёт деградировать.

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

Простой пример из растущей SaaS-команды

Представьте SaaS-команду с одним продуктом для маркетинговой отчётности. Сначала база клиентов кажется достаточно похожей, чтобы держать всех на одном roadmap. Агентства покупают продукт, чтобы вести много клиентских аккаунтов. In-house маркетинговые команды покупают его, чтобы отслеживать один бренд, один бюджет и одну цепочку согласований.

Какое-то время это пересечение скрывает проблему. Обе группы нуждаются в дашбордах, данных по кампаниям, запланированном экспорте и понятных графиках. Один и тот же reporting engine, data model и API могут обслуживать обеих. На бумаге всё ещё выглядит как один продукт.

Разделение проявляется в ежедневной работе. Клиенты-агентства просят быстро переключаться между клиентами, делать branded reports для каждого клиента и жёстче контролировать seat, чтобы аккаунт-менеджеры видели только нужные аккаунты. Им также нужны reusable templates между клиентами, потому что это реально экономит время каждую неделю.

In-house команды просят другое. Им нужны шаги согласования перед отправкой отчётов, представления бюджета, привязанные к кампаниям, и гораздо более короткая настройка, потому что они не запускают onboarding сразу для десяти клиентов. Им меньше нужны отчёты с брендированием и больше — внутренняя прозрачность.

На этом этапе у команды всё ещё общий код, но уже нет общего packaging. Sales calls тоже расходятся. Агентства лучше реагируют на «управляйте многими клиентами в одном месте». In-house покупатели — на «контролируйте расходы и согласования без лишней админки». Support начинает делиться так же. Одной группе нужна помощь с правами доступа и клиентским output. Другой — с workflow, финансовыми представлениями и запуском внутри одной компании.

Код отчётности может оставаться общим. Обещание клиенту — нет.

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

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

Ошибки, которые делают команды

Первая ошибка обычно маленькая. Команда видит, что две группы хотят разного, и вместо продуктового выбора добавляет переключатели, права доступа и custom settings. В моменте это кажется безопасным. Через полгода приложение становится сложнее продавать, сложнее объяснять и намного тяжелее поддерживать.

Так часто бывает, когда внутри одного roadmap прячутся два продукта, но команда всё равно говорит так, будто продаёт одну вещь. Общий код может какое-то время скрывать разделение. Кодовая база выглядит аккуратно. Бизнес — нет.

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

Следующей часто ломается pricing. Команды пытаются запихнуть покупателей с очень разными бюджетами и привычками покупки в одну модель. Одной группе нужен self-serve и понятная месячная цена. Другой — договоры, согласования и дополнительная поддержка. Если загнать обе группы в один pricing box, одна сторона почувствует переплату, а другая — недополученную ценность.

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

Самая дорогая ошибка — дождаться внутреннего конфликта, прежде чем признать разделение. К этому моменту sales обвиняет product, product обвиняет support, а support несёт боль с обеих сторон. Намного дешевле назвать напряжение рано и решить, что остаётся общим, что нужно разделить и какой покупатель важнее прямо сейчас.

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

Быстрые проверки перед решением

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

Используйте пять быстрых проверок.

1. Посмотрите на homepage. Может ли одно понятное сообщение за несколько секунд объяснить, почему обеим группам покупателей это важно? Если одной группе нужны другие обещания, доказательства или язык, разделение уже есть.
2. Покажите одно и то же демо обеим группам. Если sales нужны дополнительные слайды, другой порядок или отдельный звонок, чтобы убедить одну из групп, значит история продукта больше не одна.
3. Пройдите onboarding. Могут ли большинство новых пользователей достичь первого полезного результата по одному и тому же сценарию? Если одной группе нужна помощь с настройкой, свои значения по умолчанию или передача человеку, а другой — нет, этот разрыв будет только расти.
4. Прочитайте первые вопросы в support. Если обе группы в первый же день спрашивают о разном, support почувствует разделение раньше, чем engineering его признает.
5. Откройте страницу pricing. Могут ли оба покупателя понять, за что платят, без звонка? Если pricing понятен только после долгого объяснения, возможно, вы продаёте два продукта под одной вывеской.

Если не проходят три и более проверки, переставайте насильно удерживать один roadmap. Общий код ещё можно сохранить, но вести себя так, будто продукт один и тот же, уже нельзя.

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

Что делать дальше

Начните с названий, которые понятны клиенту. Не называйте направления Track A и Track B. Назовите их так, как они есть, например «инструмент для self-serve команд» и «сервис для enterprise workflow». Понятные названия быстро останавливают расплывчатые споры о roadmap.

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

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

Разделяйте те части, которые постоянно толкают команду в противоположные решения. Обычно это onboarding, packaging, правила pricing, support-потоки, админские настройки и приоритеты roadmap. Если один покупатель хочет скорость и простоту, а другой — контроль, согласования и custom work, считайте это разными продуктовыми решениями, даже если backend всё ещё частично общий.

Каждому направлению нужна своя метрика успеха, которая соответствует покупателю. Для self-serve продукта это может быть активация в первую неделю. Для продаж через sales — конверсия в сделку, время до запуска или expansion revenue. Если одна метрика снова и снова вредит другой, вы нашли настоящую границу.

Назначьте дату пересмотра до того, как создадите отдельные команды. Четырёх–восьми недель обычно достаточно, чтобы увидеть что-то полезное. Каждый раз смотрите на одни и те же сигналы: потерянные сделки, нагрузку на support, споры о roadmap, задержки релизов и путаницу у клиентов. Если эти показатели успокаиваются, оставляйте одну команду и два понятных направления. Если становится хуже, разделяйте ответственность намеренно.

Многим основателям на этом этапе нужна внешняя помощь. Когда разделение начинает влиять на архитектуру, найм и процессы, это быстро становится дорого. Если вам нужен практический второй взгляд, Oleg Sotnikov на oleg.is делает именно такую Fractional CTO работу: определяет границу, решает, что должно остаться общим, и не даёт roadmap уехать в сторону, пока команда растёт.