팀스파르타 PM과정 (24)

데일리 아티클 / 특강 / 튜터님 대면 피드백

---

데일리 아티클 

1. 아티클 정보

• 제목 : 우선순위 설정 그거.. 어떻게 잘하는 건데? (링크)
• 작성자(저자) : 팁스터

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : “글의 핵심 논지나 전달하고자 하는 메시지를 명확히 정리해 보세요.”
• 핵심 키워드 : 우선순위 설정, 백로그, 구조화, 아사나

3. 흥미로운 점/새롭게 알게 된 점

• 읽으면서 가장 흥미로웠던 부분 : 
  • 폭넓은 프레임워크 찾기 MoSCaW, Kano, RICE, ICE 기법
  • 백로그는 공통 할일 목록은 아니다 
  • 우선순위 결정에 필요한 항목은 되도록 일정한 양식을 적용하기 
    
    • MoSCaW기법
    • Must have : 프로젝트, 제품에 있어 반드시 필요한 기능을 의미
    • Should have : 중요하지만 시급성이 Must have 대비 낮은 기능
    • Could have : 있으면 좋지만, 꼭 있어야 할 필요는 없는 기능
    • Won’t have : 가장 덜 중요하고, 효과도 미미한 기능
      
      
    • RICE 기법
    • Reach : 얼마나 많은 수의 사용자에게 영향이 미치는지
    • Impact : 고객에게 선보였을 때 전환율을 얼만큼 높일 수 있는지
    • Confidence : 내가 측정한 R, I, E의 값에 얼마나 자신이 있는지(예, 구체적인 증거가 있다면 도움이 됨)
    • Effort : 이를 수행하는데 있어 드는 노력이 얼마나 클지 (시간, 인력)
    • RICE 점수는 = R * I * C / E 
      
    • ICE 기법
    • Impact : 이 실험이 얼마나 영향력 있을까? 회사의 핵심 KPI에 얼마나 많은 영향을 미칠지 측정하는 요소
    • Confidence : 이 실험이 성공할 확신을 얼마나 가지고 있는지?
    • Ease : 이 실험을 론칭하는데 시간이 얼마나 걸리는지?
    • 각 요소별 10점을 만점으로, 총 합점이 ICE점수
  • 스스로에게 묻기 / 팀에게 묻기 / 수백개의 백로그 앞에서서 질문에 대한 답을 요구하기 
  • 해결하려는 문제 / 누구를 위해 해결하려 하나 / 원하는 결과가 무엇인가 / 
  • 우선순위를 정하는 과정도 결과못지않게 중요하다 
  • 진짜일 : 우리의 핵심지표에 영향을 주는것 VS 가짜일 : 핵심지표와 관련이 없는 것
  • 최우선적인것은 항상 목표를 명확히 할것 
• 이전에는 알지 못했거나 새롭게 배운 내용 : 
  
  • 하나의기준을 정해도 적절하지않다면 반복적인 회의와 고민을 통해 가장 적절한 방향이나 기준을 꾸준히 탐색한다
  • 가장 돈을 많이 받는 사람의 의견이 의사결정에서 절대적인 역할을 하면 안된다라는 대목에서 웃었다 모두가 알고있지만 가장 실천하기 어렵다는 것도... C레벨의 지침을 어떻게 무시할것인가 
  • 다양한 회사의 여러가지의 업무 스타일을 가지고있는 PM들의 경험담이 포함되어있는 아티클
  • 팀에서 제일 중요한것은 전사이던 하나의 부서이던 또는 가장 작은 팀이던 모두가 같은 내용을 알고 동일한 이해를 하고있는 것이라는 생각이 들었다. 우선순위를 설정하는 기준이나 작성하는 양식, 더 나아가 우선순위 설정을 위해 기반이 되는 핵심 목표까지 모두가 같은 이해를 갖추고 있어야 가능한 일인것같다 

4. 나의 한 문장 요약

• 이 아티클을 한 문장으로 요약하면? “다양한 현직자들의 우선순위 선정 꿀팁.”

---

과제 우수사례 특강 

