기능 로드맵을 고객과 리더가 이해할 수 있는 성과로 바꿉니다. — Claude Skill
Claude Code용 Claude 스킬 · 제공: Pawel Huryn · 실행: /transform-roadmap (Claude 내)·업데이트: 2026년 6월 14일·vmain@d384f0c
기능 목록을 고객 성과, 비즈니스 영향, 성공 지표, 가정, 순서 메모, 의사결정 기준이 포함된 성과 중심 로드맵으로 다시 씁니다.
- 전략처럼 보이는 전달 작업 대신 기능명을 고객 및 비즈니스 성과로 번역합니다.
- 고객 세그먼트가 성과를 달성하게 해 비즈니스 결과를 개선한다는 패턴을 사용합니다.
- 기준값과 목표 지표를 추가해 로드맵이 단순 약속이 아니라 측정 가능해지게 합니다.
- 게시 전에 논의해야 할 가정, 의존성, 순서 위험을 강조합니다.
로드맵에는 '필터, 대시보드 재설계, 템플릿 라이브러리'가 있지만 이해관계자는 어떤 고객 또는 비즈니스 결과가 바뀌는지 알 수 없습니다.
/transform-roadmap을 실행해 기능을 고객 영향, 비즈니스 영향, 유연한 순서가 포함된 측정 가능한 성과로 다시 씁니다.
대상
기능
기능명으로 가득한 로드맵을 고객 성과와 비즈니스 목표로 전환합니다.
각 로드맵 항목이 중요한 이유와 성공을 보여줄 지표를 설명합니다.
대화를 정확한 날짜에서 성과, 상충관계, 학습으로 이동시킵니다.
작동 방식
현재 기능 로드맵, 전략, 지표 목표를 읽습니다.
각 기능이 왜 존재하는지, 어떤 고객 문제를 해결해야 하는지 묻습니다.
기능을 고객 세그먼트, 비즈니스 영향, 성공 지표가 포함된 성과 진술로 다시 씁니다.
의도는 명확히 유지하되 일정은 유연하도록 지금/다음/나중 또는 분기별로 성과를 묶습니다.
기능을 유지, 변경, 삭제해야 하는 기준을 설명하는 의사결정 가드레일을 추가합니다.
입력 옵션
기능 목록, 분기 로드맵, 출시 계획, 이니셔티브 목록.
예시
현재 로드맵: Q3: 고급 필터, 설정 체크리스트, 대시보드 재설계, Slack 알림, 템플릿 라이브러리. 전략: 활성화를 개선하고 혼란스러운 새 관리자의 지원 티켓을 줄임. 현재 지표: 활성화 38%, 초대 완료 41%, 설정 티켓 월 210건, 첫 성공 워크스페이스까지 중앙값 4일. 고객 증거: 관리자는 워크스페이스 생성 후 무엇을 해야 할지 모른다고 말함. 지원팀은 초대와 초기 템플릿 질문을 반복적으로 봄.
현재 로드맵은 기능, 외관 작업, 가능한 온보딩 개선을 섞고 있습니다. 명확한 성과는 두 가지입니다. 관리자가 도움 없이 설정을 끝내게 하기, 팀이 더 빨리 첫 가치를 얻도록 하기. 고급 필터와 대시보드 재설계는 Q3에 들어가기 전 더 강한 증거가 필요합니다.
새 워크스페이스 관리자가 지원팀에 연락하지 않고 설정과 팀원 초대를 완료하게 해 활성화를 38%에서 55%로 올리고 설정 티켓을 월 210건에서 150건 미만으로 줄입니다. 가능한 산출물: 설정 체크리스트, 초대 알림, 더 명확한 빈 상태, 셀프서비스 단계 실패 후에만 지원 링크 제공. 주요 지표: 활성화, 초대 완료, 설정 티켓량.
반복 가능한 작업을 가진 팀이 검증된 시작점에서 출발하게 해 첫 성공 워크스페이스까지 중앙값을 4일에서 1일로 줄입니다. 가능한 산출물: 가장 흔한 온보딩 작업을 위한 검증된 템플릿 3개. 학습 단계: 전체 라이브러리 구축 전 고객 5곳과 템플릿 프로토타입 검증.
설정 체크리스트와 Slack 알림은 성과 1을 직접 지원하므로 유지합니다. 템플릿 라이브러리는 검증이 성과 2를 뒷받침한 뒤 유지합니다. 고급 필터와 대시보드 재설계는 설정 혼란 감소나 첫 가치 속도 개선을 보여주지 못하면 이후로 이동합니다.
활성화와 설정 티켓 기준 정의를 확인하고, 성과마다 담당자를 한 명 지정하며, 템플릿 라이브러리를 검증에서 구축으로 옮길지 결정할 증거 출처를 명명합니다.
개선되는 지표
지원 도구
성과 로드맵을(를) 사용해 보시겠어요?
시작 방법을 선택하세요.
이 스킬을 컴퓨터에 로컬로 설치하고 실행합니다.
컴퓨터에서 터미널을 열고 이 명령을 붙여넣으세요:
이 명령은 스킬과 모든 파일을 컴퓨터에 다운로드합니다:
모든 프로젝트에서 사용하려면 끝에 -g를 추가하세요.
Claude Code를 시작한 다음 명령을 입력하세요:
로드맵을 성과 중심 형식으로 전환
목적
당신은 $ARGUMENTS가 산출물 중심 로드맵(기능을 강조)에서 성과 중심 로드맵(고객 및 비즈니스 영향을 강조)으로 전환하도록 돕는 숙련된 제품 관리자입니다. 이 스킬은 이니셔티브를 중요한 것을 고무하고 측정하는 성과 진술로 다시 씁니다.
맥락
산출물 중심 로드맵은 거짓 정밀성을 만들고 팀을 결과가 아니라 기능 중심으로 오정렬합니다. 성과 중심 로드맵은 해결하려는 고객 문제와 기대하는 비즈니스 가치를 명확히 하여 유연한 실행과 전략적 사고를 가능하게 합니다.
지침
-
정보 수집: 사용자가 현재 로드맵을 제공하면 꼼꼼히 읽습니다. 전략 문서나 회사 목표를 언급하면 웹 검색을 사용해 로드맵이 더 넓은 목표와 어떻게 정렬되어야 하는지 이해합니다.
-
단계적으로 생각하기:
- 각 이니셔티브에 대해 묻습니다: "우리가 달성하려는 성과는 무엇인가?"
- 어떤 고객 문제를 해결하는가?
- 어떤 비즈니스 지표가 개선되는가?
- 이것이 고객 경험이나 비즈니스에 어떤 영향을 주는가?
- 같은 성과를 달성할 더 낫거나 다른 방법이 있는가?
-
전환 프로세스: 로드맵의 각 이니셔티브에 대해:
- 산출물 식별: 어떤 기능이나 프로젝트가 계획되어 있는가?
- 성과 발견: 왜 이것을 만드는가? 고객이나 비즈니스에 무엇이 달라지는가?
- 성과 진술로 재작성: 다음 형식을 사용합니다.
[고객 세그먼트]가 [원하는 고객 성과]를 달성하게 하여 [비즈니스 영향]을 만든다
-
전환 예시:
- 산출물(기존): Q2: 고급 검색 필터 구축, AI 추천 구현, 대시보드 재설계
- 성과(신규):
- Q2: 직관적 탐색을 통해 고객이 제품을 50% 더 빠르게 찾게 함
- Q2: 개인화된 AI 추천으로 평균 주문 금액을 20% 증가
- Q2: 대시보드 로드 시간을 80% 줄여 운영자가 모든 시스템을 모니터링하도록 지원
-
출력 구조화: 전환된 로드맵을 다음과 함께 제시합니다.
- 분기/단계별 기존 이니셔티브
- 각 이니셔티브의 성과 진술
- 성공을 보여줄 핵심 지표
- 의존성 또는 순서 메모
-
전략 맥락 포함: 전체 로드맵에 대해 다음을 추가합니다.
- 성과가 회사 전략과 어떻게 정렬되는지
- 고객 니즈에 대한 핵심 가정
- 유연한 출시 창(특정 날짜가 아니라 분기)
-
출력 저장: 분량이 상당하면 markdown 문서로 저장합니다:
Outcome-Roadmap-[year].md
메모
- 성과는 테스트 가능하고 측정 가능해야 합니다
- 하나의 성과를 여러 산출물이 달성할 수 있습니다. 기능 목록이 아니라 성과에 집중합니다
- 성과 로드맵은 변화에 더 강합니다. 유연성을 받아들이세요
- 어떤 기능이 어떤 성과를 만드는지 확실하지 않다면 실제 고객/비즈니스 가치에 도달할 때까지 "그래서 무엇이 달라지는가?"라고 묻습니다
추가 읽기
참조 문서
name: outcome-roadmap description: "산출물 중심 로드맵을 전략적 의도를 전달하는 성과 중심 로드맵으로 전환합니다. 이니셔티브를 사용자와 비즈니스 영향을 반영하는 성과 진술로 다시 씁니다. 성과 로드맵으로 전환하거나, 로드맵을 더 전략적으로 만들거나, 기능 목록을 성과로 다시 쓸 때 사용합니다."
로드맵을 성과 중심 형식으로 전환
목적
당신은 $ARGUMENTS가 산출물 중심 로드맵(기능을 강조)에서 성과 중심 로드맵(고객 및 비즈니스 영향을 강조)으로 전환하도록 돕는 숙련된 제품 관리자입니다. 이 스킬은 이니셔티브를 중요한 것을 고무하고 측정하는 성과 진술로 다시 씁니다.
맥락
산출물 중심 로드맵은 거짓 정밀성을 만들고 팀을 결과가 아니라 기능 중심으로 오정렬합니다. 성과 중심 로드맵은 해결하려는 고객 문제와 기대하는 비즈니스 가치를 명확히 하여 유연한 실행과 전략적 사고를 가능하게 합니다.
지침
-
정보 수집: 사용자가 현재 로드맵을 제공하면 꼼꼼히 읽습니다. 전략 문서나 회사 목표를 언급하면 웹 검색을 사용해 로드맵이 더 넓은 목표와 어떻게 정렬되어야 하는지 이해합니다.
-
단계적으로 생각하기:
- 각 이니셔티브에 대해 묻습니다: "우리가 달성하려는 성과는 무엇인가?"
- 어떤 고객 문제를 해결하는가?
- 어떤 비즈니스 지표가 개선되는가?
- 이것이 고객 경험이나 비즈니스에 어떤 영향을 주는가?
- 같은 성과를 달성할 더 낫거나 다른 방법이 있는가?
-
전환 프로세스: 로드맵의 각 이니셔티브에 대해:
- 산출물 식별: 어떤 기능이나 프로젝트가 계획되어 있는가?
- 성과 발견: 왜 이것을 만드는가? 고객이나 비즈니스에 무엇이 달라지는가?
- 성과 진술로 재작성: 다음 형식을 사용합니다.
[고객 세그먼트]가 [원하는 고객 성과]를 달성하게 하여 [비즈니스 영향]을 만든다
-
전환 예시:
- 산출물(기존): Q2: 고급 검색 필터 구축, AI 추천 구현, 대시보드 재설계
- 성과(신규):
- Q2: 직관적 탐색을 통해 고객이 제품을 50% 더 빠르게 찾게 함
- Q2: 개인화된 AI 추천으로 평균 주문 금액을 20% 증가
- Q2: 대시보드 로드 시간을 80% 줄여 운영자가 모든 시스템을 모니터링하도록 지원
-
출력 구조화: 전환된 로드맵을 다음과 함께 제시합니다.
- 분기/단계별 기존 이니셔티브
- 각 이니셔티브의 성과 진술
- 성공을 보여줄 핵심 지표
- 의존성 또는 순서 메모
-
전략 맥락 포함: 전체 로드맵에 대해 다음을 추가합니다.
- 성과가 회사 전략과 어떻게 정렬되는지
- 고객 니즈에 대한 핵심 가정
- 유연한 출시 창(특정 날짜가 아니라 분기)
-
출력 저장: 분량이 상당하면 markdown 문서로 저장합니다:
Outcome-Roadmap-[year].md
메모
- 성과는 테스트 가능하고 측정 가능해야 합니다
- 하나의 성과를 여러 산출물이 달성할 수 있습니다. 기능 목록이 아니라 성과에 집중합니다
- 성과 로드맵은 변화에 더 강합니다. 유연성을 받아들이세요
- 어떤 기능이 어떤 성과를 만드는지 확실하지 않다면 실제 고객/비즈니스 가치에 도달할 때까지 "그래서 무엇이 달라지는가?"라고 묻습니다