Product Discovery: что стоит знать, прежде чем начинать проектировать?

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

Именно эту проблему призван решать Product Discovery. Не для того, чтобы команда стала абсолютно уверенной во всём, это невозможно. Не для того, чтобы произвести ещё один большой документ, что никто не прочитает. И не для того, чтобы бесконечно откладывать разработку. Цель значительно практичнее: уменьшить самую опасную неопределённость, прежде чем она станет дорогой для изменения. Цифровой продукт не должен начинаться с экрана. Он должен начинаться с доказательств.

Воркшоп может быть частью discovery. Воркшоп не является discovery.

НЕ ВСТРЕЧА

Discovery, это не встреча

Одно из самых распространённых заблуждений, что discovery, это воркшоп, комната, доска Miro, несколько стикеров, горстка заинтересованных сторон, и через два часа кто-то производит customer journey и называет проект «исследованным». Это не discovery. Воркшоп может быть его частью. Так же как интервью, исследование или прототип. Но сам discovery, это процесс уменьшения неопределённости и изменения решений на основе того, что узнали.

Эта последняя часть важна. Если исследование производит двадцать страниц выводов, и ничего в продукте не меняется, команда, возможно, провела исследование. Она не обязательно провела содержательный discovery. Полезный способ думать об этом: вопрос, доказательство, интерпретация, решение. Что-то открыто, когда доказательства меняют то, во что команда верит, что должна делать. Функция удаляется, целевая аудитория сдвигается, воркфлоу упрощается, предположение отклоняется. Иногда самое ценное открытие просто: нам не стоит это строить. Это не провалившийся проект. Это может быть самым успешным результатом всего процесса.

ПРОБЛЕМА СНАЧАЛА

Проблема перед решением

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

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

Платформа медицинского образования Medpresso началась именно так, как редизайн сайта для диагностического центра. Врачи были исключительными, репутация росла, и они верили, что нуждаются в лучшем сайте. Они частично были правы. Реально им нужен был лучший способ донести, кем они уже были. Эта разница, раскрытая до любой дизайн-работы, и позволила отношениям вырасти в полноценную образовательную платформу, что используют тысячи врачей, не просто более красивую версию изначального запроса.

ЧТО НАХОДИТ

Что discovery реально пытается найти

Полезный процесс discovery не пытается узнать «всё», это невозможно. Он ищет информацию, что может существенно изменить направление продукта, обычно в нескольких категориях. Люди: кто реально переживает проблему, кто принимает решение, кто пользуется, кто платит, кто управляет системой внутренне, иногда пять разных групп. Проблема: что происходит сегодня, что делает это сложным, как часто, кого это касается, сколько это стоит. Контекст: когда появляется проблема, что её окружает. Существующий обходной путь, особенно важно, потому что таблица Excel, цепочка писем или разговор в WhatsApp, что выглядит нелепо со стороны, может существовать, потому что решает что-то, чего предложенный продукт ещё не понял. Бизнес-влияние: почему решение этого реально важно. И предположения, возможно, самая важная категория из всех, потому что discovery не о доказательстве, что команда права, а о выяснении, где команда может ошибаться.

НАЧНИ С ПРЕДПОЛОЖЕНИЙ

Начни с предположений, не с вопросов

Прежде чем проводить интервью, сильная команда записывает, во что она сейчас верит: клиенты покидают чекаут, потому что процесс слишком долгий, дилерам нужен мобильный интерфейс управления инвентарём, корпоративным покупателям нужны индивидуальные цены, пользователи хотят ИИ-рекомендаций. Это гипотезы, не факты, и эта разница важна. Как только предположения явные, их можно ранжировать по важности, неопределённости и стоимости ошибки. Незначительное предположение с низким влиянием не заслуживает двухнедельного исследовательского проекта. Фундаментальное предположение о том, кто будет пользоваться продуктом, может заслуживать самого первого разговора. Это один из способов, как discovery остаётся практичным, вместо того чтобы стать исследованием ради исследования.

ИНТЕРВЬЮ

Интервью мощны, и легко сделать их неправильно

Самая большая ошибка, это просить людей предсказать будущее. «Ты бы этим пользовался?» «Ты бы за это платил?» Эти вопросы производят оптимистичные ответы, потому что люди обычно вежливы, хотят быть полезными, и могут искренне верить, что пользовались бы чем-то, не доказывая, что действительно будут. Значительно лучшая отправная точка, это прошлое: расскажи мне о последнем разе, когда это случилось, что ты пытался сделать, что сделал дальше, что раздражало. Прошлое поведение, это доказательство. Будущее намерение, это гипотеза.

