＃학습/Lessons Learned

대기업에서 스타트업 이직 후 7개월 차 회고

행복할만큼 2022. 10. 2. 00:01
 

대기업에서 스타트업으로 이직 후 7개월 차 때 쓴 회고 글이다.
(현재는 개인 사정으로 인해 퇴사한 지 9개월이 되었다 ㅎㅎ)

 

대기업 그룹 공채로 입사하여 7년 동안 일한 곳에서 우물 안의 개구리같이 사는 내가 싫어 자괴감을 느낀 것이 여러해.

시장을 경험하고 싶고, 나의 실력을 객관적으로 알고 싶고, 정정당당하게 경쟁하며 성장해보고 싶어서 스타트업 이직에 도전했다.

 

대학원 동기들과 이직 경험을 나누는 워크샵에서 내가 이야기를 하게 되었는데,

어떤 경험을 나누면 좋을까 하고 고민하면서 끄적대다보니 생각보다 길어졌다.

 

내가 했던 고민을 하고 있는 누군가에게도 도움이 될 수 있을 것 같아 이 글을 나눈다.

 

 

 

나는 왜 이직을 결심했는가?

 

💡 권한은 없이 책임과 규율만 가득한 회사에서 벗어나고 싶었다!

 

  • 비효율적인 조직문화, 업무 프로세스, 의사결정 구조
  • 빠른 시장의 변화 대비 끝없는 의사결정 지연
  • 리소스 부족으로 인해 느린 제품 개발
  • 권한/자유도가 없이 시키는 일만 해야하는 구조
    ⇒ 그런데 실패에 대한 책임과 문책은 내게로..
  • 비협력적인 유관부서

위와 같은 환경 속에서 시키는 일만 할 수 밖에 없는 상황 속에서 지금 내가 잘 하고 있는 것이 맞는지? 내 실력으로 앞으로 내가 평생을 먹고 살아갈 수 있을지? 계속되는 의문과 자괴감이 들어 이직을 결심하게 되었다.

(전 회사 동료들은 내가 공채들 중에서도 워낙 충성스러운(?) 스타일이어서, 절대 이직할 줄 몰랐다고들 한다 ㅎㅎ)

 

 

내가 이직할 때 고려한 것

  • 전통 대기업이 아닌 IT 베이스의 스타트업으로 간다
  • 에이전시가 아닌 자신의 플랫폼을 운영하는 회사로 간다
  • 이미 성공한 플랫폼이 아닌, 아직 자리잡지는 못했지만 투자 의사와 목표가 강렬한 회사로 간다
  • 서비스적 관점의 의사결정을 내릴 수 있는 대표 및 임원 마인드, 자금력이 뒷받침된 회사로 간다
  • 이윤창출이 아닌 가치창출을 목표로 하는 곳으로 간다
  • 데이터를 중시하고 비즈니스/서비스 다각화를 할 수 있는 비전이 있는 곳으로 간다
  • 산업 도메인의 성장 가능성이 있는 곳으로 간다
  • 인재를 대우해주고 중시하는 곳으로 간다
  • 나의 업무 경험을 살릴 수 있는 B2B or Seller Side or Back Office Side로 간다

 

 

 

지금 내가 하고 있는 일

Product Manager 역할

  • 신규/개선 개발 요건, 긴급 오류대응에 대한 우선순위 및 의사판단
  • TF 내 개발 리소스 관리
  • 내/외부 이해관계자들과 협의 및 커뮤니케이터 역할
    - 리더 : 로드맵에 따른 조직 구조, 인력 수급 협의
    - TF 내부 : 조직 문화, 업무 프로세스, 일하는 방식, 우선순위 협의 방식 세팅
    - TF 외부 : 개발팀, 다른 기획자, 디자이너, 커머스사업팀, 재무회계팀, 마케팅팀, 제품운영팀

 

기획자 역할

  • 상위 기획부터 상세 기획까지 진행
    - 상위 기획 : 메가 프로세스, 커머스 운영 정책서
    - 상세 기획 : 요구사항 수집, 기능 요구사항 정의, User Story, 업무 프로세스, 화면설계서, 운영 정책 협의, 테스트 케이스 및 시나리오, 매뉴얼 작성, 테스트(QA) 진행, 배포일정 협의, 배포로 인한 유관부서 업무 변화관리

 

 

스타트업(현 회사)에 와서 경험한 것

커머스 플랫폼 제품 완성 및 고도화 경험 

  • 제품 범위 및 완성품의 기준 (Fundamental) 수립
  • 커머스 서비스/비즈니스를 위해 필요한 전체 제품 목록 정리
  • 제품 로드맵 작성 및 실행
  • 다양한 요건에 대한 기획/ Product Managing 경험
  • 산재한 정보를 구조화하여 의미있는 산출물로 만드는 경험
  • 암묵지로 존재하거나 흩어져있던 정책, 프로세스를 하나의 관점으로 정리하고, 실제 업무에 적용하여 안정화시키는 경험

 

