(Опыт AI-based fintech KYC SaaS-стартапа для LATAM и Африки)

Типичная боль: Sales, Product и Engineering говорят на разных языках

Наш SaaS-стартап работал на быстро растущих fintech-рынках LATAM и Африки. Там скорость и compliance были вопросом выживания. Большинство стартапов живёт на венчурные деньги с ограниченным runway, поэтому каждый месяц задержки в доставке ценности означает потерянных клиентов, регуляторные риски и более длинный путь к самоокупаемости. Значит, команда должна быть очень бережливой и точной в выборе работы.

У нас реальность выглядела иначе. 85-й перцентиль Feature Lead Time — от создания запроса до production — составлял 244 дня. Почти восемь месяцев проходило от идеи или клиентского запроса до релиза важной фичи. Sales тянул рост и обещал возможности ради сделок, Engineering постоянно переключался между приоритетами, сроки срывались, доверие проседало. История знакомая многим продуктовым организациям. Ниже — как мы развернули этот корабль.

Как мы сломали цикл: совместный STATIK / Value Stream Mapping workshop

Слышали про Kanban Method? Тема большая, начать можно с самого прикладного входа — понять текущую систему. Я регулярно провожу митапы про Kanban и метрики, поэтому для меня естественно применять этот подход к любому потоку работы.

В тот момент я отвечал за Product Operations в Metamap. Задача была простой по формулировке и сложной по исполнению: создать прозрачную систему, которая помогает организации примерно из 500 человек работать синхронно. Мы провели Value Stream Mapping workshop с элементами STATIK — Systems Thinking Approach to Introducing Kanban. Это фасилитированная сессия, где за одним столом оказались Sales, Product и Engineering.

Как это провести:

  • Соберите совместную сессию в Miro, FigJam или офлайн.
  • Нарисуйте реальный workflow: как feature requests попадают в систему.
  • Обсудите, как вы оцениваете и обрабатываете запросы на каждом этапе.
  • Зафиксируйте артефакты, роли и события, которые нужны для процесса.

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

Карта потока создания ценности для feature requests: текущий процесс, узкие места и целевое состояние

Мы нарисовали реальный workflow, подняли на поверхность болевые точки и сделали видимыми bottlenecks, которые тормозили delivery. Сначала — As Is. Затем — To Be: какие изменения нужны, чтобы процесс стал прозрачным и предсказуемым. Такой формат дал общий язык: от Sales до Engineering все увидели одну систему и начали ей доверять.

Step 1: соберите все запросы в единый источник правды

Инструменты: Jira Product Discovery, интеграции с Salesforce и Gong.

Единый intake в Jira Product Discovery с привязкой клиентских запросов, сделок и инсайтов из Salesforce и Gong

Intake. У каждого feature request должен быть связанный Feature Intake ticket в Jira. Создание можно автоматизировать из Salesforce или Gong — например, из сделки или заметок по клиентскому звонку. Главное, чтобы в task tracker попадала релевантная информация:

  • Linked Client: active, churned или prospect; синхронизация из Salesforce.
  • Expected ARR Impact: размер потенциальной сделки или влияния на revenue.
  • Client Tier: Enterprise, MSME или high-risk segment.

Live status. Статус должен обновляться вместе с клиентским контекстом:

  • Если клиент ушёл в churn, связанные запросы автоматически переезжали в Parked.
  • Sales, Product и Engineering видели один и тот же статус в реальном времени.
  • Shadow requests исчезали: больше параллельных списков, личных обещаний и ручных «а где моя фича?».

Мы использовали Jira Product Discovery, потому что Engineering уже жил в Jira. Там есть полезная механика Insights: можно подключить интеграции и привязать к фиче места, где клиенты её просили, — email, Slack, Salesforce, call notes. В итоге у команды появляется обзор всех сигналов по одной возможности вместо разрозненного набора скриншотов и ссылок.

Step 2: triage по правилу 3x3

Правила triage для feature requests: активные клиенты, ARR impact и связь с North Star Metric

Фича двигалась дальше только при выполнении трёх условий:

  • Её запросили 3+ активных клиента или prospect-клиента.
  • Есть Expected ARR ≥ $X. Порог X команда выбирает сама; минимум — привязать его к ROI calculation.
  • Есть прямая связь минимум с одной North Star Metric (NSM).

Логика простая: отфильтровать маленькие разовые запросы, которые убедительно звучат в Slack, затем съедают capacity и почти не двигают бизнес. Посмотрите собственную статистику churn по Small, Medium и Enterprise-сегментам — быстро станет ясно, почему запросы с маленьким ARR нельзя автоматически пускать в разработку.

