3년간의 프리랜서를 끝내고 메이커가 되다

좋은 소식을 전합니다.🕊🍀.∘ 프리랜서 3년 생활을 마치고 새롭게 Product Owner로 이직했습니다.

원래 인하우스 서비스기획자로 있다가 프리랜서를 시작한 이유는 내가 잘 할 수 있는 산업과 일이 무엇인지. 내가 나답게 있을 수 있는 조직과 환경을 천천히&신중히 찾기 위해서 였습니다.

 내가 좋아하는 일과 잘하는 일이 다르다는건 알겠는데 도대체 내가 잘하는 일이 무엇인지 감이 잡히지 않는 단계에서 섣불리 이직을 하면 또 얼마안가 채용사이트 구경할게 뻔했기 때문입니다.

쉬면서 찾다가는 업무 감각을 잃어버릴것 같았고, 기약없는 공백기를 갖기에는 생활비가 필요했습니다. 이 상태로는 희망연봉을 부를 자격도 명분도 없다 판단했으니까요.

3년...오래 걸렸습니다. 3년동안 다양한 형태의 회사에서 프로젝트도 경험해보고 여러 회사로부터 지원도 제안도 받아보았습니다. 너무나 아쉽게 떨어진곳도 있었고 프리랜서 경험은 우리회사에 도움이 되지 않는다. 너는 경력이 조각조각나서 필요없다는 말도 들었습니다.

반면 너무나 과분하게도 저를 좋게 봐주시고 꼭 와달라고 좋은 조건을 제시해 준 곳도 있었습니다. 그래도 뭔가 아쉽고 부족한것이 있는데...그것이 뭔지 스스로도 답을 내리기 어려워 가지 않았습니다.

작년...인생에서 가장 몰입했던 분야가 있었고, 몰입하는 과정 중에 프론트개발자와의 팀웍이 기억에 남습니다. 계약기간 등등 여러 사정으로 아쉽게 그 일을 더 할 순 없었지만 제게는 잊을 수 없는, 좋은 경험들이었습니다. 기획자인 나도 개발자도 같이 성장하고 함께 원팀이 되어간다는 느낌을 많이 받았습니다. 그제서야 내가 할 수 있는 일들과 도메인이 뚜렷해져가는 느낌을 받았습니다.

한번도 찾아다니지 않던 무언가를 발견했는데,  그것이 내게 항상 결여되어 있었다는 것을 확신하게 될 때.

나도 모르게 간절히 원하고 있던 것이 그 회사에는 있었을 때..그 때 이직의 확신이 든다고 생각합니다. 

제게 결여되어 있던 것은 동료와 팀웍, 그리고 그들과 함께 일할 때의 즐거움과 그릿, 그리고 인정이었던 것 같습니다. (프리랜서는 고독하기에 이런 것을 누리기 매우 어려웠습니다.)

3년동안 제가 찾았던 회사의 조건은 이렇습니다.

- 도전적인 문제가 준비된 환경

- 문제 해결에 오롯이 몰입할 수 있는 팀 분위기

- 서로 믿고 시너지를 낼 수 있는 동료

- 문제를 어떻게든 해결하겠다는 그릿

- 일본시장에서의 포텐셜이 보이는 제품

- CEO와 CTO가  '기획'과 기획자를 대하는 태도

  (단순히 내 말 들어주는 사람, 화면그려주는 사람이라 생각하지는 않는지)

내가 선택한 이 길이, 어쩌면 잘못된 선택일수도 있습니다. 생각치 못한 이슈나 문제들이 생겨날수도 있고, 실망하거나 자책할수도 있습니다. 프리랜서라는 고수익(?)을 버리고 출근거리도 멀어지는 등 내게 불리한 것도 있습니다. 복지나 재택근무도 언젠가 사라질수도 있고 정말 잘 맞는 동료가 퇴사할수도 있습니다. 걱정과 불안은 끝이 없어서, 이 선택을 하는데 있어 한달동안 정말 많은 고민을 했습니다. 그럼에도 불구하고 내가 추구하는 가치가 무엇인지 중요도에 대한 메타인지가 반드시 있어야 한다고 생각합니다. 아직 아무것도 모르지만 두번의 인터뷰를 통해 느꼈던 그 확신이 맞는지 점검하는 과정이라 생각하고 지내볼까 합니다. 

