Стартапы в последние пару лет, мягко говоря, оказались между Сциллой и Харибдой. Многие бизнесы начали сжиматься (а ЦБ стран жестить), а венчурные фонды внезапно стали очень бережливыми. Как поступают стартапы в США в эпоху неопределенности? Правильно, сразу сокращают персонал и закрываются. Сегодня все уже забыли оптимизм постковидного 2021 года.

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

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

Проблема с паттерном "Feature Factory"

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

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

(в Системном Мышлении это называют “Локальной Оптимизацией”)

Начинаем вооружать "продуктовым подходом" с инженерного отдела

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

• Инженерный отдел обычно очень дорогой. Дороже только отдел продаж.

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

Если вы когда-то работали с CTO / VP Engineering - вы наверняка слышали фразу ~"давайте спустимся ваших продуктовых с небес на землю и поговорим про реально важные вещи - как мне мерить что мои инженеры работают эффективно?"

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

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

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

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

• Сколько мы потратили инженерных ресурсов на этот функционал;

• Когда мы выкатили этот функционал;

• Как пользователи взаимодействуют с функционалом, и сколько их;

• Много ли новых пользователей мы получили благодаря этому функционалу;

• Помогает ли функционал продавать больше подписок на ваш сервис;

• Влияет ли он на ARR.

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

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

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

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

А что дальше?

Переходить на продуктовое мышление. Начинать полноценно использовать HADI-цикл. Назначить ответственного за оценку (Inspection) в цикле, ввести регулярные проверки успешности гипотез на Monthly / Quarterly Business Review, убедиться что вы можете проверять ваши гипотезы до имплементации.

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

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

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