Системный подход к проверке основных предположений создания продукта (assumptions) без которых все летит баллистическим методом

С 2014 года мы со Светланой Берегулиной провели более 30 стратегических сессий по форсайту. Методология работала. Участники уходили с видением на 5-10 лет вперёд, с пониманием трендов и точек приложения усилий. Опыт накапливался, инструменты оттачивались.

В сентябре 2024 года мы решили проверить потенциал масштабирования. Сделали лендинг. Запустили охват на 20 000 маркетологов и предпринимателей — через рассылки, таргет, публикации в профильных каналах.

В открытом форсайте рассчитанном на 35 человек приняло участие 12. Ученики Школы CPO-Стратег и лично приглашённые эксперты.

Конверсия 0.06% — это не провал маркетинга. Это ответ рынка на вопрос, который мы не задавали десять лет. Форсайт — инструмент для тех, кто уже освоил базовые практики стратегической работы. Для тех, кто умеет формулировать гипотезы и проверять их до того, как вкладывать ресурсы. Рынку сначала нужны базовые инструменты. Продвинутые — потом.

Одна проверка гипотезы спроса сэкономила годы попыток масштабировать то, что не масштабируется в текущих условиях.

Ниже — 9 опорных гипотез, которые мы теперь проверяем в компании и Стратегической мастерской до старта любого продукта.

Наш случай не уникален. Статистика подтверждает: большинство продуктов умирают не от плохой реализации, а от непроверенных предположений.

90% стартапов закрываются в первые три года — данные CB Insights за последние десять лет стабильны. Главная причина смерти — no market need (42% случаев). Не нехватка денег, не конкуренция, не плохая команда. Просто продукт оказался не нужен.

В корпорациях картина не лучше. По данным Bain & Company, 75% новых продуктов, запущенных крупными компаниями, не достигают целевых показателей. Ресурсы есть, экспертиза есть, бренд есть — а результата нет.

Harvard Business Review в исследовании 2019 года показал структурное разделение: команды, которые систематически проверяют гипотезы до разработки, добиваются успеха в 10 раз чаще тех, кто этого не делает. Разница не в идеях — разница в подходе к проверке.

Почему так происходит? Три системные проблемы.

Проблема первая: не понятно, какие гипотезы критичны.

В типичном backlog продуктовой команды — 200+ идей. Фичи, улучшения, новые направления, интеграции. Всё кажется важным. Всё «нужно клиентам». Ресурсы размазываются по десяткам инициатив. В итоге ничего не доводится до состояния, когда можно получить валидный feedback от рынка.

Команда работает много. Результатов мало. Причина — отсутствие критериев отсечения. Без понимания, какие гипотезы критичны для выживания продукта, любая приоритизация превращается в политику и вкусовщину.

Проблема вторая: не понятна последовательность.

Я регулярно вижу команды, которые тестируют гипотезу о каналах привлечения (гипотеза 6), не проверив гипотезу о целевом клиенте (гипотеза 4). Или строят MVP (гипотеза 8), не убедившись, что технология вообще позволяет решить задачу (гипотеза 2).

Гипотезы связаны между собой. Одни зависят от других. Если проверять их в неправильном порядке — результаты невалидны. Вы получаете данные, которые ничего не значат, потому что базовые предположения не проверены.

Проблема третья: MVP — самый вредный термин в продуктовой разработке.

За пятнадцать лет термин превратился в оправдание для запуска сырого продукта. «Это же MVP» — говорят, когда стыдно за качество. «Мы в режиме MVP» — объясняют, почему ничего не работает.

Проблема в самом слове. Minimum читают как «минимум усилий», а не «минимум, необходимый для проверки гипотезы возможности создания Масштабируемого продукта». Viable забывают вообще — а ведь это означает «жизнеспособный», то есть способный существовать и приносить ценность даже в минимальной версии.

90% того, что сегодня называют MVP — либо не minimum (полгода разработки, три платформы, интеграции со всем подряд), либо не viable (никто не может использовать, потому что половина функций не работает).

Lovable? Тоже не панацея. Можно сколько угодно делать «любимый» продукт — если не понятно, для кого и зачем, любовь останется безответной.

Проблема глубже терминологии. Нет системы проверки того, что именно должно быть в этом «минимуме». Нет ответа на вопрос: минимум — для чего?

В этой статье — система, которую мы используем в Школе CPO-Стратег для проверки продуктовых гипотез.

Что внутри:

• Таблица 9 гипотез — три этапа развития продукта, три роли в команде, девять критичных предположений, которые нужно проверить

• Окно возможностей — инструмент для выбора, с какой гипотезы начинать, когда ресурсы ограничены

• Методы проверки — для каждой гипотезы: быстрые и глубокие способы получить ответ

• Сквозной кейс — как это работает на примере Miro-like продукта (интерактивные доски для распределённых команд)

• Pivot framework — что делать, если гипотеза не подтвердилась

Цель — дать вам инструмент, который можно применить к своему продукту в процессе прочтения )

Часть 1. Рынок и система гипотез

Треугольник миров

Любой продукт существует на пересечении трёх миров: потребностей людей, технологических возможностей и бизнес-логики. Это не абстракция — это рабочая рамка для диагностики.

Когда один из миров доминирует, продукт деформируется. Три антипаттерна, которые я наблюдаю регулярно:

Только потребности → Инфоцыганство.
Команда глубоко понимает боли аудитории, умеет их артикулировать, создаёт эмоциональный резонанс. Но технологии нет — есть только обещания. Бизнес-модель строится на продаже надежды, а не результата.Типичный кейс: EdTech-стартап с харизматичным основателем. Или сервис по подбору психологов
Красивые лендинги, мощный маркетинг, тысячи регистраций — и минимальны retention. Люди приходят за трансформацией, получают супер и систему и ноль изменений  или психолога который им не подходит. Знакомо ?

Только технологии → Чертолёт. Инженерная команда строит технически совершенное решение проблемы, которой не существует. Или существует, но не в той форме. Google Wave — каноничный пример. Революционная технология real-time collaboration, годы разработки, ноль adoption. Пользователи не поняли, зачем им это. Продукт закрыли через два года после запуска.

Только бизнес → Эксплуатация. Фокус на извлечении денег без создания реальной ценности. Dark patterns в интерфейсе, подписки, которые невозможно отменить, искусственные ограничения для upsell. Краткосрочно работает. Долгосрочно — churn, репутационный ущерб, регуляторные риски.