결론은 내가 이 회사에 들어가고 싶은 이유. 즉 나만의 조건을 반드시 정하자 입니다. 그것이 연봉이 될 수도, 통근거리, 복지가 될수도 있겠지만 가급적 하루 8시간 이상 있는 공간에서 내가 행복해지기 위한 조건을 충족해야 후회가 덜한 이직이 되지 않을까... 생각이 듭니다.

여담이지만 (이 글을 본다면)

내가 할 수있는 일과 하고 싶은 일을 명확히 찾을 수 있고, 확신을 갖게 만들어준.. 그 때 같이 일했던 프론트개발자 분에게 고맙다는 인사를 남깁니다.

🍗치킨은 비싸도, 늦어도 괜찮다.강렬하게 맛있기만 하다면..

인하우스 4년, 프리랜서 3년동안...운영기획,서비스기획, PM, PL, PO, 화면그림쟁이(...)등 별명을 달고  여러 회사의 프로젝트를 경험하면서..
MVP/프로토타이핑이란 무엇인가. 그것은 왜 만드는가에 대해 
프로덕트 메이커로서 느낀 바가 있어 가지고 공유 합니다. 

우리가 만드는 제품이 가령 치킨이라고 칩시다.
(한국 전통음식인 치킨을 택했습니다.🍗‪)
치킨을 사서 먹어주는 고객 입장에서는, 치킨을 주문할 때 무엇을
가장 중요하게 볼까요?

Quality (질): 맛있다
Delivery (납기): 빠르다
Cost (비용): 싸다

이게 우리가 진짜 풀 가치가 있는 문제입니다.

반대로 문제를 풀지 못했을 때 발생하는 불만은 
"맛없다", "느리다", "비싸다" 입니다.

이를 4분면으로 나눠서 구분해 보았습니다.

하지만 스타트업은 돈이 없고, 시간이 없고, 사람이 없다는 이유로 
"맛없다", "빠르다", "싸다"😵를 택하곤 하지요.

"빠르게 만들어서 일단 고객한테 보여주자"가

MVP 혹은 프로토타이핑이라고 알고 있으니까요.
(간혹 "맛없다", "싸다", "느리다인" 인 경우도 있습니다. 제품출시일이 계속 늦어지거나, 고객클레임을 방치하는 경우입니다.)

"우린 시간과 돈이 부족하니까 맛은 좀 없지만 저렴한 치킨부터 팔거야. 
맛은 천천히 개발해도 돼! 그러면서 고객 피드백을 받아가며 점차 개선해 나가자!" 
라고 스타트업은 말할 수 있습니다.
 

그러나...아무리 싸도, 아무리 빨라도 결국 맛이 없으면 
그 치킨은 계속 사먹지 않는 것 같습니다.
어떻게 해야 옆집 치킨집은 더이상 기억이 안나도록 맛있는 치킨을 만들까? 를 고민하는 것이 중요하다고 생각합니다.

만약 그 스타트업이 만든 제품이 시장 특성상 고객에게 제공되어야 하는 데이터 품질이 좋아야 한다면 UX니 기능이니 가입과정이니 사실은 다 부질 없을지도 모릅니다. (완전 부질없는건 아니지만)

데이터 그 자체만으로도, 고객에게 필요하다고 느끼면 
고객은 사이트가 구려도 계속 사용할 것입니다.
그러니 너무 기능이라던가, 사이트를 만들다던가, 하는 것에 집착하지 않아도 될 것 같습니다.

