# Product discovery — что из мировых практик работает в промышленности Product discovery — это не этап перед разработкой и не синоним фразы «мы поговорили с клиентом». В софтверной индустрии этому определению посвящены книги и конференции; в промышленном B2B к нему чаще всего вообще не обращаются — там гипотезу утверждает совещание, а не разговор с покупателем. За 14 лет работы с промышленными и DeepTech-продуктами я видел обе крайности: discovery, которое реально меняет решение, и discovery, которое существует только для отчёта. Разница между ними не в методичке, а в том, способен ли результат разговора отменить уже принятое решение. ## Мировая практика Marty Cagan, основатель Silicon Valley Product Group, разводит discovery и delivery как две параллельные, а не последовательные дорожки одной и той же команды. В статье [Discovery vs. Delivery](https://www.svpg.com/discovery-vs-delivery/) он формулирует цель discovery предельно прагматично: получить достаточно свидетельств, что решение, которое команда отдаёт инженерам в разработку промышленного качества, не обернётся потраченным впустую усилием. Discovery у Cagan проверяет четыре риска — ценность, удобство использования, техническую реализуемость и жизнеспособность для бизнеса — и делает это до того, как деньги уйдут в продакшн-код, а не после релиза. Teresa Torres в [«Continuous Discovery Habits»](https://www.producttalk.org/continuous-discovery-habits/) идёт дальше общего принципа и предлагает конкретный ритуал: минимум еженедельный контакт продуктовой тройки — менеджера, дизайнера, инженера — с клиентами, и визуализацию находок через opportunity solution tree. Дерево растёт от одной измеримой цели вниз, через пространство проблем, к конкурирующим решениям, которые не внедряются сразу, а проверяются как гипотезы. Ключевой приём Torres — [интервью о конкретной прошлой ситуации](https://www.producttalk.org/opportunity-solution-trees/), а не о гипотетическом будущем: люди достоверно описывают, что делали вчера, и почти всегда фантазируют, отвечая на вопрос «купили бы вы». Jeff Patton, автор [story mapping](https://jpattonassociates.com/story-mapping/), описывает ту же границу через простую формулу: [«build to learn vs build to earn»](https://www.svpg.com/build-to-learn-vs-build-to-earn/). В discovery команда строит прототип, чтобы проверить risk — ценность, юзабилити, реализуемость, — и его можно выбросить после первого же разговора с клиентом. В delivery команда строит продукт, на котором клиент будет зарабатывать или экономить деньги годами, и здесь цена ошибки другая. Story map у Patton — инструмент именно для discovery: карта дня клиента строится не для того, чтобы стать бэклогом, а чтобы показать, где в этом дне реальная боль, достаточно острая, чтобы за решение платили. У всех трёх подходов есть общее слабое место, которое хорошо описывает критика [«discovery theater»](https://thehardparts.dev/failure-modes/discovery-theater): интервью, персоны и карты пути можно провести по всем правилам и получить нулевое влияние на решение, если решение принято до начала исследования. Ритуал без права сказать «нет» — это не discovery, а согласование задним числом, которое лишь выглядит как исследование. ## Что выдержало мою практику В промышленном B2B собеседник на другом конце разговора — не конечный потребитель, а главный инженер завода, снабженец или проектировщик архитектурного бюро, который выбирает не по эмоции, а по техническому регламенту и внутреннему согласованию. Еженедельный ритм интервью Torres здесь почти нереализуем буквально: у завода нет потока новых клиентов на входе, с которыми можно назначать встречи каждый понедельник. Но принцип переносится без изменений: интервью проводится до того, как решение упаковано, а не после. Гипотезу дешевле убить интервью, чем MVP — неделя разговоров стоит меньше, чем месяцы разработки, которые упрутся в тот же отказ. Когда прорабатывал выход быстровозводимых конструкций на рынок Узбекистана, я не стал сразу готовить презентацию для архитектурных бюро — сначала разработал отдельные гайды интервью под лиц, принимающих решения, и провёл [[CustDev конструкций в Узбекистане|кастдев]]: материал разговоров лёг в основу дальнейшей работы, а не подтверждал уже готовое решение. По той же логике для внутреннего сервиса хозобеспечения [[Клиентские интервью для внутреннего сервиса|клиентское интервью]] не подтвердило абстрактную ценность продукта, а вскрыло конкретные проблемные сценарии — продукт дорабатывался под них. Показательный пример, где discovery изменило не формулировку, а саму архитектуру продукта, — история с инструментом расчёта коммерческих предложений. Задача формулировалась как ускорение расчёта: менеджер тратил на подготовку КП полтора-два месяца, и очевидным ответом казался более быстрый калькулятор. Но [[Аудит воронки продаж конструкций|аудит воронки]] продаж за год показал другую картину: из 1642 обращений целевыми оказались только 266 — 16,2%. Узкое место было не в скорости расчёта, а в том, что калькулятор одинаково старательно считал предложение и для серьёзного покупателя, и для нецелевого лида, который отваливался на следующем шаге согласования. Продукт пересобрали вокруг квалификации: [[Чек-лист квалификации входящих заявок|чек-лист]] на входе воронки и квалификационный квиз из шести вопросов, встроенный в [[Калькулятор КП и квиз квалификации|калькулятор]], сократили обработку заявки до 30 минут — не потому что калькулятор стал считать быстрее, а потому что до расчёта теперь доходили только те, кому его вообще стоило считать. Похожая находка вышла из разбора потерь на индийском направлении. Из 40 проанализированных лидов [[Win-Loss-анализ продаж в Индии|45% ушли в отказ]], и почти треть этих причин — 27,8% — оказались управляемыми внутри процесса продаж, а не особенностями рынка. Это тоже discovery: не интервью, а системный разбор фактических данных о том, где реально теряется сделка, — и он изменил план действий так же, как изменил бы его разговор с клиентом. В обоих случаях решение отменили не мнения, а числа и записанные разговоры — команда не могла бы удержать прежний план, не проигнорировав данные открыто. Это и есть проверка на «discovery theater» из мировой практики, применённая к промышленному контексту: если находка не в силах изменить архитектуру продукта или список причин отказа, то это не discovery, а иллюстрация к уже принятому решению. ## Вывод Мировая практика product discovery — набор конкретных инструментов: параллельные дорожки исследования и разработки у Cagan, еженедельный контакт с клиентом и дерево возможностей у Torres. В промышленности эти инструменты меняют форму: интервью проходят реже, собеседник — инженер или снабженец, а не потребитель, ритм задают производственные и закупочные циклы, а не спринты. Но проверка остаётся одной и той же независимо от отрасли: способен ли результат разговора или разбора данных отменить уже принятое решение. Если нет — это не discovery, а его имитация, сколько бы интервью ни было проведено. ## Мои кейсы по теме - [[CustDev конструкций в Узбекистане]] - [[Клиентские интервью для внутреннего сервиса]] - [[Аудит воронки продаж конструкций]] - [[Win-Loss-анализ продаж в Индии]] **Практический разбор по теме:** [[Как понять, стоит ли развивать продукт — продуктовая диагностика]] ## Связаться Если у вас похожая задача — обсудим ваш продукт: [[email protected]](mailto:[email protected]), Telegram [@falcolupus](https://t.me/falcolupus) или [MAX](https://max.ru/u/f9LHodD0cOJd5VFHyaG9k7YpP7BW9s55ZYkjWX6P8j51xBYS3XgDfnOxz3U). Работаю удалённо в любом часовом поясе.