problem-statement

problem-statement 스킬 개요

problem-statement 스킬은 모호한 제품 요청을, 누가 막혀 있는지, 무엇을 하려는지, 왜 중요한지, 그리고 어떤 감정을 느끼는지까지 설명하는 사용자 중심의 문제 진술로 바꿔줍니다. 솔루션을 바로 정하기 전에 먼저 정렬이 필요할 때, 즉 발견, 우선순위 설정, PRD, 이해관계자 리뷰 단계에서 특히 유용합니다.

problem-statement 스킬의 용도

이 problem-statement 스킬은 기능 설계가 아니라 문제 프레이밍을 위해 만들어졌습니다. 사용자의 관점에서 문제를 설명하도록 도와주기 때문에, 구현 방법을 두고 논의하기 전에 이 작업이 정말 할 가치가 있는지 팀이 판단할 수 있게 해줍니다.

어떤 사람에게 가장 잘 맞는가

제품 브리프, 기술 명세서, 리서치 요약, 로드맵 노트를 작성하면서 더 명확한 문제 서사가 필요하다면 이 스킬을 쓰세요. 특히 Technical Writing 워크플로에서, 지저분한 입력을 간결하고 공감 가는 진술로 정리해야 할 때 잘 맞습니다.

무엇이 다른가

이 스킬은 문제 프레이밍 프레임워크인 I am, Trying to, But, Because, Which makes me feel과 맥락, 제약 조건을 중심에 둡니다. 이 구조는 단순한 프롬프트보다 의사결정에 더 유용합니다. 기능적인 막힘과 사람에게 미치는 영향을 함께 담도록 강제하기 때문입니다.

problem-statement 스킬 사용 방법

스킬 설치 및 살펴보기

다음 명령으로 설치합니다.

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

그다음에는 skills/problem-statement/SKILL.md를 먼저 읽고, 이어서 template.md와 examples/sample.md를 보세요. 기대되는 형태, 최종 산출물, 그리고 완성도 높은 문제 진술이 어떤 모습인지 가장 빨리 파악할 수 있는 방법입니다.

프롬프트에 무엇을 넣어야 하는가

problem-statement를 잘 쓰려면, 대략적이지만 구체적인 입력을 주는 것이 중요합니다. 사용자 유형, 완료하려는 작업, 막히는 지점, 그리고 제약 조건을 함께 넣으세요. 기능 요청만 던지면 출력이 실제 문제보다 솔루션 언어 쪽으로 기울기 쉽습니다.

더 나은 입력 예시는 다음과 같습니다.

• Persona: “new support agents on mobile”
• Goal: “resolve tickets without switching tools”
• Blocker: “they lose context between CRM and chat”
• Constraints: “high volume, low training time, remote-first team”

권장 워크플로

짧은 초안부터 시작한 뒤, 다섯 부분으로 된 서사로 다듬으세요. 템플릿을 체크리스트처럼 활용하면 됩니다. Because가 해결책처럼 들리면, 실제로 무엇이 고통의 원인인지 다시 물어보세요. Which makes me feel이 너무 일반적으로 느껴지면, 워크플로와 직접 연결된 실제 사용자 감정으로 바꾸세요.

먼저 읽어야 할 파일

SKILL.md, template.md, examples/sample.md를 우선 확인하세요. 특히 예시 파일은 좋은 프레이밍 패턴과 안티패턴을 함께 보여주기 때문에, 문제 진술 대신 위장된 해결책을 쓰는 일을 피하는 데 도움이 됩니다.

problem-statement 스킬 FAQ

problem-statement는 그냥 프롬프트 템플릿인가?

아닙니다. problem-statement 스킬은 빈칸 채우기용 프롬프트가 아니라, 재사용 가능한 프레이밍 방법입니다. 이 스킬의 가치는 PRD를 쓰거나 해결책을 제안하기 전에 사용자, 막힘, 근본 원인에 대한 명확성을 강제로 확보하는 데 있습니다.

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

이미 범위가 잘 정리된 요구사항 문서가 있거나, 구현 세부사항을 문서화하는 상황이라면 problem-statement를 쓰지 마세요. 해결책 아이디어를 브레인스토밍하는 목적에도 잘 맞지 않습니다. 이 스킬은 문제를 먼저 정의하는 데 초점이 있습니다.

problem-statement는 초보자에게도 쉬운가요?

사용자와 페인 포인트를 평이한 언어로 설명할 수 있다면 그렇습니다. 템플릿 자체는 단순하지만, 사용자의 문제와 내가 선호하는 해결책을 분리해낼 수 있느냐에 따라 결과물의 품질이 달라집니다.

Technical Writing 작업에는 어떻게 맞나요?

Technical Writing에서는 독자의 고통을 명확히 하거나, 문서 요청을 뒷받침하거나, 작성 전에 콘텐츠 갭을 프레이밍해야 할 때 유용합니다. 문서를 기능 나열이 아니라 결과 중심으로 유지하는 데 도움이 됩니다.

problem-statement 스킬 개선 방법

슬로건이 아니라 근거를 넣으세요

가장 좋은 problem-statement 결과는 구체적인 관찰에서 나옵니다. 사용자가 무엇을 시도했는지, 어디에서 막혔는지, 무엇을 대신 썼는지, 무엇이 깨졌는지를 담으세요. “Users are confused”는 약합니다. “first-time admins cannot finish setup because the UI hides the required API key field”처럼 쓰는 편이 훨씬 낫습니다.

문제와 해결책을 분리하세요

흔한 실패는 해결책을 슬쩍 끼워 넣는 것입니다. 초안에 “users need a dashboard”라고 쓰여 있다면, “users cannot compare account health across services because status signals are scattered”로 다시 쓰세요. 이렇게 해야 problem-statement가 실제 장벽에 계속 초점을 맞출 수 있습니다.

답을 바꾸는 제약 조건을 추가하세요

기기, 팀 규모, 시간 압박, 규정 준수, 숙련도, 플랫폼 한계처럼 문제의 형태에 영향을 주는 요소는 모두 넣으세요. 이런 세부 사항이 있어야 문제 진술의 신뢰도가 높아지고, 최종 결과도 더 나은 우선순위 설정에 도움이 됩니다.

초안에서 의사결정 가능한 수준까지 반복하세요

첫 결과를 받은 뒤에는, 이해관계자 리뷰를 통과할 만큼 구체적인지 확인하세요. 그렇지 않다면 페르소나를 더 선명하게 하고, Because의 인과성을 더 분명하게 만들고, 마지막 문장이 추가 설명 없이도 읽히는지 점검하세요.