Алексей Ишманов
Technical Product Leader • AI workplace
AI продуктовый коммитет
Инструмент для разбора PRD, гипотез и стратегических решений — без совещаний и внутренней политики.
Оглавление
Зачем вообще это нужно
Представьте: вы дописали PRD на новую фичу. Документ выглядит убедительно. Внутри — сегмент, боль, решение, метрики. Вы отправляете его команде. Неделю спустя выясняется, что технический лид видит в архитектуре проблему, которую можно было поймать ещё на этапе спецификации. CFO задаёт вопрос по unit-экономике, на который у вас нет ответа. BDM говорит, что конкурент уже запустил похожее.
Ни один из этих вопросов не был злым умыслом. Просто у каждой роли — своя оптика. И когда все они сходятся в одном документе одновременно, это называется продуктовым комитетом. Проблема в том, что настоящий комитет требует времени, согласования расписания и определённого политического веса.
Создал для себя простую утилиту и отгрузил ее в OpenSource. Отправляешь ей PRD документ, он симулирует дебаты между AI-агентами с разными ролями — TPM, CPO, CFO, CTO, BDM. Результатом возвращает вам список замечаний, которые обычно всплывают на живом согласовании. Только быстрее, без эмоций и напряжения.
👉 Github репозиторий с кодом и инструкциями
Как это работает
Вы подаёте документ (PRD, гипотезу, стратегическое решение) и вопрос. Система запускает четыре параллельных дебатных комнаты (или больше от настроек зависит):
- PO vs CPO — продуктовая стратегия, рыночный fit, приоритизация
- PO vs CFO — бизнес-модель, unit-экономика, монетизация
- PO vs CTO — техническая реализуемость, архитектура, риски
- PO vs BDM — рыночный потенциал, конкуренты, go-to-market
Каждая комната — это структурированные дебаты в 4 этапа по 2 высказывания: opening, rebuttal, counter, final. Агент PO защищает документ, оппоненты атакуют его со своей перспективы. На выходе — final_report.md с полным дебатами и conclusion.md с вычленением ключевых мыслей.
«Главная цель была уйти от общий комментариев, а получить точные заключения и замечания где и что можно доработать. Изначально я просто ходил и сотню раз перекидывал сообщения между разными окнами DeepSeek, Claude, Perplexity и ChatGPT. В какой-то момент мне надоело и появился этот проект
Где это помогает в 5-дневном спринте
В контексте методологии 5 дней от гипотезы до рынка - помогает изначально отрезать бредовые идеи которые даже LLM считает нежизнеспособными. И не тратить время на то что не важно. Логические дыры и ошибки нужно ловить на старте, чтобы потом не платить за это деньгами разработки.
Быстрый старт: от установки до первого результата
Шаг 1. Установка
# Установить Poetry (если ещё нет)
curl -sSL https://install.python-poetry.org | python3 -
# Клонировать репозиторий
git clone https://github.com/kibarik/Deb8flow.git
cd Deb8flow
# Установить зависимости
poetry install
Шаг 2. Настройка модели
Отредактируйте config/debate_config.yaml. Минимальная конфигурация под OpenAI:
llm:
base_url: ""
model: "gpt-4o-mini"
api_key: "" # или через переменную окружения OPENAI_API_KEY
temperature: 0.8
В качестве провайдера я использую https://requesty.ai/ - у них токены дешевле и кэш лучше чем у OpenRouter.
Шаг 3. Подготовьте документ
Сохраните ваш PRD, гипотезу или спецификацию как .docxфайл. Например:my_prd.txt`.
Шаг 4. Запустите комитет
poetry run python main.py committee \
--prd path/to/my/prd.txt \
--question "Достаточно ли проработан этот PRD, чтобы служить основой для квартального планирования?"
Ждете когда сервис отработает, занимает 5-10 минут примерно.
Шаг 5. Читайте результат
Результаты сохраняются в committee_output/RUN_YYYYMMDD_HHMMSS/:
final_report.md— полные диалоги по каждой дебатной комнатеconclusion.md— исполнительное резюме с ключевыми замечаниями
Если хотите перегенерировать только вывод без повторного запуска:
poetry run python main.py conclusion --run-dir ./committee_output/RUN_20260218_234755
Как формулировать вопрос: это важно
Качество вопроса напрямую определяет качество дебатов. Плохой вопрос — агенты будут говорить ни о чём.
Рабочая формула:
«Является ли [документ] достаточно [критерии: конкретным / полным / реализуемым], чтобы служить [роль документа], с минимальной необходимостью пересматривать ключевые решения?»
| ❌ Плохо | ✅ Хорошо |
|---|---|
| «Что думаете об этом PRD?» | «Достаточно ли PRD технически детализирован для инженерной имплементации?» |
| «Хороший ли документ?» | «Содержит ли документ достаточно данных для приоритизации в Q1–Q2?» |
| «Сработает ли это?» | «Есть ли у проекта защищаемое конкурентное преимущество, оправдывающее инвестиции?» |
| «Стоит ли это строить?» | «Подтверждает ли гипотеза реальную боль платящего сегмента?» |
Вопрос должен быть сформулирован так, чтобы на него можно было честно ответить «да» или «нет». Если вы не можете представить, что означает «нет» — вопрос слишком размытый.
Кастомизация агентов
По умолчанию роли — TPM, CPO, CFO, CTO, BDM. Но вы можете настроить любой состав под свою задачу. Например, для review продуктовой гипотезы с упором на клиентский опыт:
agents:
main:
name: "PRODUCT_OWNER"
prompt: "config/prompts/roles/tpm.txt"
opponents:
- name: "UX_RESEARCHER"
prompt: "config/prompts/roles/ux_researcher.txt"
- name: "CUSTOMER_SUCCESS"
prompt: "config/prompts/roles/customer_success.txt"
Промпты для ролей хранятся в src/prompts/roles/ и редактируются как обычные текстовые файлы — никакого кода менять не нужно.
Чего ожидать от результата
Deb8flow не скажет вам, стоит ли запускать продукт. Это не его задача. Он выдаёт список вопросов и замечаний, которые команда с разными ролями задала бы на живом совещании.
Типичный вывод после прогона PRD:
- CFO находит незакрытые вопросы по unit-экономике или monetization path
- CTO ставит под сомнение техническую реализуемость за заявленный срок
- BDM задаёт вопросы про конкурентный ландшафт, которые в документе не упомянуты
- CPO проверяет, насколько решение бьёт в реальную боль сегмента
Команды, которые регулярно пропускают документы через подобный синтетический review, обнаруживают, что на живых согласованиях остаётся значительно меньше «сюрпризов» — основные возражения уже проработаны.
Это не замена реальному продуктовому комитету. Это способ прийти на него подготовленным.
Что дальше
Репозиторий: github.com/kibarik/Deb8flow
Deb8flow — open source, MIT license. Вы можете адаптировать роли агентов под свой контекст, добавить роли, специфичные для вашей индустрии, и встроить инструмент в любой рабочий процесс ревью документов. В своих командах использую для любого документа который влияет на разработку (PRD, БФТ, СТ, ADR, Планирование квартала и тд)
Один практический вопрос напоследок: какой документ или решение из вашего текущего бэклога вы бы хотели прогнать через такой комитет прямо сейчас — и какой вопрос бы задали?