여러분이 만들고 있는 제품은, 혹은 회사의 제품은 지금 어느 위치에 있나요? 
혹시 "맛있다" 보다는 "빠르다"에 집중하고 있지는 않나요?

노코드로 빠르게 검증하는것도 좋지만, 그 제품을 써야만 하는 이유를 메이커가 설명할 수 없다면....즉 그 제품이 매력이 없다면... 아무리 빠르고 저렴하더라도 사용자는 두번 이상 이용하고 싶지는 않을것 같습니다. 이미 눈이 높아진 고객이라면 더더욱...

문제를 해결했을 때 고객이 느끼는 감동과, 
그 문제가 풀 만한 가치가 있는 문제였을 때...
즉 진짜 맛있는 치킨을 만들 수 있는 방법을 찾는 게 
MVP이자 프로토타이핑이었다는걸 깨달았습니다.

제품을 만드는 사람이라면, "어떻게 하면 다른 치킨은 생각이 안 날 정도로
우리치킨에 강렬한 맛을 심어주게 할까?"에  집중해보도록 합시다.

여러분이 지금 만들고 있는 제품의 
"맛있다"는 
무엇이라고 설명할 수 있나요? 
설명을, 할 수 있나요?

[여담]
다 그렇진 않겠지만 캐시플로우가 없고 기술혁신이 퇴화된 B2B SaaS의 경우
"맛없다", "느리다", "싸다" 구간에 있는 것 같습니다.
제품개선이나 로드맵은 느리고 소구포인트는 없지만 가격으로 승부하니까요.

PM(기획자)인 내가 함께 일하기 좋아하는 개발자는

바로 제품중심으로 생각할 줄 아는 개발자이다. (Product-Minded Software Engineer)

"나쁜 엔지니어들은 기술에만 너무 집중합니다. 훌륭한 Product Engineer들은 사랑 받는 제품을 만들기 위해 제품 개발 과정에서 적절한 깊이로 고민 해야 한다는 사실을 압니다."

Shopify의 head of engineering인 Jean-Michel Lemieux은 Product Engineer를 위와 같이 정의했다.

나는 기획이라는 업을 한 지 약 7~8년차가 되었고, 프리랜서/인하우스 둘 다 경험해 보았을 때

다양한 스타일의 개발자들을 만나왔다.

사람의 성격이나 성향, 기질은 둘째 치고 함께 일할 때 즐거움을 주었던 분들의 특징은

바로 제품에 대해 "생각"이라는걸 할 줄 안다는 것이었다.

내 경험이다만, 일단 제품 중심 개발자는 질문하는 것도 행동하는 것도 달랐다.

• 이 기능이 왜 필요한지 정확히 이해하기 위해 많은 질문을 던진다.

• 이를 테스트하고 수정된 사양에 포함된 일부 제안을 가져온다.

• 빠르게 기능을 구축하고 피드백을 얻는다.

• 기능을 출시한 후에도 예상과 일치하는지 계속해서 확인한다.

• 예상과 달랐을 때, 결과를 깊이 파고들어 실제 세계에서의 제품 사용에 대해 새로운 것을 배운다.

(주니어이지만 위 1번부터 5번 모두 해당하는 개발자 분이 계셨다. 그 사람의 개발실력이 어떻든 간에 만약 내가 창업을 한다면, 가장 먼저 영입 하고 싶은 분이기도 하다.)

반면 "기획서 나오면 검토할게요". "안됩니다." "6개월 이상 걸립니다." "기능정의서 먼저 주세요." "화면 보고 얘기하시죠." "그때 자세히 못봤는데 지금 보니 이거 못합니다." 라는 대답만 나오는 개발자와는 그닥 즐겁게 일하지는 못했던 것 같다.

