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

90% стартапов проваливаются. Главная причина — они решают не те проблемы, которые реально беспокоят пользователей. Discovery-фаза существует, чтобы до начала разработки понять: нужен ли вообще этот продукт и какую боль он закрывает. Это руководство — о том, как исследовать проблемное пространство, проводить интервью, валидировать гипотезы и не тратить месяцы на создание того, что никому не нужно.

Что такое Discovery-фаза и зачем она нужна

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

Термин «discovery» (открытие, исследование) подчёркивает суть процесса: мы не знаем ответов заранее и идём их искать. В отличие от delivery (доставки), где мы реализуем известное решение, в discovery мы ещё определяем, что именно строить.

Зачем это нужно? Статистика безжалостна. По данным исследований Microsoft, 70% функций продуктов используются редко или никогда. Другие источники указывают, что 80% программных продуктов не используются, что ежегодно приводит к потере 29.5 миллиардов долларов на R&D. Discovery помогает избежать этих потерь, проверяя гипотезы до инвестиций в разработку.

«Ни один бизнес-план не выживает после первого контакта с клиентом.» — Стив Бланк, создатель методологии Customer Development

Discovery vs Delivery

Продуктовая работа состоит из двух больших активностей: discovery и delivery. Discovery отвечает на вопрос «что строить?», delivery — «как построить?». Это разные виды деятельности с разными инструментами и метриками успеха.

Критически важно: discovery и delivery не должны быть разделены между разными командами. Марти Каган из SVPG подчёркивает: «Мы никогда не хотим разделять эти две активности продуктовой команды. Когда разные люди делают discovery и delivery, те, кто реализует решение, не были в комнате, где оно принималось.» Это ведёт к потере контекста и худшим решениям.

Когда проводить Discovery

Discovery нужна не только при создании нового продукта. Она актуальна в нескольких ситуациях:

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

Новая фича для существующего продукта. Прежде чем добавлять функциональность, стоит убедиться, что она решает реальную проблему и пользователи будут её использовать.

Выход на новый рынок или сегмент. Даже если продукт успешен в одном сегменте, новая аудитория может иметь другие потребности.

Стагнация метрик. Если продукт перестал расти, discovery поможет найти новые точки роста или понять барьеры.

Continuous Discovery. Современный подход предполагает, что discovery — не разовое событие, а непрерывный процесс. Тереза Торрес рекомендует проводить интервью с пользователями минимум раз в неделю.

Problem Space vs Solution Space: фундаментальное разделение

Одна из ключевых концепций в discovery — разделение на проблемное пространство (problem space) и пространство решений (solution space). Понимание этого разделения критически важно для качественного исследования.

Что такое Problem Space

Problem Space — это пространство, где живут потребности пользователей. Здесь мы изучаем пользователей и их проблемы, чтобы понять, что продукт должен делать. Problem space отвечает на вопросы «что?» и «почему?»: какие проблемы есть у пользователей и почему они важны.

В problem space мы исследуем:

• Кто наши пользователи (персоны, сегменты)

• Какие у них цели и задачи

• С какими проблемами они сталкиваются

• Как они сейчас решают эти проблемы (workarounds, конкуренты)

• Какой контекст влияет на их поведение

Что такое Solution Space

Solution Space — это пространство, где живут продукты и их представления. Здесь мы думаем о конкретных решениях: фичах, интерфейсах, технологиях. Solution space отвечает на вопрос «как?»: как продукт будет доставлять ценность пользователям.

В solution space мы работаем с:

• Концепциями и идеями решений

• Прототипами и макетами

• Техническими решениями и архитектурой

• Конкретными фичами и их реализацией

Почему важно их разделять

Смешивание problem space и solution space — одна из главных ошибок продуктовых команд. Когда мы прыгаем к решениям, не разобравшись в проблеме, мы рискуем построить фичи, которые никому не нужны.