Люди, которых опрашивают, важны так же, как вопросы. Опрашивать только руководителей, друзей или людей, которым концепция уже нравится, распространённая ошибка, эти разговоры полезны, но не автоматически репрезентативны. У клиента одна перспектива, у продавца другая, у операционного менеджера третья, а администратор, что имеет дело с исключениями, что никто другой не видит, может иметь самую важную информацию из всех. Для B2B продуктов это становится ещё интереснее, человек, что покупает систему, может не быть человеком, что ею пользуется, а человек, что согласовывает покупку, может не быть человеком, что страдает от существующего процесса. Разговоры с заинтересованными сторонами раскрывают нечто другое, организационную реальность: какие команды задействованы, где происходят передачи, какие решения политические, не технические. Технически элегантный продукт может провалиться, потому что организация не может его принять, поэтому discovery должен понимать организацию вокруг продукта, не только конечного пользователя.

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

НАБЛЮДАЙ

Наблюдай за работой, не только спрашивай о ней

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

Мы видели именно этот разрыв с розничным клиентом, Sport Discount. Команда описывала свой сайт как работающий хорошо, вовлечённость выглядела нормально, ничего не казалось срочно сломанным. Наложение данных тепловых карт из Yandex Webvisor и Plerdy рядом с потоками поведения Google Analytics рассказало другую историю, большинство ссылок в хедере почти не получали кликов, а посетители застревали в местах, что никто не ожидал. Никто никого не вводил в заблуждение в разговоре, команда просто не видела того, что показывали записи, потому что перестала замечать трение годами раньше. Наблюдение, это то, где discovery зарабатывает свою ценность в операционном софте и любом проекте с существующим, обжитым воркфлоу.

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

ВОРКШОПЫ

У воркшопов есть цель, не монополия на истину

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

Связанная дисциплина важна так же: классифицировать то, на что смотришь. Доказательство, это что-то подкреплённое наблюдаемым поведением или надёжными данными. Предположение, это что-то, во что верят, но ещё не доказали. Интерпретация, это вывод, сделанный из доказательств. Гипотеза всё ещё нуждается в тестировании. Звучит формально, но становится реально полезным, как только проект вовлекает несколько заинтересованных сторон, это останавливает случайную реплику на встрече от того, чтобы тихо стать «требованием» через три месяца.

Утверждение, сказанное однажды на встрече, может тихо стать требованием через три месяца, если только кто-то не дисциплинирован в отношении правильной маркировки.

ТЕАТР ВАЛИДАЦИИ

Театр валидации, и как выглядит настоящая валидация

Именно здесь discovery часто становится перформативным. Команда строит прототип, показывает пяти людям, все говорят «выглядит отлично», и проект движется дальше с концепцией, названной валидированной. Обычно это не так. Валидация требует утверждения, что реально может провалиться. Если эксперимент спроектирован так, что почти любая позитивная реакция считается успехом, ничего не валидировано. «Ты бы пользовался приложением, что делает это легче» производит вежливый энтузиазм. «Проведи меня через последние три раза, когда ты решал эту проблему, теперь попробуй выполнить то же задание с этим прототипом» создаёт возможность наблюдать реальное поведение, что значительно сложнее подделать.

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

НЕ КАЖДАЯ ГИПОТЕЗА

Не каждая гипотеза нуждается в прототипе

Одна из самых больших неэффективностей в discovery, это слишком быстрый прыжок в дизайн. Иногда самый быстрый способ протестировать предположение, это интервью с клиентом, таблица Excel, фейковая дверь, лендинг, разговор о цене, или консьерж-процесс, где человек вручную выполняет то, что будущий софт должен автоматизировать. Это особенно важно для стартапов, постройка софта, чтобы проверить, хотят ли люди софта, может быть излишне дорогим экспериментом. Иногда лучший прототип, это человек, что притворяется продуктом.

Цель не в самом впечатляющем артефакте, а в том, чтобы узнать что-то важное как можно дешевле. Хорошая команда discovery продолжает спрашивать, какой наименьший эксперимент может содержательно уменьшить конкретную неопределённость, потому что если реальный вопрос, будут ли клиенты платить, тебе, вероятно, не нужен полный продукт; если вопрос, будет ли персонал реально пользоваться воркфлоу, реалистичная симуляция часто учит больше, чем отполированный UI. Именно этот вопрос может сэкономить месяцы.

ТЕХНИЧЕСКИЙ DISCOVERY

Технический discovery тоже должен случиться

Продукт может быть валидирован с пользователями и всё равно быть чрезвычайно сложным для постройки. Технический discovery существует, чтобы предотвратить эту неожиданность: какие системы уже существуют, где данные, какая система источник правды, какие API доступны и каковы их ограничения, что можно построить, купить или интегрировать. Именно здесь Product Discovery начинает напрямую соприкасаться с цифровой архитектурой.

