identify-assumptions-existing

identify-assumptions-existing 개요

identify-assumptions-existing는 기존 제품에서 기능 아이디어를 설계나 개발에 들어가기 전에 먼저 압박 테스트해보는 제품 발굴용 skill입니다. 내장된 반론가 관점으로 Value, Usability, Viability, Feasibility 전반에 숨어 있는 위험한 가정을 드러내는 데 도움을 줍니다.

이 skill은 다듬어진 전략 문서가 아니라 빠른 가정 맵이 필요한 PM, 디자이너, 엔지니어, 창업자에게 가장 잘 맞습니다. 어떤 기능을 밀어붙일 가치가 있는지 판단해야 하거나, 이미 괜찮아 보이는 아이디어의 숨은 실패 지점을 찾고 있다면 identify-assumptions-existing skill이 특히 유용합니다.

핵심 가치는 의사결정의 질입니다. 대화를 “좋아 보인다”에서 “이게 되려면 무엇이 사실이어야 하지?”로 끌어올립니다. 그래서 Strategic Planning, 로드맵 우선순위 정리, 사전 리서치용 리스크 검토에 특히 잘 맞습니다.

identify-assumptions-existing은 무엇을 위한 skill인가

이미 기능 아이디어가 있고, 현실적인 제약에 비춰 그것을 압박 테스트해야 할 때 identify-assumptions-existing skill을 사용하세요. 시장에서, 사용자 경험에서, 비즈니스에서, 또는 구현 과정에서 아이디어가 어디서 무너질 수 있는지 드러내도록 설계되어 있습니다.

누가 설치하면 좋은가

제품 아이디어를 실행 가능한 가정으로 자주 바꾸는 사람이라면 identify-assumptions-existing를 설치할 가치가 있습니다. 기능 제안이 티켓, 스펙, 실험으로 굳어지기 전에 반복적으로 반박해보는 방식을 원하는 팀에 특히 유용합니다.

무엇이 다른가

일반적인 브레인스토밍 프롬프트와 달리 identify-assumptions-existing는 모델이 PM, 디자이너, 엔지니어의 세 역할 관점에서 생각하게 합니다. 이런 크로스펑셔널 프레이밍은 사각지대를 더 빨리 찾아내고, 각 가정에 대해 더 실행 가능한 테스트를 만드는 데 도움이 됩니다.

identify-assumptions-existing 사용 방법

설치하고 실행하기

소스에 나온 repo 명령을 사용해 identify-assumptions-existing install 흐름을 따르세요:

npx skills add phuryn/pm-skills --skill identify-assumptions-existing

그다음 기존 제품의 기능 아이디어를 넣어 skill을 실행합니다. 입력이 구체적일수록 가정 목록의 품질도 좋아집니다.

skill에 맞는 입력 주기

identify-assumptions-existing usage 패턴은 아래 내용을 포함할 때 가장 잘 작동합니다.

• 제품 또는 기능 이름
• 대상 사용자 세그먼트
• 기대하는 결과
• 기능 아이디어 자체
• 플랫폼, 일정, 컴플라이언스, 의존성 같은 제약 조건

약한 프롬프트는: “내 기능을 분석해줘.”
더 강한 프롬프트는: “우리 B2B 앱에서 SMB 재무 관리자를 위한 대시보드 내보내기 기능을 압박 테스트해줘. 목표는 지원 티켓 감소야. 제약: 웹 전용, 엔지니어 2명, 새 데이터 웨어하우스는 없음.”

소스를 올바른 순서로 읽기

identify-assumptions-existing guide를 볼 때는 먼저 SKILL.md부터 확인하세요. 이후 repo가 확장되면 추가 맥락을 위해 README.md, AGENTS.md, metadata.json, 그리고 rules/, resources/, references/, scripts/ 폴더를 살펴보세요. 이 repo에서는 SKILL.md가 핵심 기준 문서입니다.

더 나은 출력을 만드는 워크플로

실용적인 identify-assumptions-existing usage 워크플로는 다음과 같습니다.