제품 중심으로 생각할 줄 아는 개발자는 각 프로젝트 이후, 제품 이해력이 깊어지고 더 나은 제품 직감력을 개발하기 시작한다. 길가에 그냥 지나쳤던 나무가 플라타너스 나무로 보이듯이, 감각이 생기면 문제 해결도 빨라지고 수월해진다. 이 과정에서 제품 중심 개발자는 더 많은 커리어 성장 기회를 얻는다.

📌 제품 중심 개발자가 되기 위한 팁

사용자가 있는 제품을 개발하고 있다면, 제품 중심 마인드를 키우는 데 도움이 되는 몇 가지 팁이 있다. 이러한 팁은 제품 중심 개발자로 성장하는 데 효과적인 것으로 보인다.

(아티클 원문에서 내가 깊게 공감하는 것만 뽑아 봤다. 약간 수정포함)

1. 회사의 존재 이유를 이해하기.

비즈니스 모델은 무엇인가? 어떻게 수익을 창출하나? 어떤 부분이 가장 이윤이 많으며 어떤 부분이 가장 확장되고 있나? 왜 그럴까?

2. PM과 좋은 관계를 구축하기.

대부분의 PM은 개발자를 멘토링할 기회에 기뻐한다. (말걸어주면 기쁘다.) 개발자들이 제품에 관심을 가지면 자신의 역량을 확장할 수 있다. 물론 제품 관련 질문을 많이 하기 전에 좋은 관계를 구축하고, PM에게 제품에 더 많이 관여하고 싶다고 분명히 전하는 것이 좋다.

3. 타당한 제안 제시하기.

비즈니스, 제품 및 이해관계자에 대한 좋은 이해를 갖게 된 후에는 제품 개발에 대한 이니셔티브를 가져갈 수 있다.

4. PM(기획자)에게 피드백 자주 요청하기.

훌륭한 제품 중심 개발자가 되기 위해서는 기존의 엔지니어링 기술에 더해 제품 기술을 개발해야 한다. 제품 기술에 대한 당신의 성과를 어떻게 평가하는지 가장 잘 아는 사람은 PM(기획자)이다. 제품 제안이 얼마나 가치 있는지에 대한 피드백을 얻고, 추가 성장을 위한 아이디어를 얻기 위해 PM에게 연락한다.

물론 저런 것이 적성에 맞지 않고 도저히 힘든 사람들도 있기에 이 세상 모든 개발자에게 강요할 수는 없을 것이다. 어디까지나 내가 맞는 직군, 내게 맞는 회사나 조직, 프로젝트에 맞춰서 일하면 될 것이다. 내 의견이 반영 되는 것이나 주도적으로 일하는 것이 버거운 사람도 있는 것일테니 말이다.

(그렇다면 프리랜서나 SI/SM을 추천한다. 불안정하지만, 오히려 월 단가는 훨씬 더 높다.)

커리어를 건강하게, 차곡차곡 쌓아 올라가고 싶은 사람에게는 제품개발 사고능력이 필수라고 본다.

나는 그런 개발자와 함께 일하고 싶다.

원문: https://eopla.net/magazines/6578

나는 생각하는 사람💁, 너는 만드는 사람👨‍💻

[나는 생각하는 사람(PM), 너는 만드는 사람(개발)이라는 인식을 버리고 모두가 제품에 책임감을 갖는게 당연한 팀을 만드는 방법]

PM/PO는 미니CEO라고 불려지며 책임과 권한을 갖고 분석도 해야 하고 어려운문제에 답도 내려야한다.
그러다보니 솔직히 너무 바빠서

“나는 생각하고 결정하는 사람, 당신은 만드는 사람”과 같은 마음이 자라나게 된다.

💁 PM: 시장분석, 고객인터뷰, 로드맵, 가설수립, 전략같이 깊게 고민하고 글 쓰는건 제가 할테니 여러분은 개발과 구현에 힘 써주세요!

👨‍💻👩‍💻🧑‍💻Dev: 넵 기획서나오면 개발하겠습니다.

