Как перестать заваливать пользователей новыми фичами и начать считать приблизительный ROI?

Стартап-индустрия в 2022–2023 годах, мягко говоря, оказалась между молотом и наковальней. С одной стороны, многие бизнесы начали сжиматься (а ставки центробанков расти), с другой — венчурные фонды почти перестали инвестировать. Начались сокращения, стартапы закрывались (и закрываются). Кажется, что 2020–2021 годы со всеобщим оптимизмом и большими раундами инвестиций были где-то там, в другой жизни.

Последние 10 лет я плотно работаю со стартапами, и рынок буквально кричит: “не время делать новые фичи”. Если смотреть на статистику Crunchbase и Dealroom по FinTech / SaaS стартапам, хорошо видна корреляция компаний, которые делали новый функционал на каждый чих, и компании, которые выбрали конкретное направление и фокусировались на его развитии. Логично предположить что в этот сложный период вторые более уверенно стоят на ногах (только если первые не AI).

Проблема с Feature Factory

Благодаря благодатной венчурной почве, особенно в финтехе, много стартапов превратилось в “заводы по поставке фичей” (en: feature factory). И в лучших традициях эти “заводы” не оглядывались назад на выпущенное, не измеряли влияние на экономические метрики. В головах у всех витало “больше фич = больше ценности = больше денег”. Но мы-то с вами знаем, что это далеко не всегда правда.

Техническое руководство часто попадает в ловушку бесконечной оптимизации инженерного отдела: работать эффективнее, доставлять быстрее. Но если оптимизировать только один отдел, то остальной поток создания ценности и его узкие места в рамках организации не меняются. А еще вы упускаете общую картинку.
(в Системном Мышлении это называют “Локальной Оптимизацией”)

Вооружаем инженерный отдел продуктовым подходом

Начнем с двух фактов:

Инженерный отдел обычно очень дорогой. Дороже только отдел продаж.
В сложные времена руководство часто рассказывает про “эффективное расходование средств”, но далеко не всегда бережливое отношение к деньгам значит что пора начинать финансовую оптимизацию, или аутсорсинг.

Самое лучшее проявление “бережливого отношения к деньгам” - это использование ваших умений и возможностей самым оптимальным образом. Что такое оптимально? В Scrum есть Product Owner, и коротко его называют Value Maximizer (ответственен за максимальное нанесение ценности). Попробуйте привнести максимальную ценность с помощью вашего отдела: сфокусируйтесь на общем продуктовом видении и целях, вместо работы над изолированными фичами. Общие цели особенно хорошо улучшают сотрудничество в распределенных командах, так как там вы постоянно сталкиваетесь с потерей контекста и ценности из-за специфики коммуникации (культурной, асинхронной, непрямой).

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

Два инструмента, их которых состоит эта табличка:

1. Проверка ROI Фичи (Feature ROI Check): Этот высокоуровневый инструмент для SaaS-платформ поможет вам понять (навскидку), как ваши уже выкаченные вещи ведут себя в бою. Для каждой фичи мы стараемся отменить:

Сколько мы потратили инженерных ресурсов на этот функционал;
Когда мы выкатили этот функционал;
Как пользователи взаимодействуют с функционалом, и сколько их;
Много ли новых пользователей мы получили благодаря этому функционалу;
Помогает ли функционал продавать больше подписок на ваш сервис;
Влияет ли он на ARR;

<i>Все совпадения в названиях компаний случайны</i>

Представим что вы собираетесь предложить пользователям новый функционал: “Автоматический оценка контрагента Антифрод-системой”. Звучит здорово, не правда ли? Тем не менее, после того как вы поставили функционал клиентам, то обнаружили что пользуется им намного меньшее количество активных пользователей. Было бы здорово узнавать об этом раньше, и менять направление фичи чтобы поставлять то что нужно клиентам.

2. Калькулятор для подсчета инженерных затрат (Engineering Cost Check): Калькулятор помогает вам понять детализацию инвестиций Инженерного отдела на каждую новую фичу. Он оценивает технологические инвестиции (время на разработку, стоимость инженеров, использованные ресурсы и инфраструктуры расходы, а также любые купленные непосредственно для этой поставки сторонние инструменты или сервисы). У меня в подсчетах используется количество времени разработчиков, и добавляется отношение QA / DevOps / Менеджмента на разработчиков. Но если у вас стабильные Agile Cross-Functional команды, почему бы не использовать среднюю цену спринта всей команды - меняйте как хотите.

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

Посмотреть и сохранить эксельку с Калькулятором ROI и Инженерных затрат можно тут. Каждое поле включает в себя заметку про особенности его заполнения. Это должно дать вам хороший data-driven старт для обсуждения с командой и проведения ретроспектив по фичам, которые не смогли оправдать ожидания.

Двигаясь дальше

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

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