Баланс трёх миров — редкость. Notion — один из примеров: глубокое понимание потребности (гибкий инструмент для мышления и организации), сильная технология (блочная архитектура), работающая бизнес-модель (freemium с понятной конверсией в платные планы). Результат: оценка $10B и продукт, который люди рекомендуют друг другу без рекламы.

Три роли в команде

Три мира требуют трёх типов экспертизы. В стартап-культуре их называют Хипстер, Хакер и Хастлер. Названия ироничные, но суть точная.

Хипстер отвечает за мир потребностей. Его фокус — понять, чего на самом деле хотят люди. Не что они говорят, а что делают. Не какие фичи просят, а какие задачи решают. В системе 9 гипотез Хипстер владеет гипотезами 1, 4 и 7: потребность рынка, потенциальные клиенты, ранние пользователи. Риск перекоса в эту сторону — инфоцыганство: много эмпатии, мало реализации.

Хакер отвечает за мир технологий. Его фокус — превратить понимание потребности в работающее решение. Не любое решение, а такое, которое можно построить, масштабировать и поддерживать. Гипотезы 2, 5 и 8: технология, состав предложения, минимальный функционал. Риск перекоса — чертолёт: технически элегантное решение проблемы, которая никого не волнует.

Хастлер отвечает за мир бизнеса. Его фокус — сделать так, чтобы ценность превращалась в деньги. Найти каналы, выстроить модель, обеспечить устойчивость. Гипотезы 3, 6 и 9: желание платить, бизнес-модель, модель выручки. Риск перекоса — эксплуатация: извлечение денег без создания соразмерной ценности.

Таблица девяти гипотез

Девять гипотез организованы в матрицу 3×3. Вертикаль — три этапа развития продукта. Горизонталь — три роли.

Вертикаль: от абстрактного к конкретному. Этап Идеи — проверяем, есть ли вообще основания для продукта. Этап Концепции — уточняем, для кого именно и что именно строим. Этап MVP — проверяем на реальных пользователях и реальных деньгах.

Горизонталь: три измерения одного этапа. На каждом этапе нужно ответить на вопросы всех трёх миров. Пропуск любого — риск провала на следующем этапе.

Зависимости между гипотезами критичны. Гипотеза 5 (состав предложения) бессмысленна без подтверждённой гипотезы 4 (потенциальные клиенты) — вы не можете определить, что строить, если не знаете, для кого. Гипотеза 8 (минимальный функционал) невалидна без гипотезы 2 (технология) — вы не можете выбрать минимум, если не понимаете технических ограничений.

Затраты по этапам — ориентир для планирования:

• Этап Идеи: 2-4 недели, 40-80 часов работы. Интервью, исследования, технические спайки.

• Этап Концепции: 4-8 недель. Глубокая проработка ICP, прототипы, тесты каналов.

• Этап MVP: 2 — 5 месяцев. Разработка, запуск, первые пользователи, итерации.

Общий путь от идеи до Product-Market Fit — 3-9 месяцев при последовательной проверке. Это быстрее, чем кажется. И намного быстрее, чем строить год, а потом узнать, что продукт не нужен.

Окно возможностей: как выбрать, с чего начать

Таблица есть. Но с чего начать, когда идей много, а ресурсы ограничены?

Типичная ситуация: 200 идей в backlog, три месяца до следующего раунда (или до конца бюджета), команда из пяти человек. Проверить всё невозможно. Нужен фильтр.

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

Для первичной фильтрации мы используем Окно возможностей — оценку timing для каждой идеи.

Четыре категории:

• Уходящая возможность. Рынок формируется прямо сейчас, окно закроется через 6-12 месяцев. Нужно действовать быстро или не действовать вообще.

• Рано. Рынок не готов. Технология есть, но привычки пользователей не сформированы, инфраструктура отсутствует. Инвестировать сейчас — замораживать ресурсы.

• Оптимально. Timing правильный. Рынок растёт, но не перегрет. Есть время построить и занять позицию.

• Поздно. Рынок насыщен, лидеры определились. Вход возможен только с радикальной дифференциацией или в узкую нишу.

Как использовать:

1. Оцените окно для каждой идеи из вашего списка

2. Отсейте «рано» и «поздно» без явных преимуществ

3. Приоритизируйте «уходящие» и «оптимальные»

4. Для топ-3 идей — переходите к последовательной проверке 9 гипотез

Подробнее об инструментах ранжирования (Feature Canvas, Force Field Analysis) — в отдельном материале. Здесь важно зафиксировать принцип: сначала выбор, потом проверка.

Маленький LifeHack

Если очень лениво читать дайте любимому ИИ ссылку на эту статью и попросите его сформировать план проверки 9 опорных гипотез вашего продукта в диалоге с вами ))
А потом можно читать дальше сверяясь с кейсом по своему продукту ).

Часть 2. Этап Идеи — гипотезы 1-3

Этап Идеи — это фильтр. Три гипотезы, которые нужно проверить до того, как написана первая строка кода. Логика последовательности жёсткая: сначала убеждаемся, что проблема существует (гипотеза 1), затем — что можем её решить технически (гипотеза 2), и только потом — что за решение готовы платить (гипотеза 3). Нарушение порядка обесценивает результаты: нет смысла проверять готовность платить за решение проблемы, которая не подтверждена.

Для иллюстрации буду использовать сквозной кейс: Miro-like продукт — интерактивные доски для распределенных команд. Референсы на рынке: MTS-Link, S-board.

Модель B2C2B (бизнес-потребитель-бизнес): эксперт или сотрудник начинает использовать продукт бесплатно, создает ценность для команды, компания покупает платную версию. Пользователь — точка входа, компания — плательщик.

Гипотеза 1. Потребность рынка

Формулировка: Существует ли проблема, которую мы решаем?

Это первая гипотеза не случайно. Без подтвержденной потребности всё остальное — технология, бизнес-модель, каналы — не имеет смысла. Можно построить идеальное решение несуществующей проблемы. Те самые 42% стартапов, которые умирают от «no market need», — это команды, пропустившие гипотезу 1.

Методы проверки

Быстрые (3-5 дней): Проблемные интервью (Problem Interviews) по методологии The Mom Test. Ключевой принцип — не спрашивать «купили бы вы?», а спрашивать «как вы решаете эту задачу сейчас?». Люди врут о будущих намерениях, но честно описывают текущее поведение. Дополнительно — опросы в профильных сообществах, анализ обсуждений на форумах и в чатах.