분업이라는 것은 가장 효율적인 업무방식이고

이렇게 일하는 것이 결코 나쁘다는 것은 아니다.
서로 각자가 잘하는 것에 최선을 다해 업무에 임하고 있는 것이니 말이다.

그러나 개발자는 작업자(만드는 사람)입장이다 보니 무엇을 만들어야 할 지 input 되지 않으면 지금 당장은 할 것이 없는 것처럼 느껴진다. 그래서 의도하지는 않았지만 이런 사이클이 익숙해지면 점점 PM, 기획자와 이야기할 시간이 줄어들고, 결국 그들이 만들어 줄 산출물(최종본)이나 계획을 기다리게만 된다.

예컨대 이런 것이다.

• 우선순위와 백로그 선정해 주시면 만들게요.

• 스펙이 정해지면 만들게요.

• 기획서부터 주세요 그럼 검토할게요.

• 피드백주시면 그 때 수정할게요.

• 구체화 되지 않으면 공수 산정이 어렵습니다.

• 우리 다음 달에 뭐 해요? (….)

• 기획이 충분하지 않으니 다시 만들어오세요.

그 업계의 전문가이거나..고객과 동일선상에 있던 PM/PO라면 적절한 아웃풋을 내놓겠지만, 도메인이나 산업기술지식이 부족한 사람이라면.. 혹은 프로젝트 경험이 적거나 혼자 작업하는 것에 익숙했다면…무엇을 만들어야 하는지..무엇이 중요한지 사실 솔직히 "모른다.“ 혹은 업계에 대해 "어설프게" 알고 있다. 고객경험이 적다는 뜻이다.

사용자가 되어 본 적이 없거나 사용자에 대한 깊은 공감 없이 접근했다는 말이다. (늘 판매자 입장이었지)

잘 몰라도, 어차피 애자일은 답을 찾는 과정이니까. 몰라도 일단 실행이 중요하다고 배웠으니까…잘 모르겠지만 일단 뭐든 빠르게 만들고 결정하고 실행한다.

그리고 이걸 점차 반복하기 시작하면…이게 디폴트가 된다.

• 잘 모르겠지만 일단 결정해 준다.

• 잘 모르겠지만 일단 대답한다.

• 잘 모르겠지만 수정 요청이 들어오면 그 때 고민해 본다.

• 잘 모르겠지만 일단 피드백을 준다.

• 잘 모르겠지만 어디까지나 개인적인 "의견"을 준다.

그리고 의도치 않았지만 묘한 갑을관계가 되어간다.

이로서 보스형PM(리더), 노예개발자가 만들어졌다.

어쩌다 이렇게 되버린걸까? 누구 잘못인걸까?

사실 누구도 잘못하지 않았다. PM도 개발자도 각자의 R&R을 준수한 것 밖에 없다.

커뮤니케이션 방향이 어디에 있는가?

PM과 개발자의 커뮤니케이션은 서로를 바라보고 있다. (상대방이 요청하면 나는 준다. 내가 주면 상대방은 다시 요청한다)

우린 사실 바쁘다는 핑계로, 제품책임자로서

내가 못하는걸 상대방에게 " 지나치게 의존" 하고 있던건 아닐까? (나는 개발자도 제품책임의 의무가 어느정도 있어야한다고 생각하기에 여기서 말하는 제품책임자는 팀원 모두이다.)

우리 팀은 무엇을 바라보고 일하나요?보다 좋은 제품을 만들기 위해서는 PM도 개발자도 같은 방향을 바라보고 있어야 한다.

고객이나 프로덕트를 바라봐야 한다는거다.

우리가 타깃으로 잡은 고객이 원하는 것은 무엇인지. 우리에게 돈을 지불하게 하려면 어떤 프로덕트를 만들어야 하는지.
제품의 현 상태를 "같이" 바라보고 합을 맞춰야 한다.

개발자는 어떤 자세로 있어야 할까?

