요즘 제일 핫 한 클럽하우스. 딱 1주일동안 사용해보고 뉴비폭죽 떨어지자마자 방 한번 만들어보자! 해서 3시간 정도 모더레이터를 진행했고 아래 내용은 스피커 분들이 참여한 대화를 요약한 내용입니다.
첫 모더레이팅이다보니 대화들을 기록해가며 진행했고, 방송을 마무리하며 말미에 스피커분들의 동의를 얻고 노트한 내용을 블로그에 공유합니다. (녹음이 아닙니다!)
개인을 특정할 수 있어서 프로필에 대해서도 생략하며, 제 발언을 제외한 모든 발언자는 이니셜로 표기합니다. (저를 제외하고 참여해주신 Speaker 총 16명, audience 100명+)

[질문] 기획자 팀원 또는 주니어 기획자들의 역량을 키우기 위해 해주는 조언이 있다면?

  • 미경 : 일단 아는걸 다 가르쳐줘야겠다고 시도했다가 역효과가 났었다. 그래서 지금 관심이 있고 잘하는게 무엇인지 물어보고, 해당하는 지식들부터 넣어주기 시작했다.
  • A : 사수가 없어서 독학으로 시작했다. 타 앱 보고 똑같이 그려보고 구현에 대해 개발자들과 이야기하고 부딪혀보고.. 근데 후임자가 나처럼 배워야한다면 힘들지 않을까..
  • B : 독학으로 했다. 기획자들에게 배운적은 없고 개발팀 소속이었기 때문에 함께 일하는 개발자들과 일하면서 배웠다.
  • C : 개인적으로 개발자로 커리어를 시작해서 기획에 유리했다. 기획을 시작할 때 스토리보드를 그리고, 피드백을 주고받으며 다듬어갔다. 패캠 기획스쿨 같은 코스를 추천해주거나, 퍼블리 등에서 일을 어떻게 하는가 등의 아티클을 추천한다.
  • D : 벤치마킹을 중요하게 생각한다. 다수가 사용하는 이유, 최근에 사용된 이유 등을 분석해서 고민해보고 새로운 시도를 하고싶다면 논의하자. 사용자들은 이미 학습한 것들이기 때문에 어느정도 표준이 있어 보수적인편.
  • E : 디자인 쪽에서 시작했다. 서비스기획을 하고 싶다면, 개발이 흘러가는 매커니즘을 이해하는게 중요하다. 이해하면 PM이 어떻게 풀어나갈지 이야기하면 된다. 물론 아직도 배우고 있는 단계.

[진행] 개발이 기획에 도움이 될까?

  • 미경 : 개발에 대한 이야기가 나왔다. 개발을 이해하는게 기획에 도움이 될까?
  • C : 기획자가 배운 개발과 현장에서 사용되는 개발은 차이가 있다. 사용하는 기술이 다르기 때문에 물어가면서 진행해야한다. 서비스 플로우 전달하면 이후는 함께 진행.
  • D : 개발자 출신 기획자들이 개발에 너무 딥하게 개입해서 좋았던 것보다 나쁜 경우를 많이 봤다. 적당히 아는게 좋고 필요이상으로 관여하는것은 반대. 자존심을 건드린다고 생각한다. 원팀으로 개발이 이뤄질 때 신뢰를 해야 하는 부분이 있다. 믿음을 갖고 프로젝트를 진행하자.
  • B : 개발자 수준이 아니더라도 개발지식이 반드시 있어야 한다고 생각한다. 되는 일인지 안되는 일인지 정도는 파악해야지. 이런 것들이 어떻게 동작하는지 리서치하고 이해하고. 개발보단 기술지식이겠다.
  • D : 다 된다고 하지만, 구현하는 사람들이 안되는게 있을 수 있다. 내가 생각한 것 이상으로 할 수 있게 역량을 끌어내주는게 더 중요하다고 생각한다. 개발방식에 개입하는 것보단 생각할 시간을 주고 내부에서 결정하는게 좋다. 다만, 개발자가 주는 피드백을 이해하려고 하는 수준이 되면 좋겠다.
  • B : 처음 팀에 조인했다면, 피드백을 받거나, 기술적으로 가능한지 물어보는 애티튜드가 조직에 처음 적응할 때 신뢰형성에 도움이 된다고 생각한다. 그러면 상상만으로 기획하는게 아니구나 라고 개발자들이 기획을 신뢰할 수 있다.
  • C : 개발 롤을 침범하는 것에 주의하자. 개발지식을 알고 있다면 퀄리티가 좋아지긴 한다. UI/UX만 고민하다보면 개발이 복잡해질 수 있기 때문에 개발을 어느정도 알면 기획서 작성할 때 도움이 된다.

