product-manager

개요

product-manager 에이전트가 책임지는 질문은 하나입니다. 무엇을 만들 것인가. 구현이 시작되기 전에 요구사항을 또렷이 다듬고, 경쟁하는 우선순위를 저울질하고, 작업의 스코프를 확정하는 일을 맡습니다. 이렇게 잡아 둔 제품 관점의 맥락이 없으면, 개발 에이전트들은 자신만만하게 엉뚱한 방향으로 달려 나갑니다.

언제 쓰는가

• 요구사항이 흐릿해서 범위를 먼저 잡아야 할 때
• 기능 우선순위를 두고 트레이드오프를 논의해야 할 때
• $deep-interview나 $ralplan 전에 제품 맥락을 정리해야 할 때
• 여러 이해관계자의 요구를 하나의 실행 가능한 스코프로 정리해야 할 때

사용 예시

"이 기능 목록에서 MVP 스코프를 정해줘"
"인증 시스템 변경의 제품 요구사항을 정리해줘"
"현재 로드맵에서 어떤 걸 먼저 해야 하는지 판단해줘"

작업 범위

작업 프로세스

1. 현재 상황과 목표를 파악합니다.
2. 요구사항의 모호한 부분을 질문으로 좁힙니다.
3. 실행 가능한 스코프와 수락 기준을 정리합니다.
4. 우선순위 근거를 명시하고 analyst나 planner에 넘깁니다.

입력

• 사용자가 제시한 기능 아이디어나 비즈니스 목표
• 기존 로드맵, 스펙 문서, 이슈 목록
• 이해관계자의 요구나 제약 조건

출력

• 범위가 확정된 요구사항 문서
• 수락 기준이 포함된 기능 정의
• 우선순위 근거가 달린 로드맵

제한 사항

• 실제 구현은 executor가 담당합니다.
• 기술 아키텍처 결정은 architect에 맡깁니다.
• 요구사항 분석의 세부 수락 기준 도출은 analyst와 함께 진행합니다.

관련 에이전트

• analyst — product-manager가 정리한 요구사항을 수락 기준으로 구체화합니다.
• planner — 확정된 스코프를 기반으로 실행 순서를 계획합니다.
• architect — 제품 요구사항을 기술 설계로 옮깁니다.