За годы работы в разнообразных командах я много раз видел одну и ту же ситуацию.

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

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

Одна команда знает, почему была изменена логика онбординга. Другая помнит, какие ограничения есть у биллинга. Третья когда-то проводила исследование, из которого следовало, что пользователи вообще не понимают текущую модель прав доступа. Где-то это лежит в презентации. Где-то в Notion. Где-то в Confluence. Где-то в почте. Чаще всего — в голове конкретного человека.

Пока этот человек рядом, система вроде бы работает. Можно написать ему в Slack, позвать на встречу, спросить: «А почему мы тогда сделали именно так?» Он вспомнит, расскажет, иногда даже найдёт старую ссылку. Но стоит человеку уйти, сменить роль или просто перестать быть доступным, как часть продуктовой памяти исчезает вместе с ним.

И это не исключение. Это нормальное состояние большинства организаций.

Однажды в большой корпорации у нас сменился Product Owner. На первой встрече с новым PO я спросил, что ему передал предыдущий. Ответ был примерно такой: «Мы встретились, он рассказал мне, что к чему».

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

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

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

Проблема не в том, что команды не документируют

Можно возразить: «Ну так надо лучше писать документацию».

И это правда. Документация нужна. Хорошие PRD, research reports, decision records, архитектурные заметки — всё это действительно важно. Но проблема глубже.

Даже если команда честно документирует всё важное, возникает следующий слой сложности: это всё нужно читать, сопоставлять и удерживать в голове.

Документ сам по себе не создаёт понимания. Он просто фиксирует фрагмент знания.

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

И вот здесь большинство инструментов ломается.

Confluence, Notion, Google Docs, Jira, Linear — все они могут хранить куски информации. Но они редко помогают понять, как эти куски связаны между собой. Исследование существует отдельно. Решение отдельно. Требование отдельно. Задача отдельно. Метрика отдельно.

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

Память есть. Но она не работает как память.

Она работает как архив.

А архив не равно “понимание”.

Почему атомарные команды усиливают эту проблему

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

Но автономия без общей структуры знаний быстро превращается в локальную оптимизацию.

Каждая команда начинает строить свою маленькую картину мира. У неё свои документы, свои решения, свои пользовательские интервью, свои приоритеты. Со временем эти картины мира расходятся. Где-то меняется понимание пользователя. Где-то по-другому интерпретируется стратегия. Где-то старое ограничение продолжает жить просто потому, что никто не знает, что оно уже не актуально.

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

Так продукт постепенно превращается в архипелаг.

Снаружи всё выглядит управляемо: есть roadmap, есть квартальные цели, есть доски, статусы. Но внутри общая «память» продукта распадается на десятки локальных контекстов.

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

Скорость разработки падает не потому, что люди плохо работают. 

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

Мы недооцениваем «мета-работу»

В продуктовой разработке есть работа, которую «видно»: написать код, нарисовать дизайн, провести исследование, поставить задачу, выкатить фичу.

А есть работа, которую почти не видно, но без неё всё остальное со временем начинает буксовать.

Я называю её «мета-работой». 

Это не «ещё одна встреча» и не «документация ради документации». Это работа по превращению разрозненных событий в связное знание продукта.

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

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

Но как системная практика это почти нигде не работает.

И вот здесь появляется интересный вопрос: если AI-агенты действительно становятся частью рабочих процессов, почему мы сразу пытаемся отдать им основную работу? Почему первый инстинкт — «пусть агент пишет код», «пусть агент делает дизайн», «пусть агент закрывает тикеты»?

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

AI не исправляет «отсутствие памяти». Он его ускоряет

Сейчас многие пытаются полностью отдать агентам часть своей работы. Это понятно: модели стали сильнее, инструменты удобнее, интеграции глубже. Агент может прочитать задачу, открыть репозиторий, написать код, создать PR, обновить тикет.

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

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

И здесь появляется опасный эффект.

Человек тоже может повторить старую ошибку. Но человек делает это относительно медленно: через встречи, обсуждения, сомнения, уточнения. Агент делает то же самое быстрее. Он может за минуты произвести результат, который выглядит убедительно, но основан на неполном или неправильном контексте.

То есть AI не обязательно снижает хаос. Иногда он просто увеличивает его пропускную способность.

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

От «переписки с документацией» к потоковому управлению знанием

Сейчас набирает популярность идея LLM Wiki или LLM Knowledge Base: складываем документы, заметки, исследования, переписки, а потом общаемся с этой базой через LLM. Это уже большой шаг вперёд. Вместо того чтобы искать нужную страницу руками, можно спросить систему: «Почему мы приняли это решение?» или «Что мы знаем про этот сегмент пользователей?».

Но мне кажется, что этого недостаточно.

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