Как это работало:

  • Раз в неделю проводили cross-functional triage по входящим feature requests: Sales и Marketing, Product, Engineering.
  • Фичи скорили через ICE — Impact, Confidence, Ease.
  • Если фича проваливала одно из правил, она уходила в Parked или закрывалась.
  • Исключения возможны: например, rare enterprise unlocker даже с отрицательным ROI. Такое должно случаться редко — примерно раз в 5–6 месяцев, а не каждую неделю.

Это помогло Sales говорить языком value, а Engineering — работать над тем, что реально важно для growth и retention.

Step 3: визуализируйте поток и управляйте им через Throughput metrics

Дашборд governance для Feature Pipeline: Throughput, Lead Time, WIP limits и доля NSM-aligned work

Ключевые метрики:

  • Throughput: сколько фич shipped за месяц.
  • 85th percentile Lead Time: отслеживали и показывали всем. Цель — ≤90 дней, потому что мы жили в quarterly planning cycles.
  • NSM-aligned work: целевой уровень — ≥70% shipped features.

Как мы управляли потоком:

  • WIP limits: максимум 2 фичи одновременно на команду из 7–9 человек.
  • Real-time analytics: throughput и utilization командных ресурсов были видны всем.
  • Trade-offs: новый запрос сразу показывал, что именно сдвинется или выпадет из delivery.

Прозрачность убирает магию из приоритизации. Если кто-то хочет добавить срочную фичу, он видит цену решения. Данные также показали жёсткую реальность: Engineering мог обработать только около четверти входящего Feature Inflow. Это даёт сильный рычаг для разговора о настоящих product goals — финансовых метриках и долгосрочном видении продукта.

Для оценки capacity мы использовали T-shirt sizes вместе с historical feature lead time. Это практичный старт для команд, которым нужно быстро перейти от мнений к данным; возможны и другие варианты.

Step 4: валидируйте до разработки

Методов много. Самые простые и быстрые в запуске:

  • Fake Door Tests: добавьте кнопку или UI-элемент, чтобы измерить интерес клиентов до полноценной разработки.
  • Concierge MVP: вручную доставьте ценность нескольким клиентам, чтобы проверить, решает ли фича реальную проблему.

Главный принцип: фича переходит в development только после проверки на реальных клиентах. Если клиент ушёл в churn во время валидации, фича должна быть закрыта или понижена в приоритете. Клиентский сигнал живёт вместе с клиентским контекстом.

Step 5: отвечайте за результат после релиза

У каждой фичи было поле с ожидаемой датой достижения результата. Общая идея — доказать impact в течение 90 дней после релиза. Для enterprise deals горизонт может быть длиннее: 180–240 дней, потому что цикл подтверждения сделки и value занимает больше времени.

Что смотрели:

  • Adoption rate: клиенты действительно используют фичу?
  • Effect on NSM: фича двигает retention, revenue или продуктовые метрики?
  • Client feedback: есть измеримое улучшение satisfaction или снижение churn?

Фичи без подтверждённого impact уходили в sunset или переоценку. Поддержка каждой возможности стоит dev + CSM effort, поэтому «просто оставить» — тоже дорогое решение.

Feature Outcomes мы разбирали на Monthly Business Reviews (MBR) и Quarterly Business Reviews (QBR). Там же смотрели, как каждая фича влияет на OKRs.

Результаты: доверие, скорость и предсказуемость

  • 85th percentile Lead Time снизился с 244 до 93 дней. Фичи стали более-менее надёжно помещаться в quarterly planning cycle.
  • Transparency: Sales, Product и Engineering получили единый взгляд на priorities, status и trade-offs.
  • Alignment: 76%+ shipped features были напрямую связаны с North Star Metrics и активным клиентским спросом.
  • Trust: Sales перестал overpromise, Engineering вернул уверенность и нормальную мораль команды.

3 правила для скорости и доверия

  • Интегрируйте системы. Подключите Salesforce, Gong или ваши аналоги к ticketing system — Jira или другому стеку. Клиентский статус и value должны быть видимы при каждом решении.
  • Держите дисциплину приоритизации. Стройте только то, что подтверждено несколькими клиентами и связано с North Star. Команды часто увлекаются списком «что попросили клиенты» и теряют связь со стратегическим видением. Баланс нужно удерживать явно.
  • Измеряйте relentlessly. Track throughput и lead time, показывайте числа всем. Это снижает уровень эмоций и догадок, помогает строить data-driven culture.

С чего начать

Проведите аудит своего Feature Pipeline:

  • Сколько запросов связано с активными high-value clients?
  • Какой у вас реальный 85th percentile Lead Time?
  • Sales и Engineering смотрят в один source of truth?

Аудит Feature Pipeline: вопросы про клиентскую ценность, lead time и единый источник правды

Если ответы неприятные, вы не одни. Это чинится — шаг за шагом. Данные из Jira или любой другой системы можно посмотреть через predictable.team — приложение, которое помогает увидеть performance команды и понять, где поток реально тормозит.