Почему внутренний IT-продукт не «взлетает» на рынке?

Многие CPO, CTO, коммерческие директора могут ответить на этот вопрос логически. Но как же сложно без конкретики убеждать топ-менеджмент не совершать 5 роковых ошибок, которые ведут к уходу IT-продуктов с рынка!

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

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

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

⏺ Ваш продукт не подходит пользователям. Другими словами, продукты не соответствуют функциональным и нефункциональным требованиям рыночных заказчиков. Это прямой признак отсутствия product-market fit, хотя PMF характеризуется далеко не только ФТ и НФТ (скоро расскажем про 18 критериев, важных для достижения PMF).

⏺ Стоимость внедрения и перехода является блокирующей. Из-за того, что большинство новых продуктов недостаточно зрелые с точки зрения функциональности «коробки», дотачивание продукта под нужды конкретного заказчика зачастую происходит в ручном режиме. Это выливается в приличные бюджеты (иногда – сотни миллионов рублей). А за эти деньги можно и самостоятельно разработать своё решение. Поэтому многие заказчики находятся на развилке build-or-buу, занимая выжидательную позицию.

⏺ Заказчики не уверены в долгосрочной продуктовой стратегии нового вендора, для которого этот бизнес не является фокусным. Что будет делать вендор, инвестировавший десятки-сотни миллионов рублей в разработку решения, у которого случилось 2-3 случайные продажи и которые требуют дальнейшей поддержки и развития продукта, а новых продаж на горизонте нет?

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

⏺ Заказчики не уверены, что небольшие вендоры «потянут» сложное enterprise-внедрение и удовлетворят все нефункциональные требования. Представьте, что небольшая компания, скажем с 20-30 разработчиками, запилила классное решение. И вот эта компания приходит к серьёзному энтерпрайзу продавать, а тот на вход выдаёт НФТ по информационной безопасности пунктов эдак на 80, из которых половина – критические требования.

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

⏺ Политические возражения. С большой степенью вероятности, компании не купят решения у другой компании в рамках одной отрасли (зачем кормить конкурента по core-бизнесу?), а ДЗО купят только у головнои организации.

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

А теперь самое интересное.

⏺ Внутренний продукт скорее всего будет повторять архитектуру коммуникаций в ключевом заказчика (закон Конвея). Это значит, что продукт изначально будет заточен исключительно под процессы ключевого заказчика. Здесь исход понятен сразу: ключевой заказчик будет считать, что его идеология оптимальна и он несёт свет остальным, поэтому все должны быть счастливы купить его продукт. А если не покупают, то «это вы не умеете продавать».

⏺ Внутренний продукт, скорее всего, будет слабо кастомизируемым. Давайте прямо: на ранних стадиях внутренний продукт – это хардкод на 100% или около того, и именно таким его выпускают в мир. Простейшее конфигурирование, требующее пересборки приложения, — это тоже хардкод. Если для каждого нового клиента требуется форк — это тоже хардкод, причём ведущий к дублированию продукта (10 продаж = 10 продуктов, и попробуйте теперь отказать своим клиентам услугу сопровождения и поддержки).

Между таким хардкодом и настройкой мета-модели, процессов и другой бизнес-логики в Runtime через UI-администратора (с возможностью плагинизации и автоматическим масштабированием), лежит ~2 года доработок и x2 инвестиций в плюс к уже потраченным бюджетам.

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

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

⏺ Внутренний продукт обязательно будет завязан на внутренний ИТ-ландшафт в части интеграций. Ключевой заказчик обязательно захочет использовать свои сервисы авторизации и аутентификации, всякие AD / ADFS, подключение к своим источникам мастер-данных, публикацию API по своим правилам. Хорошо, если эти компоненты он разрешит забрать и в рынок. Но с 80% вероятностью это будет за пределами вашего бюджета, либо текущие владельцы компонентов и интеграций не захотят поддерживать экземпляры / внести доработки, необходимые рыночной версии продукта.

А значит, все интеграционные компоненты продукта нужно будет переделать под рынок и поддерживать их развитие. (Вы ведь сразу заложили под это бюджет, да?) Потребуется создать адаптеры и передать их на поддержку команде внедрения материнской компании. (Ведь такая команда ведь есть? И команда развития продукта и команда внедрения «мамы» ведь разделены изначально?) В общем, с крайне высокой вероятностью ножницы для «перерезания пуповины» – технического отделения вашего продукта от материнской компании – в бюджет не заложены и встанут в копеечку.

⏺ Внутренний продукт не будет содержать критическую пользовательскую функциональность, потому что она закрывается другими корпоративными системами ключевого заказчика. Высока вероятность, что исполнитель внутреннего заказчика сделает автомобиль без приборной панели, потому что приборная панель уже есть у ключевого заказчика (не потому что исполнитель сам так решил, а потому что ему так сказали). А что до потребностей рынка в приборной панели – см. ответ в пункте 3: «Сначала идите и продайте, потом за вырученные деньги допилите, что нужно рынку». Да, идите и продайте автомобиль без приборной панели.

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

⏺ Бэклог ключевого заказчика всегда будет более приоритетен, чем рыночный бэклог. Любая фича ключевого заказчика, даже категории Should Have или Would Have, будет преподноситься продуктовой команде как Must Have. А если вы будете внедрять систему груминга бэклога на основе взвешенного подхода (RICE, MoSCoW и т. д.), то вы просто забыли, кто вам платит зарплату. Вспоминайте и делайте то, что нужно ключевому заказчику!

⏺ Размыты границы ответственности между подразделениями. Основной заказчик считает, что команда развития отвечает и за успех внедрения, при этом архитекторы «мамы» пытаются управлять вашим архитектурным решением не неся за это ответственности, тикеты с дефектами кочуют по линиям поддержки внутри материнской оргструктуры и оказываются у вас уже на последних секундах SLA… Эти и другие увлекательные аттракционы ждут вас!

⏺ Сквозные мотивации (как вертикальные, так и горизонтальные), как правило, отсутствуют. Если за разработку и коммерциализацию отвечают разные люди, то разработка и окупаемость являются параллельными прямыми, уходящими в бесконечность. Плохой сценарий: если вам ответят, что этим руководит один человек, но он разработчик, тогда шансов окупиться нет, равно как и стать рыночным вендором. Худший сценарий: если этот разработчик считает, что он бог в коммерции. Тут нужны сквозные мотивации на рыночных успех: от команд разработки (включая разработчиков внутри команды) и до C-level управленцев и даже выше. Причем KPI должны быть значимыми, а не по 10 %.

В итоге разработка и продажи тычут пальцем друг в друга:

– «Вы не умеете продавать!»

– «Нет, это у вас нет продукта!»

И хором – на маркетинг: «А вы вообще не пойми что за лиды нам гоните!».

Этот гордиев узел разрубает высший C-level, который живё в парадигме, что его продукт – самый лучший, и единственно верным решением объявляет, что все проблемы – в продажах и продавцах.

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

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

Хотите узнать об этом подробнее? Совсем скоро в нашем телеграм-канале выйдет пилотный выпуск подкаста, где мы поговорим в том числе об этом.

🚀 Подпишитесь на канал «Корпорация делает софт», чтобы не пропустить всю самую пользу и практику.