프로덕트 오너(PO) 스터디 경험

동기

비사이드를 통해서 사이드 프로젝트인 '빵긋' 을 진행하던 중 비사이드 플랫폼에서 주어진 스케쥴, 주어진 역할로 충분하지 않은 점을 깨달았다.
사실 서로간에 R&R 이나 프로덕트에 대한 생각을 깊게 나눠보기도 전에 오직 "출시"만을 향해서 달렸던 부분들이 있었고 달리던 과정에서 서로 알아줬으면 하는 일들이나 오해들도 있어서 이번 기회에 우리가 무엇을 만들고 있는지 전체적인 흐름을 시야를 더 넓혀서 확인해 볼 필요가 있었다.

그리하여 좀 더 베스트 팀이되기 위해서 팀원들에게 PO 스터디를 제안하게 되었고 개발파트 분들은 흔쾌히 수락하였다.
근데, 개발파트 분들만 흔쾌히 수락하였다 !
하지만 지속적으로 스터디에 대한 이야기와 영감이 다른 파트 분들도 들으면 좋을 내용임을 어필하여 2주차 부터는 기획파트 한분이 추가로 참여하여 스터디를 진행하였다. 

 

방향성

우리는 3시간 정도의 인터넷 강의를 6개의 챕터로 나눠 매주 1챕터를 보고 서로의 생각과 논의하면 좋을 내용들을 논의 하기로 하였다.
물론 초기 4주 정도는 항상 마지막의 스터디에 대한 회고하는 시간을 가져서 스터디를 계속해서 개선해 나아갔다.

예를 들어, 프로덕트 오너를다음과 같이 강의에서 정의했다면
- "비즈니스 목표와 고객 경험에 맞춰 개발 조직과 협업하여 프로덕트의 가치가 극대화되도록 구현하는 사람"

여기서 오해를 살만한 단어 의미에 대해서 생각을 아래와 같이 공유하면서 진행하였다.

• 비즈니스 목표: 근본적으로 문제를 해결 하는 것
  
  • 빵긋의 비즈니스 목표: 소비자들이 프렌차이즈 빵집 보다 동네빵집을 원하는 니즈와 그럼에도 불구하고 매년 2000곳 이상 폐업이 발생되는 문제점을 해결 하는 것
• 고객 경험: 프로덕트를 사용해본 고객의 경험 (좋은 경험, 안 좋은 경험) 을 객관화 한 데이터 수치나 이벤트
• 개발 조직: 프로덕트를 만드는 모든 사람들 (개발팀, 기획팀, 디자인팀...)
• 프로덕트의 가치: 목표한 KPI(핵심성과지표) 또는 OKR(Object Key Result) 를 통한 결과 높은 결과 수치

 

주차 별 스터디 진행 과 회고

 

인상깊었던 점

분명히 강의의 시간은 3시간이 였는데 다루는 내용이 엄청나게 많았다. 실제로 스터디가 6주 정도로 늘어났으니 말이다.
기존에 우리가 가지고 있지 배우게 된 내용을 키워드로 나열해보면 다음과 같다.

• Product owner vs. Product Manager vs. 서비스 기획자
• 비전을 통한 방향 설정
• 요구사항만 있고, PO의 판단은 없었다. → 로드맵, 우선순위 필요
• 직관에 의한 기획 → 데이터 & 테스트
• 완료조건
• 고객의 니즈에 따른 우선순위 설정
• Conversion (전환율)
• UT (사용성 테스트)
• AARRR
• 6Pager
• 중요한 것은 버리는 것이다.
• 대시보드 또한 프로덕의 일부이다.
• 소리가 큰 고객  VS 진짜 고객
• 목표 결과 측정

 

대시보드

대시보드는 여러가지 형태일 수 있다.
서버에서 로그를 모니터링 하는 대시보드 이거나 구글 애널리틱스를 통한 대시보드이거나 빵긋에 대이터를 보여주는 통계 대시보드 일 수 있다.
기존의 빵긋팀의 끝은 '빵긋' 이라는 앱을 출시하는 것 이였고 출시 스펙에서는 대시보드와 관련된 이야기가 없었다.
하지만 이번 스터디를 통해서 대시보드 또한 프로덕트의 일부임을 이야기 하게 되었고 이것이 데이터 기반에 의사소통의 기초라고 생각 할 수 있게 된 것 같다. 

중요한 것은 버리는 것이다.