Data Driven Thinking 경험

 

😂 Data 기반 의사결정, 우선순위 결정 … 을 할 수 있을 줄 알았다. 
#이상과 현실의 괴리

 

  • 비즈니스/서비스의 긴급도에 의해 우선순위가 결정될 수 밖에 없는 구조
  • 그나마 내가 리소스가 제대로 사용될 수 있도록 관리할 수 있는 포인트?
    - “진짜 사용될 기능”에 대해서 리소스를 투여하는가?
     ⇒ 이 기능에 대한 어떤 Action Plan 을 갖고 있는가?
    - 리소스 투여로 인해 어떤 효과/성과를 명확히 낼 수 있는가?
     ⇒ 어떤 지표를 Targeting 하고 있으며, 얼마나 올릴 수 있는가?
  • 당장 사용하진 않더라도, 제품 고도화 시점을 대비해 연마중!
    - SQL, Tableau 공부중!

 

Agile 개발 방식 경험

  • 요구사항 수집 내용에 따른 개발/배포가 아닌, 요구사항을 더욱 세분화하여 업무 목적에 따른 MVP 요건 단위 별 개발/배포
    • ex. 간편결제 요건 : 주문상세 내 결제수단 및 실 결제금액 영역 추가 ⇒ 토스 오픈 ⇒ 페이코 오픈 ⇒ 네이버페이, 카카오페이 오픈 ⇒ 정산내역/정산상세내역 화면 개선 ⇒ 결제대사 화면 신규 추가 각각 배포

 

스타트업의 일하는 방식 경험

  • 빠른 문제 정의와 문제 해결

 

🤣 이가 없으면 잇몸으로..
빠르게 해결해야되다보니, 자연스럽게 향상중인 역량!

 

1)고객, 입점사, 관리자의 요구사항 이해
2)문제 정의
3)기술적 해결방법 or 운영적 해결방법 or 정책적 해결방법 필요여부 판단
4)유관부서 또는 담당자에게 전달하여 구체적인 해결 방안 도출하도록 함
5)방안이 여러가지일 경우 가장 리소스가 적고 부정적 영향도가 적은 방식으로 결정
6)실행되도록 함
- 즉시 실행 가능할 경우 : 실행
- 즉시 실행 불가능할 경우 : 장애물 제거 후 실행 (우선순위 협의, 정책 협의, 이해관계자 설득 기타 등등)

 

  • Sync 문화
🤣 주간회의 정도만 하던 나에게는 낯선 문화였지만,
하나의 서비스를 바라보며 유기적으로 업무를 진행하기 위해서는
필수불가결이라고 생각되기도 하는 문화!
그래서 회의가 정말 너어어어어어무 많음. 심각함.

 

- Daily Standup을 통해 밀착 업무 내용 공유
- 수시로 슬랙 메세지로 업무 진행 상황, 변화사항 공유
- 아주 작은 핀트의 어긋남까지도 허용치 않음 (이를 맞추기 위해서 또 다시 미팅)

 

  • 암묵지의 정책화
🥰 암묵적인 기준에 따라서,
눈치껏 맞춰서 해야만하는 경우가 많았던 나에게는
너무나 속시원했던 일하는 방식!

 

- 업무 프로세스, 업무 Tool 등, 모든 일하는 방식이 암암리에, 눈치껏, 리더의 입맛에 맞도록 처리되지 않음
- 암묵적으로 이렇게 해야한다~는 기준은 절대 기준이 되지 않음
- JIRA 티켓의 상태값을 변경하는 기준까지도 모두 협의 대상!
- 암묵지까지도 정책화, 프로세스화 하고, 추상적인 영역에 대해서까지 명확하게 명문화하거나 언급해서 수면 위로 띄우고, 협의를 통해 결정하고 넘어가는 방식

 

5. 다양한 업무 Tool 연마

 

😅 업무 Tempo가 워낙 빠르다보니
반 강제적으로 새로운 Tool 을 배울 수 밖에 없는 구조..!

 

  • 사용 중인 Tool
    - Slack : 업무 커뮤니케이션
    - Gather : 업무 커뮤니케이션 (재택근무지만 사무실에 있는 느낌..)
    - Notion : Task 관리, 회의록 관리, 비즈니스 및 서비스 정책 관리, 산출물 Wiki 관리
    - MIRO : 기획서 작성 시 유용한 Tool (PPT 대체 가능)
    - JIRA : 개발자 요건, Backlog 관리
    - Confluence : 개발자 테크 스팩 등 기술 정책서 관리
    - Redash : Query, 대시보드
    - Google Drive/문서 : 파일 공유
  • 앞으로 더 배워서 활용하고 싶은 Tool
    - Tableau
    - Figma or Adobe XD

 