Классический пример от Скотта Кука, основателя Intuit. На встрече с продакт-менеджерами он спросил: «Кто главный конкурент TurboTax?» Кто-то уверенно ответил: «TaxCut от H&R Block». Кук удивил всех: «Главный конкурент TurboTax — это ручка и бумага. Больше американцев всё ещё заполняют налоги вручную, чем все налоговые программы вместе взятые.» Это пример преимущества мышления в problem space: более точное понимание рынка, на котором вы конкурируете.

«Problem space спрашивает "Почему?" и "Что?", solution space — "Как?" и "Будет ли это работать?". Размывание границ ведёт к потерянным усилиям.»

Сколько времени проводить в каждом пространстве

Здесь существуют две школы мысли, и обе заслуживают внимания.

Традиционный взгляд: Основная часть работы продакт-менеджера должна быть в problem space. Нужно фокусироваться больше на проблеме, меньше на решении. Оставайтесь в problem space столько, сколько нужно для глубокого понимания проблемы.

Взгляд Марти Кагана: Подавляющее большинство продуктовых провалов происходит не из-за отсутствия спроса, а потому что команды не могут придумать достаточно хорошее решение, чтобы люди переключились на него. Поэтому в сильных продуктовых компаниях большая часть discovery должна быть посвящена работе над решением.

Истина, вероятно, посередине: нельзя игнорировать problem space, но и бесконечный анализ без движения к решениям не приносит результата. Важно помнить, что понимание проблемы и разработка решения требуют тесного сотрудничества продукта, дизайна и инженеров — это не должно быть разделено по ролям.

Методы исследования пользователей в Discovery

Discovery использует набор качественных и количественных методов для понимания пользователей и их проблем. Рассмотрим ключевые из них.

Глубинные интервью (User Interviews)

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

Интервью — фундаментальный метод для построения эмпатии. Стив Бланк настаивает: «Нужно видеть, как расширяются зрачки собеседника. Это не делается через SurveyMonkey — только через видео, Skype или личные встречи.»

Структура интервью

Базовые вопросы для Customer Development

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

1. Расскажите, как вы сейчас делаете [задачу]?

2. Используете ли вы какие-то инструменты, продукты, приложения для выполнения [задачи]?

3. Если бы вы могли делать что-то, что сейчас не можете — что бы это было?

4. В последний раз, когда вы делали [задачу], что вы делали непосредственно до и после?

5. Есть ли что-то о [теме], что я должен был спросить, но не спросил?

Главный принцип: лучшие интервью — те, где респондент говорит больше, чем вы.

Контекстуальное исследование (Contextual Inquiry)

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

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

Этот метод идеален для ранней стадии discovery, когда нужно понять сложные процессы или найти неочевидные потребности.

Опросы (Surveys)

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

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

Анализ данных продукта

Если продукт уже существует, данные о поведении пользователей — бесценный источник инсайтов. Аналитика показывает, что пользователи реально делают, а не что говорят.

Ключевые вопросы для анализа:

• Какие фичи используются чаще всего, какие — реже?

• Где пользователи «застревают» в воронке?

• Как отличается поведение активных и ушедших пользователей?

• Какие паттерны предшествуют оттоку?

Конкурентный анализ

Исследование конкурентов — обязательная часть discovery. Нужно понять: какие решения уже есть на рынке, какие проблемы они решают (и не решают), как позиционируются, какие у них слабые места.

Игнорирование конкурентного анализа или его поверхностное проведение — одна из типичных ошибок discovery. Даже если прямых конкурентов нет, есть альтернативные способы решения проблемы (включая «ничего не делать» или «решать вручную»).

Комбинирование методов

Ни один метод не даёт полной картины. Лучшая практика — комбинировать количественные и качественные методы. Интервью дают глубину понимания, опросы — масштаб, аналитика — объективные данные о поведении, наблюдение — контекст.

