부트캠프 50일차 : 역기획 끝

🎯 오늘의 과제

과제명: [Chapter.4-1] 역기획 프로젝트

---

📌 목표

해결하려는 문제: 배달의 민족 : 성장을 견인할 전략 제안
달성 목표

• 필수 : 수익성 강화
• 선택 : 퀵커머스 + 멤버십 강화

🔍 배경

왜 이 과제가 필요했는지

• 많은 IT 기업이 입사 시 역기획 과제 제출을 요구
• 면접에서도 자사 프로덕트의 문제점과 개선점을 묻는 질문은 필수적으로 등장

기대하는 결과

• 논리적 사고력, 문제 해결력, 기획안 구성 능력을 종합적으로 점검
• 통찰력 ⇒ ‘왜 이 구조인가?’ 본질적인 문제
• 차별성 ⇒ 벤치마킹하되 고유한 관점, 새로운 접근
• 기여도 ⇒ 현실적이고 합리적 / 중~장기 관점도 고려

💻 작업 과정

일차	항목	진행도	문제점	해결 방안
1	비즈니스 방향 확정 · 문제 도출	100%	설문 모수 부족	변경 (이탈 이유)
1	17시 : 1차 피드백	50%	비즈니스 방향성 피벗	전반부 폐기
2	문제정의, 페르소나 + 가설	100%	내가 잘 팔로우 중인가?	계속 들어갔다가 나왔다가..
3	전략설계, KPI (기대 + 리스크)	100%	싱크 불일치	PRD에 지표 관련 안내
3	12시 : 2차 피드백	50%	비즈니스 방향성 피벗	전반부 폐기
4→6	발표 스토리 라인 + 완성	100%	PPT와 병행	발표자에게 전권 이임
4	11시 : 3차 피드백	50%	비즈니스 방향성 피벗	전반부 폐기
4→5	15시 : 발표 시뮬레이션	50%	수정으로 인한 PPT 작업X	전반부만 리허설 진행
5	최종검수 + PDF 제출	100%	후반부 PPT 작업 X	줌으로 거의 동시 진행
6	11시 : 튜터 참관 리허설 예정	100%	4050 유저를 너무 늙게 봤다	배민 성장 과정 어필로 전환

💡 인사이트

✨ 오늘 배운 것

기술적 인사이트

• 킥오프 단계에서 MSCN과 MoSCoW를 함께 사용하면, 단순한 목표 공유를 넘어 “이번 프로젝트에서 무엇을 반드시 하고, 무엇을 과감히 버릴지”에 대한 팀의 합의 수준을 빠르게 끌어올릴 수 있다.
• 워크플로우 DB 보드는 단순한 작업 관리 도구가 아니라, 역할 간 사고 흐름을 시각적으로 연결하는 장치로 기능한다. 특히 리드→팔로우 전환 구조를 실험할 때, 이 보드가 없었다면 역할 간 맥락 공유 비용이 훨씬 컸을 것이다.
• 슬랙 활용 규칙(단체 DM 최소화, 정보의 공개 채널화)은 초반에는 답답하게 느껴질 수 있으나, 프로젝트 후반으로 갈수록 검색 비용과 커뮤니케이션 피로도를 실질적으로 낮춘다는 점을 확인했다.

PM 사고 확장

• PM의 업무를 팀 단위로 나눌 때, 단순히 역할 명칭을 쪼개는 것만으로는 부족하며 각 역할의 ‘종료 조건(산출물)’이 명확히 정의되지 않으면 오히려 혼란을 키운다는 점을 체감했다.
• 리드 역할이 끝난 뒤 팔로우 역할로 자연스럽게 전환되면 공유 리소스가 줄어들 것이라 가정했으나, 이는 팀장 본인에게는 명확했지만 팀원 전원에게는 동일하게 인식되지 않았다. 구조는 의도만으로 작동하지 않는다는 것을 배웠다.
• 팀장의 역할은 모든 판단을 대신하는 것이 아니라, 팀원이 판단할 수 있도록 근거·맥락·경계를 정리해 주는 일이라는 점을 실제 프로젝트 안에서 경험했다.

