Привет, меня зовут Мария Табачок
18 лет я работаю на стыке бизнеса, ИТ и продуктовой стратегии — проектирую информационные системы и управляю кросс-функциональными командами в самых требовательных к данным доменах:
- финтех
- кибербезопасность
- G2C / G2B экосистемы
- AI / LLM
Среди проектов: Госуслуги, Сбер, Московская биржа, ведомственные системы антитеррора, Альфа, Group-IB, Solar и др.
Я не только про корпорации.
Последние 5 лет я владею и управляю собственным производством (гранитной мастерской) — за год перестроила её от ручного микроменеджмента до автономной, устойчивой системы.
А ещё основала парусную команду Why Not Sailing Team, с которой мы прошли не один кризис — как и любая команда в любом деле.
Зачем этот канал? Здесь я пишу про то, что стоит за сильными продуктами и решениями: — мышление и когнитивные ловушки, которые мешают создавать и управлять продуктами — исследования и работа с неопределённостью — стратегическое планирование и коммуникация на разных уровнях — от команды до стейкхолдеров
Здесь не будет «5 простых шагов к успешному продукту». Будет сложная информация, неудобные вопросы и нагрузка на мышление. Потому что стратегическое видение не покупается лайфхаками — оно выращивается. Готовы думать — оставайтесь.

Про границы

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

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

Личности, не уважающие меня и мое время, а так же тех, кто будет вести обсуждения в этом канале - будут получать бан без предупреждения.

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

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

Data-driven сводится к: «Мы смотрим на дашборд — значит, принимаем решения на данных». Методологии становятся фетишем.

Конечно, методологии и метрики важны.

НО

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

Методология — это карта, а не территория. Ни одна идеальная CJM не отражает путь реального человека со всеми его страхами, ленью, ограничениями и поеданием колбасы в 3 ночи в темноте у холодильника.

Данные всегда неполные и контекстные. Они встроены в процессы, организационные костыли, внутреннюю политику, регуляторику.

Именно здесь начинаются исследования не как профессия, а как способ мышления:

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

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

Параллельные вселенные живут не в книгах — они в наших данных.

Тёмная сторона исследований. Часть 2: как умные люди создают замкнутые циклы защиты
(цикл: власть · идентичность · организационная прокрастинация)

В первой части цикла я говорила о власти в исследованиях: кто задаёт вопросы, что вообще признаётся «проблемой» и как решения о запуске или отмене ресёрча сами являются актами власти.
https://t.me/thought404/9

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

Блок про идентичность — индивидуальную и командную — будет самым большим в этом цикле. Я ещё подробно вернусь к тому, как самообраз команды («мы умные», «мы customer‑driven», «мы сильные», «мы ошибаться не можем») формирует слепые зоны, как стыд и страх унижения задают границы допустимых данных, и почему без понимания связи между когнитивным стилем и идентичностью невозможно построить устойчивую культуру работы с данными. Этот пост — преамбула к этому блоку.

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

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

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

В следующих постах я буду разбирать по одному конкретному искажению, связанному с идентичностью: от нарративов «мы customer‑driven» и «мы уже всё знаем» до образа «умной команды», запрета на признание незнания и феноменов groupthink и in‑group bias в исследованиях. В финале этого блока будет небольшой тест: можно будет посмотреть, с какими искажениями вы чаще всего сталкивались — или просто проверить, насколько ваша психика допустила и запомнила информацию, слегка подрывающую базовую безопасность вашей идентичности 😁

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

Тёмная сторона исследований. Зачем знать нарративы команд.

(цикл: власть · идентичность · организационная прокрастинация)

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

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

Компании стратегически конструируют свой образ через нарративы: «мы инновационные», «мы customer‑centric», «мы быстро учимся». Эти нарративы становятся реальными регуляторами поведения, формируя ожидания и внутренние табу. Когда команда многократно проговаривает, что она «очень customer‑driven», это постепенно превращается в компонент её коллективной идентичности: сомнения в степени customer‑centricity начинают восприниматься не как технический вопрос, а как покушение на «кто мы есть».

Customer‑centricity давно стала одним из центральных лозунгов продуктового и CX‑мира. Почти каждая компания стремится отнести себя к этой категории, а продуктовые команды декларируют нарратив «мы customer‑driven». При этом даже при наличии исследований и опросов компании часто продолжают строить решения из того, что видно в «зеркалах» — внутренней перспективе, а не из полноценного понимания того, как живут и решают задачи их клиенты. Внешне организация выглядит customer‑centric, но фактически остаётся продукт‑ или sales‑центричной: обсуждает рынки, фичи и revenue, а не реальные контексты и боли пользователей.

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

