과제 발표일
프로젝트 개인 회고
STEP 1. 프로젝트 핵심 요약
프로젝트명
BATONG - 인수인계 시스템 MVP 프로젝트
나의 역할
- 에듀테크 B2B 도메인 선정 및 기획 주도
- 사용자 리서치 설계 및 실행 (인수자 47명, 피인수자 36명 설문 조사)
- 기획명세서(PRD) 및 기능명세서 작성
- 경쟁사 분석 및 시장 기회 발굴
- 타겟 페르소나 정의 및 가설 수립
- 발표 PPT 자료 제작 및 스크립트 수정
내가 담당한 핵심 지표/가설
H1. 효율화: 사수의 반복 교육 부담 감소 (인수인계 태스크 구성 시간 기존 방식 대비 20% 이상 감소)
H2. 적응 가속: 단계별 로드맵으로 신입의 실무 적응 가속화
H3. 정착: 체계적 인수인계를 통한 신입 조기퇴사 가능성 감소
사용한 도구
- 리서치: Google Forms (설문조사), 인터뷰 질문지 작성
- 기획: Notion, Google Docs (협업 문서)
- 발표: PowerPoint, PDF
- 분석: 경쟁사 분석 매트릭스 (Workday, Leapsome, 바인더 등 8개 서비스 비교), Claude, ChatGPT
STEP 2. PM 역량 한 조각 발굴
🔍 문제 정의 및 가설
발견한 단서
- 데스크 리서치: 신입사원 조기퇴사로 인한 기업 손실비용 1인당 2,000만원 이상, 조기퇴사 이유 1위 "실제 업무가 생각과 달랐다" (45.7%)
- 설문 응답: 대부분 Word·한글·메신저에 자료 흩어져 있음
- 인터뷰 인사이트: 사수는 "무엇을 어디까지 알려줬는지 기록이 없음", 신입은 "질문할 곳이 없어 눈치를 봄"
핵심 가설
만약 30일 인수인계 로드맵 + 주차별 체크리스트 + 질문-답변 기록 + 진행률 대시보드를 제공한다면, 사수는 반복 설명 시간을 줄이고 신입의 적응 속도가 빨라질 것이다. 왜냐하면 토스·배민에서 이미 유사한 구조(퀘스트 로드맵+버디 피드백)가 효과를 검증했기 때문이다.
기록 이 가설은 단순한 추측이 아니라 "온보딩 시스템은 많지만 인수인계 특화 서비스는 비어있다"는 시장 간극 발견에서 출발했다. 경쟁사 8개를 비교 분석한 결과, 대기업 시스템(Workday)은 강력하지만 복잡하고, 온보딩 솔루션(Leapsome)은 콘텐츠 전달 중심이며, 협업툴(Notion)은 신입 교육 전용이 아니라는 점을 명확히 했다. 이것이 "우리의 틈"이 되어 프로젝트의 논리적 닻이 됐다.
📊 데이터 기반 의사결정
가장 고민했던 선택
"MVP로 구현할 단계가 어디까지인가 "
- 짧은 기간내에 구현할수있는 범위가 어디까지인지 측정 어려움
- 인수자, 인계자라는 필수 사용자가 두종류로 나뉘어진 양면시장이기 때문에 온전한 프로그램이라면 둘다 구현해야하지만
리소스, 시간적으로 어려울것 같다는 의견
결론 : 논의끝에 당장 MVP로 구현한 페이지를 보이자면 인계자 화면이 더 중요하다고 판단
두 문제를 동시에 해결하려면 구조화된 기본 템플릿(1~4주차 골격)이 필수라고 판단했다.
최종 결정
- Must Have: 인계자 화면의 프로젝트 생성, 태스크관리, 인수자 관리 화면, 질문관리화면
- Nice to Have: 별도의 개개인 대시보드화면, 인수자 체크리스트, 인수자 화면, 인계자 등록 화면, 진행현황 확인
🤝 협업/소통
어려웠던 상황
- 일정 부족으로 인한 스코프 조정
- 초기 계획: 인수자·인수자 대시보드, 팀장 분석 페이지, Slack 알림까지 포함
- 현실: 개발 기간 1주(6/8~6/12) 제약으로 Must Have만 우선순위 결정 필요
- 기술적 한계 경험
- 초기 기획: "태스크별 진행 현황을 AI로 자동 요약해 대시보드에 띄우면 좋을 것"
- 개발팀 피드백: "3주 개발 기간에는 불가능, 먼저 기본 기능을 검증하자"
- 조정: 자동 요약은 "Should-Have"로 후순위 이동, 수동 입력 기반 대시보드로 MVP 범위 축소
내가 했던 행동
- 매일 아침 10분 스크럼 미팅 진행해 의견 차이 조기 발견
- 의견 불일치가 생기면 내가 생각했던 궁극적 서비스의 형태를 설명하여 팀원들과 의견 조정
- 개발팀의 우려(공수, 기술적 어려움)를 진지하게 듣고, 그 위에서 "최소한의 MVP 범위"를 함께 정의
- 기획/기술/디자인 간 충돌 시 항상 MVP프로젝트라는 것을 되새기며 MVP 범위에 집중하며 의사 결정
배운 점 협업에서 가장 효과적이었던 것은 "상대의 입장을 먼저 인정하고, 그 위에서 공통의 목표(MVP 검증)에 맞춰 의견을 조율하는 것"이었다. 특히 현재의 기술적 한계를 받아들이고 함께 스코프를 줄이는 과정에서 팀의 신뢰도 높아졌다.
STEP 3. Lesson Learn & Next Step
이번 프로젝트에서 가장 성장한 부분
- 비즈니스 문제를 숫자로 연결하는 경험
- 처음: "신입이 적응을 못 한다" (모호함)
- 지금: "신입 조기퇴사 44.7%, 1인당 손실 2,000만원, 조기퇴사 이유 1위 45.7%" (정확함)
- 이 과정에서 "문제의 크기를 수치화하면 솔루션의 필요성도 자동으로 설득된다"는 걸 배웠다.
- 기획-기술 간 협업 방식 체득
- 초반엔 "기획서를 완벽하게 완성한 후 개발팀에 넘기는" 방식으로 생각했다.
- 개발팀과의 소통이 어떻게 이루어지는지 체험해볼수있었다
- 어떤 형식으로 만들어야 기획단계에서 참여하지않아 문서가 처음인 협업자가 이해하고 작업해줄수있는지 알게되었다
가장 아쉬웠거나 다음엔 다르게 해보고 싶은 부분
- 리서치 타이밍
- 아쉬운 점: 좀더 많은 불특정 다수에게 설문을 돌리지못한점
- 불특정 다수에게 다양하게 받을수있는 범용성이 큰 설문이었는데 더 많이 다양한 분야에서 받지못한것이 아쉬었다
- 심층인터뷰
- 아쉬운 점: 튜터님들한테 심층인터뷰로 결정권자의 위치에 있는 분들에게 객관적인 평가를 듣지못한점
- 현실: 설문지로 활용할 질문만 임시로 뽑아두고 인터뷰를 진행하지못했다
- 다음엔: 다양한 의견 수용을 위해 심층유저인터뷰까지 진행해보고 싶다.
- 남은 개발부분
- 아쉬운 점: 최종 서비스까지 어떻게 구성할지 기획이 되었으나 리소스문제로 반쪽짜리 서비스만 제작해본점이 아쉽다
- 다음엔: MVP이후 단계까지 구현해보고 싶다.
- 유저테스트
- 아쉬운 점: 1차/2차/3차 KPI를 정의했지만, 한쪽만 개발된 상태여서 온전한 유저테스트를 진행하지 못했다
- 다음엔: 서비스를 운영할수있는 최소한의 단위를 좀더 넓게 잡아도 되지않을까 싶다.
다음 프로젝트에 가져가고 싶은 나만의 원칙
- 회의를 아까워하지않기
- 회의에서 의견 불일치가 생기지 않게 수많은 회의를 거쳤다
- 서로의 생각이 통일되어 하나의 방향과 목표를 고정해야만 업무가 나뉘어져도 같은 논리를 펼칠수 있다고 판단했다
- 그렇기에 기획단계에서 수많은 회의와 서로에게 숨김없는 질문으로 의견을 일치시켰다
- "MVP는 완벽하지 않아도 검증 가능하면 된다"
- "직무별 템플릿 자동 추천", "AI 질답 요약", "Slack 알림" 같은 고도한 기능들을 "Should-Have"로 미뤘다.
- 대신 핵심 가설(사수의 반복 설명 줄기, 신입의 명확한 로드맵 제공)을 검증하는 데만 집중했다.
- 이것이 "MVP의 정신"이고, 다음 프로젝트에서도 이 원칙을 지키고 싶다.
📝 한 줄 회고
내가 주도적으로 진행한 기획은 정말 재밌고 온전히 몰입할 수 있다는 것을 느꼈다
온전히 모든 것을 쏟아부은 시간이었다
'PM부트캠프' 카테고리의 다른 글
| 팀스파르타 PM과정 (51) (0) | 2026.06.23 |
|---|---|
| 팀스파르타 PM과정 (50) (0) | 2026.06.18 |
| 팀스파르타 PM과정 (48) (1) | 2026.06.02 |
| 팀스파르타 PM과정 (47) (1) | 2026.06.01 |
| 팀스파르타 PM과정 (46) (0) | 2026.05.29 |