Кто трусы ребятам шьёт?
Уж, конечно, не пилот...
С. Михалков

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

Технический

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

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

Менеджерский

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

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

Реальность

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

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