Как собственный продукт поможет IT-компаниям не переживать о завтрашнем дне и еще 5 причин, зачем он нужен

Однажды я понял, что на одной разработке сложных backend-решений не выехать, и мы разработали продукт. Делюсь, как система для управления корпоративными данными помогает моей компании оставаться на плаву и повышать маржинальность на 70—80%, а в перспективе — продавать услуги в 10 раз дороже и увеличить стоимость бизнеса в случае продажи.

Привет! Я основатель IT-компании Satori. Мы работаем в двух направлениях:

Я всегда переживал, что в Satori однажды не придет новый заказчик на разработку. Вот вдруг сейчас с одним закончим работать, а другого не найдем. Тогда в штате было около 20 сотрудников, которым нужно было исправно платить зарплату.

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

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

По поводу диверсификации бизнеса классно высказался Максим Валецкий — у него совсем другое мнение на этот счет. 🙂

Так я понял, что нам тоже нужна диверсификация внутри IT-бизнеса, которая поможет пережить тяжелые моменты. В итоге мы создали DLH — продукт для управления корпоративными данными. Решили делать именно такой продукт, потому что я заметил: при разработке интеграционных решений (ESB) или автоматизации сложных бизнес-процессов, мы всегда сталкиваемся с управлением данных. А еще DLH легко встроить в рабочий процесс и сделать cross-sale.

Сейчас у нас три успешных пилота и на этапе запуска один полноценный коммерческий проект с банком — об этом хочу написать в отдельной статье.

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

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

Спустя время вы доведете продукт до такой степени готовности, что вкладываться останется только в маркетинг. Срок зависит от сложности продукта и зрелости рынка. Чем сложнее продукт, тем дольше времени понадобится, чтобы сделать его зрелым. Например, DLH станет зрелым не раньше чем через 1,5—2 года. А еще, чем более зрелый рынок, тем сложнее занять его долю.

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

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

Менеджерам по продажам проще продавать продукт, а не услугу. Объяснить больше пока не могу, просто заметил такую тенденцию.

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

Заказчик может использовать вашу IT-систему без вендора. Например, так делает amoCRM. Мы в DLH тоже планируем запустить партнерскую сеть. Пока мы намеренно это не делаем, потому что еще сами учимся продавать продукт. К тому же нам критически важна прямая обратная связь от клиентов, чтобы допилить платформу до совершенства. При продаже через партнеров это невозможно на первых этапах.

У системы понятная и стабильная ценность для клиента. Например, продукт закрывает потребность в простом формировании регуляторной отчетности — это будет востребовано, т.к. почти все банки и финтех в этом нуждаются. При этом есть платформенные решения, где ценность пользователю приходится создавать самому. Например, Camunda для автоматизации бизнес-процессов с low-code.

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

Систему может продавать партнер или интегратор. Советую разрабатывать продукт, отчуждаемый от самой компании. Разрабатывать документацию, простые скрипты установки и развертывания. А еще ориентироваться на уровень готовности технологии (УГТ по ГОСТ Р 58048-2017). Так его проще будет продавать в будущем.

В Телеграм-канале «Бэк, дата, 2 апи» делюсь внутрянкой IT-бизнеса и наблюдениями чаще — заглядывайте туда.

Какой у вас опыт разработки своего продукта? Удалось добить его настолько, чтобы только продавать?