Глубокие (1-2 недели): JTBD — интервью (Jobs To Be Done — понять, на какую «работу» нанимает пользователь продукт, в каком контексте, какие альтернативы рассматривает. Тест посадочной страницы (Landing Page Test) с формой заявки — не просто «интересно», а готовность оставить контакт.

Затраты: 1-2 недели, 15-20 интервью, $0-500 на рекламу для теста лендинга.

Пример из практики

B2B SaaS для remote-команд. Гипотеза — командам сложно координироваться на расстоянии. 80% респондентов подтвердили боль. Но важнее детали: какая именно координация страдает? Оказалось — не коммуникация (Slack решает), а визуализация совместной работы.

Кейс Miro-like: Гипотеза — распределённые команды не могут визуализировать идеи вместе в реальном времени. Проверка: 20 интервью с product-командами. Результат: 85% подтверждают проблему. Используют комбинацию из 3-4 инструментов ( Google Docs, физические доски на созвонах). Переключение между инструментами, потеря контекста, невозможность работать синхронно — конкретные боли, которые люди описывают своими словами.

Критерий прохождения

• 70%+ респондентов называют проблему в топ-3 своих болей

• Могут описать текущее решение и его конкретные недостатки

  Если гипотеза не подтвердилась

  • Смена потребности (Customer Need Pivot) — возможно, реальная проблема в другом. Вернитесь к интервью, послушайте, на что люди жалуются

  • Смена сегмента (Customer Segment Pivot) — возможно, проблема есть, но у другой аудитории

  Гипотеза 1 подтверждена? Переходим к технологии.

Гипотеза 2. Технология

Формулировка: Можем ли мы технически решить эту проблему?

Гипотеза 2 находится в домене «Сложного» (Complicated) по фреймворку Cynefin — это напоминание о том, что здесь экспертиза важнее экспериментов. В сложном домене есть правильные ответы, но их нужно найти с помощью анализа и знаний, а не методом проб и ошибок. Нужен человек, который уже решал подобные задачи, а не команда энтузиастов, которая «разберётся по ходу».

Методы проверки

Быстрые (2-3 дня): Технический эксперимент (Technical Spike) — минимальный proof of concept, который отвечает на вопрос «это вообще возможно?». Не прототип продукта, а проверка ключевого технического риска.

Глубокие (1-2 недели): Документирование архитектурных решений (ADR, Architecture Decision Records) — фиксация ключевых технических решений и их обоснований. Консультация с экспертами, которые строили похожие системы.

Затраты: 1-2 недели, 40-80 часов работы технического специалиста, $0-1000 на консультации.

Пример:

ПримеСтартап в сфере AI-клонирования голоса. Гипотеза — можем клонировать голос с качеством, достаточным для коммерческого использования. Технический эксперимент: интеграция с ElevenLabs API, тестирование на 10 образцах. Результат: качество 7/10, задержка (latency) приемлемая для асинхронного использования. Реализуемо (feasible) — можно строить.

Кейс Miro-like: Ключевой технический вопрос — совместная работа в реальном времени (real-time collaboration) на холсте. Может ли 10 человек одновременно двигать объекты без конфликтов? Технический эксперимент показал: WebSocket + CRDT (бесконфликтные реплицируемые типы данных) решают синхронизацию. Выявленный риск: производительность деградирует при 50+ объектах на доске. Это не блокер, но требует внимания на этапе MVP.

Анти-кейс — цена пропущенной гипотезы

Команда год строила сервис в RetailTech. Действовали по методологии: LeanCanvas, проблемные интервью, сегментация, каналы. Всё как учили. На Мастерской разработки стратегии стартапа обнаружили бутылочное горлышко — ключевой процесс требовал ручной обработки данных и не масштабировался. Гипотеза 2 не была проверена на старте. Автоматизация требовала переписывания с нуля.

Деньги отбили, но проект пришлось закрыть. Год работы. Правильная методология. Пропущенная гипотеза.

Что было бы, если бы проверили сразу? Технический эксперимент на старте занял бы 1-2 недели. Обнаружили бы ограничение. Либо нашли бы другое техническое решение, либо изменили бы scope продукта. Экономия: 8-10 месяцев и ~500 часов работы команды.

Критерий прохождения

• Реализуемость (Feasibility): можем построить с имеющимися ресурсами

• Достаточность (Capability): технология решает проблему, а не создаёт новые

• Масштабируемость (Scalability): архитектура выдержит рост в 10-100 раз

Если гипотеза не подтвердилась

• Смена технологии (Technology Pivot) — другой стек, другой подход, использование готовых компонентов вместо разработки с нуля

• Упрощение (Simplify Pivot) — урезать scope до того, что технически реализуемо

Гипотеза 2 подтверждена? Проверяем готовность платить.

Гипотеза 3. Желание платить

Формулировка: Готовы ли люди платить за решение этой проблемы?

Важное различие: гипотеза 3 проверяет готовность платить (willingness) в принципе, гипотеза 9 — конкретную модель монетизации (mechanics). Сейчас нам нужно понять: эта проблема достаточно болезненна, чтобы за её решение отдавали деньги? Или это «хорошо бы иметь» (nice to have), которое используют только пока бесплатно?

Методы проверки

Быстрые (3-5 дней): Посадочная страница с ценой (Landing Page with Pricing) — не «оставьте email, мы сообщим о запуске», а «продукт стоит X, оставьте заявку». Опрос ценовой чувствительности по методологии Van Westendorp — найти диапазон приемлемых цен через четыре вопроса о восприятии стоимости.

Глубокие (1-2 недели): Предзаказы (Pre-orders) с оплатой или депозитом. Письмо о намерениях (Letter of Intent) для B2B — письменное подтверждение намерения купить при выполнении условий.

Затраты: 1-2 недели, $500-2000 на рекламу и тесты.

Пример — история Slack

Историю Slack пересказывать не буду. Основная идея в том что нужно следить за тем, где люди реально проводят время и реально получают ценность. Иногда это не там, где вы планировали.

Кейс Miro-like: Бесплатных досок на рынке достаточно — Jamboard, FigJam, встроенные инструменты в Notion. Готовы ли платить за ещё одну? Тест: лендинг с ценой $10/user/month, таргетированная реклама на product-менеджеров. Охват: 5000 человек. Результат: конверсия в заявку 0.3% (15 заявок). При стоимости привлечения клиента (CAC) $50 и конверсии в оплату 10% экономика не сходится.

Вывод: B2C-модель не работает для этого продукта. Pivot → Enterprise с фокусом на безопасность данных, единую авторизацию (SSO), интеграции с корпоративными системами. Другой идеальный профиль клиента (ICP), другой ценник ($50/user/month), другая экономика.

Критерий прохождения

• 10%+ аудитории готовы платить (или оставить заявку на платный продукт)

• Ожидаемое соотношение LTV/CAC > 3 при реалистичных предположениях

Если гипотеза не подтвердилась

• Смена способа монетизации (Value Capture Pivot) — не подписка, а транзакции; не B2C, а B2B; не прямые продажи, а маркетплейс

• Усиление ценностного предложения (Strengthen Value Prop) — добавить ценности до уровня, за который готовы платить.

Сводная таблица методов проверки

Основные идеи.

Этап Идеи — это 2-4 недели и 40-80 часов работы до начала разработки. Бюджет на тесты: $500-3500. Если хоть одна из трёх гипотез не подтвердилась — не начинайте строить. Вернитесь, переформулируйте, проверьте снова.

Нельзяграмм) прошёл путь от Burbn (приложение с геолокацией и множеством функций) до фото-приложения с фильтрами за 8 недель. Отбросили всё, кроме одной функции, которую люди реально использовали. Результат: $1B при продаже Facebook через 2 года после запуска.