데이터를 통해 문제 데이터를 분석 ->  인사이트 발굴 -> 문제 정의 -> “나는 여기 어떤 가설을 세워야 되지?”-> “우리는 어떤 걸 검증해야 되지?” -> 검증 -> "나는 이게 우리 서비스나 플랫폼의 문제점에 대한 해결 방안이라고 생각해” -> 유저에게 가치를 줄 수 있는 서비스가 무엇인지 찾는 것

어떤 기준을 가지고 이렇게 분류했고, 이걸 시각화해서 한눈에 보여주게 해놓기 

다른 사람이 아무것도 모르는 상태에서 봐도 이해가 될 정도로 요약을 해 주시는 게 베스트

본인만의 기준을 가지고 이 내용들을 다시 재가공해서 본인이 하고자 하는 말에 논리를 부여했다는 점

카테고리 - 대표 리뷰 - 주요문제 현상 - 서비스 영향 분류 

 

데이터에서 어떤 문제 정의를 가져오셨고, 이 문제 정의를 가지고 어떻게 다음 논리를 펼쳐가셨느냐가 중요한 포인트

문제 정의를 제시할 때는 “내가 어떤 데이터를 가지고, 이것 때문에 이런 의미여서 이렇게 가져온 거다”라는 내용이 담겨 있어야 하나의 논리가 완성

고객 관점과 비즈니스 관점에서 너무 정확하게 분석

흐름이 되는 스토리 텔링

문제 정의를 하실 때 이런 식으로 파고들 데 없는 내용들을 꼼꼼하게, 빠짐없이 정리하는 것

 

가설에 내용이 너무 명확하게 다 들어가 있어요.

AI 기반 설계 >  의도 보정 = 검색 결과의 정확도를 높이기

"검색 결과 구조를 개편했어요”라고 이력서에 적으려면, 내가 검색 결과 구조의 어떤 부분을 어떻게 개편했는지를 써야함

내용을 쓸 때 구체화되어 있어야 한다

 꼬리질문이 없을정도로 상세하게 문서화해야한다

 

문답 :

Q. 얼마나 상세해야하나요? 

A. 일단은 다 적어두세요. 왜냐하면 고민을 많이 하면 할수록 줄일 수 있는 내용들이 많이 나오거든요. 그리고 그 내용들을 가지고 “이 내용을 한마디로 요약할 수 있는 게 무엇인가

 

Q. 문서화할 때 순서의 모든 내용을 먼저 작성하고, 마지막에 내용을 요약하되, 자료의 순서만 요약본을 앞에 제시하고 시작해도 되는지

A. 이건 요약의 목적에 따라 달라요. 요약을 통해 “내 과제한 내용을 미리 프리뷰해 주겠다”가 목적이면 앞에 있는 게 맞고요. “나는 지금까지의 내용을 마지막에 한 번 정리해 주는 목적이다”라고 생각하시면 마지막에 들어가도 전혀 관계없습니다. 원하는 목적에 따라 선택하시면 됩니다.

---

대면 피드백

준비한 질문

• 과제를 진행할때 일차적으로 사전 지식이 없는 채로 리뷰데이터를 먼저 분석하고, 이후 데스크리서치를 통해 현재의 이슈를 확인한다음 목표정의를 하고 문제정의를 하고 가설설정 다음에 우선순위를 분석한 흐름으로 진행해서 과제의 흐름 정리가 힘들었었다 일부러라도 제시된 흐름대로 진행하는 것이 맞을까
  > 자연스럽고 센스 있는 현상입니다. 문제를 분석하다 보면 해결책이 먼저 떠오르는 것은 지극히 자연스러운 일이며, 오히려 아이디어가 떠오른다는 것은 기획적 감각이 있다는 증거입니다.
  단, '답정너'는 경계해야 합니다. 대략적인 방향성을 정해두는 것은 좋지만, "무조건 이 해결책으로 간다"라고 결론을 지어버리면 안 됩니다. 결론을 미리 내리면 중간에 발견하는 객관적인 리서치 결과나 근거들을 무시하고, 내 결론에 맞는 근거만 끼워 맞추게 되는 치명적인 오류를 범할 수 있습니다. 항상 "이 결론이 정답이 아닐 수 있다"는 마인드셋을 가져야 합니다
