problem-framing-canvas

problem-framing-canvas 개요

problem-framing-canvas가 하는 일

problem-framing-canvas skill은 팀이 해결책부터 서두르기 전에 문제를 먼저 정의할 수 있도록 MITRE의 Problem Framing Canvas를 따라가게 해 줍니다. 요청이 모호하거나, 이해관계자들 사이에 의견이 갈리거나, 팀이 잘못된 결과를 최적화하고 있다고 의심될 때 가장 유용합니다.

누가 사용하면 좋은가

요청을 복잡한 상태에서 공통의 문제 정의로 정리해야 하는 PM, 디자이너, 리서처, 퍼실리테이터라면 이 problem-framing-canvas skill을 쓰면 됩니다. 특히 다음에 무엇을 할지에 대한 근거가 필요할 때, 단순히 아이디어를 더 늘리기보다 판단 근거를 세우는 problem-framing-canvas for Decision Support에 잘 맞습니다.

왜 다른가

이 skill은 상호작용형이고, 좋은 의미에서 꽤 의견이 분명합니다. Look Inward, Look Outward, Reframe의 세 단계를 밀어붙이기 때문에, 편향 점검, 이해관계자 범위 확인, 그리고 워크숍이나 로드맵, 디스커버리 플랜으로 이어질 수 있는 최종 “How Might We” 프레이밍이 필요할 때 일반적인 프롬프트보다 낫습니다.

problem-framing-canvas skill 사용법

설치하고 핵심 파일 위치 확인하기

problem-framing-canvas install을 할 때는 skill 디렉터리에 표시된 repo 경로를 사용하고 skills/problem-framing-canvas/SKILL.md부터 시작하세요. 그다음 template.md에서 출력 형식을 확인하고, examples/sample.md를 읽어 완성도가 높은 canvas가 어떤 모습인지 살펴보면 됩니다.

주제 말고 실제 문제를 넣기

problem-framing-canvas usage는 맥락, 증상, 의사결정 압박이 분명할수록 더 잘 작동합니다. 좋은 입력은 “엔터프라이즈 SaaS에서 처음 로그인한 관리자들의 온보딩 이탈을 줄여야 하는데, 지원 티켓을 보면 2단계에서 혼란이 집중된다”처럼 구체적이어야 합니다. 반면 “온보딩을 개선하자”처럼 뭉뚱그린 말은 약한 입력입니다.

세 단계 워크플로를 활용하기

좋은 problem-framing-canvas guide 입력은 skill이 다음 흐름으로 이동할 수 있게 해 줍니다.

• Look Inward: 우리 팀이 무엇을 가정하고 있는지, 무엇을 선호하는지, 무엇을 놓치고 있을 수 있는지
• Look Outward: 누가 이 문제를 체감하는지, 언제 발생하는지, 누가 제외되는지
• Reframe: 더 날카로운 문제 진술과, 실제로 쓸 수 있는 HMW 질문

잘 먹히는 프롬프트 형식

canvas 결과를 한 번에 내도록 요청하고, 대상, 비즈니스 목표, 이미 알고 있는 근거처럼 중요한 제약을 함께 넣으세요. 예를 들어: “지원 로그와 제품 분석 데이터만 있다고 가정하고, 신생 SMB 고객의 이탈 문제를 problem-framing-canvas로 정리해 주세요.” 이렇게 하면 skill이 너무 일반적으로 흘러가지 않고, 현실에 붙어 있는 프레이밍을 유지하기 쉽습니다.

problem-framing-canvas skill FAQ

일반 프롬프트보다 나은가?

대체로 그렇습니다. 특히 문제가 모호할수록 더 그렇습니다. 일반 프롬프트는 아이디어를 너무 빨리 만들 수 있지만, problem-framing-canvas는 먼저 문제 정의를 하게 만듭니다. 팀이 증상만 두고 논쟁할 때 그게 가장 큰 가치입니다.

언제 쓰지 말아야 하나?

문제가 이미 명확하고, 필요한 것이 실행 계획이나 카피 작성, 해결책 아이데이션이라면 problem-framing-canvas를 쓰지 마세요. 이건 프레이밍 도구이지, 실행 계획이나 우선순위 프레임워크가 아닙니다.

초보자도 쓰기 쉬운가?

네. canvas 구조 자체는 단순합니다. 다만 결과물의 품질은 입력에 달려 있습니다. 초보자라면 하나의 구체적인 문제, 타깃 사용자, 그리고 최소 한 가지의 제약이나 근거를 함께 가져올 때 가장 큰 효과를 볼 수 있습니다.

다른 제품 워크플로와는 어떻게 연결되나?

문제에 대한 공통 언어가 필요할 때, 디스커버리 요약, 로드맵 논의, 해결책 브레인스토밍보다 앞 단계에서 가장 잘 맞습니다. 먼저 문제의 프레임을 분명하게 만든 뒤, 그 다음에 리서치 질문, 실험 설계, 아이데이션으로 넘어가세요.

problem-framing-canvas skill 개선 방법

의견 말고 근거를 넣기

품질을 가장 크게 끌어올리는 방법은 구체적인 입력을 주는 것입니다. 지원 문의 주제, 퍼널 이탈, 고객 발언, 계약 실패 사유, 관찰된 행동 같은 것들이 여기에 해당합니다. problem-framing-canvas는 증상과 근본 원인을 구분할 수 있을 때 더 날카로워집니다.

경계 조건을 분명히 하기

팀에 제약이 있다면 처음부터 말하세요. 타깃 세그먼트, 일정, 플랫폼, 법적 제한, 비즈니스 목표 같은 정보가 여기에 포함됩니다. 이런 세부 정보가 있어야 skill이 “모든 걸 해결하자”식의 넓은 프레이밍을 피하고, 실제로 쓸 수 있는 HMW 질문을 만들어 냅니다.

자주 생기는 실패 패턴을 경계하기

가장 흔한 실패는 문제를 해결책 형태로 써 버리는 것입니다. 예를 들어 “더 나은 대시보드가 필요하다”거나 “AI 자동화가 필요하다”는 식입니다. problem-framing-canvas skill의 결과를 개선하려면 먼저 사용자 불편과 맥락을 다시 적고, 그다음에 무엇이 정말 막혀 있는지, 무엇이 오해되고 있는지 물어보세요.

한 번 더 좁혀서 반복하기

첫 번째 canvas 이후에도 진술이 여전히 넓다면 더 좁은 버전으로 다시 밀어붙이세요. 유용한 후속 요청은 “첫 사용자만 대상으로 다시 프레이밍해 주세요” 또는 “이번 분기에 검증 가능한 근거만 써서 문제를 다시 써 주세요”입니다. 보통은 아이디어를 더 달라고 하는 것보다 이런 정제가 의사결정 품질을 더 많이 높여 줍니다.