Продуктовый подход при проектировании фичей в b2b К нам в МД Аудит часто приходят наши клиенты с просьбой за деньги доработать нашу систему под их нужды - добавить отчет, автоматизировать их бизнес-процесс и т.д. В заказной разработке это требовало бы классического пути - написания технического задания, оценка трудозатрат и сроков реализации, подготовка коммерческого предложения, реализация, ну и так далее. Причем заработок идет за счет маржи - разницей между внутренней оценкой и той, что предоставляется заказчику, и может составлять от 50/100/200% в зависимости от рисков проекта. Но мы не студия, а продуктовая компания, по-этому у нас немного другие подходы - мы стараемся найти такой вариант решения проблемы клиента, от которого пришел запрос, чтобы он был потенциально полезным и для других наших клиентов. Как это происходит? После получения запроса от заказчика и анализа бизнес требований мы организуем встречу, на которой присутствуют минимум две роли - продакт и архитектор. Продакт отвечает за видение с точки зрения продукта, а архитектор - с технической точки зрения. Если задача очевидная и решается только одним способом (например, добавить информацию в отчет), то мы выполняем оценку трудозатрат и сроков, готовим описание реализации для клиента и, что очень важно, подсвечиваем полезность этой доработки для других клиентов. Этот отчет мы отправляем аккаунт-менеджеру, который дальше рассчитывает конечную стоимость доработки для заказчика исходя из разных факторов: платежеспособности клиента, его ожиданий, важности сделки и т.д. Если аккаунт-менеджер понимает, что клиент не готов заплатить за эту доработку, то эта самая полезность дает ему возможность быть более гибким в ценообразовании - сделать скидку или поискать других заинтересованных клиентов, чтобы разделить стоимость пополам. Если вариантов решения проблемы клиента может быть несколько, то мы стараемся дать два варианта: вариант "в лоб", который не несет пользы другим клиентам, но можно сделать за короткое время, и "полезный" вариант. Причем вариант "в лоб" часто имеет еще и технические ограничения, например, за счет того, что мы используем Low-Code или костыли, что мы обязательно подсвечиваем в отчете, но в некоторых случаях быстрое и дешевое решение может сильно повысить лояльность клиента, а это значительно важнее моментального заработка. Такой подход позволяет снизить стоимость разработки для клиента до себестоимости, а иногда и ниже, так как прибыль компании формируется за счет подписок и лицензий, а заказная разработка - это, скорее, способ добавить ценность продукту, что в долгосрочной перспективе принесет еще большую прибыль. @beyond_senior