• 자료를 얼마나 상세히 작성해야할까
  리뷰분석때 사용한 해시태그 형 분류는 분류와 점수계산에서만 사용하고 전문을 첨부하지않음
  > 아주 잘한 선택입니다. 실제 실무형 기획서나 보고서에는 로우 데이터를 그대로 넣지 않는 것이 일반적입니다.
  규모가 있는 회사에서는 데이터 분석가(DA)가 이상치를 제거하고 정제된 데이터를 제공하며, PM은 이렇게 가공된 데이터를 바탕으로 기획을 진행합니다. 따라서 지금처럼 분석의 결과물(가중 점수 등)만 깔끔하게 정리해서 보여준 것이 올바른 판단이었습니다.
• 비즈니스적 고민을 어디까지 해야하나
  아이디어의 실현 가능성이나 구상단계에서 충분히 리스크를 떠올릴수있다면 허황된아이디어 일까
  > 비즈니스 관점의 고민은 깊을수록 좋습니다. 프로젝트는 항상 회사의 비즈니스 목표(예: 리텐션 증가)에 맞춰야 합니다.
  버리지 말고 '백로그(Backlog)'에 저장하세요. 고민하다 보면 기획 단계를 넘어선 운영 단의 문제나 C레벨이 결정해야 할 큰 문제들이 보일 수 있습니다. 당장 리소스가 없거나 권한 밖의 일이라도 그 아이디어들을 버리지 말고, 노션이나 지라(Jira) 같은 곳에 아카이빙(백로그) 해두세요. 나중에 리소스가 확보되었을 때 활용하거나, 관련된 유관 부서(마케팅 등)에 의견을 전달할 때 아주 유용하게 쓰입니다.
• 사실 강조하고 싶었던 해결책은 AI 개선이었지만 우선순위로는 혜택으로 꼽혀져서 위의 우선순위와 아래의 해결책의 순서가 상이했는데 문서의 흐름상으로는 문제 해결 우선순위와 해결방안이 일정해야한다는 것을 알고있지만 내세우고 싶거나 진행하고 싶은 가설이 후순위일때 어느쪽에 무게를 두어야하는지 고민
  > 철저히 객관적인 근거를 따라야 합니다. 주관적인 판단으로 우선순위를 조정했다가 프로젝트가 실패하면 그 책임은 오롯이 PM에게 돌아가기 때문입니다.
  가중치(Weight)를 활용하세요. 만약 회사의 현재 전략상(예: 무조건 신규 유저 확보) 특정 과제를 꼭 밀어야 한다면, 매트릭스의 기준에 '가중치'를 부여하는 프레임워크를 사용하세요. 예를 들어 'Impact' 점수에 1.5배의 가중치를 곱하여, 객관적인 수치로 해당 과제가 상단으로 올라오도록 설계해야 설득력을 얻을 수 있습니다.
  > 의도치 않은 기능의 흥행은 '회사의 비전'에 따라 대응이 다릅니다.
  유저가 특정 기능을 좋아하더라도, 회사가 투자자들에게 약속한 비전(예: "우리는 AI 커머스로 간다")이 확고하다면, 당장의 유저 반응보다 비즈니스 전략과 외부 제약에 맞춰 원래 의도한 핵심 기능을 우선적으로 키우게 됩니다. 부정적인 리뷰를 중심으로 과제를 진행했는데 사실 진행하면서 긍정적인 리뷰를 신경이 쓰였는데 쿠팡사태이전부터 네이버를 사용하고 있던 사람들과 다른 서비스가 아닌 이 서비스를 선택하여 사용하는 사람들의 리뷰도 신경을 써야하는지 아니면 실무적으로는 페인포인트 개선을 위주로 고려하는지
  > 정석 : 긍정리뷰는 강화 , 부정리뷰는 개선 
  실무에서는 둘 다 보는 것이 맞습니다. 보통 테스트 결과가 좋으면 유저들이 좋아하는 점(긍정)을 강화하고, 결과가 나쁘면 페인포인트(부정)를 해결하는 쪽으로 선택합니다. 이번 과제에서는 부정 키워드가 뚜렷했으므로 이를 먼저 해결한 것이 적절했습니다.