Восемь недель на pivot. Два года до миллиарда. Это цена правильно проверенных гипотез на этапе Идеи.

Три гипотезы подтверждены? Переходим к этапу Концепции — уточняем кто именно наш клиент, что именно строим и как будем привлекать.

Часть 3. Этап Концепции — гипотезы 4-6

Этап Идеи позади. Потребность подтверждена, технология реализуема, готовность платить есть. Теперь нужно уточнить три вещи: кто именно ваш клиент, что именно вы строите и как будете привлекать. Это этап Концепции — мост между идеей и разработкой.

Три гипотезы этого этапа детализируют абстрактное понимание рынка до конкретных решений. После их проверки у вас будет не «мы делаем продукт для всех, кому нужна совместная работа», а «мы делаем доску с real-time синхронизацией для product-команд 10-50 человек в remote-first компаниях, привлекаем через экспертный контент, конвертируем через freemium».

Гипотеза 4. Потенциальные клиенты

Формулировка: Кто именно наши клиенты и сколько их?

На этапе Идеи вы подтвердили, что проблема существует. Но «распределённые команды» — это не сегмент. Это категория размером с океан. Гипотеза 4 сужает фокус до конкретной ниши, которую можно захватить.

Объем рынка

Три уровня оценки объёма:

• TAM (Total Addressable Market, общий адресуемый рынок) — все, кто теоретически может купить ваш продукт. Для Miro-like это все компании с распределенными командами в мире. Цифра большая, красивая и бесполезная для планирования.

• SAM (Serviceable Addressable Market, доступный рынок) — кого вы реально можете достичь с учетом географии, языка, каналов. Для Miro-like в России: компании с проудктовыми-командами, работающие удаленно, русскоязычные, готовые платить за SaaS.

• SOM (Serviceable Obtainable Market, достижимый рынок) — реалистичная доля за 2-3 года. Обычно 1-5% от SAM для стартапа. Это ваша реальная цель.

Вроде очевидная история но большинство стартапов делают ее не правильно. Главный вопрос сколько мы хотим и можем заработать — масштабировать продукт история не дешевая.

Профиль идеального клиента (ICP, Ideal Customer Profile)

Три перспективы для описания:

• Компания  (Firmographics): размер компании (10-50, 50-200, 200+ человек), отрасль (IT, финтех, e-commerce), география (Россия, СНГ, глобально), стадия (стартап, рост, зрелость).

• Технологиии (Technographics): текущий стек (используют ли Jira, Notion, Figma?), зрелость процессов (есть ли product-менеджмент как функция?), готовность к новым инструментам.

• Психографика (Psychographics): ценности команды, приоритеты руководства, типичные боли и как их артикулируют. Это самое важное — понять, как они думают о проблеме.

Пропасть Мура (Crossing the Chasm)

Критическое различие для продуктовых команд:

• Ранние последователи (Early Adopters) — визионеры. Готовы терпеть баги, недоделки, отсутствие документации. Покупают будущее, не настоящее. Их мало, но они дают первый revenue и обратную связь.

• Раннее большинство (Early Majority) — прагматики. Хотят работающий продукт с референсами, поддержкой, гарантиями. Не купят, пока не увидят, что «такие же как мы» уже используют.

Между ними — пропасть. Продукт, который любят ранние последователи, не обязательно подойдёт раннему большинству. Гипотеза 4 должна чётко определить, на кого вы целитесь сейчас.

Кейс Miro-like: 

• Первая гипотеза — дизайнеры (они же визуальные люди, им нужны доски). Проверка: 50 outreach-сообщений в LinkedIn. Отклик (response rate): 15%. Низкий интерес, много возражений «у нас есть Figma».

• Вторая гипотеза — product-команды. 50 outreach. Отклик: 45%. Активный интерес, вопросы о функциях, готовность к демо.

Профиль идеального клиента подтверждён: product-команды 10-50 человек, remote-first компании, используют Jira и Confluence, ищут инструмент для визуализации стратегии и ретроспектив.

Критерий прохождения

• Профиль идеального клиента описан с точностью до должности (не «менеджеры», а «Head of Product в компаниях 30-100 человек»)

• Найдены 10-50 конкретных компаний или людей, соответствующих профилю

• Отклик на исходящую коммуникацию по целевому профилю (outreach) не менее 25%

Если гипотеза не подтвердилась

• Смена сегмента (Customer Segment Pivot) — возможно, ваш продукт нужен другой аудитории

• Сужение ниши (Niche Down Pivot) — возможно, сегмент слишком широкий, нужно специализироваться

Гипотеза 4 подтверждена? Определяем, что именно строим.

Гипотеза 5. Состав предложения

Формулировка: Что именно должно быть в продукте?

Самая опасная гипотеза для инженерных команд. Соблазн добавить «ещё одну фичу» велик. 

Но каждая фича — это время, деньги и сложность. Гипотеза 5 определяет границы: что входит в первую версию, а что — нет.

