오늘의 퀴즈 정리) 우선순위 설정 프레임워크 + 역기획과 PM 채용의 이해

• 서비스 기획 숙련 주차 퀴즈 ▼

+) 오늘의 인사이트 + KPT 회고

[게시글 목차]

1. 우선순위 설정 프레임워크

   ◾MoSCoW

   ◾Kano 모델

   ◾Value vs Effort

   ◾ICE

   ◾RICE

2. 역기획?

   ◾역기획 시 확인하는 것

3. PM 채용에서 역기획 과제를 내는 이유

   ◾기업이 보고 싶은 것

4. 토스 PO JD와 연결되는 역기획

 

+) 오늘의 인사이트 / KPT 회고

 

활동 내역

• 서비스 기획 숙련 강의 정리
  → 서비스 기획 숙련 3. 데이터 분석과 PM 의사결정
• 특강+Q&A 정리
  → 특강) PM의 데스크 리서치 : 정보의 편린에 휩쓸리지 않고 판을 읽는 법
• 아티클 카타
  → 아티클 카타) 커머스 사례로 보는 인풋 지표와 아웃풋 지표
• 정보처리기사 실기 공부(D+38)

 

---

 

오늘의 퀴즈 정리
-

우선순위 설정 프레임워크 + 역기획과 PM 채용의 이해

 

 

1. 우선순위 설정 프레임워크

◾MoSCoW : 기능을 중요도에 따라 분류하는 방법

구분	의미
Must Have	반드시 필요한 기능
Should Have	중요하지만 필수는 아님
Could Have	있으면 좋음
Won't Have	이번 릴리스에서는 제외
→ 무엇을 할 것인가보다 무엇을 하지 않을 것인가를 정하는 것도 중요하다.

 

◾Kano 모델 : 고객 만족도 관점에서 기능을 분류하는 방법

유형	설명
기본 요소	없으면 불만
성능 요소	좋아질수록 만족 증가
매력 요소	없어도 불만 없음, 있으면 만족도 급상승
무관심 요소	있어도 관심 없음
역품질 요소	오히려 불만 발생
→ 매력 요소(Delighter)는 서비스 차별화 포인트가 될 수 있다. ex. Spotify의 개인화 추천 / Netflix의 추천 알고리즘

 

◾Value vs Effort : 기능 가치와 구현 난이도를 함께 고려해 우선순위를 판단하는 방식

/	낮은 난이도	높은 난이도
높은 가치	Quick Wins	Major Projects
낮은 가치	Fill-ins	Time Sinks
→ 높은 가치 + 낮은 난이도 = 최우선

 

◾ICE : 기능 우선순위를 점수화하는 방법

요소	의미
Impact	영향도
Confidence	확신도
Ease	구현 용이성
ICE = (Impact + Confidence + Ease) ÷ 3 → 빠르게 여러 아이디어를 비교할 때 유용

 

◾RICE : ICE를 확장한 방식

요소	의미
Reach	영향받는 사용자 수
Impact	영향도
Confidence	근거 수준(실제 데이터와 근거가 얼마나 있는가)
Effort	필요한 리소스
→ RICE는 직관보다 데이터와 근거 기반 의사결정을 지향한다.

 

2. 역기획?

• 서비스를 거꾸로 분석하는 과정
  → 단순히 '기능이 좋다'가 아니라, '왜 만들었을까?'를 추론하는 작업

◾역기획 시 확인하는 것

분석 대상	확인 내용
문제 정의	어떤 문제를 해결하려고 했는가
사용자 가치	어떤 편익을 제공하는가
비즈니스 전략	왜 이 기능이 필요한가
UX 설계 의도	왜 이런 흐름으로 만들었는가
비즈니스 임팩트	어떤 성과를 기대하는가

3. PM 채용에서 역기획 과제를 내는 이유

• PM은 개발자나 디자이너처럼 눈에 보이는 결과물보다 PRD, 로드맵 등 문서 형태의 산출물이 많은 편이다.
  → so, 기업은 결과보다 사고 과정 자체를 확인하려 한다.

◾기업이 보고 싶은 것

