Многие продукты в регионе выросли из заказной разработки, и переход происходит незаметно: код общий, а компания продолжает работать как проектная. Признак настоящего перехода один — новый клиент получает решение без разработки под него. Пока каждое внедрение требует программиста, у вас проектный бизнес с общей кодовой базой, и экономика у него другая.
Шесть признаков перехода
- Новый клиент запускается настройкой, а не доработкой. Главный признак; остальные производные.
- Есть версия, а не сборка под клиента. Все на одной версии или на нескольких известных, а не на десяти уникальных.
- Обновление выкатывается всем. А не переносится в каждую сборку отдельно.
- Стоимость обслуживания клиента не растёт с их числом линейно. Проектный бизнес растёт линейно, продуктовый — медленнее.
- Дорожную карту определяет не последний крупный заказчик.
- Продажа не требует участия разработчика.
Что меняется в компании
| Было в проектах | Становится в продукте |
|---|---|
| Оценка задачи под клиента | Приоритет между клиентами |
| Успех — сдали проект | Успех — клиент вернулся и вырос |
| Деньги при подписании и приёмке | Деньги равномерно, с риском оттока |
| Разработчик знает своего клиента | Разработчик не знает клиентов, нужен отдельный канал обратной связи |
| Продажа объёма работ | Продажа результата и обещания развития |
Что ломается в переходе
- Финансовая модель. Выручка растягивается во времени, расходы остаются впереди. Нужен запас, и это главная причина, по которой переход срывается.
- Роли. Появляется человек, отвечающий за продукт целиком, а не за проекты. Без него приоритеты продолжает задавать последний крикнувший клиент.
- Продажи. Продавать продукт и продавать проект — разные разговоры, разные возражения и часто разные люди.
- Поддержка. В проектах её делает тот, кто разрабатывал; в продукте так не масштабируется.
Половинчатое состояние
Что делать с наследством
Уникальные доработки, сделанные для отдельных клиентов, — основной груз при переходе. Разумный порядок: разобрать их, найти повторяющиеся и перенести в общий продукт, а по остальным договориться с заказчиком о переходе на стандартное поведение или об отдельной оплате поддержки. Разговор неприятный, но он бывает один раз, а поддержка уникальных веток длится годами.
Как считать, где вы находитесь
Простой замер: возьмите последние пять запусков новых клиентов и посчитайте по каждому, сколько часов разработки потребовалось. Не настройки и не обучения — именно написания кода.
Если ноль на всех пяти — это продукт. Если ноль на трёх из пяти — переход идёт. Если разработка была во всех пяти, у вас проектный бизнес, и говорить о продуктовой экономике преждевременно, каким бы общим ни был код.
Второй замер: сколько версий работает у клиентов прямо сейчас. Одна-две — продукт. Пять и больше уникальных сборок — вы обслуживаете пять продуктов силами одной команды, и это самая дорогая конфигурация из возможных.
Что происходит с деньгами при переходе
| Проектная модель | Продуктовая модель | |
|---|---|---|
| Когда приходят деньги | При подписании и приёмке | Равномерно, начиная с малого |
| Когда возникают расходы | По ходу проекта | До первой продажи |
| Что определяет рост | Число проданных проектов | Удержание и расширение базы |
| Главный риск | Простой команды между проектами | Отток и медленный набор базы |
| Что нужно для перехода | — | Запас денег на период, когда расходы уже продуктовые, а выручка ещё проектная |
Как перевести существующих клиентов на общую версию
- Разобрать доработки на три группы. Полезные многим — в продукт. Полезные одному, но недорогие в поддержке — оставить как настройку. Полезные одному и дорогие — отдельный разговор.
- По третьей группе поговорить честно. Варианты: переход на стандартное поведение, отдельная оплата поддержки уникальной ветки, или расставание. Третий вариант тоже нормальный.
- Дать переходный период. Полгода-год для корпоративного заказчика — разумно, и это дешевле, чем конфликт.
- Не начинать с самого крупного клиента. Отработайте разговор на среднем, где цена ошибки меньше.
Роль, которой обычно нет
В проектной компании нет человека, отвечающего за продукт целиком. Есть руководители проектов, каждый со своим заказчиком, и технический директор, отвечающий за то, чтобы всё работало. Приоритеты при этом определяет тот, у кого сейчас горит.
Появление продуктового руководителя — самое заметное организационное изменение при переходе, и оно почти всегда встречает сопротивление: со стороны выглядит как лишний человек, который ничего не делает руками. Признак, что роль нужна: в компании регулярно спорят, что делать раньше, и спор решается не аргументами, а статусом спорящих.
Важно, что эта роль не обязательно требует найма. Часто её берёт на себя основатель или технический директор — но берёт явно, с выделенным временем и правом решать, а не в фоновом режиме между проектами.
Частые вопросы
Признак продукта один: новый клиент запускается без разработки. Всё остальное — производное, а промежуточное состояние обходится дороже, чем любой из двух чистых вариантов.
Материал обновлён 3 сентября 2026