[서비스 기획 숙련] PM이 갖추어야 할 역량

역량	핵심 의미
사고방식	WHY를 반복해 문제의 본질을 찾고, WHAT과 HOW로 실행 구조를 만든다
커뮤니케이션	오해를 줄이고, 의도와 목표를 명확히 전달한다
논리 기반	데이터와 근거를 바탕으로 의사결정하고, 이해관계자를 설득한다

---

1. 사고방식: WHY & WHY & WHY → WHAT → HOW

먼저 계속해서 왜 해야 하는지를 묻고,
그다음 무엇을 해야 하는지,
마지막으로 어떻게 실행할 것인지를 정리한다.

핵심 흐름
WHY → WHAT → HOW

문제의 이유를 찾고, 목표를 정의한 뒤, 실행 계획으로 연결하는 방식

WHY

WHY는 의사결정을 내리는 데 필요한 이유를 끊임없이 묻는 단계다.

• 왜 이 일을 해야 하는가?
• 왜 이 기능이 필요한가?
• 왜 이 방향이 맞는가?

목적	설명
문제의 근본 원인 파악	겉으로 드러난 현상이 아니라, 실제 원인을 찾기 위함
목표 명확화	무엇을 달성해야 하는지 분명히 하기 위함
합리적 의사결정	여러 선택지 중 더 나은 방향을 판단하기 위함

c.f)
프로젝트 진행 과정에도 대입할 수 있다.

e.g) 프로젝트 일정 지연

프로젝트 일정이 지연되고 있음
→ 왜 일정이 지연되는가?
→ 팀원의 업무 속도가 느려서

→ 왜 팀원의 업무 속도가 느린가?
→ 업무에 필요한 자료나 지원을 제때 받지 못하고 있음

→ 왜 자료나 지원이 전달되지 않는가?
→ 자료에 필요한 의사결정이 완료되지 못했음

처음에는 업무 속도의 문제처럼 보였지만,
WHY를 반복하면 실제 원인이 의사결정 지연에 있을 수 있다는 것을 알 수 있다.

PM에게는 정답이 없다.
답이 없다는 것은 항상 최선의 선택을 해야 한다는 뜻이다.
그리고 실패와 개선을 반복하면서 문제를 해결해 나가야 한다.

WHAT

WHAT은 구체적인 목표와 결과물을 정의하는 단계다.

WHY를 통해 이유와 문제의 본질을 파악했다면,
이제 무엇을 만들고 무엇을 달성할지 정리해야 한다.

항목	내용
목표	이번 프로젝트에서 달성해야 하는 상태
결과물	최종적으로 만들어져야 하는 산출물
프로젝트 범위	이번에 할 것과 하지 않을 것의 구분
리소스	필요한 인력, 시간, 자료, 시스템 등
작업 목록	실행을 위해 필요한 세부 작업

HOW

HOW는 프로젝트의 실행 계획을 수립하는 단계다.

WHAT에서 목표와 결과물이 정리되었다면,
HOW에서는 실제로 프로젝트를 어떻게 진행할지 구체화한다.

항목	설명
세부 계획	무엇을 어떤 순서로 진행할지 정리
작업 분배	누가 어떤 일을 맡을지 결정
로드맵 수립	프로젝트가 어떤 흐름으로 진행될지 정리

 

---

2. 커뮤니케이션: 오해를 최소화하고 의도를 명확하게 전달

요소	설명
명확성 & 간결성	핵심 메시지를 먼저 한 문장으로 정리하고, 이후 세부사항을 덧붙인다
목표와 의도 명확화	불필요한 논의와 오해를 줄이기 위해 목표를 분명히 한다
공감과 감정관리	상대의 감정과 우려를 인정하며 해결 방향을 찾는다
상대 관점 이해	이해관계자들의 서로 다른 배경과 요구를 이해하고 최적의 타협점을 찾는다
적극적인 경청	상대의 말을 귀 기울여 듣고, 질문과 피드백으로 더 깊이 이해한다

 

💡 생각해볼 지점 💡 

1. 커뮤니케이션
아이데이션 회의에서 “명확하게 커뮤니케이션한다”는 것은 무엇일까?

나조차도 확신이 없는 상태에서 모호하게 커뮤니케이션하면,
상대도 무엇을 어떻게 고민해야 할지 알기 어렵다.

아이디어가 부족해서 소극적인 것처럼 보였던 상황도,
사실은 고민해야 할 기준이 모호해서 발생한 문제일 수 있다.

2. 공감능력
상대 의견에 공감이 가지 않을 때에는, 공감되는 '척'이라도 해야 하는걸까?

예를 들어 사용자 반응 테스트를 위해 간단한(예상 작업 소요기간 1주 이내) 실험 기능을 배포해야 하는 상황이 있다고 해보자.
PM : 사용자 반응 테스트를 위한 실험 기능이므로 빠르게 배포하고 싶다
개발자 : 설계도 해야 하고, 개발 및 자체 검증도 해야 하니 한 달 정도 필요하다고 판단한다
PM : 실험 후 방향이 바뀌거나 드랍될 수 있으니 충분한 설계 공수가 필요하지 않다고 생각한다
개발자 : 그렇다 하더라도 2주 이상은 필요하다고 말한다

이 때, PM은 어떻게 반응 (커뮤니케이션) 해야 할까?

본인은 주로 병목 지점을 파악해보고,
<병목 지점 파악>
복잡도의 원인 - 어떤 부분에서 설계 복잡도가 가장 높다고 보시나요?
최소 구현 가능 범위 - 반응 테스트만 한다면 반드시 필요한 범위는 어디까지일까요?
리스크 - 공수를 줄였을 때 가장 우려되는 문제는 무엇인가요?
대안 - 1주 안에 검증 가능한 더 작은 방식이 있을까요?

정책 변경이나 스펙 아웃을 약간씩 하거나 구현 방향을 조정, 품질 기준 일부 하회 하여 
협의를 했다.

이 안에는 "공감"이 있었을까?
너무 몰아붙이는 방식이었을까..... 🤔

 

 

---

3. 논리 기반: 데이터와 근거로 설득하기

논리 기반 역량
객관적인 데이터와 분석을 바탕으로 문제를 해결하고,
이해관계자가 납득할 수 있도록 설명하는 것

목적

목적	설명
합리적인 의사결정	논리적 사고와 데이터 분석을 기반으로 판단한다
우선순위 결정 및 리소스 배분	비즈니스 목표와 사용자 요구 등 객관적 기준으로 우선순위를 정한다
이해관계자와의 협상 및 설득	논리적이고 객관적인 근거로 의사결정의 신뢰를 높인다

논리적인 설득법

방법	확인할 질문
주장과 근거의 구분	주장만 말하고 있지는 않은가? 객관적 근거를 제시하고 있는가?
문제 해결에 단계적 접근	문제를 여러 개의 작은 문제로 나누고 있는가?
논리적 흐름 만들기	주제 → 주장 → 근거 → 결론 순서로 설명하고 있는가?

논리적 흐름 예시

주제 → 주장 → 근거 → 결론

구분	예시
주제	우리는 새로운 기능을 추가해야 한다
주장	이 기능은 사용자 문제를 해결하고, 제품 가치를 높여줄 것이다
근거	사용자 피드백과 분석 결과, 60% 이상의 사용자가 이 기능을 요청했다
결론	따라서 이 기능을 개발하는 것이 가장 우선적인 과제이다

논리는 상대를 이기기 위한 도구가 아니다.
이해관계자가 같은 기준으로 판단할 수 있게 만드는 도구다.