В 2025 году в IT-индустрии говорить о важности исследований и продуктового подхода - почти моветон. Все уже в курсе, что нельзя заниматься фичеризмом, нужно ориентироваться на цели пользователей и бизнеса, использовать метрики. Продуктовый подход - это уже норма.
Что это означает на практике? Во-первых, что команда не просто реализует фичи, а формулирует и проверяет гипотезы. Во-вторых, что успех работы измеряется не количеством задач в Jira, а изменением ключевых показателей. В-третьих, что решения принимаются на основе данных полученных из аналитики, исследований, экспериментов.
Такой подход принято назвать data-driven. Он выглядит красиво и строго:
Формулируем гипотезу.
Проверяем её с помощью A/B-теста или другого эксперимента.
Получаем данные.
Делаем выводы.
Повторяем.
Повторяемость, рациональность, научность. Круто же?
Но если продуктовый подход рассматривать не как лозунг, а как ежедневную практику, то мы сталкиваемся двумя трудностями.
Трудность первая: цикла на самом деле нет
Когда мы проверили гипотезу и, например, убедились, что перекрашивание кнопки из зеленого в красный привело к росту конверсии, становится непонятно, что делать дальше. Сделать кнопку круглой? Покрасить её в фиолетовый? В общем, откуда взять следующую гипотезу? Кажется, не хватает какого-то шага, чтобы завершить цикл.
Возможно, именно поэтому во многих вакансиях на позицию продакт-менеджеров часто упоминается умение придумывать гипотезы.
Самое простое, что вы можете сделать, - это использовать не статистические, а научные гипотезы. То есть вместо проверки вроде «Если кнопку сделать больше, то конверсия вырастет» использовать подход с причинно-следственной связью: «Если кнопку сделать больше, конверсия вырастет, потому что наши пользователи, например, имеют слабое зрение и им будет проще её заметить». После проверки такой гипотезы вы сможете двигаться дальше. Например, предположить, что дело было в не в зрении, а в том, что наша аудитория находятся в таком культурном контексте, что они плохо ориентируются в современных параллакс-интерфейсах, и вместо того чтобы увеличивать кнопку, нужно сделать её более знакомой и понятной.
Таким образом причинно-следственные связи позволяет соединять гипотезы в цепочки и подсказывают следующие шаги исследования. Но вот вопрос, откуда брать эти причинно-следственные связи? Пока оставлю его открытым - а тем временем расскажу о второй трудности.
Вторая трудность: проверить только одну гипотезу за раз невозможно
Вторая трудность заключается в том, что мы, строго говоря, никогда не можем проверить только одну гипотезу за раз. В любом эксперименте вы всегда проверяете сразу несколько гипотез:
Идея была правильной, решение - хорошим, но реализация решения содержала баг.
Идея была правильной, но решение ей не соответствовало.
Идея была неправильной.
Это минимальный набор гипотез, которые вы будет вынуждены проверять одновременно. В эпистемологии, кстати, эту проблему принято называть тезисом Дюэма — Куайна.
Приведу пример. Допустим у нас есть вот такая гипотеза: если добавить на страницу оформления заказа индикатор прогресса (например, «Шаг 1 из 3»), это повысит конверсию, потому что пользователи будут ощущать большую уверенность, понимая, на каком этапе процесса они находятся. Из -за чего это предположение может не оправдаться?
Вариант 1. индикатор прогресса мог бы помочь, но в его реализации был баг: показывал неправильные шаги, сбивался при обновлении страницы или что вроде того.
Вариант 2. Индикатор прогресса был добавлен, но его дизайн или формат подачи не соответствовал ожиданиям аудитории. Вместо привычного прогресс-бара, был использован перегруженный текст: «Вы завершили 1-й из трёх этапов». В таком случае идея была хорошей, но решение не очень.
Вариант 3. Изначальная идея была неверной А с чего мы вообще взяли, что удобный мастер приведёт к росту числа заказов?
Концептуализация
Всё то, что я только что описал словами, я изобразил на схеме. Перед вами - ключевые понятия этого кейса и их взаимосвязи. Платформа содержит страницу, страница позволяет заполнять поля, заполнение полей нужно для создания заказа, создание заказа должно происходить в соответствии с критерием «Удобно» для пользователя. Эту схему я рисовал не просто так, а чтобы понять, как увеличить конверсию, то есть сделать так, чтобы клиент создавал больше заказов. Но на схеме это шаг не включено в сеть связей с другими понятиями, он просто «висит в воздухе». Чтобы работать с этим понятием, его нужно как-то встроить в концептуальную схему. Ну например, так:
Наша целевая аудитория создает несколько заказов в месяц через платформу, но при этом пользуется и другими платформами. Выбор, где именно оформить заказ, пользователь делает, ориентируясь на размер комиссии. Чтобы обосновать это, я добавил к списку пользовательских критериев наряду с «удобством» ещё и «дешевизну».
Такую принципиальную схему, позволяющую системно описать гипотезы, связанные с продуктом, потребителем или рынком в зависимости от выбранного уровня абстракции можно было бы называть либо когнитивной моделью, как это делает Лакофф, либо деревом текущей реальности как это делает Голдратт. Есть аналогичные термины и у Куна, и у Щедровицкого. В рамках этой статьи я не будут вдаваться в детали и разбирать их отличия, а будут употреблять общий термин концептуализация для всех случаев. Поэтому на моей схеме нет цветовой дифференциации, нет стрелочек, я хочу показать принцип мышления, а не дать конкретный алгоритм.
Итак. Схема состоит из концептов. Связи между концептами в которых я уверен и не собираюсь перепроверять, я буду называть фактами. Связи, наличие которых или природу которых я только предполагаю - гипотезами.
Вернусь к целевому понятию «Создание повторного заказа». На самом деле, в идеале начинать построение схемы нужно было, конечно, с него, а не встраивать его постфактум. Вообще, это отдельная большая тема — откуда начинать строить концептуализацию. С точки зрения философии науки, любое исследование начинается не с гипотезы и даже не с концептуализации, а с выбора базовой метафоры, то есть с выбора перспективы, или «оптики исследования». С того, что Карл Поппер называл «нелогическим ядром логически выстроенной теории». Выбор метафоры предопределяет концепты, которыми вы будете оперировать. Это, в свою очередь, определяет гипотезы, которые вы сможете сформулировать. А те, в свою очередь, предопределяют выводы, к которым вы в итоге придёте в своём исследовании. И всё это происходит задолго до того, как исследователь начинает проводить глубинные интервью или аналитик изучает результаты A/B-теста.
Пример: конференция как продукт
Рассмотрим чуть более сложный пример. Так получилось, что я занимаюсь организацией конференций. Поэтому посмотрим на конференцию как на продукт.
В качестве базовой метафоры я выберу «конференцию как маркетплейс знаний». С одной стороны у нас производитель знаний, с другой потребители. У первых есть потребность получить социальное признание, у вторых получить профессиональный рост. Конференция - это платформа которая соединяет их и позволяет совершить сделку по передачи знания.
Но на конференции есть не только доклады, есть еще вечеринка. Проводя глубинные интервью, мы выясняем, что есть участники, которые вообще не слушают доклады, но с удовольствием ходят на вечеринки. Наша концептуальная модель этого не объясняет. То есть мы сталкиваемся с парадоксальной зависимостью, которую невозможно интерпретировать, исходя из концептуальной схемы, с которой мы стартовали. Но эта зависимость устойчива и воспроизводима. Значит, стоит задуматься, с чем она может быть связана и изменить схему. Решение достаточно простое - мы добавляем на схему новую потребность. Моя первоначальная метафора про маркетплейс знаний несколько искажается (на маркетплейсе как бы появился непрофильный «товар»), но пока я на это закрываю глаза.
Допустим в следующем сезоне мы снова проводим исследования и находим людей, которые индифферентны как к докладам, так и к вечеринке. Разбираемся почему — выясняется: их на конференцию отправил начальник, сами они билет не покупали, но на конференцию все равно пришли. Моя концептуализация снова не может объяснить подобное поведение и мне ее нужно менять. Чтобы объяснить это явление, мы вынуждены ввести в модель новый концепт — работодатель. В этот момент модель «маркетплейс» перестаёт быть актуальной, и ей на смену приходит новая метафора - например такая: «пионерлагерь для сотрудников как замена печенек и пуфиков, как способ обучать и/или мотивировать сотрудников». Концепт слушателей при этом становится менее важен и теперь слушатели по факту это часть транзакции между конференцией и работодателем.
На следующей конференции мы снова проводим исследование и замечаем, например, что вечеринка стала дороже и теперь не рентабельна. Задаемся вопросом «почему?» Потому что её организовывал бренд, который хотел рассказать о себе участникам конференции. То есть у вечеринки была функция коммуникации с участниками, а не просто развлечения. Чтобы объяснить это нам снова нужно обновить схему, вернув концепт «слушатель».
Эти рассуждения можно продолжать. Но главный вывод такой: Концептуальная схема не бывает правильной или неправильной — она бывает подходящей или неподходящей для описания тех наблюдений, цитат и метрик, которые у нас есть и которые важны для бизнеса. Выбор концептуализации — это «своеобразное надевание шор на глаза». Только надев шоры, вы можете что-то увидеть. Когда вы выбираете определённые концепты, вы должны отдавать себе отчёт в том, что с их помощью вы можете увидеть (подсветить), а что — нет. Увидеть всё невозможно. Невозможно построить схему, которая описывает всё.
Может показаться,что я говорю какие то банальности. Но каким бы здравым ни казалось концептуальное мышление, которое я пытаюсь продемонстрировать, оно строго говоря противоречит тому, к чему мы привыкли в обычной жизни. Традиционный подход, который преподают в школе и универе опирается на взаимно-однозначную логику: вот задача решить квадратное уравнение. Вот формула. Вот правильный ответ. Вот старые модели — их больше не используют. А вот новая модель — она правильная, научная, современная. И мы к ней переходим. Всё строго, линейно, последовательно.
И в этом подходе почти не остаётся места для сомнений в самих фреймах мышления. Мы редко останавливаемся и спрашиваем себя: а почему мы видим именно так? Почему нам это кажется логичным, очевидным, правильным? И вот это умение — поставить под вопрос не только выводы, но и сам способ видеть — как раз и начинается с концептуализации.
Сегментация
Проводя исследования и уточняя свою концептуальную схему, вы будете постепенно делать её всё более детальной.
С большой вероятностью в какой-то момент вас перестанет устраивать универсальный концепт «Пользователь».
Вы захотите заменить его на несколько более точных концептов, например: «Пользователь, который...»
На практике чаще всего встречаются три варианта или их комбинация:
«Пользователь, который...» — и далее следуют какие-либо демографические характеристики - пол, возраст, профессия и тд.
«Пользователь, который...» — и далее описывается характерный сценарий поведения пользователя при взаимодействии с продуктом.
«Пользователь, который...» — и далее идёт некая латентная характеристика, которая, как вы полагаете, предопределяет выбор целей и сценариев поведения. Это могут быть, например, ценностные установки (про шварцу, по рокичу), архетипы или другие глубинные конструкты.
Как вы уже поняли, я сейчас описываю сегментацию потребителей, которая по сути является частным случаем прикладной концептуализации.
Следующий шаг - операционализация
Итак, напомню. Мы закодировали исследуемый объект- потребителя, рынок или продукт с помощью сети концептов. Эта процедура, называемая концептуализацией. Но это только первых шаг: после того как мы создали идеальный тип, или, как говорит Макс Вебер, «создали недействительное, чтобы понять действительное», необходимо сделать следующий и перевести концепты в операнты, то есть в конкретные наблюдаемые индикаторы, которые позволяют нам собрать данные об объекте и затем сформулировать объясняющие высказывания о нём.
Ну например, мы выделили сегмент участников конференции, для которых профессиональный рост является ценностью и которые посещают все доклады. Но как понять, что человек, на которого мы смотрим, действительно относится к этому сегменту? Мы ведь не можем проводить с каждым участником глубинные интервью. Можно поступить так - будем учитывать количество просмотренных докладов, а также убедимся, что человек обязательно заходил на страницу расписания как минимум на несколько минут. На основе таких данных мы можем начинать строить агрегированные показатели: рассчитывать для этого сегмента ретеншн, отток, DAU, MAU, LTV и так далее.
На практике часто неосознанно пропускают шаги операционализации и концептуализации. Это происходит потому, что существует соблазн использовать «готовые» метрики, не пытаясь понять, какие концепты лежат в их основе. Если в своей работе вы используете статистические гипотезы, о которых я говорил в начале статьи, то подобные искажения для вас практически неизбежны.
Классический пример. Допустим, есть такая проблема: после нескольких взаимодействий с продуктом пользователи начинают «отваливаться». Когда это замечают, часто даже не пытаются выяснить причины, а просто сразу увеличивают частоту push-уведомлений, чтобы заставить пользователей вернуться. Формально таким образом желаемый результат достигается: график ретеншна выправляется. Однако при этом люди, раздражённые чрезмерным количеством уведомлений, просто удаляют приложение или отключают уведомления. На графиках ретеншна это уже не отображается, и реальная проблема по факту остаётся скрытой.
Когда метрики становятся самоцелью и фактически заменяют собой концепты, мы сталкиваемся с тем, что в экономике принято называть эффектом Гудхарда. Он формулируется так: «Когда мера становится целью, она перестаёт быть мерой». Это как если бы вы были недовольны скоростью, с которой едет автомобиль, и вручную передвинули стрелку спидометра на желаемое значение. Что произойдёт в этом случае? Во-первых, спидометр перестанет быть метрикой — он больше не показывает реальную скорость движения автомобиля. А во-вторых, вы продолжаете двигаться с той самой скоростью, которая вас не устраивает, хотя теперь и не знаете об этом.
Проблема неосознанной, механистической операционализации, как мне представляется, коренится в нежелании принять неопределённость этого мира. Действительно, проще смотреть на набор цифр, которые предлагает Google Analytics или Amplitude, получая иллюзию контроля, чем признать, что мы плохо понимаем, что из себя представляет наш продукт и кому он на самом деле нужен. Подобное наивное, естественно-научное мышление в нашей индустрии принято называть data-driven подходом. Его часто воспринимают как нечто объективное, лишённое субъективности и человеческих предвзятостей. В этом и заключается основное заблуждение: несмотря на видимую строгость чисел, любая метрика — это продукт человеческой интерпретации. Цифры не существуют в вакууме и не говорят сами за себя.
Забавная вещь. Мой личный опыт показывает, что отличная операционализация плохих продакт-менеджеров, т.е. таких которые не понимают смысл своей работы - это фраза типо «моя цель - растить такую-то метрику». После этой фразы этого идиота можно смело увольнять, он бесполезен.
Шаблоны моделей
Мы обсудили, к чему приводит неосознанная, механистическая операционализация — теперь перейдём к неосознанной концептуализации. Наше мышление устроено так, что даже если вы не будете явно рисовать схемы, не станете задаваться вопросами «какие здесь концепты?» и «в каких они отношениях?», — в голове всё равно сложится некая картина. Эта картина может быть построена на бытовом здравом смысле, на корпоративных штампах или на одной из универсальных моделей, заимствованных из популярных фреймворков.
Именно здесь начинается неосознанная концептуализация: вы вроде бы придумываете новые гипотезы, но на самом деле уже положили в основание своего мышления определённую структуру. А дальше — как снежный ком: под эту структуру начинают подгоняться вопросы, наблюдения, формулировки, метрики.
Вы могли где-то прочитать, что в основе любого цифрового продукта лежит пиратская воронка AARRR — и вот уже мысленно раскладываете поведение пользователя по этим пяти стадиям, даже если ваш продукт — это сервис по сопровождению сделок в недвижимости с длинным циклом. Или вспоминаете JTBD и начинаете придумывать «работы» пользователя, хотя большая часть пользовательских программ вашего продукта — это привычки и рутина.
Проблема не в самих моделях — они в целом рабочие и могут быть полезны. Проблема в том, что они подменяют собой исследование, когда применяются как универсальные рецепты без оглядки на контекст.
Поэтому важно не просто «не полениться придумать свою модель», а осознать, какую модель вы уже используете — пусть даже не в виде схемы, а на уровне интуиции, языка и гравитации мышления. И уже потом решить: подходит ли она вам или её нужно пересобрать под реальный контекст.
Собираем все вместе
В начале статьи я сказал, что мы добавим один шаг в цикл исследования, но не сказал, что из-за этого придется пересмотреть весь цикл.
Поэтому еще раз подведем итоги — как выглядит полный цикл.
Есть некоторый язык описания. Этот язык через определенные выборы мы трансформируем в прикладную концептуализацию — систему понятий, описывающих наш объект исследования ещё до контакта с ним. Затем каждому концепту мы присваиваем определённый индикатор — операнд. Этот операнд, как часть инструментария, попадает в поле исследования. Мы собираем данные. Получаем «гору» расшифровок глубинок, наблюдений, значений метрик. Между данными мы ищем связи, некоторые из которых наделяем объяснительной силой: X таков, потому что Y таков. Это и есть наши гипотезы. Гипотезы, которые проходят валидацию, мы называем фактами.
Если наложить эмпирические данные на нашу концептуальную схему не получается — мы её пересматриваем и заходим на следующий круг исследования.
По сути, исследование — это не просто способ проверять гипотезы и получать четкие ответы. Это — спираль, на каждом витке которой мы уточняем рамку, внутри которой формулируем свои вопросы. Мы начинаем с одного понимания ситуации, задаём вопросы, получаем ответы — и эти ответы меняют не только то, что мы знаем, но и то, как мы дальше смотрим на проблему.
Литература
Батыгин Г. С Методология по социологических исследований
Лакофф Д. Метафоры, которыми мы живём
Карл Вейк: Смыслопроизводство в организациях
Кун Д. Структура научных революций
Кучаров. Методы концептуального анализа и синтеза в теоретическом исследовании и проектировании социально-экономических систем.
Никаноров С.П Введение в концептуальное проектирование АСУ
Щедровицкий Г.П. О методе исследования мышления
Регулярно пишу в Telegram-канал Токсичный манагер про управление, продукты и исследования. Заходите.