На практике это выглядит так: стратегические решения рождаются внутри, а пользователь используется как источник подтверждения, а не как партнёр в определении проблемы. Публично и внутри команда может бесконечно обсуждать «user pains», проводить UX‑воркшопы, рисовать journey, но при этом системно игнорировать те зоны, которые не вписываются в текущий roadmap или бросают вызов полюбившейся стратегии.

Идентичность «мы customer‑driven» становится экраном, скрывающим от самой команды её слепые зоны. Признать, что мы чего‑то не видим в опыте пользователя, значит допустить, что наша картинка «мы заботливые и правильные» не полностью совпадает с реальностью. А это уже не только про данные, это про боль и стыд. Поэтому чем громче команда повторяет «мы и так очень customer‑driven», тем сложнее ей увидеть, что есть целые пласты пользовательского опыта, о которых она не знает или которые сама системно отодвигает.

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

Настроение: душнить
(и разобрать пост в одном из продуктовых каналов)

Сама мысль в посте верная: стратегию нельзя писать на год и потом делать вид, что рынок обязан под неё подстроиться. Но здесь есть важная оговорка: частота пересмотра метрик зависит не от общей любви к “data-driven”, а от типа продукта, стадии его развития и длины ценностного цикла.

Месячный пересмотр метрик — это хороший инструмент для продуктов с коротким циклом ценности, но в сложных B2B-доменах он легко приводит к ложным управленческим выводам.

Если продукт имеет длинный time-to-value и внедряется итерационно, отсутствие роста метрик в первый месяц не означает, что стратегия неверная. Это может означать только одно: функция ещё не дошла до стадии, на которой её ценность вообще может проявиться.

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

Именно здесь важна работа с ожиданиями стейкхолдеров. Если от сложной функциональности ждут немедленного эффекта, это не “строгость к цифрам”, а методологическая ошибка. В итоге команда начинает оптимизировать не продукт, а ожидания в дашборде: резать развитие, дробить roadmap на микрофичи и убивать потенциал до того, как он успеет раскрыться. В сложном B2B это почти всегда стратегия локальной оптимизации, а не развития.

Корректнее мыслить горизонтами:

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

Метрики важны, но они должны помогать управлять стратегией, а не подменять её.

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

За окном rain, на душе pain

Мы много говорим — и я в том числе — о важности исследований, о необходимости слышать боль потенциальных клиентов. Тратим огромные бюджеты, недели и месяцы на исследования, формируем портреты аудитории, CJM и прочие артефакты. А потом теряем клиентов и не понимаем почему. Сюрприз-сюрприз.

Вопрос на миллион: кто отслеживает как взаимодействует клиент не с продуктом, а с людьми по другую сторону продукта?

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

Обращаюсь в поддержку, описываю ситуацию, прикладываю часть скринов.
«У нас нет сведений о технических проблемах».
Намекаю: вот они, сведения, прямо сейчас перед вами — проблема есть
«Пришлите скрины каждого шага, сетевые логи и har-файл».

Сдержав всё, что я думаю по поводу этого прекрасного предложения, отвечаю, что в мои планы не входит выполнять работу продуктовой команды. (Умолчим здесь о том, что я желая поработать с резюме или вакансией, почему-то должна знать, что такое сетевые логи и har-файл?)

Спустя пару минут мне с достоинством сообщают (цитата): сожалеем, что у вас возникло недопонимание в работе нашей платформы. Если вы передумаете, необходимо будет предоставить весь перечисленный список артефактов, чтобы мы могли помочь вам с решением ВАШЕЙ проблемы.

Мне очень хотелось найти контакты директора по развитию или CPO этого продукта и просто показать им переписку. Но поддержка отвечает по скриптам, которые согласовала команда. Та самая команда, которая проводила кастдевы и рисовала CJM.

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

Команда сначала рисует сценарии, а потом говорит клиенту: у НАС проблемы нет. Но так и быть рассмотрим возможность решить вашу проблему( если я достаточно убедительно докажу её существование и ещё предоставлю всю техническую фактуру, чтобы команде тестирования не пришлось напрягаться с воспроизведением.)

Месяц-два назад я выступала на конференции, организованной SELECTEL и сообществом «Немного продакт» на тему «Почему продукты управляются правильно, а денег нет».

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