Pitch Deck(피치덱)을 통한 프로젝트의 Why 찾기
이전글: PM의 랜딩페이지 기획
다음글:
저희 팀은 최근, 애자일과 워터폴을 결합한 'Shape up'이라는 새로운 방법론을 적용하여 프로젝트를 수행하고 있습니다. 새롭게 시도하고 있는 방법론이므로 여러 시행착오를 겪으며 개선해 나가고 있습니다.
그런 의미에서, 제가 이번 글에서 공유하려는 내용은 ‘Shape up’ 방법론의 프로세스 중 하나인 'Pitch deck' 문서에 관한 내용입니다.
Pitch deck은 프로젝트의 배경, 목표, 계획 등을 간략히 정리한 프로젝트 제안서로 일반적인 '원 페이저'와 유사합니다.
Pitch deck을 사용해 '프로젝트의 당위성'을 동료들에게 알려준 경험이 있습니다. 이를 바탕으로 Pitch deck의 중요성과 가치에 대해 다뤄보겠습니다.
우선, 제가 이 글에서 말씀드리고 싶은 Pitch deck(피치덱)은 'Shape up' 방법론에서 사용하는 프로세스로 프로젝트의 우선 순의를 정하기 위해 참고하는 문서입니다.
일반적으로 Pitch deck은 투자자의 관심을 끌고 자금을 확보하기 위해 작성하는 사업 계획서로 많이 쓰이고 있습니다. 이를 태면, 실리콘밸리의 인큐베이팅 프로그램에서는 창업자들이 자신의 비즈니스 아이템을 투자자들에게 소개하고 설득하기 위해 30분에서 1시간가량 발표를 합니다. 이런 짧은 시간 동안의 발표를 '피칭(Pitching)'이라고 부릅니다.
피칭의 어원을 살펴보면, 프로야구에서 투수를 Pitcher라고 부르는데, 투수가 공을 던지듯이 상대방에게 자신의 사업 아이템을 전달하는 과정과 비슷해서 붙여진 파생어입니다.
다시 말해서, 피치덱이란 상세기획에 들어가기 전 C레벨이나 팀원들에게 프로젝트를 설득(피칭)하는 데 사용하는 문서입니다.
Shape up 방법론을 처음 도입하기 시작했을 때, 해당 방법론을 사용하고 있는 사례가 거의 없었습니다. 또한, 피치덱을 준비하는 데 있어서도 정해진 양식이 없었기 때문에, 팀의 업무 프로세스를 보며 적용할 수 있는 피치덱 양식을 직접 만들었습니다.
제가 어떠한 방법으로 피치덱을 작성하였는지 예시와 함께 보여드리겠습니다.
Pitch deck은 "배경(Back ground), 문제 정의(Problem), 목표(Goal), 가치(Value), 해결 방안(Solution), 토끼굴, 목표가 아닌 것(Non-Goals)"으로 구성되어 있습니다.
예시의 경우에는 구성의 설명을 위해 실제 제가 작성한 백오피스 프로세스의 내용의 일부를 가져와 가공하였습니다.
1. 배경(back ground)
서비스 기획 전 이슈가 발생한 상황 또는 환경에 대한 내용
‘왜 이 기능을 만들게 되었는지’, ' 동기는 무엇인지'
(예시) 백오피스 데이터 및 기능에 대한 보수 관리가 어려움
2. 문제 정의 (Problem Statement )
프로젝트에서 해결하고자 하는 문제를 명확히 정의하는 것
서비스 & 플랫폼에 있어서 사용자가 마주치는 문제
즉, 어떤 사용자의 문제를 해결하려 하는 것인지
(예시) 백오피스 데이터 이슈
백오피스 지표 및 일부 데이터에 상이한 부분이 있어 DB단계에서 확인 필요
사용자들이 백오피스의 데이터를 재구성하여 새롭게 쓰고 있음 (업무의 수동 공수 발생)
3. 목표(Goal)
서비스 & 플랫폼을 통해 지향하고자 하는 것
정의한 문제들이 해결되었을 때 이루어져야 할 것
(예시)
업무의 표준화 및 러닝 커브 감소
프로세스 효율화를 통한 수동 공수 감소
4. 가치(Value)
프로덕트가 사용자의 경험에 어떤 도움을 주는지 (기대효과)
기획 및 개발된다면 어떤 목표를 달성할 수 있을지
(예시)
업무 프로세스의 효율성
사용자 편리성
유지 보수 관리 용이성
5. 해결 방안(Solution)
문제를 해결하기 위해 필요한 서비스 또는 기능
(예시) 백오피스 리뉴얼(로그인 > 통계 > 상품 관리 순으로 진행)
6. 토끼굴
레거시처럼 프로세스 일정에 큰 지장을 줄 수 있는 리스크
리스크를 어떻게 패치할 것 인지에 대한 내용
(예시) 정산 프로세스 확인 필요
상품, 주문, 통계에 영향을 끼치고 있어 정확한 프로세스 정립 필요
7. 목표가 아닌 것(Non-Goals)
연관되어 있지만 의도적으로 해결하지 않으려는 사항
여러 CASE에서 우선순위가 밀리는 서비스 & 플랫폼 기능
(예시)
로그인 통계를 제외한 나머지 메뉴
일정에 따라 검토 및 진행 예정
각 파트의 업무가 세분화되어 있을수록 업무를 부여받았을 때, '어떻게' 해당 업무를 수행해야 할 지에 대해 고민을 합니다.
그런 와중에 Pitch deck은 이 업무를 '왜' 해야 하는지에 대한 근본적인 질문을 합니다. 즉, 업무에 대한 ‘Why’를 명확하게 해 주며, 현재 진행 중인 프로젝트의 가치를 이해하는 데 큰 도움이 됩니다.
"Shape up 방법론을 도입하게 된 배경 중 일례로, 스프린트를 진행하며 파트에 상관없이 팀원들의 다양한 의견을 수용하려 했었습니다. 하지만 대부분의 회의에서 동료들이 의견을 제시하는 것에 어려움이 보였습니다.
그 이유를 확인해 보니 프로젝트의 히스토리를 파악하기 어려워 말을 꺼내기가 쉽지 않다는 이유가 가장 많았고 워터폴로 업무를 계속해서 진행하다 보니 의견을 내는 것 자체가 부담스러운 동료들이 있었습니다.
새로운 방법론을 채택하면서 이 문제를 해결하고자 했습니다. 그래서 Pitch deck을 직접 작성하여 브리핑하는 시간을 가졌고 각 파트 리드들과 PM이 선정한 프로젝트에 대한 설명과 프로젝트의 Why에 대해서도 강조했습니다."
지금도 시행착오를 하며 검증 중에 있는 프로세스지만 확실한 것은 동료들의 의견을 이끌어 내는 경험을 하고 있다는 점에서 Why를 설명하는 Pitch deck에 대한 가치를 느꼈습니다.
- Pitch deck은 우리의 제품 또는 서비스에 대한 이해를 더욱 명확하게 도와줍니다.
- 프로젝트에 대한 PM의 의견을 더욱 효과적으로 전달할 수 있습니다.
- Why를 잘 아는 것은 프로젝트의 우선순위(중요도)를 정할 때 큰 역할을 합니다.
- 프로젝트에 대한 방향성을 잡을 때도 도움을 얻을 수 있습니다.
결론적으로, 제가 이 글에서 말씀드리고 싶은 부분은, 피치덱을 쓰지 않더라도 업무를 진행하며 프로젝트의 why를 고민할 수 있는 시간이 중요하고 필요하다는 것입니다.
감사합니다. ;)
1. 최근 애자일과 워터폴을 결합한 ‘Shape up’이라는 방법론으로 프로젝트를 수행하고 있음
2. ‘Shape up’ 방법론의 프로세스 중 원페이저 형식과 유사한 'Pitch deck' 문서라는 것이 있음
3. Pitch deck은 프로젝트의 우선 순의를 정하기 위해 참고하는 문서임
4. 상세 기획에 들어가기 전 C레벨이나 팀원들에게 프로젝트를 설득(피칭)하는 데 사용함
5. Pitch deck은 '배경, 문제 정의, 목표, 가치, 해결 방안, 토끼굴, 목표가 아닌 것'으로 구성되어 있음
6. Pitch deck은 업무를 '왜' 해야 하는지에 대한 근본적인 질문을 함
7. Why를 통해 동료들의 의견을 이끌어 낸 경험이 있고 경험을 통해 Pitch deck의 가치를 느낌
8. 업무를 진행하며 프로젝트의 why를 고민할 수 있는 시간이 중요하고 필요함