«Используйте микс методов: контекстуальное исследование, этнографию, поведенческую аналитику. Это даёт целостное понимание пользователей. Continuous discovery — ключ. Потребности пользователей эволюционируют, и исследования должны адаптироваться вместе с ними.»

Customer Development: методология Стива Бланка

Customer Development — методология, разработанная Стивом Бланком в 1990-х годах. Она стала основой для Lean Startup и современного подхода к созданию продуктов. Суть: прежде чем строить продукт, нужно понять клиентов через систематическое исследование.

Четыре этапа Customer Development

Процесс состоит из четырёх последовательных этапов:

Customer Discovery (Обнаружение клиентов). Первый и критически важный этап. Цель — проверить, существует ли проблема, которую вы хотите решить, и есть ли клиенты, готовые за решение платить. На этом этапе вы формулируете гипотезы и проверяете их через интервью.

Customer Validation (Валидация клиентов). Проверка того, что найденный сегмент клиентов готов покупать ваше решение. Здесь появляются первые продажи или чёткие сигналы готовности платить.

Customer Creation (Создание клиентов). Масштабирование привлечения клиентов после того, как модель валидирована.

Company Building (Построение компании). Переход от стартапа к масштабируемой организации.

Для discovery-фазы наиболее релевантен первый этап — Customer Discovery.

Принципы Customer Discovery

Get Out of the Building. Ключевой принцип Бланка. Нельзя понять клиентов, сидя в офисе. Нужно выходить и разговаривать с реальными людьми. В курсе Бланка студенты должны провести 100 интервью за 10 недель.

Фокус на поведении, не на мнениях. Люди плохо предсказывают своё будущее поведение. Вместо вопроса «Купили бы вы такой продукт?» спрашивайте о том, как они решают проблему сейчас, сколько времени и денег тратят, какие альтернативы пробовали.

Ищите закономерности. Одно интервью — это анекдот. Десять интервью с похожими ответами — паттерн. Ищите повторяющиеся проблемы, боли, поведение.

Итерации, не водопад. Customer Development — итеративный процесс. Вы формулируете гипотезы, проверяете их, корректируете понимание, формулируете новые гипотезы.

Кого интервьюировать

Не все пользователи одинаково полезны для discovery. По кривой принятия инноваций, фокусируйтесь на:

Лучшие респонденты для discovery — инноваторы и ранние последователи. Они остро чувствуют проблему и активно ищут решения. Также важно интервьюировать разных пользователей: активных, редких, ушедших, тех, кто выбрал конкурентов.

Jobs to Be Done: фреймворк для понимания мотивации

Jobs to Be Done (JTBD) — фреймворк, который помогает понять, какую «работу» пользователи «нанимают» продукт выполнять. Разработан Тони Ульвиком, основателем Strategyn, и популяризирован Клейтоном Кристенсеном.

Ключевая идея

Люди не покупают продукты — они «нанимают» их для выполнения определённой работы. Milkshake покупают не потому, что он вкусный, а потому, что он решает задачу «занять руки и рот во время скучной поездки на работу». Дрель покупают не ради дрели, а ради дырки в стене.

JTBD помогает выйти за рамки демографии и фич к пониманию глубинных мотивов поведения. Вместо вопроса «какие фичи добавить?» спрашиваем «какую работу пользователи пытаются выполнить?»

Структура Job Statement

Job Statement — формулировка работы — имеет структуру:

Когда [ситуация], я хочу [работа], чтобы [результат]

Или альтернативная формула:

[Глагол действия] + [объект действия] + [контекст]

Примеры для Spotify:

• «Найти подходящую музыку для определённой активности — тренировки, вечеринки, готовки»

• «Открыть новые плейлисты в дороге, основанные на моих предпочтениях»

• «Делиться плейлистами с друзьями и создавать общие подборки»

Практическое применение

JTBD особенно ценен на этапе discovery, потому что позволяет:

Точнее определить конкурентов. Конкуренты — не те, кто делает похожий продукт, а те, кто выполняет ту же работу. Для Netflix конкурент — не только Disney+, но и сон, и прогулка, и видеоигры.

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

