一键在 Manus 中运行任何 Skill

working-backwards

星标53

分支17

更新时间2026年6月2日 14:01

제품을 출시 시점의 보도자료(PR)와 FAQ 로 먼저 써서, 만들기 전에 고객 가치와 위험을 검증한다. PR 은 과장 없는 고객 언어로, FAQ 는 가장 불편한 질문부터 정직하게 답한다. 출처는 Amazon 의 Working Backwards / PR-FAQ.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

kimsanguine

kimsanguine/AI_PM

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Skill — Working Backwards (PR-FAQ)

Task

아직 만들지 않은 제품/기능에 대해, 출시일 기준의 가상 보도자료(Press Release) + FAQ 를 작성한다. 목적은 마케팅 문구가 아니라 만들 가치가 있는지 사전 검증 이다.

Scope

PR-FAQ 작성과 자체 비평까지. 실제 구현·일정 확정·예산 승인은 별도 단계.
입력은 기능 아이디어 + 타깃 고객 + 알려진 근거(인터뷰/데이터). 근거 없으면 가정으로 명시.
PR 은 1페이지를 넘기지 않는다 — 길어지면 가치가 한 문장으로 안 잡혔다는 신호.
수치·인용은 실제 근거가 있을 때만. 없으면 [가정] 태그.

Length

PR 본문 ≤ 400자(헤드라인·서브헤드 제외). FAQ 외부용 3–5개 + 내부용 3–5개.
전체 1,500–3,000자.

Format

## Press Release — 헤드라인 / 한 줄 서브헤드 / 문제 단락 / 해결 단락 / 가상 고객 인용 1개 / "시작하는 법" 한 줄.
## FAQ — 고객용 — 고객이 실제로 물을 질문 (가격, 기존 도구 대비, 데이터 안전 등).
## FAQ — 내부용 — 가장 답하기 싫은 질문부터 (왜 우리가, 왜 지금, 실패 조건, 안 만들면 무슨 일).
## 검증 신호 — 이 PR-FAQ 가 통과/기각될 기준(이 가정이 틀리면 만들지 않는다).
## 한계 — [가정] 으로 채운 부분, 근거 부족 항목, 추가 확인 필요.

룰

출처 명시: Working Backwards / PR-FAQ 는 Amazon 의 제품 기획 관행이다. "고객으로부터 거꾸로 일한다(start from the customer and work backwards)" 원칙을 인용할 때 출처를 적는다.
PR 은 고객 언어 로. "혁신적", "업계 최고", "seamless" 같은 마케팅 형용사 금지 — 구체적 진전으로 대체.
가상 고객 인용은 그 고객이 실제로 할 법한 문장으로. 칭찬이 아니라 "무엇이 달라졌는지" 를 말하게 한다.
내부 FAQ 는 반대 의견을 먼저 적는다. 통과를 전제하지 않는다.
근거 없는 수치("3배 빨라짐")는 [가정] 표기. 검증 전 사실로 쓰지 않는다.
PR 한 문장으로 가치가 안 잡히면, 만들 가치가 불명확하다는 결론을 숨기지 않고 적는다.

의존

입력 우선순위: 사용자가 제시한 기능 아이디어 + samples/ 근거
참고 챕터: 4.1-discovery-user-research.md

예시

좋은 출력: good-examples/prfaq-team-digest.md
나쁜 출력: bad-examples/marketing-fluff-pr.md

同仓库更多 Skills

同仓库

jtbd

kimsanguine/AI_PM

인터뷰·기능 요청을 "사람들이 해결하려는 job(과업)" 으로 재구성한다. 기능·솔루션 언어를 상황(when)·동기(want)·기대 결과(so I can) 의 job statement 로 환원하고, 근거 없는 job 은 가설로만 표기한다. 출처는 Clayton Christensen / Anthony Ulwick.

2026-06-0253

opportunity-solution-tree

kimsanguine/AI_PM

하나의 outcome 에서 출발해 opportunity → solution → experiment 로 내려가는 트리를 만든다. opportunity 는 발견된 사용자 니즈/페인(솔루션 아님)으로만 적고, solution 은 opportunity 에 매달리며, 각 solution 은 검증 실험으로 닫는다. 출처는 Teresa Torres (Continuous Discovery Habits).

2026-06-0253

competitor-battlecard

kimsanguine/AI_PM