• 긍정리뷰가 의도하지않은 기능이었을때 우선순위가 바뀔까?
  > 의도치 않은 기능의 흥행은 '회사의 비전'에 따라 대응이 다릅니다. 유저가 특정 기능을 좋아하더라도, 회사가 투자자들에게 약속한 비전(예: "우리는 AI 커머스로 간다")이 확고하다면, 당장의 유저 반응보다 비즈니스 전략과 외부 제약에 맞춰 원래 의도한 핵심 기능을 우선적으로 키우게 됩니다
  > 비즈니스 목표
  > 대표자 입장 : 자생적인 성장보다 투자자들이 요구하는 방안쪽으로 흘러간다 
• 과제를 AI에 내생각과 자료들을 넣어가며 진행했는데 중간중간에 생각나는것을 마구잡이로 집어넣은 편이라 시간이 지날수록 놓쳤던 아이디어나 흐름이 있었다 생각의 흐름을 어떻게 정리하는 것이 좋을까
  > 백로그(Backlog) 페이지'를 만드는 업무 습관을 들이세요. 노션 등에 아이디어 테이블을 하나 만들어 두고, "지금 당장 할 수는 없지만 나중에 보면 좋을 것들", "작업 중 스쳐 지나간 좋은 인사이트" 등을 그때그때 기록(아카이빙)해 두는 것이 좋습니다.
•  “왜 네이버플러스 스토어는 쿠팡의 강력한 대체제로 인식되지 못하는가" 가 초기의 문제정의였는데 
  경쟁사와 차별점있는 서비스 제공으로 네이버 쇼핑에서 최종 결제까지 가지 못하고 이탈하는 문제를 해결한다.로 변경했었다 기존의 문제정의도 문제정의가 될수있을까
  > 네, 아주 좋은 문제 정의가 될 수 있습니다. 단, 전제 조건이 있습니다. "쿠팡은 리텐션이 90%인데 우리는 70%다"라는 식으로, 타당하고 객관적인 지표와 근거가 반드시 바탕이 되어야 합니다. 근거만 탄탄하다면 경쟁사를 벤치마킹하고 문제의 원인을 파고드는 것은 매우 훌륭한 접근 방식입니다.

 

튜터님의 피드백 총정리

서면 피드백과 대면(녹음) 피드백을 종합하여, 지원 님의 기획안에서 빛났던 강점과 앞으로 디벨롭해야 할 포인트를 정리했습니다.

👍 칭찬받은 강점 (Keep)

• 스마트한 데스크 리서치 활용: 리서치 내용을 앞단에 몰아넣지 않고, 주장을 뒷받침하는 근거로 중간중간 적절히 배치한 점은 실무적으로 아주 훌륭한 스킬입니다.
• 깔끔한 시각화와 지표 설정: 리뷰 데이터를 깔끔하게 시각화(가중 점수 등)한 점, 그리고 핵심 지표와 가드레일 지표를 나누어 세밀하게 설정한 점이 매우 돋보였습니다.
• 비즈니스적 사고와 리스크 예측: 문서 전반에 비즈니스 목표가 잘 녹아있으며, 가설 하단에 부작용(리스크)을 미리 예측하여 기재한 점은 PM으로서 아주 좋은 시각입니다.

💡 한 끗 차이를 만드는 보완점 (Action Item)

• 우선순위 산정의 객관성 확보: 배송을 '중장기 과제'로, 혜택/AI를 '낮은/중간 리소스(Effort)'로 판단한 명확하고 객관적인 근거(예: 관련 아티클 추가 등)가 필요합니다. 실제 실무에서 개발자의 리소스는 항상 부족하므로, 에포트(개발 공수)는 생각보다 더 보수적으로(높게) 잡는 것이 좋습니다.
• 리스크에 대한 구체적인 대응책(Action Plan): "토큰 비용 증가", "할루시네이션" 등의 리스크를 찾은 것은 훌륭합니다. 여기서 한 발 더 나아가 "어떻게 검증하고 해결할 것인지(예: 타 조직과의 협업 방향 등)" 구체적인 대응 방안까지 한 줄 덧붙이면 100점짜리 기획서가 됩니다.
• 정량적인 목표 수치 제시: 진입률 상승, 이탈률 감소 등의 지표를 적을 때 "현재 몇 %인데, 몇 %까지 개선/방어하겠다"는 구체적인 정량적 수치를 고민해 보면 좋습니다.