Более сильная идея — не просто отвечать на вопросы по базе знаний, а постоянно извлекать из рабочего потока продуктовые сущности: инсайты, решения, требования, ограничения, действия, противоречия, открытые вопросы. Не ждать, пока человек аккуратно оформит документ, а помогать превращать рабочий поток в структуру.

То есть уходить от классического управления, где главным объектом является задача на kanban-доске, к более живому управлению, где команда видит не только «что нужно сделать», но и откуда это пришло, на чём основано, с чем связано и куда ведёт.

Задачи при этом никуда не исчезают. Но они перестают быть центром вселенной.

Центром становится поток знаний.

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

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

Product Graph как попытка описать этот фундамент

Именно в таком контексте я думаю про Product Graph.

Не как про ещё один таск-трекер. И не как про «замену Jira». Скорее как про методологию, в которой структура знаний важнее структуры процесса.

Главная идея Product Graph в том, что методология — это не набор церемоний, не cadence, не спринты и не story points. Методология — это то, как команда структурирует знание о продукте: как решения связаны с доказательствами, как требования связаны с инсайтами, как реализация связана с исходной причиной, как результаты возвращаются обратно в систему. В манифесте Product Graph это сформулировано прямо: knowledge structure is the methodology — структура знаний и есть методология.  

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

Это важно не только для людей, но и для агентов.

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

Вот здесь AI становится не заменой команды, а её усилителем.

Что меняется, если смотреть на продукт под другим углом

В обычной модели команда управляет задачами. Есть backlog, доска, статусы, приоритеты. Это удобно для контроля исполнения, но плохо отвечает на вопрос «почему мы вообще это делаем?».

В модели Product Graph задача — только один из объектов. Причём не самый главный. Важнее то, что стоит до неё и после неё.

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

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

Когда эта цепочка сохраняется, продукт начинает учиться.

Не отдельные люди. Не отдельные команды. Сам продукт как система.

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

Что такое Product Graph в сухом остатке

Если коротко, Product Graph — это попытка описать продуктовую разработку не через процесс, а через структуру знаний.

Обычно мы смотрим на работу команды через задачи: что в backlog, что в работе, что заблокировано, что уехало в релиз. Это полезный слой, но он не отвечает на главный вопрос: почему эта работа вообще существует?

Product Graph предлагает смотреть глубже. Не только на задачи, а на связи между тем, что команда знает, что она решила и что она делает.

В такой системе важны не отдельные документы и не отдельные тикеты, а цепочка:
источник → инсайт → решение → требование → реализация → результат

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

Главное — эта цепочка не должна исчезать.

Если через полгода человек открывает задачу, он должен видеть не только описание работы, но и путь назад: откуда она пришла, на какие данные опиралась, какие альтернативы рассматривались, почему выбрали именно это решение и что получилось после запуска.

Тогда продуктовая память перестаёт быть набором заметок. Она становится живой системой.

Принципы Product Graph

Видение и стратегия должны быть связаны с работой.

Видение не должно жить только в голове CEO, в quarterly deck или в красивом документе, который все однажды прочитали и забыли. Если стратегия действительно важна, от конкретной задачи должен быть виден путь наверх: к стратегической ставке, продуктовому направлению или большому решению, ради которого эта работа существует.

У каждой задачи должна быть причина.

Если команда не может объяснить, почему задача существует, это не обязательно значит, что задача плохая. Но это значит, что перед нами допущение. Его нужно либо подтвердить, либо честно пометить как гипотезу, а не выдавать за очевидную необходимость.

Решения должны быть отдельными объектами.

Решение — это не строчка в Slack и не воспоминание человека, который «тогда был на встрече». У решения должен быть контекст: какой вопрос обсуждали, какие варианты рассматривали, почему выбрали именно этот, на какие данные опирались и при каких условиях это решение стоит пересмотреть.

Знание должно накапливаться.

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

Противоречия должны становиться видимыми.

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

Контекст должен возникать как побочный продукт работы.

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

Именно это я называю мета-работой.

Не бюрократией. Не дополнительной нагрузкой. А слоем, который делает продуктовую работу осмысленной и накопительной.

Какая роль здесь у AI

AI-агенты могут быть очень полезны в мета-работе.

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

Тогда агент перестаёт быть просто быстрым исполнителем задач.
Он становится участником продуктовой памяти.

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

Product Graph для меня — способ описать именно этот фундамент.

Не как замену Agile, Shape Up, Kanban или другим подходам. Их можно продолжать использовать. Но под ними нужен слой, который отвечает не за ритм работы, а за накопление знания: что мы узнали, что решили, почему решили, что сделали и чему научились после этого.

Пока такого слоя нет, AI будет ускорять не только продуктивность, но и организационную амнезию.

А если такой слой появляется, AI наконец начинает работать не поверх хаоса, а поверх памяти.