제품개발이나 사업기획에 함께 투입 되는 개발자는 흔치 않을 것이다. 하지만 산출물 자체에 의지하고 있다보면 PM,PO,기획자가 하고 싶은 것을 만들어 주는 손과 발 역할로밖에 있을 수 없다. 그래서 여건만 된다면

• 인셉션 덱, 린캔버스를 함께 만들어 간다.

• 제품백로그 아이템사양을 PO와 함께 생각하는 시간을 갖는다.

• 스프린트 플래닝에서 우선순위 백로그 아이템을 함께 생각한다.

• 유저 테스트 결과를 같이 보면서 대응방법을 같이 논의한다.

사실 (비개발자인)기획자인 내 입장에선 이게 되나? 싶은 것들이 많아서, 잘 모르겠지만 일단 기획을 진행하는 경우가 많았다. 그래서 개발자는 기획자가 잘 모르고 애매한 부분이 있을 때 가능한 같이 고민을 얘기하고, 대화해 나가주면 좋겠다.

"개발자는 코딩만 하면 되는거 아닌가요?" 라고 되묻는 사람도 있을 수 있다. 비즈니스에 참여하는 것이 싫은 개발자가 많다. 뜬구름 잡거나 아름다운 미래만 얘기하는거 같아보일테니 그럴 것이다. 왜 그러는지 아는가? 사실 PM도 제대로&잘 몰라서 그런거다. 고객과 미팅해도 알까말까인데 자기 생각만 고집하거나 자기가 만들고 싶은 것만 만들고자 하는 PM은 고객이 원하는게 뭔지 애매하고 몰라서 그런거니

잘 모르는 사람들끼리 설령 실패를 하더라도 가급적 팀원이 서로 모여 머리를 맞대고 고민해야 한다. 그래야 배울 것이 있는 실패를 한다. (매도 같이 맞는게 낫다)

PM의 “잘 모르는데 이 정도면 되겠지” 라는 마음으로 어설픈 역할 분담을 하게 되면...즉 제품메시지가 전달이 되지 않은 상태에서 기능이나 "만드는 것"에만 집중하다 보면
어느 순간 아무도 안 쓰는 제품을 만들고 있게 된다. (경험담)

본 내용은 Regional Scrum Gathering Tokyo2023 (RSGT 2023)에서 mori yuya씨가 발표한 “나는 생각하는 사람, 당신은 작업하는 사람 (중략) ”이라는 세션을 풀어 쓴 글이다. (원본) 발표 시간 40분, 300페이지가 넘는 방대한 내용에도 이해하기 쉬운 단어와 일러스트로 단숨에 빠져든 글이었다. (다만 너무 양이 많아 인쇄 해서 두고두고 봤음 좋겠다. 책으로 만들순 없나? 내가 번역해서 출간 의뢰해볼까?)

내용은 길지만 문장 자체는 초급과 중급 사이의 일본어 수준이니 일본어를 배우고 있는 사람이라면 읽어보는 것도 좋겠다.

내가 지그재그 일본사업PM을 그만 둔 이유

저는 2021년 2월 2일 카카오스타일 (지그재그) 일본신사업부를 퇴사하고 프리랜서의 길을 걷게 되었습니다. 벌써 2년이 지났습니다. 인터뷰를 하든, 커피챗을 가지든, 항상 나오는 화두가 왜 지그재그를 (그렇게 빨리) 그만 두었나? 인데요.
개인사유나 내부 사정, 니탓내탓 등 블레임은 최대한 배제하고, 직무/시장 관점에서 퇴사한 이유가 무엇이었는지.. 그 이후 내가 변한 것은 무엇 이었는지 회고 하고자 합니다.

마지막으로 나오기 직전 찍은 나우나우 사무실

1️⃣ PM 이라는 역할을 너무 쉽게 봤다.