Максима одного из потоков стратегической мастерской :
— Каждая новая Feature увеличивает приспособленность к КОНКРЕТНОЙ нише, и снижает охват за счет той аудитории которой не подойдет наша реализация

Приоритизация по MoSCoW

Четыре категории для каждой фичи:

• Must (обязательно) — без этого продукт не работает. Вообще не запускаемся без этих функций. Для доски: холст, объекты, возможность их двигать.

• Should (следует) — важно для ценности, но можно отложить на версию 1.1. Для доски: шаблоны для типовых сценариев.

• Could (можно) — хорошо бы иметь, но не критично. Для доски: интеграции с другими сервисами.

• Won’t (не будем) — хотели , но явно исключаем из этой версии. Важно зафиксировать, чтобы не было «а давайте добавим». Для доски: видеозвонки, мобильное приложение.

Категория Won’t — самая ценная. Она защищает команду от расползания scope.

Просто известно , но если сделаете визуал повесите себе на рабочую доску очень сильно может помочь сфокусироваться ))

Модель Кано (Kano Model)

Другой взгляд на фичи — через восприятие пользователя:

• Базовые (Basic) — ожидаемое. Не восхищают, но без них — провал. Если доска тормозит при 10 объектах — это провал, даже если есть крутые шаблоны.

• Линейные (Performance) — чем больше, тем лучше. Скорость синхронизации: 100мс лучше, чем 500мс. Количество шаблонов: 50 лучше, чем 10.

• Восхищающие (Excitement) — неожиданное. Вау-эффект. То, чего пользователь не просил, но что заставляет рекомендовать продукт. Для Notion это были блоки — никто не просил, но все полюбили.

Хороший MVP = все базовые + один-два восхищающих элемента. Не наоборот.

Пример Notion: MVP включал базовый редактор (Basic) и блочную структуру (Excitement). Won’t: мобильное приложение и API — добавили через год после запуска.

Кейс Miro-like: Определение scope для MVP.

• Must: холст, стикеры, базовые фигуры, real-time синхронизация, авторизация.

• Should: шаблоны для ретро и стратегических сессий, экспорт в PNG.

• Could: интеграции с Jira и Notion, комментарии, история версий.

• Won’t: видеозвонки (есть Zoom), мобильное приложение (десктоп-first), AI-функции (хайп, но не validated need).

Срок разработки: 3 месяца с командой из 3 разработчиков.

Антипаттерн «Чертолёт»

Признак проблемы: инженеры увлечённо строят фичи, которые никто не просил. «Мы добавили real-time курсоры с анимацией и тенями» — технически элегантно, пользователь не заметит. «Мы переписали рендеринг на WebGL» — круто, но пользователям достаточно было Canvas.

Противоядие: каждая фича должна быть привязана к конкретной боли из интервью гипотезы 1 или запросу из тестирования гипотезы 4.

Критерий прохождения

• Scope MVP укладывается в 2-4 месяца разработки

• Прототип (кликабельный или даже бумажный) показан 5+ потенциальным клиентам

• Получен feedback: «да, это решает мою проблему»

Если гипотеза не подтвердилась

• Упрощение (Simplify) — слишком сложно, урежьте до минимума

• Смена фокуса (Zoom In/Out) — возможно, одна фича важнее всего продукта, или наоборот

Гипотеза 5 подтверждена? Определяем, как привлекать клиентов.

Гипотеза 6. Бизнес-модель

Формулировка: Как мы будем привлекать и конвертировать клиентов?

На этапе Идеи мы подтвердили, что готовы платить. Но как они узнают о продукте? Где их искать? Сколько стоит привлечение? Гипотеза 6 — про каналы и экономику привлечения.

Эксперименты с каналами (Channel Experiments)

Правило: тестируйте 2-3 канала параллельно, не ставьте всё на один.

Для каждого канала измеряйте:

• Охват (Reach): сколько людей увидели

• Конверсия (Conversion): сколько совершили целевое действие

• Стоимость привлечения (CAC, Customer Acquisition Cost): сколько потратили на одного клиента

Пример расчёта: LinkedIn outreach. 500 сообщений, конверсия в ответ 10% (50 ответов), конверсия в демо 20% (10 демо), конверсия в клиента 20% (2 клиента). Потратили на инструменты и время $1000. CAC = $500 на клиента.

Анализ стоимости привлечения

Платные каналы (paid): быстрый результат, предсказуемый объём, но дорого. Таргетированная реклама, контекст, спонсорство.

Органические каналы (organic): медленно, требует экспертизы, но sustainable. Контент-маркетинг, SEO, сообщества, виральность.

Правило экономики: CAC < LTV/3. Если пожизненная ценность клиента $300, стоимость привлечения должна быть меньше $100. Иначе экономика не сходится.

Рост через продукт или продажи (PLG vs Sales-Led)

Рост через продукт (PLG, Product-Led Growth): продукт продаёт сам. Пользователь регистрируется, пробует, приглашает коллег, компания покупает. Slack, Notion, Miro, Figma — все PLG.

Рост через продажи (Sales-Led): нужны продавцы. Работает для Enterprise с длинным циклом сделки и высоким чеком.

Гибрид: PLG для входа и маленьких команд, Sales для expansion в крупных компаниях. Наиболее частая модель для B2C2B.

Кейс Miro-like: Первая гипотеза — B2B sales через кейсы. Холодный outreach, презентации, демо. Результат за 3 месяца: 5 клиентов, CAC $2000 при LTV $1200. Экономика не сходится.

Pivot: контент от экспертов «как использовать доски для ретро», «визуальная стратегия за 60 минут». Статьи, вебинары, шаблоны. Органический трафик, регистрации, freemium конверсия.

Результат через 3 месяца: CAC снизился до $200, конверсия в платных выросла (тёплые лиды vs холодные). Модель B2C2B заработала: пользователь приходит на контент → пробует бесплатно → приглашает команду → компания покупает.

Пример из корпорации: Тинькофф-инвестиции. Геймификация в приложении: достижения, соревнования, обучение. Пользователи приглашают друзей ради бонусов. Результат: 250K новых пользователей через реферальную программу, CAC ≈ $0.

Критерий прохождения

• Найден минимум 1 работающий канал

• CAC < LTV/3 на выборке 10+ клиентов

• Канал масштабируется (можно увеличить бюджет и получить больше клиентов)

Если гипотеза не подтвердилась