[R님의 질문] 주니어인데 PO 역할을 맡고 있다. 물어볼 사람이 없어서 확신이 안든다. 어떻게 하나?

  • E : PO로 어떤 역할을 하고 있는지?
  • R : 기획을 하고 상위에 보고 후 의사결정.
  • E : 팀에서 상의를 하는지?
  • R : 다른 PO들은 자기서비스가 있어서 의견을 주긴 하는데 피드백이 명확하진 않다. 책으로 공부하려고 해도 불필요하단 의견이 있다. (도움이 안되나?)
  • D : PO도 누구가의 의견을 수렴하는 역할. 컨펌하는 사람이 없다고 의견이 없는건 아니라고 생각한다. PO로서 인터뷰, 관찰 등 다양한 방법.. 확신이 있어야 한다고 생각한다. 누군가에게 컨펌을 올릴 때 조사한걸 바탕으로 적어도 이게 최선이라는 확신. 기획자는 시장을 확인할 수 있어야 한다고 생각함.
  • E : PO, PM(프로젝트매니저) 동시에 해야할때는?
  • G : 조직사이즈마다 상황이 다를 수 있음. 역활에 맞게 사람도 분리된 경우도 있으니.
  • 미경 : PO로서 프로덕방향을 잡고, 이후론 그 방향에 맞게 플젝매니징을 나눠서 1인 2역으로 진행. 사실, 워킹타임엔 PM으로 일하고 다 퇴근하면 혼자서 조용히 고독을 곱씹으며 PO가 되는게.. ㅋㅋ

[E님의 질문] 유저분석은 어떻게 하나?

  • E : 유저 페르소나, 유저 저니 등을 정의하는 업무들을 진행하고 있다. PO로 사용자 리서치 이야기가 나왔는데, 유저분석은 어떻게 하고 있나?
  • D : 리서치해도 대부분 알고 있는 것들. 5% 정도의 엣지?를 발견하는데서 유의미를 찾는다. 설문이나 그룹인터뷰 들은 이미 호감이 있는 사용자를 대상하기 때문에 사용하는 걸 관찰하는 방법이 괜찮았다.
  • B : FGI 비용 만만치 않다. 나쁜 피드백을 듣기가 어렵다. 에이전시는 유저풀 관리를 하고있어서 참여자들도 거의 전문가다
  • E : 외국의 hotzar 와 같은 서비스를 도입했다. 녹화를 해줘서 좋다.
  • R : CS 앱리뷰 같은거 개선요청이 오는데 마음이 급하다. 우선순위는 어떻게 정하나?
  • B : 요청배경을 좀 더 파악한다. 서비스 장애인지, 고객불만인지.. 요청사항에 대한 실무자들의 공감대 형성이 어느정도 되는지 보는게 좋을 것 같다. 개선된 후에도 괜찮았던 개선인지 복기해보는게 좋다.
  • 미경 : 목소리 큰 유저들의 이야기만 듣다가, 정작 중요한 고객들을 잃을 수도 있다. 어느 고객들이 타겟되어 영향받는 요구사항인지 보고 판단하는게 필요하다
  • B : 예를들어 돈내는 사용자 10%와 돈안내는 강성유저 90%… 이 패치에 어느 고객을 타겟하는지. 불만이 있다고 다 들어주는건 생각해봐야.

[진행] 벤치마킹 이야기도 나왔다. 어떻게 하길 조언해준다면?

  • 미경 : 앞에서 벤치마킹 관련된 이야기도 나왔다. 화면만 보고 벤치마킹 하는 경우가 있는데 그건 벤치마킹이 아니다
  • D : 많은 것들을 보고 사용해보고 분석해보고 결정하는게 벤치마킹. 화면만 놓고보면 오히려 고르기 어려울 듯.
  • 미경 : 맘에 드는 화면하나에 꽂힌 케이스가 젤 안좋다.
  • E : 어설프게 배끼다가 뒷단이 더 복잡해지는 경우가 많다. 예전에 벤치마킹 가르쳐줄 때, 화면에 있는 모든것을 눌러보라는 조언이 있었다. 실제로 동작시켜보고 로직을 정리해보는게 큰 도움이 된다.
  • 미경 : 이왕 눌러보는 김에 약관이나 정책, 설정 구석에 박힌 크레딧까지 꼼꼼하게 다 보는편.

