The post has been translated automatically. Original language: Russian
Custom development for a large client is often perceived as a threat to the product vision: you give up once, and the roadmap has already turned into a list of wishlist of several customers, and the development team is working in perpetual service mode. But in our practice, it often happens differently: the client sees the problem before us — he simply formulates it as his own private task, and not as a systemic need of the market.
The difference between these two situations is not always obvious at the time of the request. The client doesn't come with the idea of a feature — he comes with pain. "We need to check configuration changes before they go to the combat system" is not a technical task, it is a description of the risk that the operator's team lives with every day. The task is on our side: to hear a universal problem behind a private inquiry. If its solution is useful not for one operator, but for a whole class of customers, this is no longer custom. It's a product.
This is exactly the case in the SC platform.SMSC has added a routing emulation feature. The request that was at its core sounded like a private engineering task: to make it possible to check how the new routing rules would work on a specific message before the changes affected real traffic. But behind this request there was a pain familiar to any operator: an error in the configuration is detected not in the test environment, but by the dropped delivery rate and tickets from corporate clients.
We implemented this feature and included it in the platform. Today, the operator's engineer can create a new route in the graph editor, run a test message with any parameters through it, and see the detailed processing log — down to the exact error line in the script — even before the changes are published. When we started offering this feature to other clients, it turned out that not all of them formulated such a need on their own. But after seeing how it works and what operational risk it removes, most immediately understood the value.
Not every request goes this way. There are tasks that are truly unique to a particular client — the specifics of the regulatory environment, non-standard integration, and the specifics of the business model. We implement such improvements as separate projects with a separate economy, without trying to stretch them onto a product roadmap. The question that helps us draw this line is: "Is this the task of this client or the task of such clients?" If the answer is the latter, the conversation turns to the development of the platform.
The customer doesn't have to think in terms of a product roadmap — that's not his job. But the vendor must be able to translate private requests into the language of system solutions. Then customer orientation and product vision cease to contradict each other: the former becomes the source of the latter.
Кастомная разработка под крупного клиента часто воспринимается как угроза продуктовому видению: дашь слабину один раз — и вот уже roadmap превратился в список хотелок нескольких заказчиков, а команда разработки работает в режиме вечного сервиса. Но в нашей практике нередко бывает иначе: клиент видит проблему раньше нас — просто формулирует её как свою частную задачу, а не как системную потребность рынка.
Разница между этими двумя ситуациями не всегда очевидна в момент запроса. Клиент не приходит с идеей фичи — он приходит с болью. "Нам нужно проверять изменения конфигурации до того, как они уйдут на боевую систему" — это не техническое задание, это описание риска, с которым живёт команда оператора каждый день. Задача на нашей стороне: услышать за частным запросом универсальную проблему. Если её решение полезно не одному оператору, а целому классу клиентов — это уже не кастом. Это продукт.
Именно так в платформе SC.SMSC появилась функция эмуляции маршрутизации. Запрос, который лежал в её основе, звучал как частная инженерная задача: дать возможность проверить, как новые правила маршрутизации отработают на конкретном сообщении — до того, как изменения затронут реальный трафик. Но за этим запросом стояла боль, знакомая любому оператору: ошибка в конфигурации обнаруживается не в тестовой среде, а по упавшему delivery rate и тикетам от корпоративных клиентов.
Мы реализовали эту возможность и включили её в платформу. Сегодня инженер оператора может выстроить новый маршрут в редакторе графа, прогнать через него тестовое сообщение с любыми параметрами и увидеть детальный лог обработки — вплоть до точной строки с ошибкой в скрипте — ещё до публикации изменений. Когда мы стали предлагать эту функцию другим клиентам, выяснилось, что далеко не все из них формулировали такую потребность самостоятельно. Но увидев, как это работает и какой операционный риск снимает, большинство сразу понимали ценность.
Не каждый запрос проходит этот путь. Есть задачи, которые действительно уникальны для конкретного клиента — особенности регуляторной среды, нестандартная интеграция, специфика бизнес-модели. Такие доработки мы реализуем как отдельные проекты с отдельной экономикой, не пытаясь натянуть их на продуктовый roadmap. Вопрос, который помогает нам провести эту границу: "Это задача этого клиента или задача таких клиентов?" Если ответ — второе, разговор переходит в плоскость развития платформы.
Клиент не обязан думать категориями продуктового roadmap — это не его работа. Но вендор обязан уметь переводить частные запросы на язык системных решений. Тогда клиентоориентированность и продуктовое видение перестают противоречить друг другу: первое становится источником второго.
Share
