Что мешает аутсорсинговым компаниям стать продуктовыми: реальные примеры

Многие ИТ-компании, работающие на аутсорсинг, задумываются над тем, чтобы заняться созданием собственных продуктов. Но часто такие попытки не приводят к успеху. Почему? Своими наблюдениями делится Вадим Станкевич, практикующий product-менеджер, преподаватель ИТ-Академии БелХард.

- Судя по бурным обсуждениям проекта декрета о ПВТ 2.0, нет такой аутсорсинговой компании, которая не хотела бы стать продуктовой. Это вполне объяснимо: в продуктовой разработке больше возможностей для масштабирования бизнеса без существенного увеличения издержек.

---

Тем не менее, несмотря на всю привлекательность продуктового ИТ-бизнеса, количество аутсорсинговых компаний в ПВТ заметно превышает число продуктовых. И дело не только в юридических трудностях приема платежей от Amazon, Apple и Google. В чем проблема? Попробуем рассмотреть на нескольких примерах, с которыми в свое время мне довелось столкнуться.

Первое: инвестиции в продукт кажутся ставками в рулетку

Я не один раз беседовал с белорусскими ИТ-бизнесменами, как известными широкой публике, так и не очень. Большинство из них не были готовы инвестировать в программные продукты, поскольку, на их взгляд, риски были неоправданно высоки. Для них были более интересны другие направления: недвижимость, общественное питание, гостиничный бизнес.

Если вспомнить последние громкие новости в белорусском ИТ, то ни в одной из них вы не найдете упоминания о том, что аутсорсинговая компания реинвестировала значительные средства в собственный продукт. Напротив, можно наблюдать обратный тренд: бизнесы, далекие от ИТ, готовы вкладываться в продуктовую разработку. Яркий пример - это вложения «Зубр Капитал» в продуктовую компанию «СофтКлуб», агрегатор av.by.

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

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

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

Решение этой проблемы - изучение специфических для продуктовой разработки методологий (например, Lean, методологии бережливой разработки), и предварительное тестирование рынка. Это позволит понять перспективность дальнейших инвестиций и принять обоснованное решение, стоит ли заниматься данным продуктом, и какую модель развития выбрать. Сделать это можно и самостоятельно, и с помощью консультантов или агентств, если в команде нет собственного «продуктолога» (менеджера по продукту).

Второе: бездумное повторное использование заказных разработок

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

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

Для этого у разработанного на заказ продукта поменяли дизайн и во избежание проблем с заказчиком нашли партнера, который взялся принимать платежи от покупателей за новый продукт. Перспективная, на первый взгляд, идея была реализована следующим образом: компания нашла нескольких стажеров на роль менеджера по продажам. Перед стажерами был поставлен план сделать несколько десятков продаж в России, Беларуси, странах Балтии. При успешном старте планировалось сразу масштабироваться на Западную Европу и США. Тем не менее, несколько месяцев мучений стажеров закончились полным провалом: новый сервис оказался совершенно не востребованным среди хостелов, небольших гостиниц и агроусадеб. Большинство из них отлично справлялись с помощью Excel и 1С, а кое-кому и вовсе хватало записной книжки. Более крупные гостиницы уже давно использовали одну из имеющихся на рынке систем, и переход на новую не планировали, т.к. даже при меньшей стоимости подписки на такую систему затраты на переход окупились бы в лучшем случае через несколько лет.

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

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

Третья: хороший продукт НЕ продает себя сам

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

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

Классический пример: одна из ИТ-компаний презентовала на конкурсе стартапов «соцсеть для соцсетей»: мобильный агрегатор всех сообщений и новостей, приходящих пользователям через Facebook, ВКонтакте, Одноклассники и Мой Мир. В дальнейшем планировалось добавить Viber, WhatsApp, LinkedIn и все другие более-менее популярные средства коммуникации. Зарабатывать планировалось на рекламе, откусывая кусок рекламного пирога у самих социальных гигантов. На вопрос о том, как продукт планирует привлекать пользователей, команда основателей ответила, что «нет ничего проще, они ведь уже есть в этих соцсетях».К сожалению, понимания того, как можно обеспечить переходы людей из соцсетей в новое приложение, у авторов последнего не наблюдалось. Результат такого подхода вполне закономерен: приложение не обновлялось в AppStore и Google Play уже больше года.

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

Идеальная ситуация - это разработка продукта под уже готовое, живое сообщество пользователей, пока что существующее в какой-то другой форме (почтовая рассылка, группа в социальной сети, канал Telegram). Здесь можно вспомнить историю Product Hunt, основатель которого развил его на основе почтовой рассылки, которую сам вел в течение нескольких лет.

Вывод простой

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