니즈 접수부터 성과 측정까지 한 싸이클 돌아보기

제품의 기능 개선 또는 신규 기능 추가했을 때 어떤 싸이클을 어떻게 돌아야 하는지 전체적인 프로세스를 정리해보았습니다.

PM 업무를 하실 때 도움이 되시길 바라며! 들어가겠습니다.

 

1. 니즈 접수

• 사업팀이든, 콘텐츠팀이든, VoC든, 대표님이든, 프로덕트팀 자체에서든 니즈를 접수하여 상시로 요구사항을 한 공간에 모아둔다.
• 프로젝트 1회를 진행하기 위해 최소 1개에서 최대 3개 정도의 아이템을 선정한다.
  • 당시의 작업 리소스와 작업량을 먼저 PM이 대략적으로 파악을 해둔다.
  • 아이템 선정은 먼저 PM이 현재 회사 비즈니스 우선순위를 고려하여 1차로 제안하고, 팀 내 합의를 거친다.
  • 회사에서 선제적으로 제안을 하는 경우, 프로덕트 관점에서 임팩트를 낼 수 있는지 추가로 고려한다.
    • 만약 프로덕트 관점에서 임팩트를 내기 힘들다고 판단한 경우에도 우선 팀 내에 공유하여 진행 여부를 판단한다.

2. UX 리서치

• 아이템을 결정했다면 사용자가 실제로 어떻게 사용하고 있는지 데이터 확인하여 실제로 문제인지 판단한다.

구분 세부 구분 항목

분류	소분류	내용
정량 데이터	내부	완료율, 발화 내용, 행동 데이터 등
	외부	리서치 기관에서 게시한 학습 데이터
정성 데이터	내부	고객 후기, 사용자 설문, 개인/기관/학교 고객 Voc
	외부	관련 아티클, 논문, 경쟁사 앱 리뷰 등

3. 문제 정의

• 문제라고 판단되었다면 가설 설정하여 왜 문제인지 정의한다.
• 문제를 정의할 때 되도록이면 사용자의 행동 데이터 기반으로 정의하는 것을 권장하나, 파악할 시간이 부족하거나 데이터를 수집할 수 없는 상황이라면 비즈니스 맥락을 참고하여 정의한다.
• PM이 먼저 문제를 정의 하였다면 팀내에서 합의를 한 후, 회의에서 실무자 멤버에게 공유한다.

4. 목표 설정

• 문제 해결을 위한 제품 개선 프로젝트가 각 영역에서 어떤 임팩트를 낼 수 있는지 KPI를 설정한다.
  • 사업적: 얼만큼 돈을 벌 수 있는지
  • 학습적: 학습적으로 얼마나 효과적인지
  • 사용경험적: 사용자는 얼마나 만족할 것인지
  • (이 부분은 각 유관부서와 합의하여 정하도록 한다.)
• 목표 설정의 순기능은 2가지이다.
  • 실제로 우리 프로덕트가 얼마나 더 나아질 수 있을지 객관적인 지표로 활용된다.
  • 메이커들에게 개선 지표를 제시함으로써 동기부여와 설득 근거를 제시할 수 있다.

5. 해결 방안 제안

• 정의된 문제로부터 어떻게 해결할 것인지 간단한 화면 또는 MVP를 구축하여 팀, 이해관계자들에게 공유하여, 의견을 받는다.
  • 특히 PM이 가장 신경써야할 대상은 이해관계자들이다. 대부분의 경우 B2C, B2B, B2S 등 요구사항이 세부적으로 상이한 고객을 마주하기 때문에 각 팀 팀장, 실무자, 본부장과 커뮤니케이션을 최대한 많이 시도해야한다. (이 부분의 난이도가 가장 높습니다..)
• 팀 내 합의, 이해관계자들의 의견을 수렴하고 PM은 1차 기획서를 작성한다.
• 1차 기획 리뷰를 할 때 디자이너, 개발자, QA 담당자를 포함시켜서 더 나은 구현 아이디어와 feasibility check 를 받는다.
• 2차 기획 리뷰 전까지 디자이너와 지속적으로 소통 하면서 디자인 공수를 받아 마감일을 합의한다.
• 최종 확정된 3차(또는 n차) 기획 내용으로 상세 기획 / 세부 정책 정의한다. (개발 시작 전까지 세부 정책 정의까지 마무리한다.)
  • 이때 쯤 이면 작업 범위와 항목이 정해지기 때문에 개발 공수 산정이 가능하다.
  • 따라서 개발/QA 공수를 받아 프로젝트 마감일을 정한다.