[진행] 시스템기획은 어떻게 해야할까?

  • 미경 : 백단 기획 이야기가 나와서 시스템기획으로 넘어가보자.
  • D : 경계가 없이 전체 사용자부터 어드민까지 전체 기획을 하고 있다. 분리가 가능한가?!
  • C : 사용자가 UI/UX를 주로 신경쓴다면, 시스템은 백오피스 설계라서 DB에 대해서 이해해야 할 때가 많은 것 같다. 큰 크림을 그리는 역할. 프론트 데이터들이 어떻게 어드민에 정리되어야 할지 등등
  • B : 그렇게 보면 백오피스는 벤치마킹이 어렵긴 하다.
  • 미경 : 사업자번호 하나 따서 판매자사이트 같은데 돌아다녀보면 도움이 크게 된다.
  • B : 실제로 커머스쪽에선 많이 사용하는 방식. 아쉬운건 파트너사이트 위주다보니 실제로 내부 백오피스 구조를 볼 수가 없긴 하다.
  • C : 우리업계 쪽 셀러오피스는 너무 올드하고 어렵고 레거시도 많은 편이라 별 참고가 안되긴 하다.
  • 미경 : 쿼리같은거 배우면서 디비 들여다보는 것도 시스템 기획에 도움이 많이 된다.

[C님의 질문] 기획자가 쿼리를 알아야하나?

  • C : 기획자가 쿼리를 꼭 배워야할까? 신규 입사자가 들어오면 쿼리까지 가르쳐야할지 고민이 든다.
  • D : 요즘 대부분 리더들은 기획자가 쿼리를 실행할 줄은 알아야지 하고 생각하는 것 같다. 나는 반대이긴 하다. 리얼디비에 하는 것은 위험하고, 클론디비에 하는건 오래걸릴 때가 있어서 그냥 어드민 보는게 빠름.
  • C : 쿼리까지 봐야하나 싶어서 엑셀 받아서 전달하고, 가공해서 보세요 할 때가 많다
  • D : 그걸로도 충분하다고 생각함
  • 미경 : 데이터분석이 필수는 아니라고 생각하지만, 환경구축이 되어 있는 회사라면 꼭 배워보라고 이야기하고 싶다.
  • D : 요즘 다들 데이터 분석에 챌린지를 받고 있는데.. 볼줄아는 분이라면 성장하기 좋다.
  • H : 근데 너무 강박이 있는 것 같다. 분석이라고하면 멋잇고 어려운 수학을 연상하는데, 기획자 수준에서는 1차원 수준의 경향파악만 할 수 있어도 된다고 본다.
  • C : 같은 업계에서 오래 일해서 그런지 예상했던 결과대로 나오더라고
  • H : 분석말고도 할일 많음 ㅋㅋ
  • 미경 : 뭔가 근사한 분석말고 장애분석 같이 영향도 파악하는데에 쓰고있다. 아 그보다 장애를 안내야하는데..

[Z님의 질문] 신입입사를 희망한다. 어떻게 기획을 시작하게 됐나?

  • Z : 이야기를 듣다보니 내가 생각하던 기획보다 더 많은 부분을 고려해야 한다는 사실에 헉했다. 어떻게 기획자를 시작하게 됐나?
  • D : 기획자 참 좋은 직업이라고 생각한다. 만족함~ 나는 나같은 기획자와 일하려면 끔찍할거 같아서 개발자는 못할거 같다
  • 일동 : 나도나도 ㅋㅋ
  • C : 개발자에서 전직한 계기는 내가 기획한대로 서비스 방향이 정해지는 희열이 있었다. 현실은.. 신입기획자는 뽑기 어렵다. 가르쳐야할게 많고.. 요즘 클라이언트 기획으로 구성된 포폴/이력서가 많아서 보다보면 구현을 고려한게 느껴지지 않았던 경우도 있었다.
  • Z : 포폴이 없는데 어떻게 어필해야할지 고민이다
  • D : SI로 시작하는 것도 좋은 방법이다. 에이전시에도 일 잘하시는 기획자분들이 많다.
  • 미경 : 에이전시나 SI 출신들을 서류/면접볼 때 아쉬운 건 운영경험이다. 제안, 플젝진행은 잘하시더라도 실제 운영개선없이 계속 다른 플젝을 연이어 하기 때문에 운영경험을 찾기 어려워서 채용이 힘들다. 만약 SI로 커리어를 시작하기로 마음먹었다면, 운영되고 있는 앱의 릴리즈노트나 업데이트를 분석해보면서 왜 이렇게 개선했고 어떤 부분들이 나아졌는지 끊임없이 분석해보는 훈련을 해보면 도움이 될거다.

