PM 프롬프트 20개, 트레이드오프를 그대로 보여줍니다

01. 정리 안 된 브리프로 PRD를 쓰고 열린 질문 뽑기

슬랙 스레드와 통화 메모와 마감일은 있는데 스펙이 없을 때.

이 정리 안 된 브리프를 제품 요구사항 문서(PRD)로 바꿔줘.

[브리프, 스레드, 통화 메모 등 가진 것을 붙여넣기]

섹션은 이 순서로: 문제와 그 문제를 겪는 사람, 그 문제에 대해 우리가 가진 근거, 측정 가능한 결과가 있는 목표, 범위에 포함되는 것, 범위에서 제외되는 것, 번호를 붙인 사용자 흐름, MUST 또는 SHOULD로 표시한 요구사항, 다른 팀과의 의존성.

브리프에 적힌 내용만 써줘. 브리프에 없는 부분은 지어내지 말고 그 자리에 [OPEN: 질문]이라고 적어줘.

마지막에 열린 질문을 전부 모아서 답할 수 있는 사람별로(나, 디자인, 개발, 법무, 고객) 묶어주고, 개발을 막는 질문 세 개를 맨 위에 둬줘.

02. 기능을 인수 조건이 있는 사용자 스토리로 쪼개기

리파인먼트가 내일인데 기능이 아직 큰 티켓 하나일 때.

이 기능을 팀이 하나씩 만들어서 출시할 수 있는 사용자 스토리로 쪼개줘.

기능: [기능이 하는 일]
사용자: [누가 쓰고 무엇을 하려는지]
제약: [플랫폼, 마감일, 이미 만든 것]

각 스토리마다:
1. [사용자]로서, 나는 [행동]을 하고 싶다, 그래서 [결과]를 얻을 수 있다.
2. Given / When / Then 형식의 인수 조건을 스토리당 세 개에서 여섯 개, 각각 쓰지 않은 사람도 테스트할 수 있게.
3. S, M, L 중 규모 추정과 그 추정을 불확실하게 만드는 한 가지.

첫 번째 스토리는 작더라도 실제 사용자가 쓸 수 있는 것을 내놓도록 순서를 정해줘. 사실은 스토리 두 개인 스토리와, 다른 스토리가 출시된 뒤에야 의미가 있는 스토리에는 표시해줘.

03. PRD가 놓친 엣지 케이스 찾기

스펙이 끝난 것 같고 개발이 다음 주에 시작될 때.

이 PRD를 출시 후에 버그 리포트를 받게 될 개발자의 입장에서 읽어줘.

[PRD 또는 스펙 붙여넣기]

스펙이 다루지 않은 엣지 케이스를 다음 항목별로 묶어서 나열해줘: 빈 상태와 첫 사용 상태, 오류와 타임아웃, 권한과 역할, 한계(아주 긴 값, 아주 많은 수, 0, 중복), 동시성(두 사람이 동시에 편집, 더블 클릭, 재시도), 이 기능이 생기기 전의 데이터, 접근성.

각 항목마다: 시나리오를 한 줄로, 지금 스펙대로라면 어떻게 될 것 같은지, 내가 답해야 할 질문. 첫 한 달 안에 실제 사용자가 부딪힐 가능성이 높은 순서로 상위 다섯 개를 골라줘. 요구사항을 지어내지 말고 물어봐줘.

나머지 프롬프트 17개를 무료로 열어보세요

Whizi 뉴스레터를 구독하면 이 팩의 나머지 프롬프트를 볼 수 있어요.

4. RICE로 백로그 점수를 매기고 계산 과정 보여주기
5. 인터뷰 메모를 해야 할 일, 불편, 인용문으로 정리하기
6. 사람들이 원하는 것이 아니라 한 일을 묻는 디스커버리 인터뷰 가이드 쓰기
7. 지원 티켓을 고칠 가치가 있는 제품 문제로 묶기
8. 개발자가 바로 만들 수 있는 한 페이지 스펙 쓰기
9. 성공 지표와 그 지표를 정직하게 지켜주는 카운터 지표 고르기
10. 실험을 설계하되 표본 크기 문제부터 답하기
11. 팀마다 담당자가 있는 출시 체크리스트 만들기
12. 사용자가 실제로 읽는 릴리스 노트 쓰기
13. 바뀐 점부터 말하는 이해관계자 업데이트 쓰기
14. 하지 않을 일까지 말하는 로드맵 내러티브 쓰기
15. 이유와 다음 단계를 담아 기능 요청 거절하기
16. 출시 전에 프리모템 돌리기
17. 경쟁사 제품 페이지의 주장을 하나씩 해부하기
18. 긴 티켓 목록에서 스프린트 목표 하나 쓰기
19. 요청받은 해결책을 그 뒤의 문제로 되돌리기
20. 다른 모델에게 첫 번째 모델이 쓴 PRD 검토시키기