opportunity-solution-tree

Opportunity Solution Tree 스킬 개요

opportunity-solution-tree 스킬은 제품 디스커버리를 위한 Opportunity Solution Tree를 만드는 데 도움을 줍니다. 즉, 원하는 성과에서 시작해 고객 기회, 후보 솔루션, 실험으로 이어지는 구조화된 경로를 정리해 줍니다. 다음에 무엇을 만들지 바로 기능으로 뛰어들기보다, 더 분명한 판단 기준이 필요한 Product Management 팀에 특히 유용합니다.

이 스킬의 용도

전략, 리서치, OKR을 의사결정 가능한 디스커버리 맵으로 바꿔야 할 때 opportunity-solution-tree 스킬을 사용하세요. 제품 성과를 정의하거나, 고객의 pain point를 묶어 보거나, 여러 솔루션 아이디어를 비교하거나, 개발에 착수하기 전에 테스트를 설계할 때 잘 맞습니다.

가장 도움이 되는 대상

이 스킬은 공통의 문제 영역에서 일하는 제품 매니저, 디스커버리 리드, 디자이너, 그리고 크로스펑셔널 팀에 가장 적합합니다. 특히 이해관계자들이 이미 기능 아이디어를 갖고 있지만, 그것을 근거와 더 탄탄하게 연결해야 할 때 효과적입니다.

일반적인 프롬프트와 다른 점

일반 프롬프트로도 OST 형태의 답변은 만들 수 있습니다. 하지만 opportunity-solution-tree 스킬은 재사용 가능한 구조를 제공합니다. 먼저 outcome, 그다음 opportunities, 그다음 solutions, 마지막에 experiments를 두는 식입니다. 이 순서는 솔루션 편향을 줄이고, 팀원들에게 트레이드오프를 설명하기도 훨씬 쉽게 만들어 줍니다.

opportunity-solution-tree 스킬 사용 방법

스킬 설치하고 먼저 살펴보기

opportunity-solution-tree install을 사용할 때는 skills 환경의 디렉터리 설치 흐름을 따라 설치한 뒤, 먼저 SKILL.md를 여세요. 에이전트 설정이 repository 기반 설치를 지원한다면 phuryn/pm-skills와 pm-product-discovery/skills/opportunity-solution-tree 경로를 지정하면 됩니다.

판단 가능한 입력값을 먼저 주기

이 스킬은 처음부터 네 가지를 주면 가장 잘 작동합니다. 목표 outcome, 사용자 세그먼트, 이미 확보한 근거, 그리고 알려진 제약 조건입니다. 예를 들어 “OST 만들어 줘”라고 하기보다, “셀프서비스 trial 사용자에서 7일 retention을 높이기 위한 Opportunity Solution Tree를 만들어 줘. 인터뷰 노트, churn 사유, 기존 onboarding flow가 하나 있다. solution보다 opportunity를 먼저 우선순위화해 줘.”처럼 요청하세요.

먼저 읽어야 할 파일

워크플로와 필수 입력을 이해하려면 SKILL.md부터 시작하세요. 로컬 설치 환경에서 파일이 하나만 노출된다면, 그것을 단일 기준(source of truth)으로 보면 됩니다. 더 넓은 repository 구조가 함께 보인다면, 가까운 package metadata나 discovery guidance도 확인해 팀의 제품 용어와 tree를 맞추세요.

올바른 순서로 워크플로 실행하기

실용적인 opportunity-solution-tree usage 흐름은 이렇습니다. outcome을 정의하고, 리서치나 사용자 피드백에서 opportunities를 모으고, 그것들을 묶고 우선순위를 정한 뒤, 각 opportunity마다 여러 solutions를 브레인스토밍하고, 마지막으로 가장 위험한 가정을 검증할 experiments를 붙입니다. tree는 하나의 outcome에 집중해야 유용합니다. 그렇지 않으면 backlog를 쏟아 넣은 목록처럼 되어 버립니다.

opportunity-solution-tree 스킬 FAQ

이건 그냥 브레인스토밍 템플릿 아닌가요?

아닙니다. opportunity-solution-tree 스킬의 목적은 무작위 아이디어를 생성하는 데 있지 않고, 제품 디스커버리를 구조화하는 데 있습니다. 이 스킬의 핵심 가치는 outcome에서 출발해 근거가 있는 opportunities를 거쳐 테스트 가능한 solutions로 이어지는 더 명확한 연결고리를 강제하는 데 있습니다.

언제는 사용하지 말아야 하나요?

문제가 이미 완전히 정의되어 있고 작업이 실행 중심일 때, 또는 실제 opportunities를 찾을 만큼 고객 근거가 충분하지 않을 때는 OST를 쓰지 마세요. 이런 경우에는 더 단순한 요구사항 브리프나 delivery plan이 보통 더 적합합니다.

초보자도 쓰기 쉬운가요?

이미 제품 목표를 알고 있다면 그렇습니다. 핵심 난점은 형식이 아니라, 하나의 outcome을 고르는 일과 opportunities를 숨은 기능이 아니라 고객 관점의 언어로 표현하는 일입니다.

Product Management에 어떻게 도움이 되나요?

Product Management 관점에서 opportunity-solution-tree 스킬은 우선순위 대화를 더 선명하게 하고, 디스커버리 작업을 눈에 보이게 만들며, 왜 어떤 opportunity나 experiment가 더 가치 있는지 팀이 설명하도록 돕습니다. 특히 roadmap 약속을 하기 전에 매우 유용합니다.

opportunity-solution-tree 스킬 개선 방법

더 좁은 outcome부터 시작하기

더 좋은 OST는 더 타이트한 프롬프트에서 나옵니다. “activation을 높여라”는 너무 넓습니다. 반면 “가입 후 7일 이내의 신규 팀 관리자 activation을 높여라”처럼 쓰면, 스킬이 다룰 구체적 목표, 사용자 세그먼트, 판단 기준이 생깁니다.

실제 opportunity 데이터를 넣기

tree의 품질은 opportunities의 품질에 달려 있습니다. 인터뷰 인용문, 지원 문의 주제, 세션 노트, win/loss 패턴, 사용 데이터 등을 넣어 고객의 실제 pain과 내부 가정을 구분할 수 있게 하세요.

가지치기보다 우선순위와 트레이드오프를 요청하기

더 강한 opportunity-solution-tree usage 결과를 얻으려면, opportunities를 순위화하고, 왜 중요한지 설명하고, 각 solution을 반증할 수 있는 가장 작은 experiment를 제안해 달라고 요청하세요. 그러면 산출물이 디스커버리 리뷰와 이해관계자 정렬에 훨씬 더 실행 가능하게 바뀝니다.

첫 번째 tree 이후에 다시 다듬기

첫 버전으로 빈틈을 드러낸 뒤, 더 나은 근거와 더 날카로운 표현으로 수정하세요. tree가 지나치게 solution 중심으로 느껴지면 기능을 다시 opportunity 언어로 되돌리고, 너무 모호하면 세그먼트 상세 정보, outcome 지표, 그리고 일정, 기술 한계, 리서치 확신도 같은 명시적 제약을 추가하세요.