6. 문책성/책임회피성 문화가 아닌 자율적/협력적인 조직문화

 

🥰 “문제는 일어날 수 있다.
하지만 우리는 문제를 함께 해결할 수 있다!”

 

  • 업무에 도전적인 목표를 가지고 있는 구성원들이 모인 조직이기에, 토스만 하지 않음
  • 명확하고 합리적인 근거가 있고, 목표가 명확하다면 모든 유관부서들이 협력
    ⇒ 단. 우선순위에서 밀릴 수 있다는 것은 함정…
  • 빠르게 업무 처리를 하다보니 문제/이슈가 생길 수 있음을 이해함
    (그렇다고 아무렇게나 해도 된다는 의미라고 생각하는 사람은 거의 없음)
  • 매 순간의 제약 조건 하에서 최선을 다해 노력했음에도 불구하고 생긴 문제/이슈는 함께 협업하여 해결

 

7. C레벨의 중요성 체감

  • 비즈니스/서비스의 시점 별 C레벨의 의사결정이 서비스/사업의 성공을 좌우
  • 향후 내가 어딘가로 또다시 이직한다면 반드시 고려할, C레벨에 대한 판단 기준이 생김

 

8. 동료평가 / 피드백

  • 동료들과 협업을 잘하기 위해 어떤 부분을 개선해야할지 허심탄회하게 이야기를 나누는 부분에서는 좋았음
  • 그러나 평가가 어떻게 성과/보상으로 이어진다는건지.. ? 명확한 기준이 없었음.
    ⇒ 일단 정기 평가/보상 책정 시기를 기다려봐야할듯!

 

 

스타트업(현 회사)에 와서 느낀 한계

기술부채로 인해 Fundamental 이 없으니 고도화된 생각을 할 수 없다

 

🤣 서비스를 급하게 올린 스타트업들의 공통적인 운명..

 

  • Agile / Lean 을 외치지만 규모가 급성장하면서 기술부채가 발목을 붙잡는 이런 상황에서는 오히려 Waterfall 보다도 개발 속도가 느릴 수 밖에 없는 구조.
  • 추가 리소스를 아무리 많이 확보한다고 하더라도 제품의 누수를 잡지 못하면 제품을 개선 하는데에 예상보다 더 많은 비용이 필요할 것으로 보임.
  • 앞으로 제품 완성을 위해서는 신규 기능 개발 보다는 최대한 빠른 시간 내에 향후 확장성을 고려한 제품 Fundamental을 만드는 것이 반드시 필요한 전제조건이 될 것으로 보임.

 

중개 BM 만 운영하는 플랫폼으로서 물류/WMS 과 연계된 커머스 프로세스를 볼 수 없다

  • 직매입 BM과 중개 BM을 모두 운영했던 전 회사에서는 물류/WMS 까지 연계된 커머스 전체 주문/배송 프로세스를 업무 범위로 가지고 있었기에, 관점이 좀 더 넓었던 것 같음.
  • 직매입 BM을 가지고 있는 플랫폼에서는 물류 비용에 의한 유지관리 비용 및 재고 관리, 반품/교환 등의 CS 과정, 손실 관리 등 다양한 업무 프로세스의 경험을 할 수 있으나, 중개 BM의 경우 해당 책임이 입점사에 있으니 아무래도 해당 업무에 대한 기능/정책적인 Develop을 하는 데에 업무 우선순위를 할당하지 못함
  • 커머스 플랫폼 Product Manager 로서는 해당 업무 역량이 중요한 부분이라고 생각하기 때문에, 계속 갈고닦을 수 있는 기회가 필요.

 

🤣 나의 직무에서
내가 어떤 포트폴리오를 꾸려갈지,
어떤 도메인에서 핵심 역량을 키워갈지에 따라
이직할 회사 또는 사업을 선택하는 것이 중요하다는 깨달음!

 

Back Office/Backend Only Side에 대한 권한만으로는 서비스의 변화를 일으키기 어렵다

  • 도메인 단위로 Vertical 한 업무 범위를 가져가야 업무를 자율적으로 진행할 수 있음
  • 이해관계자를 기준으로 업무 범위를 쪼개서 Horizontal 하게 진행하려 하니 서로 Dependency가 커서 자율적 우선순위 할당 및 협의 자체가 어려움
    ex. App (고객 관점) 은 쿠폰 기능을 개선할 필요성이 대두되고 있는데, Backoffice (판매자/관리자 관점) 은 주문/배송 영역을 개선하고자 하는 필요성이 더 크다면?
  • 서로 영향도가 너무 커서 함께 업무를 하기도 어렵고, 그렇다고 따로 업무를 하자니 정책이 짝짝이가 될 가능성이 높음

 