Создавать продукты, а не фичи. JTBD фокусирует на результате для пользователя, а не на функциональности.

Примеры успешного применения

Microsoft Software Assurance. Через JTBD Microsoft обнаружил, что клиенты ищут не просто обновления ПО, а возможность оптимизировать IT-бюджеты, управлять рисками и минимизировать сбои. Переработка программы на основе этих инсайтов привела к 100% росту выручки год к году.

Kroll Ontrack. Юристы приоритизировали 20 недообслуженных результатов в области e-discovery и управления информацией при судебных разбирательствах. Продукт, разработанный на основе этих данных, за пять лет принёс дополнительные 200 миллионов долларов выручки.

Opportunity Solution Tree: визуализация discovery

Opportunity Solution Tree (OST) — инструмент, созданный Терезой Торрес в 2016 году для визуализации и структурирования процесса discovery. Это способ наглядно представить путь от бизнес-целей к решениям через понимание возможностей.

Структура дерева

OST имеет четыре уровня:

Outcome (Результат). Корень дерева — желаемый бизнес-результат. Это должна быть чёткая, измеримая цель, которая отражает создание ценности для бизнеса. Например: «Увеличить retention Day 30 с 25% до 35%».

Opportunities (Возможности). Второй уровень — неудовлетворённые потребности, боли и желания пользователей, которые, если адресовать, приведут к желаемому результату. Это problem space в чистом виде.

Solutions (Решения). Третий уровень — идеи и фичи, которые команда считает способными закрыть выявленные возможности.

Experiments (Эксперименты). Четвёртый уровень — способы проверки предположений о решениях до полноценной разработки.

Зачем использовать OST

Opportunity Solution Tree помогает решить несколько проблем:

Alignment команды. Дерево создаёт общее понимание того, над чем работает команда и почему. Все видят связь между бизнес-целями и конкретными задачами.

Навигация в хаосе discovery. Discovery — хаотичный процесс с множеством направлений. OST помогает структурировать этот хаос и не терять фокус.

Фрейминг решений. Вместо подхода «делать или не делать» OST позволяет сравнивать альтернативные решения для одной возможности.

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

Работа с деревом

OST — не статичный артефакт, а живой инструмент. Ключевой принцип: «Карты не статичны. Они должны отражать то, что вы знаете сейчас. Если вы непрерывно учитесь, они должны непрерывно эволюционировать.»

Работа с OST предполагает:

• Регулярное обновление по мере получения новых инсайтов

• Декомпозицию больших возможностей на меньшие, более решаемые

• Разбиение идей на лежащие в их основе предположения для быстрой проверки

• Отсечение веток, которые оказались тупиковыми

Assumption Mapping: работа с неопределённостью

В основе любого продуктового решения лежат предположения (assumptions). Assumption Mapping — техника для выявления и приоритизации рискованных предположений, разработанная Джеффом Готельфом и Джошем Сейденом, авторами Lean UX.

Зачем маппить предположения

Большинство продуктовых фич (до 70%) не достигают ожидаемых бизнес-результатов. Непроверенные предположения ведут к потраченным ресурсам, сорванным дедлайнам и продуктам, которые не решают реальных проблем. Assumption mapping экономит время и деньги, помогая принимать более обоснованные решения.

Типы предположений

Процесс маппинга

Шаг 1: Выявление предположений. Команда собирается и записывает все предположения, которые лежат в основе продуктовой идеи. Без фильтрации — записываем всё.

Шаг 2: Классификация. Каждое предположение размещается на матрице 2x2 по двум осям:

• Важность: насколько критично это предположение для успеха

• Неопределённость: насколько мы уверены в его истинности

Шаг 3: Приоритизация. Предположения в квадранте «высокая важность + высокая неопределённость» — самые рискованные. Их нужно проверять в первую очередь.

