Архитектура продукта после первой корпоративной сделки

Что меняется после первой корпоративной сделки

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

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

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

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

Именно поэтому архитектура продукта так важна после первой корпоративной сделки. Команда больше не решает только, что строить. Она решает, каким продуктом хочет стать.

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

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

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

Как сортировать входящие запросы

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

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

Затем разложите запросы по нескольким понятным категориям:

• юридические
• безопасность
• рабочий процесс
• отчётность
• брендинг

Это сразу меняет разговор. Юридические и запросы по безопасности обычно приходят от отдела закупок или из-за проверки IT. Запросы по рабочему процессу приходят от людей, которые пользуются продуктом каждый день. Запросы по отчётности приходят от менеджеров, которым нужны выгрузки, подтверждения или журналы аудита. Брендинг важен, но редко заслуживает той же срочности, что и контроль доступа или работа, которую люди делают внутри продукта.

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

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

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

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

Настройка, функция, сервис или отказ

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

Хорошая архитектура продукта начинается с простого правила: каждый запрос попадает в одну категорию, прежде чем кто-то скажет «да».

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

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

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

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

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

Несколько вопросов помогают разобраться:

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

Последний вопрос часто самый честный. Если ответ «нет», безопаснее всего обычно продать это как сервис или вежливо отказать.

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

Простой процесс принятия решения

Большинство ошибок начинается одинаково: покупатель просит функцию, а команда начинает проектировать, не разобравшись в проблеме.

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

Короткий процесс помогает не дать дорожной карте прогнуться под одного покупателя:

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

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

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

Ставьте границы до того, как обещания продаж накопятся

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

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

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

Один путь для исключений

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

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

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

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

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

Если в процессе участвует фаундер или Fractional CTO, сделайте этот этап согласования явным.

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

Реалистичный пример из SaaS-команды

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

Команда рано делает одну умную вещь. Она перестаёт воспринимать весь список запросов как единый пакет. По каждому пункту принимается отдельное решение.

SSO попадает в продукт. Крупные покупатели часто ждут этого ещё до начала security review, и будущие клиенты, скорее всего, тоже будут этого просить. Это улучшает продукт, не меняя то, как основное приложение работает для меньших аккаунтов.

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

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

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

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

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

Ошибки, которые команды совершают после большой победы

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

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

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

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

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

Несколько ранних признаков выглядят так:

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

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

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

Быстрые проверки перед тем, как вы соглашаетесь

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

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

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

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

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

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

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

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

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

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

Олег Сотников из oleg.is работает со стартапами и небольшими командами над архитектурой продукта, поддержкой в формате Fractional CTO и практичными процессами разработки с приоритетом ИИ. Если ваша первая большая сделка уже начала гнуть дорожную карту, внешний аудит поможет навести порядок в правилах принятия решений, правильно оценить сервисную работу и поставить более жёсткие границы, прежде чем один клиент начнёт рулить компанией.

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