사실 티몬에 있을 때는 서비스기획자 였지, PM의 role을 가지고 있지는 않았습니다. 채용공고의 일본 신사업부 PM이라는 키워드를 보고, '그냥 오너십이 조금 더 있는 기획자' 이겠거니- 생각하고...😂🤦기존 해 왔던 업무 방식대로. 디테일한 운영기획자의 업무 수행을 해왔습니다. 타임머신이 있다면 그 때의 나한테 가서 등짝을 때리고 싶을 정도로 가장 후회 되는 행동이었습니다. 당시 팀원 중 누군가가 기획자와 PM의 차이.그리고 저에게 바라는것과 아쉬운점을 말해 준적이 있는데, 가슴에 비수가 꽂혔지만 팩트라 반박불가였습니다.

2️⃣ 해야할 일 제쳐두고 하고 싶은 일만 하려 했다.

사실 일본비즈니스를 다루는 걸 오래 전부터 해 오고 싶었습니다. 개인적으로 관심도 많고, 연구대상이기도 하고.. 오랫동안 짝사랑 해온 시장이랄까요. 하지만 아이돌덕후는 매니저가 될 수 없듯이, 좋아하는 것만으로는 일 잘하는 사람이 될 수 없습니다. 그리고 일본신사업부에 들어가면, 일본어도 활용하고 내가 관심있는 분야를 매일 접할 수 있으니까 당연히 가슴 뛰는 일을 할 수 있을 것이라 기대 하였습니다.
하지만 좋아하는 일이 더 이상 가슴 뛰는 일이 되지 않을 때 오는 무력감과 한계까지는 생각하지 못했습니다. 물론 자기 업무에 열정을 가지려면 일단 '좋아함'이 베이스에 깔려야 합니다. 하지만 그럴 시간에 조금 더 유저를 만나고, 무엇이 문제인지 탐구하는 과정을 더 심도있게 가졌어야 했습니다. 내가 전문지식이 없다면 전문가를 만나든, 전문 회사를 만나든, 어떻게든 이 비즈니스를 성공시키기 위해 수단과 방법을 가리지 않고 모색해야 했습니다.

3️⃣ 미움 받는 것을 두려워 했다. 모두에게 잘 보이려 했다.

PM은 너무 의견이 많아 배가 산으로 갈 수도 있는 상황 속에서도 나름 최선의 의사결정을 주도하는 사람입니다. 설령 반대의 의견이 있다 하더라도 그들을 설득 할 수 있는 역량도 중요하죠. 하지만 저는 최대한 조직구성원들과 친해지고 싶고, 팀으로 인정받고 싶어서. 맞지 않는 옷을 입은 것처럼 팀회식에 참여하거나, 밥을 같이 먹거나, 선물공세(?)를 하는 등 잘못 된 방향으로 호감을 사려 했습니다.

흡연은 개개인의 취향인지라 나무랄 수 없지만, 그래도 한국에는 학연 혈연 지연 흡연(...)이 있기에... 주요 멤버들이 담배타임을 자주 가지고 있어서나름 전자담배🚬도 피워보려고 구매도 해봤습니다. 당연히 효과는 없었지요. (훌륭한 PM은 따라하지 마세요!🙅🙅)

또 팀원들이 얘기하는 주장은 무조건 받아주고, 팀원들이 불편하다고 하는 것들을 우선적으로 해결하려 했죠. 운영이나 마케팅 등 의견조율이 안되는 상황에서도 눈치를 보고, 내가 반대하면 날 싫어하겠지.. 이런 생각을 하며 지내왔습니다. 그러다 보니 PRD 한 문장 쓰는 것도 몇시간이 걸리더라고요. "이 요건을 적었을 때 팀원들이 반대하면 어쩌지?" 이렇게 생각하면서요.
피드백을 듣더라도 또 내 탓이라고 비관하거나, 이쁨 받기 위해 팀원이 해야 할 일을 대신 해주고 있었습니다. 정작 PM이 진짜 할 일은 하지 못하면서요. 팀원도 중요하지만 우리의 고객이 더 중요하단 것을 그 때 알았더라면. 직장에서는 인성도 인성이지만 오로지 일을 하고 있을 때의 모습으로 평가 받는다는 것을 그 때는 너무 몰랐습니다.