Шаг 4: Формулирование гипотез. Предположения превращаются в тестируемые гипотезы. Формат: «Мы верим, что [предположение]. Мы проверим это, [метод проверки]. Мы поймём, что были правы, если [критерий успеха].»

Шаг 5: Проверка. Гипотезы тестируются минимальными способами: интервью, прототипы, fake door tests, MVP.

Методы проверки предположений

MVP (Minimum Viable Product). Это не уменьшенная версия продукта, а минимальный эксперимент для сбора данных. Может быть интерактивным прототипом, лендингом или ручным «Wizard of Oz» тестом.

Fake Door Test. Добавляете кнопку или ссылку на несуществующую фичу. Когда пользователь кликает, видит сообщение «Скоро будет» с предложением оставить email. Количество кликов показывает интерес.

Concierge MVP. Вручную делаете то, что должен делать продукт. Позволяет проверить ценность решения до написания кода.

Landing Page Test. Создаёте страницу с описанием продукта и призывом к действию (регистрация, предзаказ). Конверсия показывает спрос.

Артефакты Discovery-фазы

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

Персоны (User Personas)

Описание типичных пользователей: их цели, боли, контекст, поведение. Хорошая персона основана на реальных исследованиях, а не на фантазиях команды.

Customer Journey Map

Визуализация пути пользователя: этапы взаимодействия с продуктом, точки контакта, эмоции, барьеры. Помогает увидеть опыт глазами пользователя.

Problem Statement

Чёткая формулировка проблемы, которую решает продукт. Формат: «[Пользователь] хочет [цель], но сталкивается с [барьер], что приводит к [негативный результат].»

Value Proposition Canvas

Связка между потребностями пользователя (jobs, pains, gains) и тем, как продукт их адресует (products, pain relievers, gain creators).

Prioritized Opportunity Backlog

Список возможностей (проблем, потребностей), приоритизированный по влиянию на бизнес-метрики и уверенности в понимании.

Validated Hypotheses Log

Журнал проверенных гипотез: что тестировали, как, какой результат. Накопленная база знаний о том, что работает и не работает.

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

Даже опытные команды совершают ошибки в discovery. Вот самые распространённые и способы их избежать.

Ошибка 1: Валидация в конце

Многие команды относятся к валидации как к финальному штампу одобрения: построили — валидировали. К этому моменту уже потрачены недели или месяцы на разработку потенциально неверного направления.

Решение: интегрировать валидацию в каждый этап discovery. Проверять предположения до начала разработки, а не после.

Ошибка 2: Confirmation Bias

Когда вы предвзяты, вы используете discovery для подтверждения своего мнения, а не для поиска истины. Это одна из самых коварных ошибок, потому что она часто неосознанна.

Решение: активно искать информацию, которая опровергает ваши гипотезы. Задавать вопрос «что должно быть правдой, чтобы мы были неправы?»

Ошибка 3: Discovery только для продакта

Изолирование discovery в руках продакт-менеджера или дизайнера — распространённая ошибка. Инженеры подключаются позже и не имеют контекста.

Решение: discovery требует активного участия продукта, дизайна и инженеров. Все должны быть в комнате, где принимаются решения.

Ошибка 4: Прыжок к решениям

Команды часто так стремятся начать строить, что пропускают глубокое понимание проблемы. Результат — продукты, которые решают не те проблемы.

Решение: сознательно задерживаться в problem space. Не начинать обсуждение решений, пока нет ясности по проблеме.

Ошибка 5: Слишком долгий discovery

Обратная крайность — бесконечное исследование без перехода к действиям. Компании проводят трёхмесячные discovery-циклы и достигают точки убывающей отдачи.

Решение: discovery должен быть лёгким и непрерывным. Для среднего проекта достаточно 1-2 недель для первого цикла, затем — итерации.

Ошибка 6: Опора на один источник данных

Легко манипулировать данными для поддержки идеи. Сложнее сделать это с несколькими независимыми источниками.