🔄 개선 사항 & 한계점

🚧 아쉬운 점 3개

팀원 의견

• “업무 범위(해야 할 일 / 하지 않아도 되는 일)가 완전히 명확하다고 느끼진 않았다.”
• “업무 요청 시 배경과 맥락 정보가 함께 주어지면 더 효율적이었을 것 같다.”
  이유 : PM이 혼자 수행하던 업무를 억지로 5명에게 분배하는 과정에서, 역할 명칭은 있었지만 각 역할에서 반드시 나와야 하는 산출물과 종료 신호를 충분히 구체화하지 못했다. 이로 인해 특히 문서화 단계에서 수정 요청이 반복되며 일의 양과 판단 부담이 동시에 증가했다.
  개선 방향
• 역할 정의 시 “이 역할이 끝났다고 판단하는 기준은 무엇인가?”를 문서로 명시하기
• 요청 전 정리해서 알리기 : 지금 상황이 왜 생겼는지, 이 판단의 기준은 무엇인지, 이 요청이 전체에서 차지하는 위치
• 질문을 유도하는 구조보다 질문이 필요 없게 만드는 문서/맥락이 더 중요할 때도 있음을 명심하기

팀원 의견

• “팀원의 말을 끝까지 듣지 않고 중간에 끊는 느낌을 받은 적이 있다.”
• “의사결정의 방향은 이해됐지만, 맥락 설명이 더 있었으면 좋았을 상황도 있었다.”
  이유 : 시간 압박 속에서 효율을 우선하다 보니, 결론 중심으로 커뮤니케이션을 당기는 순간들이 있었고, 그 과정에서 팀원이 사고를 전개하던 흐름을 충분히 받아주지 못한 장면이 있었다.
  개선 방향
• 판단이 급할수록 의사결정 이전 30초를 ‘맥락 정리’에 의도적으로 투자하자
• “왜 이 결정을 하는지”를 먼저 말하고 요청 사항을 전달하는 습관화하자
• 타인의 말을 끊는 습관을 고치자
• 다음 그라운드 룰에서 넣을 부분 : 지금 단계에서 검증하지 않는 가설, 이번 주간에 만들지 않는 산출물, 각 역할이 책임지지 않아도 되는 영역
• 내가 어떤 관점 안에서 판단하고 있는지 팀원에게 알린 뒤 생각을 듣자

🚀 다음 액션

📝 단기 성장가능성 + 튜터 피드백 아카이빙

• 워크플로우 DB를 프로젝트 초반(문제 정의 이전)에 먼저 구축하고, 역할별 이동 경로를 시각화한다.
• 와이어프레임을 결과 단계가 아니라 사용자 여정마다 분해하여 제시하는 방식으로 개선한다.
• 가설 설정 과정을 해결 방안에 자연스럽게 녹여, “왜 이 기능인가?”가 문서 안에서 자동으로 설명되도록 구조를 재설계한다.
• 국내 레퍼런스에 한정하지 않고, 글로벌 사례를 기준점으로 삼아 판단의 스케일을 넓힌다.

📌 한 줄 요약

오늘의 핵심: PM 역할을 구조적으로 나누는 것은 가능하지만, 구조는 ‘의도’가 아니라 ‘명시성’으로 작동한다.
성장 포인트

• 팀 단위 PM 역할 분해 실험
• 리드와 팔로우 구조의 실제 한계 인식 : 업무 과중
• 판단·중단·조율까지 포함한 PM 경험 축적

🧭 튜터 피드백 기반 사고 정제

킥오프 설계에 대한 재정의

• 킥오프는 ‘그라운드룰 공유’가 아니라, 기획서의 삽을 뜨는 순간에 해당한다. 즉, 어떤 목적과 목표를 가지고 어떤 핵심 지표를 기준으로 어떤 데이터에서 어떤 가설까지 도출했으며 그 결과 어떤 와이어프레임/해결 방향을 보려는지
  를 공유하고 의견을 조율하는 자리에 가깝다.