Представь концепцию, где клиент настраивает сложный товар и получает мгновенную персонализированную цену. UX можно спроектировать и прототипировать, но откуда реально берётся цена, что случится, когда движок ценообразования недоступен, может ли CRM сохранить конфигурацию, может ли ERP её понять, видит ли клиент ту же цену везде. Это не более поздние детали реализации, они влияют на то, жизнеспособна ли концепция продукта вообще, поэтому технический discovery не должен начинаться после того, как Product Design «завершён». Он должен информировать его с самого начала, та же дисциплина, разобранная со стороны продукта в Product Design против UX/UI.

СКОЛЬКО ВРЕМЕНИ

Сколько времени это должно занять, и когда останавливаться

Нет универсального ответа, сфокусированная функция может нуждаться в днях, сложная B2B система с несколькими отделами и существующей инфраструктурой может нуждаться значительно дольше. Но discovery не должен становиться бесконечным исследовательским проектом, цель никогда не была знать всё, она в том, чтобы знать достаточно для разумного следующего дорогого решения. Это даёт естественное условие остановки: может ли команда ответить, с разумной уверенностью, какую проблему решает, для кого, как она решается сегодня, какие основные ограничения, какие предположения остаются рискованными, и что первая версия должна явно не делать. Разумная уверенность, не полная уверенность. Ожидание полной уверенности может стать своей формой избегания.

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

Чеклист решений discovery

РЕЗУЛЬТАТЫ

Результаты должны менять решения, не просто существовать

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

Есть одна ошибка, хуже полного пропуска discovery: провести его и потом проигнорировать. Три недели интервью раскрывают, что клиентам на самом деле не нужен запрошенный дашборд, им нужен более быстрый способ выполнить одну конкретную задачу. Все соглашаются. Дашборд всё равно строится, потому что «он уже в скоупе». В этой точке discovery стал театром, потому что весь смысл процесса в том, что новой информации позволено менять план. Иначе команда не занимается discovery, она документирует решение, что уже было принято.

Иногда самый ценный результат, это не меньшая версия запрошенного решения, а полностью другое. У бизнеса реально есть проблема продаж, но исправление, не замена CRM. Реально есть проблема конверсии, но исправление, не полный редизайн. Именно здесь discovery доказывает свою ценность, отделяя проблему, достойную решения, от решения, что кто-то случайно запросил первым.

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

От Discovery к Product Design

Как только критическую неопределённость уменьшили, вопрос меняется. Discovery спрашивает, что мы узнали. Product Design спрашивает, чем должен стать продукт из-за этого, точная граница и передача, что мы разбираем напрямую в Product Design против UX/UI. Две дисциплины пересекаются, но не одинаковы, discovery создаёт доказательства и уменьшает неопределённость, Product Design превращает это знание в продуктовую модель, UX/UI превращает модель в опыт, цифровая архитектура определяет, как должна работать система, разработка превращает систему в реальность. Последовательность редко идеально линейна, и на каждом этапе новая информация может двигать процесс назад. Это не неэффективность. Это обучение.

Это касается обычного корпоративного сайта так же, как и сложной платформы. Корпоративный сайт SV Group, производителя кастомной мебели и изделий из дерева, начался с бизнес-discovery до того, как существовал хоть один вайрфрейм, картируя, как компания реально хотела донести свою экспертизу, продукты и философию, не просто организовать страницы. Собственные слова клиента позже подытожили, почему эта последовательность важна: «компания не продаёт сайты, она продаёт новое понимание бизнеса». Discovery, это то, что делает это понимание возможным, независимо от того, насколько простым выглядит финальный результат.

Discovery добавляет реальную работу до начала разработки, это правда, и звучит как затрата. Но честное сравнение никогда не было стоимость discovery против отсутствие стоимости discovery, это стоимость discovery против стоимости выяснения той же правды после реализации. Узнать во время интервью, что клиенты не хотят функцию, дёшево. Узнать об этом после трёх месяцев разработки, дорого. Цель никогда не была полностью убрать неопределённость, она в том, чтобы переместить дешёвый тип неопределённости раньше, до того, как он станет дорогим. Хороший продукт не начинается в момент, когда кто-то открывает Figma. Он начинается, когда команда может сказать, с разумной уверенностью, вот проблема, вот кого она касается, вот почему это важно, и вот решение, что мы готовы принять из-за того, что узнали. Только тогда следующий реальный вопрос становится, что вообще проектировать.

Чем Product Discovery отличается от kickoff-звонка или сбора требований?

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

Нужна ли каждому проекту полная фаза discovery?

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

Какой самый большой признак, что процесс discovery провалился?

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

Может ли discovery случиться после того, как проект уже начался?

Да, и часто должен. Новая информация редко приходит по удобному расписанию. Команда, что относится к новому открытию как к причине пересмотреть план, даже посреди проекта, всё ещё правильно занимается discovery.