Q&A

[Y님의 질문] 주니어 분석가다. 기획직군으로 전직할 수 있나?

  • Y : 지금 업무들이 운영유지보수에 가깝다. 도전적인 신사업 과제를 맡을 때 즐거웠다. 기획자로 일해보고 싶다고 생각했다.
  • 미경 : 데이터 분석출신의 PO 가능하고 충분히 매력적인 무기를 갖고있으니 걱정은 안해도 될거같다
  • H : 지금 커리어가 2년이라면 조금 애매하긴 하다고 생각한다. 분석경험이 많아도 PO로 넘어가기 어렵지 않다. (기획이 분석으로 넘어가는건 어렵다) 그냥 지금 프로젝트 자체가 루즈한거 아닐까?

[Q님의 질문] 신입기획자로 지원중. 왜 떨어지고 왜 붙는지 이유를 알기어렵다

  • 미경 : 따로 연락을?

[W님의 질문] 비즈니스와 프로덕을 동시에 맡고있다. 못보는 부분들이 있어 정보교류를 해나가면 좋겠다

  • (요건 다음 세션에 다뤄보면 좋겠다고 말씀을 못드렸네요)

[V님의 질문] 주니어인데 직전 회사나 제품이 이직에 영향을 주나?

  • 미경 : 결정적이진 않다고 생각한다.. 지금이 8번째 회사인데 두어군데 빼고 전부 망했다. 지금 회사에서 어떻게 내공을 쌓느냐, 어떻게 그걸 다음 이직에 어필하느냐가 중요하다고 본다.

[S님의 질문] 온갖 잡일을 맡아서 하고있다. 포폴이 지저분한데 JD와 맞는 걸 찾기가 어렵다. 어느 포지션에 전문성이 있는지 모르겠다
[N님의 질문] 다양한 일을 하고 있는데 어디로 커리어패스를 잡아야할지 모르겠다

  • 미경 : 같은 질문이라 합쳐도 될것 같아서.
  • H : 사실 특별한일 시킬거 같지만, 막상 들어오면 이것저것 다 하게 돼있다 (ㅋ) 다 잘한다고 써도 된다고 생각한다.
  • 미경 : 커리어를 편집하는 것도 방법이다. 꼭 지원해야 되는 포지션이 있다면 어필하고 싶은거 강하게, 나머지는 약하게 포폴을 정리해보자.
  • 미경 : 또 커리어패스 같은 경우는.. 이일 저일 해보면서 나의 전문성에 맞는 일이 무엇인지 탐색해봐도 될것 같다. 아직 이거다! 싶은게 없다고 불안해하지 않아도 될것 같다.

[M님의 질문] 사수없이 일하고 있다. 나만 없으면 서비스가 더 잘될 것 같다. 일의 한계를 느낄 때 어떻게 극복하나?

  • 일동 : 너무 조심스러워서 코멘트해주기가 어렵다
  • 미경 : 사수없이 일하는 사람들이 대부분일텐데.. 기획자가 모든걸 완벽하게 알아야한다는 생각을 버렸으면 좋겟다. 함께 하는 디자이너 개발자들과 함께 보완하고 채워서 프로덕을 완성하는 거니, 님 대신 어떤 기획자가 와도 완벽하게 할 수 없다. 그러니 자신감을 찾았으면 좋겠다.
  • C : 맞다맞다.. 함께 일하는 사람들고 함께 만들어도 된다. 하다보면 누락도 있고 잘못한것도 있고.. 개발하면서 맞춰나가는 거지.. 개발자들도 개발하고 테스트하면서 수정해나가는 거다.

혹여나 잘못 적힌 부분이 있다면 슬쩍 말씀해주셔도 좋을 것 같습니다. 시간부족으로 급하게 진행된 Q&A가 아쉬워서 다음 방송 테마는 기획자스몰토크#2. 신입은 왜 안뽑아요?(주니어 입사, 이직 등등) 로 하기로 했습니다. 2월 24일(수) 9시에 만나요 🙂

함께 해주셔서 감사합니다!


(노트북으로 실시간 위키 회의록 내리쓰던 습관이 이렇게 유용하게… 노트로도 되는 군?)