1. 제품 맥락과 기능 아이디어를 설명한다.
2. Value, Usability, Viability, Feasibility별로 가정을 나눠 달라고 요청한다.
3. 각 가정의 신뢰도와 테스트 방법을 함께 요청한다.
4. 나온 결과를 바탕으로 무엇부터 검증할지 정한다.

Strategic Planning 용도로 쓴다면 시장 세그먼트, 비즈니스 목표, 출시 제약을 포함하세요. 그래야 skill이 전략적 리스크와 UX/엔지니어링 리스크를 구분할 수 있습니다.

identify-assumptions-existing skill FAQ

identify-assumptions-existing는 기존 제품에만 쓰는 skill인가요?

네, 그게 의도된 용도입니다. 이 skill은 처음부터 완전히 새로운 개념을 발상하는 용도가 아니라, 기존 제품의 기능 아이디어를 압박 테스트하는 데 맞춰져 있습니다.

일반 프롬프트와 뭐가 다른가요?

일반 프롬프트는 장단점을 나열하는 데 그칠 수 있습니다. identify-assumptions-existing skill은 리스크를 네 가지 범주로 정리하고, 무엇이 잘못될 수 있는지, 얼마나 확신하는지, 어떻게 시험할지를 묻기 때문에 더 깊이 들어갑니다. 그래서 결과를 바로 실행하기가 더 쉽습니다.

identify-assumptions-existing는 초보자도 쓰기 쉬운가요?

제품, 대상, 기능을 평이한 언어로 설명할 수 있다면 그렇습니다. 잘 쓰기 위해 정교한 가정 맵 프레임워크를 알고 있을 필요는 없지만, 모델이 현실적인 트레이드오프를 판단할 만큼의 맥락은 제공해야 합니다.

언제는 쓰지 말아야 하나요?

상세한 UX 카피, 구현 코드, 최종 출시 계획이 필요하다면 identify-assumptions-existing를 쓰지 마세요. 이 skill은 리스크 식별용이므로, 개발 결정을 내리기 전 단계에서 가장 효과적입니다.

identify-assumptions-existing skill 개선 방법

더 선명한 맥락을 제공하기

identify-assumptions-existing의 품질을 가장 크게 좌우하는 것은 사용자와 비즈니스 목표의 구체성입니다. “AI 검색을 추가해줘”라고만 하면 skill이 너무 많이 추측해야 합니다. 반면 “반복 문의의 답변 시간을 줄이기 위해 지원 담당자를 위한 AI 검색을 추가해줘”라고 하면 훨씬 유용한 가정이 나옵니다.

걱정거리만 말하지 말고 테스트도 요청하기

소스는 skill이 무엇이 잘못될 수 있는지와 어떻게 테스트할지를 포함하도록 안내합니다. 그러니 리스크에서 멈추지 마세요. 인터뷰, 프로토타입 테스트, 로그 검토, 내부 dogfood 점검 같은 가벼운 검증 아이디어도 함께 요청하세요. 그래야 결과가 단순한 비평이 아니라 계획 자료가 됩니다.

제품 리스크와 전달 리스크를 분리하기

가장 쓸모 있는 identify-assumptions-existing skill 출력은 보통 사용자 가치, 도입 장벽, 비즈니스 제약, 기술적 실현 가능성을 구분합니다. 프롬프트가 이 모든 것을 한데 뭉뚱그리면 답변도 의사결정에 덜 도움이 됩니다. 제약을 명시적으로 주어 가장 위험한 가정부터 우선순위를 매길 수 있게 하세요.

첫 결과 이후에 다시 반복하기

첫 번째 결과를 사용해 범위를 좁힌 뒤, 더 초점이 맞는 기능 조각으로 skill을 다시 실행하세요. 예를 들어 첫 번째 결과에서 사용성 리스크와 통합 리스크가 드러났다면, 온보딩 흐름만 다시 묻거나 데이터 동기화 의존성만 따로 요청하세요. 보통 이것이 Strategic Planning 논의를 가장 빠르게 선명하게 만드는 방법입니다.