💡 내가 맡은 업무 범위 내에서는
최대한 자율적 의사결정으로 업무를 진행할 수 있는 조직 구조가 만들어져 있는지가
정말 너무너무 중요!

 

어디서든 정치는 해야한다

  • 인간관계에 기댄 정치가 아니라, 성과를 위한 논리적 정치, 근거가 있는 정치가 필요.
  • 내가 이루고 싶은 성과/목표를 설정하고, 그 성과/목표를 해야하는 당위성을 만들어야하고, 리소스 할당을 받아내야하고, 의사결정 협의체 안에 들어가야하고, 협의체 구성원들을 설득할 논리가 있어야 하고, 의사결정자의 우선순위에 들어가야함.

 

🤣 이 부분은 앞으로 내가 어떤 회사를 들어가든지
성과를 만들어내기 위해
어쩔 수 없는 부분이라고 생각함!

 

 

결론 : 만족 or 불만족?

70% 만족, 30 % 불만족

  • Why?
    • 일단 전 회사 (대기업) 을 나온 것에 만족함.
    • 후생 조건에 만족해서 고인물이 되지 않기 위해 내가 내 자신의 퇴로를 차단한 것을 자랑스럽게 생각함.
    • 스타트업의 일하는 방식이나 기타 등등에는 기대했던 것에 못미치는 것이 많았지만,
      그럼에도 불구하고 스타트업이 어떤 일하는 방식을 갖고 있고 어떤 시스템과 문화로 일하는지 도전해보지 않았으면 절대 몰랐을 것이라고 생각함.
    • 앞으로 나의 미래를 더욱 명확하게 다듬어나갈 계기를 얻었다고 생각하기에 만족하는 면이 더 큼.

 

 

앞으로 내가 시도할 것!

제품 Fundamental을 2022년 1분기 내 완성

  • 실패하여 Drop한 구축 프로젝트에서 완성시키지 못한 Fundamental을 완성시키기
  • 제품의 로드맵을 실행시킬 수 있도록 자원 총동원
  • 제품의 시기별 적절한 Action을 판단할 수 있는 판단 능력 기르기
  • Agile Prodcut Management 조직 구조, 일하는 방식, 업무 프로세스 등을 더욱 다듬기

 

Data Driven 의사결정을 통한 제품 개선 진행

  • 설득력이 곧 우선순위 할당! 설득력의 근거는 데이터!
  • 요구사항을 제안하는 사람도, 실행하는 나 조차도 데이터를 기준으로 커뮤니케이션 하도록 유도하기
  • 2022년 1분기 전까지 SQL, Tableau 열심히 공부하기!
  • 자유자재로 A/B 테스트 가능한 기술적 환경과 업무 프로세스 만들기
  • 현업에서 보고 있는 지표, 대시보드 등 숙지하기!

 

앞으로 내가 경험해보고 싶은 업무

  • 현 회사에서는 Product Manager 는 조금 더 기술지향적인 측면이 있는데, Product Owner 나 조금 더 사업 지향적으로 가보는 것이 서비스적 변화를 일으킬 수 있는 권한이 있을 것으로 보임
  • App / Backend Side 까지 함께 개선할 수 있는 업무 범위를 가져가서 자율적으로 업무를 진행할 수 있는 구조로 Setting 필요

 

향후 나의 비전, 내가 해결하고 싶은 시장의 문제가 무엇인지 정하기

  • 꼭 커머스 플랫폼이 아니더라도 사람들에게 도움이 되는 서비스를 만들어보고 싶다
  • 내가 진짜 해결하고 싶은 문제가 무엇인지 고민중
  • 내가 해결하고 싶은 문제가 뭔지 정하고, 그에 필요한 핵심 역량과 경험, 포트폴리오를 쌓을 수 있도록 해야할 것 같다

 

 

 

이렇게 정리하면서 그동안 추상적으로만 느꼈던 답답함과, 내가 삽질하고 있는 것은 아닌가? 하는 의문들도 해소되고,

그동안 나는 어떤 경험을 했으며 어떤 것을 배웠고, 어떤 한계를 느꼈는지 회고하고, 앞으로의 업무 방향성을 잡아갈 수 있었던 시간이었던 것 같다.

답 없는 불평 불만으로 가득한 것이 아니라, 이 시간을 어떻게 활용하여 앞으로 어떤 방향성에 나의 시간과 노력을 투여해야할 것인지 정리해볼 수 있어서 특히 좋았다.

 

부디 누군가에게도 이 글이 도움이 되기를 바란다.