# Витамины или обезболивающие: как определить истинную ценность ИТ-продукта? Источник: https://www.youtube.com/watch?v=KwWxIURQVRg Канал: SaaStr Опубликовано: 09.02.2023 --- Разработка коммерчески успешного программного обеспечения требует от продуктовых команд глубокого понимания психологии потребителя. Директор по продукту (CPO) компании DigitalOcean Гейб Монрой на конференции SaaStr представил концепцию разделения ИТ-решений на «конфеты», «витамины» и «обезболивающие». Основываясь на своем опыте управления многомиллиардными сервисами в Microsoft Azure и запуске собственных стартапов, он объяснил, почему слепое добавление запрашиваемых функций ведет к краху и как методология Jobs to Be Done помогает спасти бизнес-стратегию. ## 💊 Классификация ценности: конфеты, витамины и обезболивающие [[JUMP:00:00]] Продуктовый ландшафт можно сегментировать с помощью простого, но эффективного фреймворка, который Гейб Монрой перенял у венчурного капиталиста Кевина Фонга. Согласно этой классификации, все бизнес-планы и ИТ-продукты делятся на три категории: * **Конфеты (Candy):** приятное дополнение, без которого пользователь вполне может обойтись. По мнению Монроя, этот тип продуктов дает быстрый выброс дофамина. Отличным примером успешной реализации «конфет» является индустрия мобильных и видеоигр, генерирующая огромную прибыль. * **Витамины (Vitamins):** продукты, улучшающие качество жизни или рабочие процессы, но остающиеся в категории «полезно иметь» (nice-to-have). Их ценность неочевидна в момент кризиса, и от них легко отказываются при урезании бюджетов. * **Обезболивающие (Painkillers):** жизненно необходимые решения категории «должно быть» (must-have). Они закрывают критическую уязвимость или острую проблему клиента, поэтому их проще всего продавать. Главная ошибка многих основателей, как подчеркивает спикер, заключается в неверном позиционировании. Команда может разработать привлекательный интерфейс («конфету») и выстроить маркетинг вокруг улучшения общих показателей («витамин»), пытаясь продать продукт как критически важное «обезболивающее». Подобный дисбаланс неизбежно разрушает всю стратегию выхода на рынок (Go-to-Market). ## 📉 Кейс OpDemand: ловушка «минимального» MVP и цена ложных иллюзий [[JUMP:01:45]] В 2011 году, когда инфраструктура Amazon Web Services (AWS) росла стремительными темпами, Гейб Монрой вместе со своим партнером основал стартап OpDemand. Основная идея бизнеса строилась вокруг рыночного консенсуса: облако AWS обладало колоссальной эластичностью, но было слишком сложным для конечных пользователей. Продукт OpDemand (Operations on Demand) задумывался как SaaS-платформа, упрощающая взаимодействие с AWS. Команда привлекла посевные инвестиции и за один год создала минимально жизнеспособный продукт (MVP). Однако после запуска обнаружилось отсутствие ожидаемой тяги (traction). Трафик на посадочную страницу шел, но конверсия в реальное использование была крайне низкой, а выручка — практически нулевой. В попытках исправить ситуацию руководство стартапа допустило классические ошибки, детально описанные Монроем: 1. **Неверная интерпретация отзывов:** на звонках обратной связи клиенты выражали замешательство относительно ценностного предложения, но те, кто все же внедрил инструмент, хвалили его интерфейс. Команда ошибочно решила, что их MVP просто «слишком минимальный» и ему не хватает функционала. 2. **Слепое расширение бэклога:** разработчики собрали пожелания пользователей, приоритизировали их и оперативно внедрили новые функции — импорт ресурсов, командную работу, кастомные шаблоны. Результат оказался нулевым: показатели вовлеченности не изменились. Осознав неэффективность подхода, Гейб Монрой изменил стратегию интервью. Он перестал спрашивать о самом продукте OpDemand и сфокусировался на контексте: как пользователи строят приложения и какие альтернативы выбирают. Выяснилось, что главным скрытым конкурентом была платформа Heroku. Клиенты признались, что готовы платить большие деньги за инструмент, сочетающий простоту Heroku с гибкостью и контролем управления их собственным аккаунтом AWS. Этот инсайт привел к болезненному пивоту (потере части команды и дефициту капитала) и созданию открытой платформы Deis. Продукт Deis, ставший полноценным «обезболивающим» для рынка, оказался коммерчески успешным: сначала его поглотила компания Engine Yard, а затем активы выкупила корпорация Microsoft. ## 🔄 От Azure Container Service к AKS: трансформация ИТ-продукта через реальную боль [[JUMP:10:19]] После перехода в Microsoft Гейб Монрой возглавил команду Azure Container Service (ACS). Этот сервис, вышедший в общий доступ (GA) в 2016 году, предоставлял клиентам возможность быстрого развертывания систем оркестрации контейнеров в облаке. Проведя серию глубинных интервью, Монрой осознал, что ACS в текущем виде представлял собой типичный «витамин». Клиенты открыто заявляли, что платформа лишь экономит им немного времени, но они могут самостоятельно настроить аналогичную инфраструктуру вручную. При отсутствии специфических функций (например, поддержки нужных типов серверов) крупные заказчики легко возвращались к собственным кастомным разработкам. Продукт не был незаменимым. Тогда продуктовая команда Azure временно сместила фокус с продвижения ACS на изучение чужих кастомных решений. В ходе исследования были обнаружены две ключевые точки боли пользователей: * **Сложность обновлений:** процесс перехода на новые версии платформ оркестрации требовал колоссальных временных затрат, ручного переноса данных и уничтожения старых систем. * **Низкая надежность:** самописные системы крупных компаний регулярно аварийно завершали работу (crash) при пиковых нагрузках, нанося ущерб бизнесу. Опираясь на эти данные, Microsoft полностью переработала продукт, запустив в 2017 году Azure Kubernetes Service (AKS). В AKS изначально заложили автоматическое обновление, повышенную отказоустойчивость и глубокую интеграцию с инфраструктурой Azure. Решение острой технической боли превратило сервис в «обезболивающее», сделав AKS самым быстрорастущим вычислительным сервисом в истории Azure. ## 🛣️ Концепция «Дорога перед кодом»: как сэкономить миллион долларов на MVP [[JUMP:13:51]] Многолетний опыт в стартапах и корпорациях привел Монроя к жесткому правилу: концепция «дорога перед кодом» (road before code) должна соблюдаться неукоснительно. Для технических специалистов и инженеров естественным желанием является непрерывная разработка (менталитет build-build). Однако написание кода без предварительной валидации сопряжено с колоссальными финансовыми рисками. Создание полноценного MVP для OpDemand обошлось инвесторам примерно в $1 млн, и только после траты этих средств команда получила реальный рыночный отклик. По оценке Монроя, создание простых интерактивных макетов (mocks) и визуальных цепочек интерфейса обошлось бы всего в $25 000 — $50 000. Демонстрация клиентам прототипов до написания кода позволяет полностью дерисковать (снизить риски) цикл разработки и избежать дорогостоящих пивотов. Внедрение дизайн-ориентированного подхода (design-first approach), который сейчас оперативно применяется в DigitalOcean, строится на следующих принципах: * Тщательное изучение ожидаемых результатов (outcomes) клиента, а не просто фиксация списка желаемых функций. * Визуализация ключевых пользовательских путей и проведение клиентов через интерактивные сценарии. * Вовлечение инженерной команды в процессы общения с пользователями для формирования прямой эмпатии. Для структурирования этой работы Монрой рекомендует использовать проверенные индустриальные фреймворки, такие как методология Design Sprints от Google и Customer-driven Playbook от Microsoft. ## 🥤 Методология Jobs to Be Done на примере молочных коктейлей McDonald’s [[JUMP:17:43]] Для точного определения продуктовой категории и выявления «обезболивающего» Гейб Монрой рекомендует использовать концепцию Jobs to Be Done (JTBD), сформулированную профессором Гарвардской школы бизнеса Клейтоном Кристенсеном. Данная теория гласит: клиенты не просто покупают продукты, они «нанимают» их для выполнения определенной работы. Спикер привел классический пример исследования Кристенсена для сети McDonald’s, которая пыталась увеличить продажи молочных коктейлей. Изначально маркетологи пошли по стандартному пути: опросили покупателей, сформировали огромный список улучшений рецептуры, внедрили их, но продажи не изменились. Поведение потребителей казалось необъяснимым, пока исследователи не заметили, что огромный объем продаж коктейлей приходится на 7 часов утра. Анализ контекста помог выявить реальную «работу», на которую нанимали коктейль: * **Контекст:** у покупателей впереди была долгая и скучная поездка на автомобиле до работы. * **Задача:** им требовалось что-то, что займет их во время вождения и одновременно позволит продержаться без чувства голода до 10–11 часов утра. Оказалось, что главными конкурентами коктейля в этой задаче были бананы (съедаются слишком быстро) и шоколадные батончики (вызывают чувство вины и тяжести). Понимание этой «работы» позволило McDonald’s изменить продукт под реальный паттерн использования: сделать коктейли более густыми, чтобы процесс питья через трубочку занимал больше времени и развлекал водителя в пути. Монрой проводит прямую параллель с ИТ: клиенты Azure Container Service хотели «нанять» сервис не ради самого факта наличия контейнеров, а для обеспечения надежности инфраструктуры и делегирования болезненных апгрейдов. Пока продукт не начал выполнять именно эту работу (что произошло только в AKS), он оставался необязательным «витамином». ## 🔄 Управление динамикой ценности продукта в меняющейся экономике [[JUMP:25:52]] Завершая свое выступление, CPO DigitalOcean напомнил, что позиция продукта на шкале «конфеты — витамины — обезболивающие» не является фиксированной раз и навсегда. Продукт, который создавался как критически необходимое решение, со временем может деградировать. Изменение рыночной конъюнктуры, макроэкономические сдвиги или реорганизация внутри компаний-клиентов способны превратить вчерашнее «обезболивающее» в «витамин» или даже в «конфету», лишенную реальной ценности для бизнеса. Руководителям и продуктовым лидерам необходимо постоянно отслеживать метрику воспринимаемой ценности (perceived value) своих пользователей. Проектирование стратегии через призму JTBD и постоянный прямой диалог с рынком позволяют вовремя адаптировать ИТ-архитектуру к новым вызовам.