Почему инновационный проект может быть технически сильным, но коммерчески слабым

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

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

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

Почему хорошая технология еще не означает хороший бизнес

У разработчиков и покупателей разные точки зрения. Инженер видит:

• архитектуру;
• алгоритмы;
• материалы;
• конструктивные решения;
• производительность;
• точность;
• технические ограничения;
• сложность решенной задачи.

Покупатель видит другое: «Что конкретно изменится в моей работе?»

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

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

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

Простой пример

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

• Что ограничивало клиента раньше?
• Действительно ли скорость была проблемой?
• Что дает ее увеличение бизнесу?
• Экономит ли клиент время или другие ресурсы?
• Позволяет ли обслуживать больше операций?
• Уменьшает ли простои?
• Или существующей скорости ему уже достаточно?

Без ответов на эти вопросы техническая характеристика остается характеристикой.

Какую проблему должен решать инновационный продукт

Одна из распространенных ошибок — начинать описание с продукта. «Мы разработали платформу, которая использует…» Для рынка логичнее начинать с проблемы. «У определенной группы пользователей возникает ситуация X, из-за которой происходит Y». И только после этого появляется технология.

Сильная проблема обладает несколькими признаками

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

Последний признак особенно полезен. Если проблема действительно значима, рынок часто уже использует какую-то альтернативу:

• программное обеспечение;
• оборудование;
• ручной труд;
• подрядчика;
• внутреннюю разработку;
• комбинацию нескольких инструментов;
• организационный процесс.

Даже решение «ничего не менять» является конкурентной альтернативой.

Плохая формулировка

«Компании недостаточно эффективно используют современные технологии». Непонятно:

• кто именно;
• в каком процессе;
• что означает «недостаточно эффективно»;
• к каким последствиям это приводит.

Более полезная логика

Кто → в какой ситуации → сталкивается с какой проблемой → как решает ее сейчас → какие ограничения имеет существующий подход.

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

Почему важно понимать своего покупателя

«Наш продукт нужен промышленным предприятиям» — слишком широкое определение рынка. Даже внутри одного предприятия могут находиться разные участники решения:

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

В разных компаниях эти роли распределяются по-разному. Поэтому фраза «клиенту нравится технология» почти ничего не говорит о вероятности продажи.

Пользователь и покупатель могут хотеть разного

Пользователю может быть важнее удобство. IT-подразделению — интеграция и безопасность. Руководителю — влияние на бизнес-показатели. Финансовому блоку — стоимость и экономическое обоснование. Если продукт решает задачу одного участника, но создает серьезную проблему другому, продажа усложняется.

Для B2B полезно составить карту принятия решения

Такая карта особенно важна для сложных B2B-продуктов с длинным циклом принятия решения.

Как оценивать существующие альтернативы

Инновационные команды часто ищут только прямых конкурентов. Если похожих продуктов мало, появляется вывод:

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

Конкурировать приходится не только с похожими технологиями

Представим систему автоматизации определенной операции. Ее альтернативами могут быть:

• другое специализированное ПО;
• универсальная корпоративная система;
• ручная работа;
• внешний подрядчик;
• собственная разработка клиента;
• изменение бизнес-процесса;
• сохранение текущей модели.

Именно с этими вариантами покупатель фактически сравнивает новый продукт.

Что происходит, если технология сложнее потребности рынка

Инженерная команда естественным образом стремится улучшать разработку:

• Повысить точность.
• Увеличить производительность.
• Добавить алгоритм.
• Расширить функциональность.
• Автоматизировать еще один процесс.

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

У каждой дополнительной возможности есть цена

Она может увеличивать:

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

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

Возникает технологическая ловушка

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

• выбран не тот сегмент;
• проблема недостаточно острая;
• стоимость перехода слишком высока;
• непонятна экономическая ценность;
• продукт трудно внедрять;
• отсутствует доверие к новому поставщику;
• покупатель не видит оснований менять существующий процесс.

Еще одна техническая функция эти препятствия не устранит.

Как понять, что команда слишком рано ушла в разработку

Есть несколько характерных сигналов:

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

Полезный вопрос для команды

Перед следующей крупной доработкой спросите: «Какую подтвержденную проблему покупателя решает эта функция?»

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

Как проверить бизнес-модель

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

1. Кто платит

Не абстрактный «рынок», а конкретный тип клиента.

2. За что платит

• За лицензию?
• Доступ?
• Оборудование?
• Использование?
• Внедрение?
• Другой формат?

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

3. Как происходит продажа

Можно ли приобрести решение относительно быстро или требуется длительная техническая проверка? Нужен ли пилот? Кто участвует в согласовании?

4. Сколько ресурсов требует внедрение

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

5. Что происходит после продажи

Нужны ли:

• сопровождение;
• обновления;
• вычислительные ресурсы;
• техническая поддержка;
• обслуживание оборудования;
• обучение?

Все это влияет на экономику.

6. Может ли модель повторяться

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