• Смена канала (Channel Pivot) — возможно, ваши клиенты в другом месте

• Смена модели (PLG ↔ Sales-Led) — возможно, нужен другой подход к продажам

Сводная таблица методов проверки на этапе Концепция

Основные идеи

После гипотез 4-6 у вас есть ответы на три вопроса:

• WHO: профиль идеального клиента с точностью до должности и компании

• WHAT: scope MVP с чёткими границами Must/Won’t

• HOW: работающий канал привлечения с экономикой CAC < LTV/3

Если хоть один ответ отсутствует — дорабатывайте до начала полноценной разработки. Этап Концепции занимает 4-8 недель, но экономит месяцы переделок.

Три гипотезы подтверждены? Переходим к этапу MVP — проверяем на реальных пользователях и реальных деньгах.

Часть 4. Этап MVP — гипотезы 7-9

Концепция готова. Вы знаете кто ваш клиент, что строите и как привлекаете. Теперь — проверка на реальности. Этап MVP — это не «запуск продукта», а серия экспериментов с работающим кодом и живыми пользователями.

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

Гипотеза 7. Ранние пользователи

Формулировка: Кто будет первыми пользователями и как их привлечь?

Ранние последователи ≠ Идеальный клиент

Критичное различие, которое многие упускают:

Ранние последователи (Early Adopters) — визионеры. Они покупают потенциал, не текущее состояние. Готовы терпеть баги, отсутствие документации, сырой интерфейс. Им интересен сам факт участия в чём-то новом. Дают честный feedback, но их потребности Всегда отличаются от массового рынка.

Идеальный клиент (ICP, раннее большинство) — прагматики. Хотят готовый продукт, референсы, поддержку. Не будут разбираться в недоделках. Платят больше, но приходят позже.

Типичная ошибка: строить продукт для прагматиков на основе feedback визионеров. Ранние последователи скажут «добавьте API и webhooks» — потому что они разработчики и любят интеграции. Массовый рынок скажет «сделайте проще» — им не нужны webhooks, им нужно решение задачи в три клика.

Методы привлечения ранних пользователей

Сообщество (Community-First): идите туда, где уже собрана ваша аудитория. Telegram-каналы, Discord-серверы, ProductHunt, профильные форумы. Не покупайте трафик — ищите людей, которые уже обсуждают вашу проблему.

Ранний доступ (Early Access): waitlist с ограниченным количеством мест создаёт ощущение эксклюзивности. «Первые 100 пользователей получат lifetime-доступ» работает лучше, чем «регистрируйтесь все».

Реферальная программа (Referral): каждый ранний пользователь приводит 2-3 новых. Dropbox вырос на реферальной программе — бесплатное место за приглашённого друга.

Удержание важнее привлечения (Retention Matters)

Кейс Lingualeo: 100 000 скачиваний приложения. Красивая цифра для отчёта инвесторам. Day 7 retention: 3%. Из 100 000 пользователей через неделю осталось 3 000. Через месяц — несколько сотен. Это не рост, это решето.

Различайте метрики тщеславия (vanity metrics) и метрики действия (actionable metrics). Скачивания, регистрации, посещения — тщеславие. Retention, активация, конверсия в платных — действие.

Кейс Miro-like: Где искать ранних последователей?

Первая гипотеза — ProductHunt. Запуск, попадание в топ дня. Результат: 500 регистраций. Day 1 retention: 25%. Люди пришли посмотреть, но не вернулись. Слишком широкая аудитория.

Вторая волна — Telegram-сообщества продактов (Product Management, Product Craft). Точечные посты, приглашения на бета-тест. Результат: 200 регистраций. Day 1 retention: 60%.

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

Пример из мобильных приложений и игр: Soft launch — запуск в одной небольшой стране (Филиппины, Канада, Австралия) перед глобальным релизом. Собираете метрики, итерируете продукт, чините критичные баги. Только после достижения целевых показателей — глобальный запуск.

Базовые метрики удержания (Retention Baseline)

Ориентиры для SaaS и мобильных продуктов:

• Day 1 (первый день): 40%+ пользователей возвращаются на следующий день

• Week 1 (первая неделя): 25%+ активны через неделю

• Month 1 (первый месяц): 10%+ активны через месяц

Если ваши цифры ниже — проблема не в привлечении, а в продукте. Не масштабируйте дырявое ведро.

Критерий прохождения

• 10-50 активных ранних пользователей (не регистраций, а активных)

• Retention выше baseline для вашей категории

• Пользователи сами возвращаются, не только когда вы напоминаете

Если гипотеза не подтвердилась

• Смена канала привлечения — возможно, ваши ранние последователи в другом месте

• Пересмотр активации — возможно, люди приходят, но не понимают, как получить ценность

Ранние пользователи есть и возвращаются? Проверяем минимальный функционал.

Гипотеза 8. Минимальный функционал

Формулировка: Какой минимум функций нужен для проверки ценности?

Вернёмся к проблеме из введения: 90% того, что называют MVP, не является ни минимальным, ни жизнеспособным. Гипотеза 8 определяет, что действительно минимально необходимо для создания ценности для ранних пользователей и особенно тех кто соответствует профилю идеального клиента.

Четыре типа MVP

Консьерж (Concierge MVP): вы вручную делаете то, что потом автоматизируете. Клиент получает результат, вы — понимание процесса. Wealthfront начинали с ручного управления инвестициями для первых клиентов.

Волшебник из страны Оз (Wizard of Oz MVP): интерфейс автоматический, backend — люди. Клиент думает, что взаимодействует с системой, на самом деле за экраном оператор. Zappos начинался так: сайт есть, а основатель сам бегал в магазины и покупал обувь по заказам.

Посадочная страница (Landing Page MVP): только описание продукта и сбор заявок. Проверяет интерес до написания кода. Buffer собрал 100 000 email до запуска.

MVP одной функции (Feature MVP): одна работающая функция, не продукт целиком. Twitter начинался как функция статусов внутри Odeo.

Как выбрать тип MVP

Используйте фреймворк Cynefin как напоминание о природе задачи:

Сложный домен (Complicated) — есть правильный ответ, нужна экспертиза. Используйте технический эксперимент (Technical Spike) для проверки ключевых рисков.

Запутанный домен (Complex) — нет правильного ответа, нужны эксперименты. Консьерж или Волшебник из страны Оз — вы учитесь в процессе.