평가 항목	확인 내용
문제 정의 능력	문제를 제대로 찾는가
사용자 이해	고객 관점으로 생각하는가
전략적 사고	비즈니스 관점이 있는가
논리적 사고	근거를 가지고 설명하는가
우선순위 판단	무엇을 먼저 해야 하는지 아는가

4. 토스 PO JD와 연결되는 역기획

• 문제 정의 → 비전 → 전략 → 비즈니스 임팩트
  ⤷ PM의 사고 흐름 : 문제 발견 → 문제 정의 → 비전 수립 → 전략 수립 → 기능 기획 및 설계 → 비즈니스 임팩트
  ⤷ ex. 왜 만들었는가? → 어떤 문제를 해결하는가? → 왜 이런 방식으로 설계했는가? → 어떤 성과를 기대했는가?

 

---

 

오늘의 인사이트

 

특강과 아티클 카타를 포함하여 오늘 진행한 활동을 종합해서 보자면

'판단 기준'에 대한 이야기들이었다.

 

특강에서는 정보의 편향된 내용만 보지 말고 전체 판을 읽어야 한다고 했고,

아티클에서는 결과 지표보다 인풋 지표를 먼저 봐야 한다는 내용이 기억에 남는다.

(인풋 지표와 아웃풋 지표를 쪼개는 과정이 약간 마인드맵 같기도 하고,

상위 지표와 하위 지표가 연결되는 모습은 SQL에서 PK와 FK 관계를 보는 느낌도 들었다.

에러가 발생했을 때 로그를 따라가며 원인을 찾는 과정이 제일 흡사하지 않나 싶은데,

결과가 아니라 그 결과를 만든 원인을 계속 추적해 들어간다는 점에서 비슷한 느낌이었다.

빨간 글자 PTSD...)

 

우선순위 프레임워크도(이렇게 많은 줄 몰랐다)

MoSCoW, Kano, RICE 같은 기준을 활용해 왜 먼저 해야 하는지 설명할 수 있어야 했다.

(후... 어렵다 / 요즘 단 게 땡기는 이유가 PMS인 줄 알았는데 아닐 수도)

 

역기획도 단순한 기능 나열이 아니라, 그 기능이 왜 만들어졌는지, 어떤 문제를 해결하려 했는지,

어떤 비즈니스 임팩트를 기대했는지까지 추론하는 과정에 가까웠다.

(물음표 살인마라 불렸던 나도(농담) 주춤하게 되는 물음표의 향연...

사실 이론적으로만 그런가 보다 했지, 실제로 해봐야 체감이 되고 반복적으로 진행해야 체화될 것 같다)

 

그래서 앞으로는 결과보다 원인을, 기능보다 의도를,

정보의 일부보다 전체 흐름을 먼저 보려는 습관을 만들어야겠다고 느꼈다.

 

 

오늘을 마무리하는 한 마디

-

어려워도 좌절하지 말자...!

하다 보면 늘게 돼 있다!

 

 

---

 

오늘의 KPT 회고

 

Keep	• 특강, 아티클, 퀴즈 내용을 따로 학습하지 않고 하나의 관점으로 연결해 이해하려 한 점 • 기능 자체보다 '왜 만들었는가'를 먼저 생각하며 역기획 관점으로 접근하려 한 점(but, 아직 잘 모르겠음)
Problem	• 우선순위 프레임워크(MoSCoW, Kano, ICE, RICE 등)의 차이와 실제 적용 기준은 아직 익숙하지 않음 • 인풋 지표와 아웃풋 지표를 분해하는 사고는 이해됐지만, 실제 서비스에서 어떤 지표를 어디까지 쪼개야 하는지는 경험이 더 필요함 • 역기획도 아직은 기능 의도를 추론하는 과정이 익숙하지 않아 실제 서비스 분석 경험이 더 필요함
Try	• 결과 지표를 보면 한 단계씩 원인을 거슬러 올라가며 인풋 지표를 추적하는 연습하기(과연 얼마나 쪼개야 만족스러운 결과가 나올 것인가...) • 앞으로 진행할 경쟁사 분석에서도 기능 나열보다 문제 정의 → 전략 → 비즈니스 임팩트 흐름으로 분석해보기