경쟁사 3–5곳을 동일 축으로 비교한 표 + 배틀카드를 생성한다. 정량/공개 자료만 근거로 사용하고, 추측이나 미확인 정보는 한계 절에 분리한다.

2026-06-0253

discovery-synthesizer

kimsanguine/AI_PM

인터뷰 트랜스크립트·설문·사용 로그를 받아 PM 이 의사결정할 수 있는 인사이트 표로 합성한다. 빈도가 낮은 신호는 "약한 신호" 로만 표기하고 인사이트로 승격하지 않는다.

2026-06-0253

experiment-analyzer

kimsanguine/AI_PM

A/B 테스트·실험 결과 CSV/표를 받아 PM 보고용 결과 절 + ship/iterate/kill 권고를 출력한다. 가드레일 위반·표본 편향·novelty 효과를 항상 점검한다.

2026-06-0253

kpi-card-builder

kimsanguine/AI_PM

KPI 1개에 대한 정의 카드(이름·계산식·source·반응 임계치·소유자·반反사례) 를 생성한다. 한 카드 = 한 KPI 룰을 강제하고 KPI 가 측정 불가하면 정의를 거부한다.

2026-06-0253

name	working-backwards
description	제품을 출시 시점의 보도자료(PR)와 FAQ 로 먼저 써서, 만들기 전에 고객 가치와 위험을 검증한다. PR 은 과장 없는 고객 언어로, FAQ 는 가장 불편한 질문부터 정직하게 답한다. 출처는 Amazon 의 Working Backwards / PR-FAQ.
trigger	"working backwards", "PR-FAQ", "보도자료 먼저", "역방향 기획", "출시 보도자료 써줘", "이 제품 진짜 가치 있나" 요청 시.
model	claude-opus-4-8

Skill — Working Backwards (PR-FAQ)

Task

Scope

PR-FAQ 작성과 자체 비평까지. 실제 구현·일정 확정·예산 승인은 별도 단계.
입력은 기능 아이디어 + 타깃 고객 + 알려진 근거(인터뷰/데이터). 근거 없으면 가정으로 명시.
PR 은 1페이지를 넘기지 않는다 — 길어지면 가치가 한 문장으로 안 잡혔다는 신호.
수치·인용은 실제 근거가 있을 때만. 없으면 [가정] 태그.

Length

PR 본문 ≤ 400자(헤드라인·서브헤드 제외). FAQ 외부용 3–5개 + 내부용 3–5개.
전체 1,500–3,000자.

Format

## Press Release — 헤드라인 / 한 줄 서브헤드 / 문제 단락 / 해결 단락 / 가상 고객 인용 1개 / "시작하는 법" 한 줄.
## FAQ — 고객용 — 고객이 실제로 물을 질문 (가격, 기존 도구 대비, 데이터 안전 등).
## FAQ — 내부용 — 가장 답하기 싫은 질문부터 (왜 우리가, 왜 지금, 실패 조건, 안 만들면 무슨 일).
## 검증 신호 — 이 PR-FAQ 가 통과/기각될 기준(이 가정이 틀리면 만들지 않는다).
## 한계 — [가정] 으로 채운 부분, 근거 부족 항목, 추가 확인 필요.

룰

출처 명시: Working Backwards / PR-FAQ 는 Amazon 의 제품 기획 관행이다. "고객으로부터 거꾸로 일한다(start from the customer and work backwards)" 원칙을 인용할 때 출처를 적는다.
PR 은 고객 언어 로. "혁신적", "업계 최고", "seamless" 같은 마케팅 형용사 금지 — 구체적 진전으로 대체.
가상 고객 인용은 그 고객이 실제로 할 법한 문장으로. 칭찬이 아니라 "무엇이 달라졌는지" 를 말하게 한다.
내부 FAQ 는 반대 의견을 먼저 적는다. 통과를 전제하지 않는다.
근거 없는 수치("3배 빨라짐")는 [가정] 표기. 검증 전 사실로 쓰지 않는다.
PR 한 문장으로 가치가 안 잡히면, 만들 가치가 불명확하다는 결론을 숨기지 않고 적는다.

의존

입력 우선순위: 사용자가 제시한 기능 아이디어 + samples/ 근거
참고 챕터: 4.1-discovery-user-research.md

예시

좋은 출력: good-examples/prfaq-team-digest.md
나쁜 출력: bad-examples/marketing-fluff-pr.md