Решение: триангуляция данных. Интервью + аналитика + опросы. Если разные источники дают одинаковый сигнал — уверенность выше.

Ошибка 7: Игнорирование конкурентов

Продуктовый discovery без глубокого конкурентного анализа — огромная ошибка. Даже если прямых конкурентов нет, есть альтернативные решения.

Решение: систематический анализ конкурентов и альтернатив. Понимание их сильных и слабых сторон.

Ошибка 8: Vanity Metrics

Фокус на метриках, которые хорошо выглядят, но не говорят о реальном прогрессе: просмотры страниц, скачивания приложения, подписчики в соцсетях.

Решение: фокус на actionable metrics, которые связаны с бизнес-результатом и на которые можно влиять.

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

Continuous Discovery: от проекта к процессу

Современный подход рассматривает discovery не как отдельную фазу, а как непрерывный процесс. Тереза Торрес определяет continuous discovery как «проведение небольших исследовательских активностей через еженедельные контакты с пользователями командой, которая строит продукт».

Принципы Continuous Discovery

Еженедельные контакты с пользователями. Минимум раз в неделю кто-то из команды разговаривает с пользователем. Это поддерживает близость к реальным потребностям и позволяет быстро проверять гипотезы.

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

Вся команда участвует. Не только продакт или дизайнер, но и инженеры участвуют в discovery. Это создаёт общее понимание и лучшие решения.

Баланс discovery и delivery. Это не последовательные фазы, а параллельные активности. Команда одновременно исследует новые возможности и реализует валидированные решения.

Каденция

Как понять, что Discovery успешна

Discovery — это про уменьшение неопределённости. Но как измерить успех?

Индикаторы качественного discovery

Команда может артикулировать проблему. Каждый член команды может ясно объяснить, какую проблему решает продукт и для кого.

Есть evidence, не только мнения. Решения основаны на данных исследований, а не на интуиции или мнении HiPPO (Highest Paid Person's Opinion).

Ключевые предположения проверены. Самые рискованные гипотезы протестированы до начала разработки.

Alignment по приоритетам. Команда и стейкхолдеры согласны, какие возможности приоритетны и почему.

Есть чёткие критерии успеха. Определено, как будет измеряться успех решения после запуска.

Метрики процесса

Количество интервью в неделю. Индикатор того, насколько команда близка к пользователям.

Время от гипотезы до проверки. Как быстро команда переходит от предположения к данным.

Процент валидированных гипотез перед разработкой. Сколько ключевых предположений проверено до написания кода.

Kill rate. Процент идей, отсеянных на этапе discovery. Если kill rate низкий, возможно, команда недостаточно критична или тестирует недостаточно.

Заключение: Discovery как инвестиция в успех

Discovery-фаза — это не бюрократическая процедура и не «трата времени вместо разработки». Это инвестиция, которая многократно окупается, предотвращая создание продуктов, которые никому не нужны.

Ключевые принципы успешного discovery:

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

Второе — выходите из офиса. Discovery не делается в переговорных комнатах. Разговаривайте с реальными пользователями, наблюдайте за ними в контексте.

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

Четвёртое — делайте discovery непрерывным. Это не фаза, а образ мышления. Еженедельные контакты с пользователями, маленькие эксперименты, постоянное обучение.

Пятое — вовлекайте всю команду. Discovery — не работа только продакта. Инженеры и дизайнеры должны участвовать, чтобы иметь контекст и вносить свою экспертизу.

Шестое — используйте фреймворки как инструменты. Customer Development, JTBD, Opportunity Solution Tree, Assumption Mapping — это инструменты, не догмы. Адаптируйте их под свой контекст.

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

Статистика говорит сама за себя: 90% стартапов проваливаются, и часто причина — в решении не тех проблем. 70% фич не используются. Миллиарды долларов тратятся на разработку продуктов, которые не нужны пользователям.

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

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

А лучшие вакансии для менеджеров ищите на hirehi.ru