Очевидный домен (Obvious) — решение понятно, нужно просто сделать. Feature MVP — минимальная реализация известного решения.

Кейс Miro-like: Выбор — Feature MVP. Одна функция: совместная доска со стикерами и синхронизацией в реальном времени. Без шаблонов (Could), без экспорта (Should), без интеграций (Could), без истории версий (Could).

Результат: ранние последователи получают ценность — могут проводить ретро и брейнштормы онлайн. Feedback чёткий: «работает», «нужны шаблоны», «хочу экспорт». Приоритеты для следующей версии понятны.

Пример Нельзяграмм: Приложение Burbn имело 12 функций: чекины, планы, фото, социальные связи, очки, бейджи… Команда посмотрела на данные: люди использовали только фото. Pivot: оставили одну функцию (фото с фильтрами), убрали 11 остальных. День первый после перезапуска: 25 000 пользователей.

Урок: Фокус побеждает разнообразие. Одна отлично работающая функция лучше десяти посредственных.

Критерий прохождения

• Ранние последователи получают ценность от минимального продукта

• Метрики PMF (Product-Market Fit) улучшаются неделя к неделе

• Есть чёткий feedback, что добавить в следующей версии

Если гипотеза не подтвердилась

• Ещё больше упростить — возможно, даже ваш минимум слишком сложен

• Zoom In — возможно, одна фича из вашего MVP и есть весь продукт

Минимальный функционал проверен? Переходим к деньгам.

Гипотеза 9. Модель выручки

Формулировка: Как именно мы будем зарабатывать деньги?

Гипотеза 3 проверяла готовность платить. Гипотеза 9 проверяет механику: какая модель монетизации работает, какие цены оптимальны, какая экономика получается.

Четыре модели монетизации (Revenue Models)

Подписка (Subscription): предсказуемый recurring revenue, нужен высокий retention. Работает для продуктов постоянного использования. Netflix, Spotify, большинство SaaS.

Транзакции (Transaction): процент от сделки или фиксированная комиссия. Работает для маркетплейсов и платформ. Airbnb, Uber, Stripe.

Freemium: бесплатная базовая версия, платные продвинутые функции. Конверсия обычно 2-5%, нужен большой объём. Dropbox, Slack, Spotify.

Корпоративные продажи (Enterprise): большие чеки, длинные циклы продаж, кастомизация. Salesforce, Workday.

Юнит-экономика (Unit Economics)

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

LTV (Lifetime Value, пожизненная ценность) — сколько денег приносит один клиент за всё время использования продукта.

Формула: LTV = ARPU × Время жизни клиента (в месяцах)

Пример: ARPU (средний доход на пользователя) = $20/мес, клиент остаётся в среднем 24 месяца. LTV = $20 × 24 = $480.

CAC (Customer Acquisition Cost, стоимость привлечения) — сколько тратим, чтобы получить одного платящего клиента.

Правила здоровой экономики:

• LTV/CAC > 3 (зарабатываем в три раза больше, чем тратим на привлечение)

• Payback < 12 месяцев (возвращаем стоимость привлечения менее чем за год)

Если LTV/CAC < 3, бизнес не масштабируется. Каждый новый клиент приносит убыток.

Кейс Miro-like: Модель — Freemium + Enterprise.

Free: до 3 досок, 1 пользователь. Достаточно для индивидуального использования и пробы с командой.

Pro ($10/user/month): безлимитные доски, командные функции, экспорт.

Enterprise (custom pricing): SSO, единая авторизация, admin-панель, приоритетная поддержка.

Результат первых 3 месяцев: конверсия Free → Pro 4% (выше среднего 2-3%), средний чек Pro $50/мес (5 пользователей), LTV ~$600 при среднем времени жизни 12 месяцев. CAC через контент ~$200. LTV/CAC = 3. Экономика на грани — нужно либо снижать CAC, либо увеличивать retention.

Пример — Marketplace/Fintech (Dropbox): Изначально Dropbox был B2C freemium. Конверсия в платные ~4%, ARPU низкий ($10/мес). Pivot на B2B: корпоративные тарифы, команды, администрирование. Результат: 70%+ выручки от бизнес-клиентов при среднем чеке в 10 раз выше.

Критерий прохождения

• LTV/CAC > 3 на выборке минимум 20-30 платящих клиентов

• Payback < 12 месяцев

• Модель монетизации протестирована и оптимизирована

Если гипотеза не подтвердилась

• Смена модели — возможно, подписка не работает, попробуйте транзакции или enterprise

• Смена ценовой точки — возможно, цена слишком высокая или слишком низкая

• Смена сегмента — возможно, B2C не работает, но B2B будет.

Сводная таблица методов проверки

Основные идеи

Этап MVP — итеративный. Цель не мгновенная прибыльность (instant profitability), а подтвержденное обучение (validated learning). Spotify шёл к положительной юнит-экономике 7 лет. Но каждый месяц команда понимала, что работает, а что нет.

Три гипотезы этапа MVP дают ответы:

• WHO (кто первый): ранние последователи найдены и активны

• WHAT (что минимально): функционал достаточен для ценности

• HOW MUCH (сколько зарабатываем): экономика сходится или понятно, как её починить

Если все девять гипотез подтверждены — у вас есть основание для масштабирования. Если нет — у вас есть основания для pivot.

Часть 5. Делаем мертвую петлю (Pivot Framework)

Девять гипотез проверены. Возможны три исхода: все подтверждены (редко), часть не подтверждена (часто), критичные гипотезы провалены (тоже часто). В последних двух случаях встаёт вопрос: что делать дальше?

Pivot — не провал. Это уточнение на основе данных.

10 типов pivot

Эрик Рис в «The Lean Startup» систематизировал типы pivot (изменение концепции). Каждый отвечает на вопрос: что именно меняем, сохраняя то, что работает?

Ключевой принцип: pivot меняет одно измерение, сохраняя остальные. Если меняете всё — это не pivot, это новый продукт.

Разбор кейса: Miro-like

Вернёмся к сквозному кейсу. После проверки девяти гипотез картина:

Что изменилось:

• Гипотеза 3 (желание платить): B2C конверсия 0.3% — экономика не сходится. Pivot → Enterprise с фокусом на безопасность и SSO (единую авторизацию). Это Value Capture pivot.

• Гипотеза 6 (бизнес-модель): B2B sales с CAC $2000 при LTV $1200 — убыточно. Pivot → контент-маркетинг + B2C2B. Это Channel pivot.

