5 ошибок вывода внутреннего IT-продукта на рынок

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

Но на практике из соблазнительно ясных 4 шагов вытекает 5 фундаментальных проблем.

Какие? Почему? Давайте разбираться🙂

На первом шаге корпорация часто думает: если продукт нам самим подходит (читай — «крутой»), то деньги потекут рекой. Команда радостно строит финансовую модель: «Средний чек 10 миллионов, продадим 1000 клиентов — вот и выручка в 10 ярдов». То, что это бизнес-модель является математической, и не сойдётся на третьем шаге, будет понятно позже.

На самом деле, на старте можно более-менее реалистично оценить только расходы на разработку. Скорее всего, лицензионная модель для коммерциализации будет опираться на COST+, а это самая неудачная модель для расчёта выхода на рынок (почему и что делать, расскажем в ближайших постах).

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

И дешевле продавать тоже не можем — из-за налоговых рисков материнской компании, которая приобретает продукт по установленной цене (если разработкой занимается «дочка»), и других особенностей финмодели.

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

Акционерам на данном этапе крайне сложно принять мысль, что рыночный запрос будет отличаться от внутренних требований к продукту на 30-40 %. Это станет очевидно только когда продукт выйдет на рынок и никто не захочет его покупать. Внутри компании очень удивятся, ведь материнской корпорации решение подходит и нравится! («Мы же лидеры рынка! Мы же улучшили процессы благодаря продукту в 5 раз! Значит он подходит всем, вы просто не умеете продавать!»)

Помимо методологии, корпорация применит к разработке и свой основной бизнес-процесс: зрелый, обкатанный и… громоздкий.

Это выльется в огромный налог на управление, множественные quality gates и сатанинские танцы с бубнами перед каждым релизом. Расходы на разработку вырастут примерно в 1,5 раза, а скорость разработки — во столько же упадёт.

Вдобавок к этому, материнская компания требует короткий Time to Market, так как ей (в отличие от рыночных клиентов, накатывающих по 6-12 релизов раз в квартал или полугодие) необходимы частый инкремент, и она может его себе позволить. Это дополнительно увеличивает «управленческий налог» ещё в 6-12 раз.

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

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

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

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

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

Что ж… Допустив описанные выше ошибки, корпорация вывела-таки своё детище на рынок. Что получается? Продукт вроде как есть, продаж нет, а значительный бюджет уже потрачен.

Реальная причина отсутствия продаж — в том, что продукт ни разу не рыночный. Но что делает корпорация вместо обидного (ведь придётся признать допущенные упущения), но необходимого разворота разработки лицом к рынку?

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

Кончается история грустно: в конце первого-второго бюджетного цикла акционеры спросят «Где продажи?», но не спросят «Где продукт?». И будут искать ключ не там, где потеряли, а там, где светло. Примут кадровые решения, пройдут ещё 1-2 бюджетных цикла, не увидят изменений и просто свернут инициативу.

Но так ли все плохо на самом деле? Наш ответ — нет! В большинстве случаев всё исправимо, и мы будет исчерпывающе описывать в нашем канале, как это можно делать.

А пока — подпишитесь на наш TG-канал: всё самое ценное — там 🚀
🧑‍💻Поделитесь в комментариях: какие из этих проблем вы прожили на своём опыте? Как было у вас? Какие ещё подводные камни есть в этой модели вывода внутренних продуктов на рынок?