Ваш пост — это просто кринж, и сейчас я обьясню, почему. Вы пытаетесь говорить о продуктовом подходе, но ваше видение — это чистый waterfall в мире agile. Очень боomer-energy.

Вы правы в одном: слепое execution of user requests — это путь в feature factory и product death cycle. Но ваш альтернативный путь звучит как какой-то esoteric crystal healing вместо data-informed product management.

Смотрите, вы говорите: "Цель продуктового подхода всегда была и будет в исследовании боли клиента и генерации гипотез". Это такой себе oversimplification. Продуктовый подход — это не про "исследовать боль", а про continuous discovery и validated learning. Это про построение sustainable business на основе value, viability, usability и feasibility, как тотально заезженно, но authoritative Marty Cagan в "Inspired" описывает. Вы же предлагаете просто заменить один костыль ( implementation of user ideas ) на другой ( intuition-driven "исследование" ).

Ваш пассаж про кастдевы — это вообще мисс. Вы против того, чтобы спрашивать "что болит и как починить", и это правильно. Но современный product discovery — это не про "смотреть и продуктово думать". Это про фреймворки вроде Opportunity Solution Tree (см. работу Teresa Torres), которые systemize подход к генерации гипотез, связывая opportunity с решениями и experiments. Вы же предлагаете просто заменить запросы пользователей на интуицию продукт-менеджера. Это не гипотеза, а opinion. А opinion — это самый слабый currency в современном продукте.

И насчет метрик. Вы говорите: "метрики позволяют либо показать фокус на проблемных местах, либо помочь в исследовании проблемы". Это 2010-й год звонит, он хочет свой подход назад. Метрики — это не про "показать фокус". Это про formation of a hypothesis, design of an experiment, и measurement of outcome. Это про цикл "Build-Measure-Learn" из Lean Startup Эрика Риса. Без этого ваш "продуктовый дзен" — это просто guessing.

Ваше заключение, что люди "бездумно используют инструменты" — это maybe единственная валидная point. Но ваш proposed alternative — это не better. Вы essentially предлагаете перейти от customer-driven (что плохо) к vision-driven без всякого validation (что еще хуже). Современный продукт — это data-informed, hypothesis-driven и customer-centric подход одновременно. Это не выбор одного из трех.

В итоге, ваш mental model упускает ключевые концепции modern product management:

1. Experimentation over opinion (ссылка на "Experimentation Works" by Stefan Thomke, HBR). 2. Discovery as a continuous process, а не разовое "исследование" (ссылка на "Continuous Discovery Habits" by Teresa Torres). 3. Outcome over output (ссылка на "Impact Mapping" by Gojko Adzic).

Ваше видение — это просто old wine in new bottles. Оно не обосновано ничем, кроме личного мнения, и это тотал.

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

Согласен и поддерживаю. В идеальном приближении, клиент хочет кнопку "сделать зашибись" (работа по принципу "чёрного ящика"). Если же мы выясняем, что он хочет добавить строчку в отчёт или завести новую страничку, велика вероятность, что продукт не делает достаточно "зашибись". И вот это нужно срочно исправлять.

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

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

Так для того и существуют фреймворки JTBD и проблемного интервью, когда исследуешь именно работу, на которую нанимают продукт, а также исследуешь боль, чтобы понять, какую боль, потребность, работу клиент хочет закрыть, а не в лоб спрашиваешь - а как вы хотите решить вашу потребность/боль, работу

А не будет ли тут истории с фантомной болью, когда бизнес навязывает боль клиенту?

Задача для product manager/ Архитектора удержать превращение продукта во Франкенштейна. Понять боль заказчика да, но предложить « правильное» решение. Для этого необходимо владеть процессами заказчика лучше него. А когда состав команды бесконечно меняется и состав junior и middle то и получаем, что получаем

Интересный диалог) хочется продолжения)) Тогда ломается и не работает техника продаж. На первом месте всегда ПРОДУКТ, а уже дальше техника продаж. Предлагаю продолжить эту тему с конкретными примерами…..

Кстати, очень сильно соглашусь. Я бы к бесполезному еще отнесла брейнштормы. В большинстве проектов это выглядит «мы придумываем работу, чтобы работать». О сути «почему эта проблема/мысль/идея вообще появилась» мало кто думает

Кастдевы -да. Но решение задачи оставляю  аналитикам и архитектору

А потом система превращается во Франкенштейна, который состоит из таких костылей, решающих хотелки клиентов. Но рано или поздно, появляется такая хотела клиента, которая ставит под вопрос, целесообразность существования такой чудной конструкции. В общем, чемодан без ручки. И нести тяжело и бросить жалко.