Что НЕ изменилось:

• Гипотеза 1 (потребность): распределённые команды по-прежнему нуждаются в визуальной совместной работе. Боль подтверждена.

• Гипотеза 2 (технология): WebSocket + CRDT работают. Техническое решение валидно.

• Гипотеза 5 (состав предложения): MVP scope тот же — холст, стикеры, real-time синхронизация.

Инсайт: Pivot затронул 2 из 9 гипотез. Семь остались неизменными. Это не «начинаем с нуля» — это уточнение на основе данных. Успешные продукты делают 1–3 pivot до достижения PMF.

Когда делать pivot

Сигналы к pivot:

• Гипотеза не подтверждается после 2–3 итераций проверки

• Метрики стагнируют или деградируют при увеличении усилий

• Качественный feedback однозначно указывает в другом направлении

• Unit-экономика не сходится при реалистичных предположениях.

Сигналы НЕ делать pivot:

• Одна неудачная проверка (мало данных)

• Желание «попробовать что-то новое» без данных

• Давление инвесторов или стейкхолдеров без объективных оснований

• Выгорание команды (это про людей, не про продукт)

Заключение

Моя позиция: тестирование гипотез без стратегического видения — потерянное время и деньги.

• Lean Startup учит «выходить из здания», но не говорит, куда идти. 

• Design Thinking фокусирует на эмпатии, но не отвечает на вопрос «кто заплатит за этот продукт». 

• Agile оптимизирует скорость доставки, но не гарантирует, что доставляете то, что нужно. 

Я видел команды, которые год крутили A/B-тесты без понимания, зачем им этот продукт. Каждый спринт — новые эксперименты. Каждый месяц — отчёты о validated learnings. Через год — ни продукта, ни понимания.

Хорошо, если это корпоративный R&D с бюджетом на эксперименты. Но были случаи, когда люди продавали квартиры, чтобы «вырваться из найма и сделать своё» — и оставались без продукта и без квартиры. Это не метафора. Это реальные истории слава богу не из  Мастерской разработки стратегии.

9 гипотез — это не чек-лист для галочки. Это способ не врать себе на старте.

Практические рекомендации: 5 шагов

1. Определите цель

Зачем вам этот продукт? «Заработать денег» — не ответ. Сколько? За какой срок? (Правильный Tam-Sam-Som в помощь)  Какой ценой — в часах, в риске, в отказе от альтернатив? Без честного ответа на эти вопросы любая проверка гипотез превращается в имитацию деятельности.

2. Заполните таблицу 9 гипотез

Для каждой из девяти ячеек: что вы предполагаете? На чём основано предположение? Как проверите? Не «мы верим, что клиенты захотят», а «мы предполагаем, что product-команды 10–50 человек готовы платить $10/user/month за визуальные доски, потому что 85% интервью подтвердили боль».

3. Примените Окно возможностей

Оцените timing для каждой идеи. Отсейте «рано» (рынок не готов) и «поздно» (лидеры определились). Сфокусируйтесь на «оптимальных» и «уходящих». Ресурсы ограничены — не распыляйтесь.

4. Проверяйте последовательно

Идея → Концепция → MVP. Не перескакивайте. Гипотеза 8 (минимальный функционал) бессмысленна без подтвержденной гипотезы 4 (потенциальные клиенты). Зависимости между гипотезами — не формальность, а логика валидации.

5. Pivot — это нормально

Если гипотеза не подтвердилась — это данные, не провал. Используйте таблицу pivot-ов. Меняйте одно измерение, сохраняя то, что работает. Instagram сделал zoom-in pivot за 8 недель и через 2 года стоил миллиард.

Timeline: 4–9 месяцев от идеи до PMF при последовательной проверке. Это быстрее, чем год строить без проверки, а потом узнать, что продукт не нужен.

Типичные ошибки

1. Мечемся Без цели. Тестируем всё подряд, не понимаем, зачем. Результат — много данных, ноль решений.

2. Слишком общие гипотезы. «Люди хотят удобства» — не гипотеза. «Product-команды 10–50 человек готовы платить $10/user/month за доску с real-time синхронизацией» — гипотеза.

3. Неправильная последовательность. MVP до проверки потребности. Каналы до проверки готовности платить. Всё задом наперёд.

4. Confirmation bias. Ищем подтверждение, не опровержение. Интерпретируем нейтральные данные как позитивные. Игнорируем негативный feedback.

5. Vanity metrics. 100K скачиваний, 3% retention. Красивые цифры для отчётов, ноль value для бизнеса.

6. Затянутые циклы. 6 месяцев на проверку одной гипотезы. Либо гипотеза слишком сложная (разбейте), либо процесс неэффективен (ускорьте).

Часто задаваемые вопросы: 

Сколько времени требует проверка одной гипотезы?

От 3 дней (технический spike) до 2–3 недель (глубокие JTBD-интервью). В среднем: 1–2 недели на гипотезу этапа Идеи, 2–4 недели на этап Концепции. Этап MVP — итеративный, здесь недели превращаются в месяцы.

Как использовать AI для проверки гипотез?

AI помогает на этапе подготовки: генерация вопросов для интервью, анализ конкурентов, синтез feedback из источников, формулировка гипотез. Но AI не заменяет разговор с реальными клиентами. GPT может симулировать ответы, но не может подтвердить готовность платить или выявить неартикулированную потребность.

Можно ли использовать 9 гипотез для существующего продукта?

Да. Для новой фичи или нового направления — те же 9 гипотез с нуля. Для оптимизации существующего — фокус на гипотезах 5–9 (состав предложения, каналы, ранние пользователи, функционал, монетизация). Гипотезы 1–3 уже подтверждены фактом существования работающего продукта.

Дополнительные материалы

Планируем сделать

• Инструменты ранжирования — Feature Canvas, Force Field Analysis, Окно возможностей в деталях

• Синдром второго продукта — почему успешные команды проваливают следующий продукт

9 гипотез — это не гарантия успеха. Это способ увидеть реальность до того, как она заберет кусочек вашей жизни и уверенности в своих силах ;-)

P.S. Жду ваши вопросы и инсайты в комментариях. Опишите ваш проект или ключевую дилемму: на каком этапе находитесь, с какой гипотезой самая большая неопределенность?

---

Дмитрий Безуглый и Команда Страт. Мастерской. Подписывайтесь на наш канал Продуктовые истории Дмитрия Безуглого