4️⃣ 일본사업은 어렵다. 그래서 팀 모두가 진심이어야 한다.

많은 스타트업, IT기업들이 일본에 진출합니다. 근데 성공한 사례를 보면 공통점이 있습니다. 바로 일본에 거점을 둡니다. 일본은 한국 대비 데이터 리터러시가 현저히 떨어져 있는 곳입니다. 해서 아직도 오프라인 생태계를 무시할 수 없습니다. O2O가 아니라 OMO. 즉 오프라인과 온라인을 통합하여 동일한 경험을 제공해 줘야 하는 미션이 존재합니다. 한국에서 해 왔던 성공 방정식이, 안 통할 수가 있습니다. 해서 우리가 잘 하고 있는 테크나, 추천로직이나, 데이터나 하는 것들이 생각보다 의외로 안 먹힐 수도 있습니다. 왜 안 먹히는지 알려면 안타깝지만 실무자가 현장을 봐야 합니다. 코로나 때문에 안 되면 현장의 유저를 끌고와서 물어봐야 합니다. 그래도 안 되면 현장의 전문가를 찾거나 마케팅을 전적으로 서포트 해 줄 기업과 협업 해야 합니다.
SKU가 많고, 가격이 싸도, 결국은 현지에서 배송&구매 하는 것만큼 메리트가 있는 것은 없습니다. (지나치게 싼 SHEIN은 논외) 처음에는 매출을 박스권까지 올릴 수는 있어도 그 다음이 문제입니다. 박스권"만" 유지하게 되고, 그냥 평범한 쇼핑몰이 되어버릴 수 있으니까요. 그러니 일본 시장을 제대로 잡겠다라고 마음 먹었으면, 인적자본이나 투자, 지원 등이 국내사업만큼 중요도를 높게 다뤄야 하고, 그만큼 신경도 써야 합니다. 하지만 결국 그것이 실현 되지 못했지요. (극히 주관적인 의견이지만 일본에서 "패션플랫폼"으로 유의미한 성과를 보여주고 있다고 생각하는 곳은 디홀릭커머스, 메디쿼터스 의 NUGU입니다. 광고 아님.)

언젠가 만들었던 메인화면 리뉴얼 된 모습

이 외에도 퇴사사유는 많지만..결론은 저 자신이 부족하고 보완할 부분이 많았기에 나오게 되었습니다. 굳이 프리랜서를 택한 이유도, 좀 더 다양한 도메인에 대해 경험할 수 있는 환경에서 시야를 넓혀보면 뭔가 달라지는 것이 있겠지- 라는 생각으로 부딪혀 본 것입니다. 프리랜서로서 어쩌다 PL, PM, 기획총괄 등의 역할을 하면서...새롭게 배운 것도, 터득한 것도 많았던 1년이었습니다. 그리고 나의 강점이 무엇인지, 나는 무엇을 잘하고 무엇이 약한지.. 자신을 돌아보는 여유도 생겨졌으며 아직 멀었지만 멘탈도 조금은 단단해 졌습니다. 이젠 오히려 저에게는 지그재그에서의 경험이 저를 더 성장하게 해 주었기에, 제게는 고마운 회사이고 또 응원합니다. 올해도 어떤 일을 하게 될 지 모르지만, 작년보다 더 단단해지고 성장하는 내가 되었으면 좋겠습니다. 여기까지 긴 글 읽어주셔서 감사합니다.🙇‍♀️🙏🍀

아직 노란색이 아니라 핑크색 명찰이었던 시절. 언젠가 파O나스몰 2X층에서 찍었던 셀카