백로그(Backlog) 가 존재하는 이유는 백로그에 있는 모든 것을 구현하기 위해서가 아니라, 낮은 우선 순위에 있는 것을 버리기 위해서 존재하는 것이다.
이는 기획파트 팀원분과 같이 이야기를 할 수 있어서 좋았다. 초기에 기획파트 분들은 백로그의 있는 기능들을 모두 구현하는 것을 목표로 삼을 수 도 있을 것 같고 또 개발파트는 "이를 맹목적으로 수용해야 하는 것인가?" 를 고민 할 수 있을 것 같다.
하지만 이 스터디를 통해 "고객의 가장 중요한 기대에 집중하는 것이 중요하다는 것을 확인하게 되었고" 위와 같은 고민은 조금은 해결 될 수 있었다.

소리가 큰 고객 VS 진짜 고객

"'B TO C' 라고 해서 고객의 말을 전부 들어야 할 필요가 있을까?", "전부 들으면 우리의 정체성이 사라지지 않을까?", 그러면 우리는 "어떤 고객의 말을 들어야 할까?" 에 대해서 이야기를 많이 하게 되었다. 이를 위해선 우리는 우리의 진짜 고객을 찾아야 한다는 결론을 다달았다. 데이터를 기반으로 우리의 핵심 지표를 달성에 높은 지분을 가진 고객이 진짜 고객이라고 생각한다.

완료조건을 통한 ATDD 의 입구

기능에 대한 명세가 "익명의 사용자로서 별명을 입력받아 회원가입을 할 수 있다" 로 되어있다면 개발을 하면서 여러가지 생각을 할 것이다.예를 들어, "별명은 몇글자까지 이지?", "영어는 안되지 않을까?", "만약 잘못된 별명이라면 어떻게 처리하면 좋을까?" 등의 생각을 할 것이다.
따라서 이에 대한 생각이 한번에 나진 않을 것이고 하나 하나 기획자와 다시 대화를 하면서 생각해 나갈 것이고 개발자는 기능 구현이 늦어진 경험을 하게되어 실제로 빵긋 스프린트 동안에 원하는 기능을 다 끝내지 못했던 사례가 있었다.

만약에 아래와 같이 기능을 끝내기 위한 완료조건이 있다면 개발자는 엣지 케이스에 대한 커뮤니케이션을 줄일 수 있고 완료조건에 대한 테스트까지 작성하기 쉬울 것이다. 

• 별명은 최소 1글자 최대 7글자이내 한글 또는 영문이어야 한다(8글자 초과 불가능)
• 별명에 특수 문자 사용 불가능, 띄어쓰기 불가능
• 별명이 이미 존재하는 경우 :  빨간 메시지로 에러메시지를 표출한다.

완료조건에 대한 테스트를 인수 테스트 (ATDD 의 입구라고 생각한다.)

좋았던 점

처음에 이 스터디를 개발 파트 팀원들 끼리만 했을 경우에는 개발 파트라는 바운더리가 있어 팀 전체가 변화하는데 한계가 있다고 생각하였다. 하지만 계속된 구애 끝에 개발자 뿐만 아니라 기획 파트 팀원과 같이 스터디를 하게 되어 너무 좋았다.
특히 "중요한 것은 버리는 것이다.", "완료조건" 와 같은 주제를 같이 다루면서 파트 간에 생각을 공유할 수 있어 좋았다

 

아쉬웠던 점

팀원 모두가 참여하지 못하였던 것이 아쉬운 부분이다.
모두가 같이 참여했더라면 전파하거나 생각을 공유할때 다같이 있으면 좋았을 텐데 아쉽다.
어떻게 하면 여기서 배운 인사이트를 전파하여 팀 전체에 녹일 수 있을지가 추가적인 고민인 것 같다..
하지만 혼자가 아니기 때문에 긍정적으로 보고 있다 !

 

느낀점

6주간이라는 긴 시간동안 제안한 스터디에 참여해준 팀원들에게 너무 감사하다.
그 동안 배운 내용을 다른 팀원들에게 전파하면서 빠르게 사이드 프로젝트에 실험적으로 적용하고 싶다.
그리고 이번 스터디가 신호탄 처럼 팀원들이 자발적으로 필요한 부분이 있다면 스터디를 만들고 진행 했으면 좋겠다.

 

참고 
인터넷 강의: "TheRED:최고제품책임자(CPO)윤희경Online"