• 내가 진행했던 MSCN 정리, 역할 분배, 협업 규칙 설정은 킥오프라기보다는 그라운드룰 세팅에 해당한다.

현업 기준에서의 보완점

• 그라운드룰은 더 심플해야 한다 (5개 이하)
• MSCN은 규칙에서 출발하기보다, 지표가 목표가 되면서 자연스럽게 도출되어야 한다
• 목표 → 지표 → MSCN → 역할의 흐름이 한 번에 보였어야 했다
  정리된 인식
  나는 ‘잘 준비된 킥오프’를 목표로 했지만, 실제로는 킥오프 이전 단계의 준비를 정교하게 한 상태에 가까웠다.
  다음에는 “이번 프로젝트에서 어떤 지표를 성공으로 볼 것인가”를 가장 먼저 두고 그 이후에 MSCN과 역할을 최소 단위로 정리하는 방식을 사용해야겠다.

리드/팔로우 역할 분리 구조에 대한 평가

• 의도에 대한 평가 : 직무스터디 당시 KPT(무의미한 회의 반복, 수정 공수 과다)를 바탕으로 역할을 분리하고 흐름을 단순화하려 했던 문제 인식과 시도 자체는 타당하다. 특히 이전 경험에서 발생했던 워터폴식 분업, 최종 단계에서의 의도 붕괴, 발표 자료 수정 회의 장기화 를 줄이기 위한 설계였다는 점은 명확하다.

• 한계로 지적된 부분 : 문제정의는 PM(팀장), 디자인은 디자이너의 책임으로 두고 나머지 영역은 전원이 참여해 논리를 합의하는 과정이 필요했다. 역할을 과도하게 분리하면서 일부 팀원에게는 사고 참여의 기회가 줄어들 수 있고 결과적으로 포트폴리오나 면접에서 “왜 그렇게 설계했는지” 설명하지 못하는 리스크가 생길 수 있다. 회의는 비효율의 원인이기도 하지만, 동시에 내가 생각하지 못한 더 나은 판단을 발견하는 장치이기도 하다.

정리된 인식

• 리드/팔로우 구조는 문제를 줄이기 위한 구조였지만, 학습과 사고 확장의 측면에서는 제약이 있었다. 다음에는 역할을 나누더라도, 각 핵심 판단 구간에서는 전원이 사고에 참여하는 지점을 의도적으로 설계해야 한다.

역할별 산출물 및 작업 종료 신호에 대한 피드백

• 하루 회고 및 팔로업 방식 자체는 적절했다. 사전 작성 → 구두 확인 → 다음날 리마인드 → 노션 기록까지의 흐름은 명확했다.
• 다만, ‘완료도’가 아니라 ‘진행도’가 보였어야 했다. 오늘의 %는 “끝났는가”가 아니라 “어디까지 왔는가”를 보여주는 지표여야 한다.
• 이슈 하나에 공수가 과도하게 소요될 경우, PM이 가드레일을 치고 종료 사인을 줘야 했다.
  정리된 인식
  나는 종료 사인을 ‘구두’로는 주었지만, 산출물 기준으로 명확하게 시각화하지 못했다. 그 결과 문서 수정 → 디자인 수정 요청이 반복되었고 일부 팀원은 “아직 끝난 게 아닌가?”라고 인식했을 가능성이 높다.
  다음 기준
• 역할 정의 시 반드시 포함할 것 : 산출물 형태 최소 기준, 다음 단계로 넘어가는 명확한 조건
• 회고 시 완료 여부(X/O)가 아니라 진행 구간(예: 60%, 논리 확정 / 표현 미완)을 표시한다.

✨추가 인식 정리

• 이번 프로젝트를 통해 지표 설계 → MSCN 도출 → 구조 설계라는 흐름이
  PM에게 얼마나 중요한지 인지했다.
• 특히 전환율과 같이 데이터가 풍부한 커머스 도메인을 통해 앞으로 지표 중심 사고로 킥오프를 설계하는 연습이 필수가 될 것이다.