Как развивать ИТ-продукты быстро, а главное — управляемо
Перед началом масштабирования важно провести определённую работу и ответить на вопросы, которые я часто задаю слушателям курса Школы продуктового трекинга ФРИИ: что вы пытаетесь масштабировать? У вас новый продукт или уже существующий? У компании только один продукт или несколько? А может, у вас пока только идея? В статье подробнее поговорим об ответах на эти и другие вопросы.
Стартап и скейлап: в чём разница при управлении продуктами
В продуктовом подходе важно понимать, на каком этапе находится ваш продукт, чтобы выбрать правильные инструменты управления. Ошибка в оценке стадии развития может привести к неэффективным стратегиям и, как следствие, к провалу.
Каждый продукт можно отнести к одному из двух состояний:
- Стартап — временная структура для проверки бизнес-гипотез и поиска повторяемой бизнес-модели в условиях чрезвычайной неопределённости.
- Скейлап — продукт, подтвердивший бизнес-модель, который движется к прибыльности/окупаемости, тиражируется и масштабируется.
Даже если крупная компания с хорошей репутацией запускает новую инициативу, этот стартап тоже может провалиться. Поэтому важно каждым продуктом внутри компании управлять в отдельности: для новых и масштабируемых продуктов нужны разные инструменты и подходы.
Например, компания OpenAI объявила о запуске нового продукта Sora, который позволяет генерировать видеоконтент высокого качества. И даже несмотря на то, что у OpenAI уже есть популярный ChatGPT и хорошая репутация, Sora — это отдельный стартап, его бизнес-модель ещё предстоит подтвердить.
Неизвестно, появятся ли платящие пользователи, будут ли они возвращаться, какой будет прибыль (и будет ли вообще). Техническая сложность и качество продукта не означают, что бизнес-модель будет успешной.
Каковы основные причины гибели стартапов? Наверняка они вам известны — рассмотрим диаграмму:
Прежде чем приступить к созданию и развитию нового продукта, нужно убедиться в том, что у целевой аудитории есть проблема, которую ваш продукт будет решать. Иначе есть риск потратить время и ресурсы на разработку того, что никому не нужно. Проверка гипотез на ранних этапах — это не просто формальность, а критически важный шаг, который помогает минимизировать неопределённость и повысить шансы на успех.
Рассылка: как вести бизнес в России
Раз в неделю присылаем самые важные новости и лайфхаки для развития вашего бизнеса
Две методологии, которые помогают развивать продукт
Продуктовый подход опирается на проверенные методологии, которые помогают командам минимизировать риски и эффективно развивать продукт. Их принципы лежат в основе успешного создания и масштабирования новых решений.
Рассмотрим две методологии:
- Lean Startup, или «бережливый стартап», — метод развития бизнеса, направленный на максимальную экономию ресурсов и получение быстрой обратной связи от рынка через короткие итерации и тестирование. Важно придумывать короткие итерации не на уровне разработки, а на уровне стратегии продукта. Речь о том, что нужно делать MVP. Это одно из ядер продуктового подхода.
- Customer Development — методология, направленная на выявление потребностей клиентов и разработку продукта, который эти потребности удовлетворяет. Процесс включает формирование и проверку гипотез разных типов: гипотез о проблемах клиентов, о продукте, о рынке, о сегменте и т.д. В рамках данной методологии могут применяться разные инструменты — проблемные и решенческие интервью, UX-исследования, JTBD (Jobs to be Done — работа для выполнения) и многие другие.
Важно: Customer Development не равно проблемное интервью. Понятие Customer Development ещё в 2005 году ввёл Стив Бланк, а инструмент «проблемное интервью» придумал Роб Фитцпатрик в 2011-м.
Использование этих инструментов помогает не только создавать востребованные продукты, но и управлять рисками, проверяя гипотезы до того, как компания вложит значительные ресурсы в разработку. В конечном итоге, именно способность быстро учиться и адаптироваться определяет успех продукта на рынке.
Почему внутренние продукты в большинстве случаев тоже проваливаются
Действительно, немало проектов внутренней трансформации не становятся успешными.
Проекты внутренней трансформации ИТ-компании — это инициативы, направленные на улучшение внутренних процессов, структуры, технологий и культуры компании для повышения её эффективности, адаптивности и конкурентоспособности. Они могут включать изменения в управлении, операциях, подходах к разработке продуктов или сервисов, а также в интеграции новых технологий.
Напомню основные направления проектов внутренней трансформации:
- Технологическая трансформация: переход на новые технологии, платформы или архитектуры; автоматизация внутренних процессов, таких как разработка, тестирование или деплой; усиление кибербезопасности.
- Операционная эффективность: оптимизация бизнес-процессов для сокращения затрат и повышения скорости; внедрение Agile, DevOps или других подходов для повышения гибкости и скорости разработки.
- Управленческие изменения: реформа организационной структуры для улучшения взаимодействия между командами; введение продуктового подхода (переключение с проектного подхода на управление продуктами).
- Культурные изменения: обучение сотрудников новым методологиям и инструментам; создание культуры непрерывного обучения и инноваций; повышение уровня вовлечённости и ответственности сотрудников.
- Цифровизация процессов: внедрение инструментов для аналитики, управления проектами или CRM; переход на цифровой документооборот.
- Трансформация клиентского опыта: повышение уровня обслуживания внутренних и внешних клиентов; улучшение интерфейсов внутренних платформ и инструментов.
Итак, по статистике 70% проектов цифровой трансформации не достигают поставленных целей. Даже у гиганта ИТ-бизнеса — компании Google — есть своё «кладбище» проектов. Killed by Google — список сервисов, которые были «похоронены» (закрыты).
Каждый год список пополняется десятками новых проектов. Одни из них просто устарели, другие, например, Google Podcast, не выдержали конкуренции.
На мой взгляд, часто причина провалов в том, что компания так и не смогла найти повторяемую бизнес-модель, которая бы создавала достаточную ценность в виде трафика или в виде прямой выручки.
Причины провал внутренних проектов во многом схожи с причинами провалов внешних стартапов:
- Решение ошибочных проблем — таких, которых в компании на самом деле нет.
- Отсутствие хорошего решения проблемы. Продукт не даёт то, что нужно пользователю.
- Изменение системы без понимания, как она сейчас работает. Например, когда разрабатывают мобильное приложение для нефтяников, а потом оказывается, что те не могут им пользоваться — просто потому, что на Севере температура -50°C и люди ходят в перчатках, а батареи смартфонов не выдерживают подобного мороза.
- Психологическое влияние на инвестиционные решения. Например, страх, неуверенность, боязнь провала и пр.
Таким образом, недостаточно просто запустить проект трансформации — критически важно понимать, какие реальные задачи он решает и какие метрики успеха будут использоваться. Без этого даже самые амбициозные инициативы рискуют превратиться в бесполезные эксперименты, так и не давшие бизнесу ощутимого результата.
Почему нельзя путать стартап и скейлап
Скейлап — это «подросший» стартап. Продукт, который уже подтвердил свою бизнес-модель и движется к прибыльности и окупаемости. Для руководителей проекта очень важно научиться различать эти два состояния продукта, потому что под каждый из них нужны разные инструменты, компетенции и даже разные команды.
Ключевое различие между стартапом и скейлапом — подтверждённая бизнес-модель и положительная юнит-экономика (это обязательный финансовый инструмент, позволяющий определить, сколько зарабатывает бизнес).
Опасно путать два состояния продукта: стартап и скейлап
Расскажу реальный пример. В США в 2000 году случился кризис доткомов: тогда на биржу вышло много ИТ-стартапов, которые собрали деньги от венчурных инвесторов и даже вышли на биржу, но в определённый момент — схлопнулись.
Оказалось, что эти стартапы не зарабатывали столько, сколько планировали. Причина: стартапы пытались масштабировать не повторяемую бизнес-модель. Ещё не было доказано, что их модель прибыльна, повторяема и масштабируема, а они уже вливали туда большие деньги.
Итог: американская экономика тогда просела на 5 триллионов долларов (при общем госдолге на тот момент 5 трлн долларов).
Два признака скейлапа:
- Трекшн (от англ. traction — сцепление) — показатель того, что стартап растёт, у него есть «сцепление» с рынком, прирост пользовательской аудитории, регулярная динамика роста продаж и пр. Существует и противоположное понятие — растерянность. И это уже почти диагноз для бизнеса.
- Product&Market fit, или совпадение продукта и рынка, — это характеристика продукта, который растёт и у которого есть трекшн. Обычно говорят о квартальной динамике в 20-30%. Если продукт устойчиво растёт, то может претендовать на хороший раунд инвестиций: стартапы — на 3-5 млн рублей, скейлапы — уже на 30-50 млн.
Важно! Нельзя оценивать компанию (весь портфель её продуктов) как стартап или скейлап. Каждый продукт бизнеса нужно оценивать отдельно. Стартапом или скейлапом может быть только конкретный продукт или монопродуктовая компания. Не пытайтесь усреднить все продукты сразу.
Как быстро можно достичь хорошего трекшена? Давайте в качестве примера рассмотрим статистические данные о росте аудитории разных продуктов известных мировых компаний. Мы увидим, что компании Netflix понадобилось 18 лет, чтобы получить 100 млн пользователей, ChatGPT достиг этой отметки за 2 месяца, а Threads — всего за 2 дня. В 2022 году выручка компании OpenAI составила 200 млн долларов, в 2023 — 2 млрд долларов, а в 2024 они планировали сделать 5 млрд. И это пример отличного трекшена, хотя такой быстрый рост — исключение, а не правило.
Подытожим. Задача стартапа — вначале достичь Problem&Solution fit, затем дойти до Product&Market fit и научиться повторять свою бизнес-модель. Задача скейлапа — обеспечить динамику выручки.
Основные этапы жизненного цикла стартапа
Развитие стартапа — это не хаотичный процесс, а последовательное движение по ключевым этапам. Каждый из них имеет свои задачи, риски и инструменты, которые помогают стартапу вырасти из идеи в масштабируемый бизнес.
Давайте рассмотрим схему.
Остановимся на первых четырёх стадиях цикла:
- Discovery — этап, на котором нужно выявить клиента и понять его проблему.
- Validation — создание пилотного продукта, или MVP (минимально жизнеспособного продукта).
- Efficiency — доведение MVP до состояния, когда его можно предлагать широкому рынку.
- Scale — масштабирование, активное стимулирование роста.
Стив Бланк, автор методологии Customer Development, развитие стартапа изобразил следующим образом.
На разных стадиях развития стартапа можно задействовать большое количество разных инструментов. Я собрал их в таблице.
Понимание этапов развития продукта помогает предпринимателям избежать типичных ошибок, таких как преждевременное масштабирование или недостаточная проверка гипотез. А теперь непосредственно перейдём к конкретным инструментам и методикам.
Три инструмента для оптимизации работы с командой продукта
Речь пойдёт о нетривиальных вещах, а именно — о тех инструментах, которые в меньшей степени на слуху. Делюсь методами, которые использую сам.
Давайте очень коротко познакомимся с тремя инструментами (способами), которые помогают делать ИТ-бизнес более управляемым (если захотите изучить инструменты подробно и развёрнуто, можете перейти по соответствующим ссылкам в тексте).
Дизайн-спринты от Google. Это фреймворк для команд любого масштаба, позволяющий за 5 дней от определения проблемы дойти до прототипа, который тестируется вместе с целевой аудиторией в формате решенческого или UX-интервью.
В России некоторые крупные компании научились делать дизайн-спринт за один день: утром команда формулирует суть идеи, а к вечеру уже получает кликабельные прототипы в Figma, которые тестируются с реальными клиентами. И это один из немногих лайфхаков, позволяющий радикально сократить сроки этапа Discovery.
Проведение этапа Discovery до этапа Delivery. Этап Discovery надо делать раньше этапа Delivery. Ниже на схеме можно увидеть все шаги тестирования гипотез о продукте.
Причем делать Discovery до этапа Delivery нужно достаточно быстро: для В2С-продуктов и малого бизнеса — желательно пройти этап за пару недель, а для В2В-продуктов, среднего или крупного бизнеса — от 1,5 до 3 месяцев.
Приоритизация бэклога. Работая над продуктом, команда занимается не только разработкой, но и менеджерскими задачами — например, проведением проблемных интервью.
В идеале все задачи нужно приоритизировать и разложить по функционалу команды: бэклог разработки и бэклог менеджеров. Бэклог менеджера или продакта может включать в себя гипотезы о проблемах клиентов и проведение проблемных интервью. Это не задачи по разработке, а задачи по изучению целевой аудитории.
Далее гипотезы продакта или бэклог можно приоритизировать. Сделать это можно разными способами. Коротко рассмотрим три инструмента приоритизации.
Приоритизация при помощи модели ICE. Это полезный и очень простой инструмент. ICE — это способ оцифровать свою интуицию. Мы можем приоритизировать бэклог разработки или бэклог менеджерских задач с помощью трёх компонентов:
- Impact — влияние на успех проекта (1 — слабое, 10 — высокое).
- Сonfidence — вера в успех (1 — нет веры, 10 — высокая вера).
- Еase — лёгкость реализации (1 — сложно, 10 — легко).
Покажу, как это выглядит на условном примере с помощью таблицы.
Задачи разработки и менеджеров лучше не сравнивать между собой (разный ресурс).
Инструмент ICE — это способ оцифровки интуиции членов команды. Он позволяет избежать «пустых» споров в команде, ведь у каждого есть свой голос. Можно провести 2-3 тура оценки с промежуточным обменом мнениями. Иногда опрос следует проводить в «закрытую».
Приоритизация по системе MoSCoW. Оценка по методу MoSCoW может проводиться как внутри команды, так и с клиентами или пользователями. В системе MoSCoW все задачи делятся на 4 категории:
- Must — нужно сделать в первую очередь.
- Should — нужно выполнить, но можно немного позже.
- Could — желательно выполнить, если останутся время и ресурсы.
- Would — хотелось бы сделать, но можно отменить или перенести на следующие релизы без вреда для продукта.
Рассмотрим условный пример приоритизации по системе MoSCoW.
Метод MoSCoW помогает команде сфокусироваться на действительно важных задачах и не распылять ресурсы. Такой подход особенно полезен при ограниченном времени и бюджете, когда нужно быстро определить приоритеты.
Приоритизация методом WSGF. WSGF (Weighted Shortest Job First) — переводится как более ценная и короткая работа сначала. По этой методике для каждого элемента бэклога вычисляется приоритет, для чего используются следующие формулы:
Cost of Delay = User-Business Value + Time Criticality + Risk Reduction
WSJF = Cost of Delay / Job Duration
Где:
- Cost of Delay — упущенная выгоды или потери, которые происходят, пока не запущен продукт.
- User-Business Value — ценность для пользователей или бизнеса.
- Time Criticality — критичность по времени.
- Risk Reduction — снижение рисков.
- Job Duration — оценка длительности.
Применение метода WSGF поможет сосредоточиться на наиболее важных задачах и ускорить процесс принятия решений. Каждый из методов приоритизации вы можете изучить отдельно и понять, какой из них больше подходит под ваши задачи.
Четыре самые важные мысли, которые вам стоит унести с собой
Успешный бизнес требует постоянного анализа и корректировки стратегии. Эффективное использование методов и инструментов на разных стадиях развития продукта позволяет минимизировать риски и повысить вероятность достижения успеха.
Кратко подытожу основные мысли, изложенные мной в этой статье:
- Методология Customer Development и Lean Startup подразумевают быстрые итерации для проверки гипотез, большинство гипотез ценности может быть проверено без разработки (прототипы, MVP).
- Стартап и скейлап — это разные стадии развития продукта. Для них подходят разные инструменты и компетенции. Скейлап отличается от стартапа тем, что бизнес-модель уже подтверждена, а юнит-экономика положительна.
- Этап Discovery идёт до этапа Delivery и не включает разработку, особенно для весомого функционала.
- Бэклог нужно приоритизировать на основе потенциальной ценности для клиента и для бизнеса.
Нет никакой золотой пули или секретной таблетки. Есть только возможность повысить шансы на успех, опираясь на проверенные методики и продуктовый подход. Они давно стали стандартом в работе с инновациями — именно на них строятся практики Школы продуктового трекинга ФРИИ.