• 큰 틀은 변하지 않기 때문에 상세 기획/ 세부 정책은 지속적으로 메이커들의 의견을 받아 업데이트한다.
  • 이 때, 커뮤니케이션 오류가 없도록, 문서 최신화, 문서내 히스토리 남기기, 슬랙 채널에 공유 이 세개를 반드시 진행한다. (마이너한 이슈는 문서 내 히스토리까지만 남긴 후 문서 내에 코멘트로 언급하는 정도로 충분하다.)

6. 프로젝트 관리 문서/티켓 작성

• 이번 개발 프로젝트의 버전 이름을 명시하여 문서를 만든다.
• 문서 내에는 정해진 일정과 작업 항목을 기입한다.
• 지라에서 에픽 티켓을 작성한다.
  • 에픽 티켓에는 작업의 큰 목표와 방향성에 대해서 적어두고, 문서를 첨부해둔다. (에픽 티켓에 상세하게 작성하면 문서 업데이트 시 에픽 티켓도 업데이트해야하기 때문에 핵심적인 내용만 적어둔다.)
  • 에픽 티켓 하위로, 산정된 개발 항목 티켓을 작성한다.
    • 필요 시에는 개발 항목 티켓에도 내용을 작성하지만, 대부분의 경우엔 공란으로 비워둬도 무방하다. (개발자, 디자이너가 작업을 하면서 내용을 채울 수 있기 때문.)
• 프로젝트 문서에는 에픽 티켓을 첨부하고 에픽 티켓의 하위 티켓들이 잘 보이도록 쿼리문을 통해 표시한다.
• 디자인, 개발, QA 팔로업
  • 순차적으로 작업이 진행되기 때문에 작업 도중에 이슈가 발생하는 경우엔 최소 30분 이내로 답변한다. 더 길어지면 작업자의 현재 흐름을 끊을 수 있기 때문에 되도록이면 빠르게 대응한다.
  • 중간에 이슈가 많이 나온다면 미리 모든 내용을 관계자들과 정리를 끝낸 후, 비정기적인 회의를 잡고 메이커가 모인 자리에서 정리된 내용을 공유한다.

7. 홍보

• 배포 할 시기에 다가오면 실 사용자, 또는 적용 서비스 담당자에게 알린다. 어떤 내용이고 어떻게 변경될 것인지는 기획 초기부터 알도록하고, 윤곽이 드러났을때에(2차 기획 완료 또는 디자인 완료) 따로 홍보 자료를 만들어서 직관적으로 이해가 가능하도록 소통한다.
• 현재 맡고 있는 프로덕트는 B2B 솔루션 이기 때문에 서비스 담당자, 사업부에만 알리면 되지만 B2C 제품일 경우엔 실 사용자에게 넛지하는 방법을 고민해야할 것. (아마도 미리 슬쩍슬쩍 알리는 방식은 비슷할거 같긴한데 이 부분은 경험이 없어서 잘 모르겠다)

8. 배포

• 모든 QA가 완료되면 상용 배포를 진행한다.
• 그리고 해당 버전을 각 서비스에 언제 적용하는지 일정을 서비스 측과 합의한다.
  • 서비스A는 2주 단위 배포, 서비스B는 분기 단위 배포이기 때문에 담당 PM과 적용 일정을 합의하는 것이 중요하다.

9. 성과 모니터링

• 목표로 설정한 성과가 얼마나 이뤄졌는지 적용된 서비스 대상으로 조사를 실시한다.
  • 정량적인 활동 데이터를 볼 수도 있고
  • 사용자의 설문 만족도로 측정할수도 있다.
• 이 부분은 사업부와 조율하여 가장 마찰이 적고 수집에 용이한 방향으로 결정한다.
  • 예를 들어 PM은 되도록이면 심층 인터뷰나 사용성 테스트를 실제 사용자를 대상으로 하기 원하나, 마케팅/세일즈 상황 상 여의치 않을 수 있기 때문에, 간단한 설문지로 대체하여 경향성을 확인한다.

10. 회고

• 메이커들을 대상으로 이번 배포를 진행하면서 Keep, Problem, Try에 대한 의견을 받고 다음 iteration에 실행할 Action Items를 선정한다.
• 회고는 반드시 이번 프로젝트에서 기능을 ‘만든’ 사람들을 대상으로 하며, 그 외에 인원에게 소통이 필요할 경우엔 PM이 전달한다.

11. 다음 프로젝트 준비

• 최종 기획의 상세 정책 정의 작성이 완료된 시기 부터 PM은 full time으로 프로젝트 관련 업무를 진행하는 경우가 드물기 때문에, 다음 프로젝트에 대한 1~5번을 미리 진행한다. 그래야 메이커의 리소스가 비지 않고 계속 프로덕트 성장을 위해 Align 을 맞출 수 있다.