---

2. 질문 & 답변 (Q&A) 핵심 정리

📍 [흐름과 데이터] 과제 진행 방식에 대한 고민

Q. 로우 데이터(리뷰 전문)를 다 넣지 않고, 가공된 해시태그 점수만 넣었는데 괜찮은가요?

• A. 아주 잘한 선택입니다. 실무에서도 로우 데이터를 기획서에 전부 넣지 않습니다. 데이터 담당자가 정제해 준 데이터를 바탕으로 기획을 전개하는 것이 일반적이므로 깔끔하게 요약한 현재 방식이 맞습니다.

Q. 분석 -> 리서치 -> 가설 -> 우선순위 등 정석적인 흐름을 벗어나서 생각이 튀었는데 괜찮은가요?

• A. 자연스러운 현상이며 센스가 있다는 증거입니다. 문제를 보다 보면 해결책이 먼저 떠오르는 것은 당연합니다. 단, '답정너'식으로 미리 결론을 내리고 거기에 근거를 끼워 맞추는 것은 논리적 오류를 범할 수 있으므로 절대 주의해야 합니다.

• 📍 [비즈니스와 우선순위] PM의 의사결정

  Q. 실현 가능성이 낮거나 리스크가 큰 아이디어(운영/C레벨 이슈)는 허황된 것이니 바로 접어야 하나요?

  • A. 버리지 말고 '백로그(Backlog)'에 저장해 두세요. 당장 리소스가 없어서 못 하는 좋은 아이디어들은 노션이나 지라(Jira) 등에 아카이빙해두고, 추후 리소스가 생기거나 유관 부서(마케팅 등)에 전달할 때 활용하면 됩니다.

  Q. 객관적 데이터(혜택이 1순위) vs 내 개인적 기획 욕심(AI 개선을 먼저 하고 싶음) 중 무엇을 따라야 하나요?

  • A. 철저히 객관적 데이터를 따라야 합니다. 주관적 판단으로 진행했다가 프로젝트가 실패하면 오롯이 PM의 책임이 됩니다. 만약 특정 과제를 우선하고 싶다면, 현재 비즈니스 목표에 맞춰 우선순위 매트릭스에 가중치(예: 리텐션이 급하므로 Impact에 1.5배 가중치 부여)를 설정하여 객관적으로 끌어올리는 방식을 사용하세요.

  📍 [리뷰 분석] 긍정 vs 부정의 딜레마

  Q. 부정 리뷰 위주로 분석했는데, 긍정 리뷰(왜 네이버를 계속 쓸까?)를 분석하는 것도 필요할까요?

  • A. 둘 다 보는 것이 맞지만, 이번 과제에서는 부정(페인포인트) 해결이 우선입니다. 실무에서는 테스트 결과에 따라 부정을 고칠지, 긍정을 강화할지 결정합니다.

  Q. 만약 회사가 의도하지 않은 기능이 긍정 리뷰를 받는다면 우선순위가 바뀌나요?

  • A. 회사의 비전과 투자자의 요구에 따라 다릅니다. 유저가 다른 기능을 원해도 회사가 'AI'로 투자를 받았다면 AI를 밀어붙여야 하는 등 외부 제약과 비즈니스 목표에 따라 유동적으로 변합니다.

  📍 [생각 정리와 문제 정의] 기획자의 습관

  Q.  쏟아지는 생각과 아이디어들을 놓치게 되는데 어떻게 정리하나요?

  • A. '백로그' 페이지를 만드는 습관을 들이세요. 노션 등에 표를 만들어 당장 쓸 수 없는 아이디어, 번뜩이는 인사이트 등을 꾸준히 기록해 두는 것이 좋은 업무 습관입니다.

  Q. "왜 쿠팡의 대체제로 인식되지 못하는가"처럼 경쟁사를 대놓고 저격하는 문제 정의도 괜찮은가요?

  • A. 아주 좋은 문제 정의입니다. 단, "쿠팡은 리텐션이 90%인데 우리는 70%다"라는 식의 타당하고 객관적인 지표(근거)가 반드시 뒷받침되어야 합니다. 근거만 탄탄하다면 경쟁사를 벤치마킹하는 문제 정의는 훌륭한 시작점이 됩니다.