Какие гипотезы нужно проверить до масштабирования

Для удобства их можно разделить на четыре группы.

1. Проблема. У выбранной аудитории действительно существует значимая задача?
2. Решение. Технология действительно помогает решать ее лучше приемлемых альтернатив?
3. Покупка. Клиент готов пройти процедуру приобретения и внедрения?
4. Экономика. Компания способна предоставлять решение на условиях, при которых модель остается жизнеспособной? Эти гипотезы связаны. Можно подтвердить проблему, но ошибиться с продуктом. Можно создать хороший продукт, но выбрать неудобную модель внедрения. Можно получить первых покупателей, но обнаружить, что каждое новое внедрение требует слишком много индивидуальной работы. Поэтому развитие инновационного проекта должно проверять не одну гипотезу «нравится ли людям идея», а всю цепочку создания коммерческой ценности.

Какие признаки указывают на коммерческий потенциал

Здесь важно не создавать ложного универсального набора критериев. Для промышленного оборудования, SaaS, медицинской технологии и корпоративной платформы подтверждения будут различаться. Но есть несколько полезных сигналов.

Клиенты узнают проблему

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

Существующее решение имеет ощутимые ограничения

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

Технологическое преимущество связано с ценностью

Можно объяснить цепочку: характеристика технологии → изменение процесса → практический эффект.

Есть конкретный сценарий применения

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

Потенциальные клиенты готовы тратить ресурсы на проверку

Это сильнее, чем фраза «интересная разработка». Например, компания может согласиться выделить специалистов для предметного обсуждения или тестирования. Конкретная форма зависит от рынка и стадии продукта.

Понятен путь к покупке

Известно, кто участвует в принятии решения и какие этапы необходимо пройти.

Решение можно повторять

Следующему клиенту не требуется фактически создавать новый продукт с нуля.

Экономика хотя бы предварительно складывается

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

Как связать технологические характеристики с деньгами клиента

Для B2B это особенно важная задача. Не каждая характеристика обязательно переводится напрямую в рубли. Но ее практическое значение должно быть понятно. Используйте последовательность: техническая характеристика → изменение рабочего процесса → измеримый или наблюдаемый эффект → экономическое значение.

Например:

Алгоритм обрабатывает данные быстрее. Это характеристика. Дальше нужно выяснить:

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

Не придумывайте ROI

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

Если данных пока нет, лучше честно обозначить гипотезу, которую предстоит проверить.

Когда пора говорить с рынком

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

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

Причем полезнее спрашивать о реальном прошлом поведении, чем о гипотетическом будущем. Вопрос «Купили бы вы систему, которая делает X?» может дать вежливый, но малоинформативный ответ. Гораздо содержательнее:

• «Как вы решали X в последний раз?»
• «Какие инструменты использовали?»
• «Что оказалось самым сложным?»
• «Кто принимал решение?»

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

Технологическая экспертиза и коммерческая проверка не заменяют друг друга

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

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

Чек-лист проверки технологического продукта

Перед следующей крупной инвестицией в разработку ответьте на вопросы максимально конкретно.

Проблема

• Кто сталкивается с проблемой?
• В какой ситуации она возникает?
• Как часто?
• Какие последствия создает?
• Как ее решают сейчас?
• Почему существующий подход недостаточен?

Пользователь

• Кто непосредственно работает с продуктом?
• Что для него важно?
• Что может помешать использованию?
• Какие изменения потребуются в привычном процессе?

Покупатель

• Кто инициирует приобретение?
• Кто оценивает технологию?
• Кто отвечает за бюджет?
• Кто может заблокировать внедрение?
• Как выглядит путь от первого контакта до решения?

Альтернативы

• Какие прямые конкуренты существуют?
• Какие косвенные решения используются?
• Может ли клиент решить задачу вручную?
• Может ли разработать решение самостоятельно?
• Что произойдет, если он вообще ничего не изменит?

Ценность

• Какое техническое преимущество имеет продукт?
• Как оно влияет на рабочий процесс?
• Значим ли этот эффект для покупателя?
• Есть ли данные, подтверждающие эффект?

Бизнес-модель

• За что именно клиент платит?
• Как происходит продажа?
• Сколько ресурсов требует внедрение?
• Какие расходы возникают после продажи?
• Можно ли повторить модель для следующего клиента?

Коммерческая проверка

• Разговаривала ли команда с потенциальными пользователями?
• Изучала ли их существующий процесс?
• Есть ли подтверждение проблемы кроме мнения разработчиков?
• Проверялись ли основные барьеры внедрения?
• Известно ли, какие гипотезы пока остаются неподтвержденными?

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

Как не превратить коммерциализацию в попытку «продать любой ценой»

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

Сильная технология должна пройти еще одну проверку — рынком

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

• Есть ли значимая проблема?
• Кто действительно заинтересован в ее решении?
• Почему новый продукт предпочтительнее существующих альтернатив?
• Можно ли превратить эту ценность в повторяемую экономическую модель?

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

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