Learning by Doing

Learning by Doing님의 아티클

Learning by Doing

Learning by Doing

2023년 5월 2주차 회고

  • 결국 그 자리에 있어야 하는 사람이 있는 것이다.


주니어 때 정말 말을 못 알아듣는 사람들이 저보다 직급이 높을 경우 정말 이해가 안되었던 경험이 많았습니다. '아니 이 회사는 뭘 보고 사람을 승진시키는거지? 주니어가 뭘 보고 배우라는 거지?' 등등 온갖 부정적인 생각을 하며 '여긴 더 배울 것 없다'란 생각에 쉽사리 이직 결정을 내린 적도 있습니다.  


지금 링크드인 등 업계 관련된 분들이 모여 있는 곳에 글도 쓰고 활동을 하다보니 커피챗을 요청하기도 혹은 커피챗을 요청받기도 하면서 결국 그 자리에 있어야 하는 사람이 그 자리에 있다 라는 것을 깨닫고 있습니다. 물론, 짧게 만나 단편적인 이야기를 나누는 것이라 전체를 볼 순 없지만 예를 들자면, Pre-A, Series A 단계 회사 사람들은 문서화하는 부분은 과감히 생략하고 제품의 더 빠른 변화를 가지고 올 수 있는 일에 우선순위를 높여 진행하고 있었고 Series B, C의 회사 사람들은 일하는 체계를 만들면서 리스크가 적은 일들에 우선순위를 높이는 모습을 볼 수 있었습니다.  


결국 리더가 되고, 임원이 되고, 중요한 일을 맡게 되는 사람들은 일을 잘해서이기도 하지만 기업의 상황, 스테이지, 크기에 따라 본인의 역할이 어디까지이고 회사에 필요한 것이 무엇인지 명확히 아는 사람이 그 자리에 있는 것이다라는 것을 알게 되었습니다. 

 

 


* 링크드인 계정이 해킹당하다. 


저에게 이러한 일이 일어날 줄 몰랐었는데 링크드인 계정을 해킹당했었습니다.

목요일 저녁 멘토링한 친구들이랑 간단히 저녁을 먹고 있던 도중 계속 알림이 울렸는데 폰을 보기 애매해서 나중에 확인해보니 정말 예전에 가입한 홈페이지에서 비정상적인 로그인이 발견되었다는 메일이 왔었고 그 다음 메일로 링크드인에 알 수 없는 계정이 등록되었다는 메일이 와있었습니다. 바로 비밀번호를 바꿀려고 접속했는데 이미 2FA 설정이 되어 있어 제가 아무것도 할 수 없는 상황이 되어버렸습니다. 너무 당황해서 우선 링크드인에 해킹 신고하고 기존 동일한 비밀번호를 사용하던 모든 사이트의 비번을 완전 다르게 다시 만들었습니다.


2일 후인 토요일 링크드인에서 계정이 해킹당했음을 확인했고 2FA를 강제적으로 풀어주고 접속 제한을 막아주어서 제 계정을 다시 되찾을 수 있었습니다. 알고보니 1촌이었던 다른 사람들과 몇 마디 이야기를 나누었던 게 다였던 것 같습니다.


해커는 장난으로 한 것 같은데 정말 당황스러웠습니다. 실제 이렇게 당해보니 정말 단순한 로그인이, 비밀번호가 엄청 중요하게 느껴졌습니다. 앞으로는 무조건 서로 다른 비밀번호와 2FA를 사용하려고 합니다. 

 

추천하는 비밀번호 관리 프로그램

- 1password : https://1password.com/ko

- Enpass : https://www.enpass.io/




url thumbnail

2023년 5월 2주차 회고

* 결국 그 자리에 있어야 하는 사람이 있는 것이다. 주니어 때 정말 말을 못 알아듣는 사람들이 저보다 직급이 높을 경우 정말 이해가 안되었던 경험이 많았습니다. '아니 이 회사는 뭘 보고 사람을 승진시키는거지? 주니어가 뭘 보고 배우라는 거지?' 등등 온갖 부정적인 생각을 하며 '여긴 더 배울 것 없다'란 생각에 쉽사리 이직 결정을 내린 적도 있습니다. 지금 링크드인 등 업계 관련된 분들이 모여 있는 곳에 글도 쓰고 활동을 하다보니 커피챗을 요청하기도 혹은 커피챗을 요청받기도 하면서 결국 그 자리에 있어야 하는 사람이 그 자리에 있다 라는 것을 깨닫고 있습니다. 물론, 짧게 만나 단편적인 이야기를 나누는 것이라 전체를 볼 순 없지만 예를 들자면, Pre-A, Series A 단계 회사 사람들은 문서화하..

https://wikilog.tistory.com/77


2
1
Learning by Doing

Learning by Doing

Today I Learned #6 (23.05.11)

오늘 본 내용


url thumbnail

How To Develop Structured Thinking As A Product Manager? | HackerNoon

Structuring your thoughts as a Product Manager is imperative to help you make the right decisions. We've collated some tips to help you do just that!

https://hackernoon.com/how-to-develop-structured-thinking-as-a-product-manager


  • 구조적 사고가 필요한 이유
  • PM의 하루는 내외부 이해관계자들의 끊임없는 요청으로 가득 차있을 예정
  • 이런 와중 PM은 당면한 문제를 해결하고, 제품의 실제 문제를 이해하여 큰 그림을 바라보고, 문제/기회가 해결할 가치가 있는지 평가해야 함


  • 구조적 사고를 위해 해야할 것들
  • 시간 우선순위를 더 잘 정하세요
  • 결정이 되돌릴 수 있는 것이라면 너무 깊이 생각하지 않아도 괜찮습니다.
  • 최악의 시나리오를 생각해 보세요. 잘못된 결정의 결과가 제한적이라면 그 결정에 너무 많은 시간을 소비하지 않는 것이 가장 좋습니다.
  • 세 가지 C, 즉 창조(Creation), 큐레이션(Curation), 소비(Consumption)를 지키세요
  • 세 가지 C는 해야 할 일과 해야 할 방법을 세분화하여 필요한 곳에 주의를 집중하고 부담감을 느끼지 않도록 하는 간단하면서도 효과적인 방법입니다.
  • 문제를 정의하세요
  • 자신의 관점에서 문제에 대해 질문할 수 있지만 문제에 대한 해결책은 모든 고객의 사용 사례에 맞아야 하므로 다양한 관점에서 문제를 이해하려면 문제에 대한 다양한 프레임이 필요합니다.
  • 다양한 부서별 이해관계자에게 문제 또는 이슈의 개요를 설명하고 해결책을 제시하도록 요청하는 대신 문제에 대한 다양한 질문을 제시하도록 요청하세요.
  • 문제 자체에 집중하세요
  • 문제 진술은 당면한 핵심 문제에 집중하는 데 도움이 되지만, 이 과정에서 잠재적인 해결책까지 포함시키고 싶은 유혹에 빠지게 됩니다. 해결책을 찾는 것이 아니라 타겟 사용자의 입장이 되어 그들의 관점에서 문제를 생각해야 하므로 이를 자제하는 것이 중요합니다.
  • 문제를 해결하기 위해서는 아래 문장에 대해 작성해볼 것
  • (공감하는 언어를 사용하여 사람을 묘사) (요구 사항은 동사) 때문에 (이해 관계자와 그 사람의 요구 사항에 대해 알게 된 내용을 설명하세요.)
  • 반드시 사용자 인터뷰를 하세요 
  • 사용자가 가장 편한 시간에 인터뷰 일정을 잡고, 바쁜 일정에서 시간을 내어 대화를 나누는 등 시간이 많이 소요될 수 있지만, 사용자보다 사용자의 관점을 더 잘 전달할 수 있는 사람은 없습니다. 그렇기 때문에 사용자 인터뷰는 반드시 필요한 투자입니다.
  • 검증 없이 사용자가 제품/기능을 사용하여 특정 작업을 수행한다고 가정해서는 안 됩니다.



url thumbnail

Today I Learned #6 (23.05.11)

오늘 본 내용 How To Develop Structured Thinking As A Product Manager? | HackerNoon Structuring your thoughts as a Product Manager is imperative to help you make the right decisions. We've collated some tips to help you do just that! hackernoon.com 구조적 사고가 필요한 이유 PM의 하루는 내외부 이해관계자들의 끊임없는 요청으로 가득 차있을 예정 이런 와중 PM은 당면한 문제를 해결하고, 제품의 실제 문제를 이해하여 큰 그림을 바라보고, 문제/기회가 해결할 가치가 있는지 평가해야 함 구조적 사고를 위해 해야할 것들 시간 우..

https://wikilog.tistory.com/76


2
0
Learning by Doing

Learning by Doing

Today I Learned #5 (23.05.09)


API PM을 맡으면서 가장 고민했던 부분이 보안이었습니다. API의 특성상 한 번 유출되면 영향도가 크기 때문에 항상 미리 API 보안에 대해 신경써야 되기 때문입니다.


아래는 링크드인(https://www.linkedin.com/posts/husseinbeygi_security-api-restfulapi-activity-7053079537470836736-saWu/)에서 찾은 API 보안 체크리스트를 번역한 내용입니다.


  • 인증
  • BASIC AUTH를 사용하지 마세요. 대신 표준 인증(JWT 등)을 사용하세요.
  • 인증, 토큰 생성, 비밀번호 저장에서 새로운 방법을 개발하지 마세요.
  • 표준을 사용하세요.
  • 로그인에서 최대 재시도 및 감옥 기능을 사용하세요.
  • 모든 민감한 데이터에 대해 암호화를 사용합니다.
  • 무작위 복잡한 키(JWT SECRET)를 사용하여 토큰의 무차별 대입 공격을 매우 어렵게 만드세요.
  • 헤더에서 알고리즘을 추출하지 마세요. 백엔드에서 알고리즘을 강제하세요(HS256 또는 RS256).
  • 토큰 만료(TTL, RTTL)를 가능한 짧게 설정하세요.
  • JWT 페이로드에 민감한 데이터를 저장하지 마세요. 이는 쉽게 디코딩될 수 있습니다.
  • 너무 많은 데이터를 저장하지 마세요. JWT는 일반적으로 헤더에서 공유되며, 이에는 크기 제한이 있습니다.
  • 접근
  • DDOS / 무차별 대입 공격을 방지하기 위해 요청을 제한(스로틀링)하세요.
  • 서버 측에서 HTTPS를 사용하고 TLS 1.2+ 및 안전한 암호를 사용하여 MITM(중간자 공격)을 방지하세요.
  • SSL STRIP 공격을 방지하기 위해 SSL과 함께 HSTS 헤더를 사용하세요.
  • 디렉토리 목록을 끄세요.
  • 개인 API의 경우, 화이트리스트에 등록된 IP/호스트만 접근을 허용하세요.
  • 권한 부여
  • 항상 서버 측에서 REDIRECT_URI를 검증하여 화이트리스트에 등록된 URL만 허용하세요.
  • 항상 토큰 대신 코드를 교환하려고 시도하세요(응답 유형=토큰 허용 안 함).
  • OAUTH 인증 과정에서 CSRF를 방지하기 위해 무작위 해시와 함께 상태 매개변수를 사용하세요.
  • 기본 범위를 정의하고, 각 응용 프로그램에 대한 범위 매개변수를 검증하세요.
  • 입력
  • 작업에 따라 적절한 HTTP 메서드를 사용하세요: GET (읽기), POST (생성), PUT/PATCH (대체/업데이트), DELETE (레코드 삭제), 그리고 요청된 리소스에 대해 요청된 메서드가 적절하지 않은 경우 405 메서드 허용 안 됨으로 응답하세요.
  • 요청 수락 헤더(CONTENT NEGOTIATION)의 CONTENT-TYPE를 검증하여 자신이 지원하는 형식만 허용하세요 (예: APPLICATION/XML, APPLICATION/JSON 등). 일치하지 않는 경우 406 허용되지 않는 응답으로 응답하세요.
  • 수락하는 POSTED DATA의 CONTENT-TYPE을 검증하세요 (예: APPLICATION/X-WWW-FORM-URLENCODED, MULTIPART/FORM-DATA, APPLICATION/JSON 등).
  • 일반적인 취약점 (예: XSS, SQL 인젝션, 원격 코드 실행 등)을 피하기 위해 사용자 입력을 검증하세요.
  • URL에 민감한 데이터(자격 증명, 비밀번호, 보안 토큰, API 키)를 사용하지 마세요, 대신 표준 권한 부여 헤더를 사용하세요. 서버 측 암호화만 사용하세요.
  • 캐싱, 속도 제한 정책 (예: 할당량, SPIKE ARREST, 또는 동시 속도 제한)을 활성화하고 API 리소스를 동적으로 배포하기 위해 API 게이트웨이 서비스를 사용하세요.
  • 출력
  • X-CONTENT-TYPE-OPTIONS: NOSNIFF 헤더를 보내세요.
  • X-FRAME-OPTIONS: DENY 헤더를 보내세요.
  • CONTENT-SECURITY-POLICY: DEFAULT-SRC 'NONE' 헤더를 보내세요.
  • 지문 인식 헤더 - X-POWERED-BY, SERVER, X-ASPNET-VERSION 등을 제거하세요.
  • 응답에 대한 CONTENT-TYPE을 강제하세요. APPLICATION/JSON을 반환하면, CONTENT-TYPE 응답은 APPLICATION/JSON입니다.
  • 자격 증명, 비밀번호, 보안 토큰 같은 민감한 데이터를 반환하지 마세요.
  • 완료된 작업에 따라 적절한 상태 코드를 반환하세요 (예: 200 OK, 400 BAD REQUEST, 401 UNAUTHORIZED, 405 METHOD NOT ALLOWED 등).



url thumbnail

Today I Learned #5 (23.05.09)

오늘 본 내용 인증 BASIC AUTH를 사용하지 마세요. 대신 표준 인증(JWT 등)을 사용하세요. 인증, 토큰 생성, 비밀번호 저장에서 새로운 방법을 개발하지 마세요. 표준을 사용하세요. 로그인에서 최대 재시도 및 감옥 기능을 사용하세요. 모든 민감한 데이터에 대해 암호화를 사용합니다. 무작위 복잡한 키(JWT SECRET)를 사용하여 토큰의 무차별 대입 공격을 매우 어렵게 만드세요. 헤더에서 알고리즘을 추출하지 마세요. 백엔드에서 알고리즘을 강제하세요(HS256 또는 RS256). 토큰 만료(TTL, RTTL)를 가능한 짧게 설정하세요. JWT 페이로드에 민감한 데이터를 저장하지 마세요. 이는 쉽게 디코딩될 수 있습니다. 너무 많은 데이터를 저장하지 마세요. JWT는 일반적으로 헤더에서 공유되며, ..

https://wikilog.tistory.com/75

1
0
Learning by Doing

Learning by Doing

Today I Learned #4 (23.05.08)

오늘 본 내용


url thumbnail

Week 27 - 📈 📊 How to Develop and Write KPIs: A Guide for Product Managers 📋

Quote KPIs are like a GPS for product managers, except they won't reroute you when you take a wrong turn, they'll just tell you how far away from your destination you are. Poll - Know from fellow PMs 🚀 Want to stay ahead in Product Management, Growth, and Strategy? Don't miss out on our daily updates click the link below to follow 💡 LinkedIn profile now

https://sidsaladi.substack.com/p/week-27-how-to-develop-and-write


  • KPI와 지표는 제품이 얼마나 잘 하고 있는지 측정하고 개선할 수 있는 영역을 파악하는데 도움을 주는 중요한 도구
  • KPI
  • 특정 비즈니스 목표와 연계된 고수준 성과 지표
  • 잘못되었는지만 알려줄 뿐 어떻게하면 올바른 길을 갈 수 있는지 알려주지는 못함
  • 지표 
  • 특정 영역에서 제품이 얼마나 잘하고 있는지를 이해하는 데 도움이 되는 더 세부적인 성과 측정
  • 제품 관리자를 위한 KPI 개발 및 작성 방법
  • 비지니스 목표를 설정
  • 비지니스 목표를 달성하기 위한 제품의 주요한 측면 확인
  • 각 영역에 대한 지표 정의
  • 지표와 일치하는 KPI 설정
  • 지속적으로 KPI를 모니터링하고 조정
  • 효율적인 KPI 작성을 위한 템플릿
  • 정의 : KPI의 정의 작성
  • 목표 : KPI의 목표 작성
  • 목표치 : KPI에 대한 구체적인 목표값 설정
  • 측정 : KPI 측정을 위한 방법
  • 책임 : KPI 모니터링 담당자
  • 행동 계획 : 목표값 이하로 하락한 경우 KPI 개선을 위해 해야할 행동
  • 이유 : 이 KPI가 비지니스에 왜 중요한지와 전반적인 전력을 어떻게 지원하는지 작성
  • 관련 KPIs : 이 KPI와 함께 추적하여 성능의 전체적인 그림을 이해하는데 중요한 다른 KPI들



고민하고 생각해 볼 내용

  • 자사 제품에 대해 각 기능별로 KPI를 수립할 수 있는지 고민해보기 
  • KPI 수립이 어렵다면 왜 어려운지 고민해보기



url thumbnail

Today I Learned #4 (23.05.08)

오늘 본 내용 Week 27 - 📈 📊 How to Develop and Write KPIs: A Guide for Product Managers 📋 Quote KPIs are like a GPS for product managers, except they won't reroute you when you take a wrong turn, they'll just tell you how far away from your destination you are. Poll - Know from fellow PMs 🚀 Want to stay ahead in Product Management, Growth, a sidsaladi.substack.com KPI와 지표는 제품이 얼마나 잘 하고 있는지 측정하고 개선할 수 ..

https://wikilog.tistory.com/74



3
0
Learning by Doing

Learning by Doing

2023년 5월 1주차 회고

  • 책 추천
url thumbnail

제품의 탄생 - YES24

소프트웨어 엔지니어로 출발해 구글, 마이크로소프트, 라인, 스마트뉴스 등 글로벌 기업 PM으로 활약해온 세계 수준 프로덕트 매니저의 지혜와 경험을 한 권에 읽는다! 모든 기업의 PM(프로덕트 매니저)와 PO(프로덕트 오너)는 물론이고, 신사업 기획, 디지털 트...

http://www.yes24.com/Product/Goods/115832798


근래 읽었던 책들 중에 가장 많은 도움을 주고 있는 책 한 권 추천하고자 합니다. 보통 제품과 관련된 책들을 보면 저자가 실리콘밸리에서 일하면서 느꼈던 것들, 그들의 업무 방식 등에 대한 내용을 에세이 형식으로 많이 작성해두었는데 이 책은 제품과 PM/PO를 중심으로 회사의 단계에 따라 어떤 상태와 관점을 유지해야 하는지 잘 작성되어 있습니다. 읽으면서 현실적이다라는 생각을 가질 정도로 실제 업무에도 많은 도움이 될 것 같습니다. 기회가 된다면 읽어보시길 추천드립니다.



 

* 유튜브를 시작하다!


올해 만다라트 계획을 세우면서 유튜브 도전이라는 항목을 추가했었습니다. 사실 매년 해봤으면 좋겠다 수준으로 그치는 일 중 하나였었기 때문에 못해도 그만이다 생각했었는데 다 때가 있었던 듯 합니다. 기회가 되었는지 멘토링도 시작하고 Management 3.0, 애자일 등을 배우게 되었고 주변에서 같이 하자는 분들이 많아서 4월 한 달 준비하고 어제 처음 컨텐츠를 업로드하였습니다. 막상 첫 컨텐츠를 업로드하니 '이렇게 쉬웠던 것을..'이란 생각도 들면서 이제 첫 컨텐츠를 업로드 한 것이라 우선 시작했다에 큰 의미를 부여하려고 합니다. 



url thumbnail

2023년 5월 1주차 회고

* 책 추천 - 제품의 탄생 제품의 탄생 - YES24 소프트웨어 엔지니어로 출발해 구글, 마이크로소프트, 라인, 스마트뉴스 등 글로벌 기업 PM으로 활약해온 세계 수준 프로덕트 매니저의 지혜와 경험을 한 권에 읽는다! 모든 기업의 PM(프로덕트 www.yes24.com 근래 읽었던 책들 중에 가장 많은 도움을 주고 있는 책 한 권 추천하고자 합니다. 보통 제품과 관련된 책들을 보면 저자가 실리콘밸리에서 일하면서 느꼈던 것들, 그들의 업무 방식 등에 대한 내용을 에세이 형식으로 많이 작성해두었는데 이 책은 제품과 PM/PO를 중심으로 회사의 단계에 따라 어떤 상태와 관점을 유지해야 하는지 잘 작성되어 있습니다. 읽으면서 현실적이다라는 생각을 가질 정도로 실제 업무에도 많은 도움이 될 것 같습니다. 기회가..

https://wikilog.tistory.com/73


3
0
Learning by Doing

Learning by Doing

Today I Learned #3 (23.05.04)

오늘 내용 


url thumbnail

Moving Motivators: A Management 3.0 Game

One of the easiest and definitely most fun ways to delve into intrinsic motivations is to play Moving Motivators. Find out more!

https://management30.com/practice/moving-motivators/

 

  • Management 3.0 과정 중 배웠던 Moving Motivotor를 1:1 미팅에서 활용해보았다. 확실히 많은 장점을 지닌 방법이라는 것을 알 수 있었다. 그 중 가장 크게 느꼈던 장점 3가지를 작성해보았다.
  1. 아이스 브레이킹 없이 시작하였는데 어색하지 않았고 상대방이 자연스레 마음을 열고 이야기 한다는 느낌을 받았다.
  2. 직접 말로 이야기하기 어려운 것들을 카드로 표현할 수 있어서 이해하기 쉬웠고 더 많은 대화를 나눌 수 있었다.
  3. 개개인마다 동기부여를 가지는 포인트가 다른데 Moving Motivotor를 통해 이를 쉽게 파악할 수 있었다.

 

고민하고 생각해 볼 내용

  • 현재 업무와 개개인들이 필요로 하는 동기부여 항목이 많이 다르다는 것을 알게 되었다. 중요한 동기부여 항목임에도 낮은 만족도를 나타내고 있는 항목에 대해 어떻게 상승시키면 좋을지 고민된다. 


url thumbnail

Today I Learned #3 (23.05.04)

오늘 본 내용 Moving Motivators: A Management 3.0 Game One of the easiest and definitely most fun ways to delve into intrinsic motivations is to play Moving Motivators. Find out more! management30.com Management 3.0 과정 중 배웠던 Moving Motivotor를 1:1 미팅에서 활용해보았다. 확실히 많은 장점을 지닌 방법이라는 것을 알 수 있었다. 그 중 가장 크게 느꼈던 장점 3가지를 작성해보았다. 아이스 브레이킹 없이 시작하였는데 어색하지 않았고 상대방이 자연스레 마음을 열고 이야기 한다는 느낌을 받았다. 직접 말로 이야기하기 어려운 것들을 ..

https://wikilog.tistory.com/72


2
0
Learning by Doing

Learning by Doing

Today I Learned #2 (23.05.03)


오늘 본 내용


url thumbnail

🚀 기업 가치 7조. 듀오링고의 시행착오에 대한 기록

듀오링고의 시행착오에 대해 제대로 알고 계신 분들은 안보셔도 괜찮아요.

https://maily.so/productlab/posts/66777207


  • 듀오링고에서 고객을 모으기 위해 했던 전략
  • 게이미피케이션 강화 → 실패
  • 추천시스템 → 실패
  • 데이터 및 구조화 → 성공
  • 각 단계별로 보았을 때는 실패했지만 그 과정 속에서 배웠던 것들이 명확했다.
  • 게이미피케이션을 통해 회사 문화와 리더십 개선하는 방법을 습득
  • 추천시스템을 통해 다른 접근 방식이 필요함을 느낌
  • 재정비 시간을 통해 우리만의 제품에 대해 어떤 것을 봐야할지 고민
  • 다른 회사에서 성공한 전략이 우리 제품에서도 성공한다는 것은 보장할 수 없다.
  • 제품 간의 차이를 고려하지 않는다면 결국 실패한다.  



고민하고 생각해 볼 내용

  • 데이터, 인사이트, 기본 원칙에 기반한 의사결정을 내리기 위해 필요한 것은 무엇인지 고민
  • 우리가 보유한 데이터를 기준으로 북극성 지표를 찾아보자.



url thumbnail

Today I Learned #2 (23.05.03)

오늘 본 내용 🚀 기업 가치 7조. 듀오링고의 시행착오에 대한 기록 듀오링고의 시행착오에 대해 제대로 알고 계신 분들은 안보셔도 괜찮아요. maily.so 듀오링고에서 고객을 모으기 위해 했던 전략 게이미피케이션 강화 → 실패 추천시스템 → 실패 데이터 및 구조화 → 성공 각 단계별로 보았을 때는 실패했지만 그 과정 속에서 배웠던 것들이 명확했다. 게이미피케이션을 통해 회사 문화와 리더십 개선하는 방법을 습득 추천시스템을 통해 다른 접근 방식이 필요함을 느낌 재정비 시간을 통해 우리만의 제품에 대해 어떤 것을 봐야할지 고민 다른 회사에서 성공한 전략이 우리 제품에서도 성공한다는 것은 보장할 수 없다. 제품 간의 차이를 고려하지 않는다면 결국 실패한다. 고민하고 생각해 볼 내용 데이터, 인사이트, 기본 원..

https://wikilog.tistory.com/71


2
0
Learning by Doing

Learning by Doing

Today I Learned #1 (23.05.02)


url thumbnail

프로덕트 팀의 신뢰를 ‘자산’처럼 관리해야 하는 이유 | 요즘IT

프로덕트를 만드는 사람들이라면 구성원들 간의 '신뢰'가 중요하다는 이야기들을 많이 들어보셨을 것입니다. 많은 프로덕트 매니저(PM)들의 지침서가 되는 책 <인스파이어드(Inspired)>, <스프린트(Sprint)>, <실리콘밸리의 팀장들(Radical Candor)>에서도 구성원들끼리의 '신뢰' 구축에 대해서 끊임없이 강조합니다. 유독 프로덕트를 만드는 사람들 사이에서 많이 강조되는 것 같은 이 '신뢰'란 무엇일까요? 때때로 조직의 기술적 문제보다도 '신뢰'의 문제를 해결하는 것이 제품 개발 속도를 좌우하는 키가 되기도 하는데요. 그렇다면 제품 개발 속도에도 영향을 줄 수 있을 만큼 중요한 이 '신뢰'는 어떻게 쌓아야 할까요?

https://yozm.wishket.com/magazine/detail/1999/


오늘 본 내용

  • 신뢰자산
  • 인간의 뇌는 구조상 말의 내용을 듣기 전에, 말하는 사람이 누구인지를 보고 결론을 낸다고 한다.
  • 그렇기 때문에 결국 신뢰도 자산으로 생각하고 관리해야 한다. (Trust Index)
  • 신뢰자산이 프로덕트 개발에 중요한 이유
  • 커뮤니케이션 비용 절감
  • 도전에 대한 독려
  • 신뢰자산을 쌓는 3가지 방법
  • 본업을 잘하는 모습을 보여준다.
  • 도전적인 일을 약속하고, 이를 지킨다.
  • 라포를 형성한다.


고민하고 생각해 볼 내용

  • 나의 신뢰자산은 어느정도 되는지 짐작해보기
  • 신뢰자산을 쌓기 위한 3가지 방법 도전해보기



url thumbnail

Today I Learned #1 (23.05.02)

오늘 본 내용 프로덕트 팀의 신뢰를 ‘자산’처럼 관리해야 하는 이유 | 요즘IT 프로덕트를 만드는 사람들이라면 구성원들 간의 '신뢰'가 중요하다는 이야기들을 많이 들어보셨을 것입니다. 많은 프로덕트 매니저(PM)들의 지침서가 되는 책 ,

https://wikilog.tistory.com/70


4
0
Learning by Doing

Learning by Doing

2023년 4월 4주차 회고

  • ‎1등은 고객으로부터 배워서 제품을 만들지만 2등은 1등의 제품을 보고 제품을 만든다.


요새 부쩍 드는 생각이 1등은 고객으로부터 배워서 제품을 만들지만 2등은 1등 제품을 보고 제품을 만든다는 생각이 듭니다. 우리가 쉽게 벤치마킹이라는 단어로 경쟁사를 조사하지만, 결국 우리가 집중해야할 부분은 고객이 아닌가 싶습니다. 고객이 실제 필요로 하는 것은 무엇인지 우리의 제품 방향성과 맞는지 등을 직접 검토하며 실제 문제가 무엇인지 고민해야 합니다. 이러한 고민없이 필요에 따라 혹은 1등 제품에 해당 기능이 있어서 우리 제품에도 포함한다면 과연 경쟁력이 있는지 의문이 듭니다. 결국, 이렇게 포함된 기능들은 기획 의도와 다르게 사용되어 너도 나도 이해가 안되는 피드백으로 돌아오기 때문입니다. 


물론 고객에게 답이 있다고 철저히 신뢰하는 것도 좋지 않습니다. 또한 고객의 니즈를 분석해보니 기존 경쟁 제품의 동일한 기능이 필요해서 벤치마킹할 수 있습니다. 하지만 고객의 니즈를 분석하는 것보다 1등의 제품을 더 많이 사용해보고 비슷하게 따라가려고 한다는 것에 문제가 있습니다.

 


 

* Today I learned을 시작해보자


현재 제 모습은 애매한 연차에 애매한 경력이라는 생각이 떠나지 않습니다. 그래서 5월부터는 Today I learned에 대해서도 글을 작성해볼까 합니다. Today I learned은 초짜 개발자일 때 매일 작성하면서 하루하루 놓치고 있었던 부분을 점검할 수 있었고 저를 가장 많이 성장할 수 있었던 방식입니다. 해서, 직군과 직급이 달라졌지만.. 다시 시작해보려 합니다. 



url thumbnail

2023년 4월 4주차 회고

* ‎1등은 고객으로부터 배워서 제품을 만들지만 2등은 1등의 제품을 보고 제품을 만든다. 요새 부쩍 드는 생각이 1등은 고객으로부터 배워서 제품을 만들지만 2등은 1등 제품을 보고 제품을 만든다는 생각이 듭니다. 우리가 쉽게 벤치마킹이라는 단어로 경쟁사를 조사하지만, 결국 우리가 집중해야할 부분은 고객이 아닌가 싶습니다. 고객이 실제 필요로 하는 것은 무엇인지 우리의 제품 방향성과 맞는지 등을 직접 검토하며 실제 문제가 무엇인지 고민해야 합니다. 이러한 고민없이 필요에 따라 혹은 1등 제품에 해당 기능이 있어서 우리 제품에도 포함한다면 과연 경쟁력이 있는지 의문이 듭니다. 결국, 이렇게 포함된 기능들은 기획 의도와 다르게 사용되어 너도 나도 이해가 안되는 피드백으로 돌아오기 때문입니다. 물론 고객에게 ..

https://wikilog.tistory.com/69


5
4
Learning by Doing

Learning by Doing

2023년 4월 3주차 회고

* Data-Driven 보다 Data 기반한 Feedback Loop 가 중요하다.


요새 이력서를 보면 혹은 일하다가도 Data-Driven이라는 단어를 쉽게 찾아볼 수 있습니다. 또한 면접을 볼 때에도 Data-Driven을 하고 싶다는 분들을 많이 볼 수 있습니다. 곰곰이 생각해보면 Data-Driven이 중요한 것이 아니고 HIPPO(the Highest Paid Person's Opinion)가 발생하지 않도록 어떻게 좋은 의사결정을 만드냐가 중요한 것입니다. Data-Driven은 단순히 하나의 도구에 불과합니다. 또한 Data-Driven에서도 Data보다 목표 지표 설정 - 액션 - 피드백 루프가 더 중요하고 고민되어야 합니다. 


과거 일을 할 때 대표 혹은 임원의 감 혹은 이야기에 의해 많은 것들이 결정되다보니 많은 리스크를 질 수 밖에 없었고 이를 방지하고자 나온 것들 중 하나가 Data-Driven입니다. Data 즉, 정량적 수치를 바탕으로 의사결정 내린다는 것은 우선 리스크에 대한 검토를 진행한다는 의미입니다. 하지만 정량적 수치가 있다고 해서 무조건 좋은 것은 아닙니다. 올바른 의사결정을 내리기 위한 데이터가 충분히 있어야 하며, 더욱 중요한 것은 누가 어떻게 Data-Inspired 하냐는 것입니다. 결국 데이터를 해석하고 의사결정을 내리는 것이 사람이기 때문입니다.


그렇기 때문에 우리는 정량적 수치를 기반해 리스크를 검토하는 것 뿐만아니라 결과에 따라 어떠한 액션들을 취하고 다시 피드백을 수집하냐는 것까지 고민해야 합니다. 중요한 것은 이 과정을 무수히 반복할 수 있는 꺽이지 않는 마음이 아닌가 합니다.

 


 

‎* 누구에게나 멘토가 필요하지만 결국 성장은 나 혼자할 생각을 가져야 한다.


예전에 유튜브에서 ‎컨설팅으로 몇 백만 달러 받는 사람에 대한 이야기를 본 적이 있습니다. 당시에는 돈을 주는 사람이나 돈을 받는 사람이나 전혀 이해 안 되지 않았습니다.


사람이라면 누구나 내가 잘되기는 것을 바라다보니 성장에 대해 중요하게 생각합니다. 좋은 사수, 뛰어난 사람들과 같이 일하기를 원합니다. 실제로 저 또한 좋은 회사에 가면 뛰어난 분들이 있는 있을테니 더 많이 성장하겠지란 생각으로 이직을 하고자 노력도 많이 하였고 실제 좋은 곳에 있어보기도 한 것 같습니다. 돌이켜보면 성장에 대해 가장 중요한 것은 우선 마음가짐이었습니다. 


무협지를 보면 주인공이 정말 기연을 얻어 천하제일 무공인이 되는 경우가 대부분입니다. 성장이 중요한 회사 생활에서도 이러한 기연이 일어날 수 있을까요? 거의 없을 겁니다. 결국 내가 이 회사에서, 이 구성원들과 일하면서, 내가 하는 일 안에서 어떻게 성장할지 고민하고 길을 만들어야 하는 것은 결국 나입니다. 그렇기 때문에 마음가짐이 제일 중요합니다. 


이 회사에서는 이것을 배울거야! 이 사람들과는 이것을 해보면 좋을 것 같아! 다음 회사 가서는 더 큰 것을 해보면 좋을 것 같아!


이러한 생각들이 모이고 모여 실제 변화를 만들어내고 성장하는 것 같습니다. 


 

‎

‎* 업무에서 위임이란?


업무를 하다보면 내가 한 일을 누군가에게 넘겨주어야 할 때도 있고 누군가가 하던 일을 이어받아서 할 때도 생깁니다. 하나의 일을 둘이 같이 하게 되는 구조가 빈번하게 발생하는데 어떻게하면 트러블 없이 성과를 낼 수 있을까 고민해보면 결국 상호간의 위임이 잘 되어합니다. 위임이 잘 안되었을 때 기존 업무 실무자는 "나는 다 전달했는데 왜 결과가 이렇지?", "바빠도 내가 하는 것이 나았나?" 란 생각을 하게 되고, 신규 업무 실무자는 "내가 할 수 있는게 없네..", "결국 자기가 다할 거면서.." 이런 생각을 가지게 됩니다. 


이러한 것을 예방하려면 사전에 1-2주 정도 같이 업무를 분석하고 싱크 맞추는 과정이 반드시 필요합니다. 단순히 기존 업무하는 사람이 신규로 참여하는 사람에게 업무를 설명하는 자리가 되는 것이 아니라 어느 영역까지는 내가 할 것이고 어느 영역까지는 너가 해줬으면 좋겠다는 구체적인 영역을 나눠야 합니다. 모든 것을 한 번에 넘겨주거나 모든 것을 안 넘겨주거나 해서는 안됩니다. 나누려면 정확하고 구체적으로 나누어야 합니다. 


그렇기 때문에 위임을 잘하기에는 항상 어려운 것 같습니다. 이래서 서로의 합이 중요하다라는 말이 나오는 것 같습니다.




url thumbnail

2023년 4월 4주차 회고

‎* Data-Driven 보다 Data 기반한 Feedback Loop 가 중요하다. 요새 이력서를 보면 혹은 일하다가도 Data-Driven이라는 단어를 쉽게 찾아볼 수 있습니다. 또한 면접을 볼 때에도 Data-Driven을 하고 싶다는 분들을 많이 볼 수 있습니다. 곰곰이 생각해보면 Data-Driven이 중요한 것이 아니고 HIPPO(the Highest Paid Person's Opinion)가 발생하지 않도록 어떻게 좋은 의사결정을 만드냐가 중요한 것입니다. Data-Driven은 단순히 하나의 도구에 불과합니다. 또한 Data-Driven에서도 Data보다 목표 지표 설정 - 액션 - 피드백 루프가 더 중요하고 고민되어야 합니다. 과거 일을 할 때 대표 혹은 임원의 감 혹은 이야기에 의해 ..

https://wikilog.tistory.com/68


4
0
Learning by Doing

Learning by Doing

2023년 4월 2주차 회고

  • 리더는 모든 것을 하는 자리가 아니다

 

이번 주 읽은 글(마이크로 매니지먼트와 위임) 중 와닿은 글이 있어 소개하고자 합니다.


우리는 일을 하면서 사람을 믿어야 하기도 하고 믿기도 합니다. 그러한 과정 속에서 "내가 얼마나 관여를 해야하지?", "내가 신경 안써도 되는 걸까?" 를 셀 수 없이 고민합니다. 저 또한 많은 고민을 가지면서 일하는데 저는 일반적으로 결국 먼저 믿고 맡기고 이슈 생기면 챙기자는 식으로 진행합니다. 


이 글을 읽으면서 과연 저는 마이크로 매니지먼트를 할 수 있는데 안하는 것인지 마이크로 매니지먼트를 할 수 없는데 참견만 하는 것인지 돌아보게 되었습니다. 또한 한 편으로는 제가 경험했던 리더들은 어떠한 유형의 사람들이었는지도 돌아보게 되었습니다. 누군가를 리딩하는 자리는 끊임없이 위임과 마이크로 매니지먼트를 반복적으로 해야하는 자리입니다.


적절한 것이 좋지만 적절함을 모르겠다면 무조건 마이크로 매니지먼트 혹은 위임하는 것보다 솔직히 팀원과 이야기를 나눠 Scope을 같이 정하는 것도 좋지 않을까 합니다.

 


 

* Management 3.0 리더쉽 교육을 이수하다!


우연한 기회로 Management 3.0 리더십 교육을 듣게 되었습니다. 사실 자격증이 큰 의미가 있는 것은 아니겠지만 이러한 교육을 통해 다른 회사에서는 어떻게 일을 하고 있는지, 우리가 가지고 있는 문제를 어떻게 풀고 있는지 서로 이야기를 나누는 것만 해도 큰 의미가 있다 생각합니다. 


교육 중 가장 인상 깊었던 부분은 Management는 모두가 하는 것이고, 조직의 역량 강화를 위해 무엇을 할 수 있냐는 부분이었습니다. 기존에 일하면서 혹은 주니어 PM/PO 분들과 이야기를 나누면서 "리더는 서번트해야한다.", "좋은 프로세스는 항상 좋은 결과를 만든다", "개인의 역량은 결국 조직의 역량이다." 생각했었는데 모두 잘못된 생각임을 알았습니다. 교육이 끝나갈수록 과연 저는 어떤 리더인지, 무엇을 하고 싶어하는지 깊이 고민할 수 있었습니다. 개인적으로는 정말 정말 뜻깊은 시간이었습니다.


기회가 된다면 주변에 배운 내용들을 공유하고 이야기 나눠보고자 합니다.



url thumbnail

2023년 4월 3주차 회고

* 리더는 모든 것을 하는 자리가 아니다 마이크로 매니지먼트와 위임 위임도 일이 잘되게 하기 위한 도구다. sonujung.com 이번 주 읽은 글 중 와닿은 글이 있어 소개하고자 합니다. 마이크로 매니지먼트와 위임에 대한 내용으로 개인적으로는 많은 공감이 되었습니다. 우리는 일을 하면서 사람을 믿어야 하기도 하고 믿기도 합니다. 그러한 과정 속에서 "내가 얼마나 관여를 해야하지?", "내가 신경 안써도 되는 걸까?" 를 셀 수 없이 고민합니다. 저 또한 많은 고민을 가지면서 일하는데 저는 일반적으로 결국 먼저 믿고 맡기고 이슈 생기면 챙기자는 식으로 진행합니다. 이 글을 읽으면서 과연 저는 마이크로 매니지먼트를 할 수 있는데 안하는 것인지 마이크로 매니지먼트를 할 수 없는데 참견만 하는 것인지 돌아보게..

https://wikilog.tistory.com/67


3
0
Learning by Doing

Learning by Doing

2023년 4월 1주차 회고

  • PM/PO에게 도메인이란 무엇일까?


요즘 멘토링을 통해서도, 커피챗을 통해서도 도메인에 대한 질문이 많이 들어옵니다. 그러면서 점점 PM/PO로 도메인이 얼마나 중요할까라는 생각을 많이 하게 됩니다. 제 성향 자체가 워낙 다양한 것을 많이 하고 싶어하기 때문에 도메인에 대해 많은 고민을 하지 않았는데 이제는 할 때가 아닌가란 생각도 들게 됩니다.


도메인이란 B2C, B2B, B2B2C 등의 제품의 성향을 말하기도 하면서 내가 일하고 있는 산업군을 의미합니다. 예를 들면, 이커머스, 금융, 핀테크, 보안 등등의 분류입니다. PM/PO에게 도메인이 중요한 이유는 아무래도 시장에 대한 인식과 통찰력 때문이 아닐까 싶습니다. 특히나 요새 PM/PO가 회사에서 맡고 있는 역할이라면 전문성을 가진 것은 확실히 중요하기 때문입니다.


그렇기 때문에 주니어 PM/PO 분들 혹은 PM/PO 을 지망하는 분들에게는 도메인에 대한 중요성을 꼭 말합니다. 그 산업을 잘 이해하는 것 은 그만큼 PM/PO에게 굉장한 메리트이기 때문입니다. 


그럼에도 제가 도메인을 고집하지 않는 이유는 제 개인적으로는 PM/PO는 얕더라도 넓게 알아야 한다 생각하기 때문입니다. 예를 들어 이커머스 회사를 다닌다고 할 때 보안에 대한 지식을 아는 것은 강점으로 작용합니다. 또한 Speech to Text 업체를 다닌다고 할 때 AI 지식이 있다면 이 또한 강점으로 작용하기 때문입니다. 점점 연차가 쌓이면서 저도 결국 하나의 도메인을 정해야 할 시기가 오겠지만 아직까지는 여러 도메인을 경험하며 다양한 경험을 쌓고 많은 인사이트를 얻고 싶습니다. 



url thumbnail

2023년 4월 2주차 회고

* PM/PO에게 도메인이란 무엇일까? 요즘 멘토링을 통해서도, 커피챗을 통해서도 도메인에 대한 질문이 많이 들어옵니다. 그러면서 점점 PM/PO로 도메인이 얼마나 중요할까라는 생각을 많이 하게 됩니다. 제 성향 자체가 워낙 다양한 것을 많이 하고 싶어하기 때문에 도메인에 대해 많은 고민을 하지 않았는데 이제는 할 때가 아닌가란 생각도 들게 됩니다. 도메인이란 B2C, B2B, B2B2C 등의 제품의 성향을 말하기도 하면서 내가 일하고 있는 산업군을 의미합니다. 예를 들면, 이커머스, 금융, 핀테크, 보안 등등의 분류입니다. PM/PO에게 도메인이 중요한 이유는 아무래도 시장에 대한 인식과 통찰력 때문이 아닐까 싶습니다. 특히나 요새 PM/PO가 회사에서 맡고 있는 역할이라면 전문성을 가진 것은 확실히 ..

https://wikilog.tistory.com/66


3
1
Learning by Doing

Learning by Doing

2023년 3월 5주차 회고

‎* 첫 커피챗, 그리고 우수 과제 선정


이번 주에는 좋은 일 2가지가 있었습니다. 우선 하나는 저에게도 드디어 첫 커피챗 요청이 들어왔습니다. 커피챗을 신청한 경우는 많았는데 실제 제가 커피챗 요청을 받아보니 감회가 새로왔습니다. 20분의 짧은 통화 시간이었지만 누군가에게 도움이 되어 정말 감사하다는 말을 듣는 것은 항상 큰 동기부여가 됩니다. 


두번째로는 제가 멘토링을 했던 팀 중 한 팀이 우수 과제 수행 팀으로 선정된 것입니다. 제가 한 것은 별로 없지만 아무 생각없이 멘토링을 시작한 멘토링인데 좋은 결과까지 얻을 수 있어서 더 기쁩니다. 확실히 저는 누군가에게 베푸는 것을 좋아한다는 것을 또 한 번 깨달았습니다.




‎* 무조건 아끼는 것이 좋을까?


요새 스타트업은 불황입니다. 거의 모든 회사들이 채용도 닫거나 한정적으로 운영하며, 지출을 줄이고자 합니다. 지난 시절 매출없이도 아이템만으로도 창업했던 시절과는 매우 다르게 느껴지는 것이 사실입니다. 하지만 구성원의 한 사람으로 볼 때 너무 지나치게 줄이는 것도 "회사가 안 좋은가? 다른 곳 가야하는 거 아닌가? 이렇게까지 한다고??" 하는 의구심이 들게 만듭니다. 이러한 모습을 보면서 중간, 적당히 이런 말들은 참으로 어렵다. 똑같은 말을 들어도 다들 다르게 생각하는구나 라는 생각을 하게 됩니다. 실제 주변에서도 회사가 어렵다는 말을 듣고 자발적으로 다른 곳을 알아보는 사람도 늘었기 때문입니다. 


나가야하는 지출을 줄이는 것은 당연히 모두를 위해서 좋습니다. 하지만 회사는 구성원들이 다니는 곳입니다. 무작정 모든 것을 다 줄이겠다는 것이 아니라 어디서부터 어떻게 줄이겠다는 계획이 있다면 정말 좋을 것 같습니다. 




‎* 면접은 사람을 이해하는 자리 


주변으로부터 면접 후기를 많이 접하게 되는데 면접은 참으로 알다가도 모르는 일인 것 같습니다. 사실 면접이라는 프로세스는 수치를 이야기하는 자리가 아니고 사람의 의중을 이해하고 파악해야 하는 자리입니다. 그러다보니 일반적으로 결과를 짐작하기 어렵습니다. 그래서 면접 후 항상 기대하지 말고 할 것을 하라고 조언합니다. 


실제로 저도 많은 면접을 보기도 하고 면접관으로 들어가기도 하면서 면접 때 느낌과 면접 후 느낌이 많이 달랐는데 이는 면접의 결과가 스코어로 나오지 않기 때문이라 생각합니다. 그래서 면접을 잘 준비하고 싶다면 면접관이 어떤 직무의 분들인지, 몇 분 들어오는지 반드시 알아보고 면접 시간 전까지 그 사람들이 한 인터뷰를 많이 볼 것을 추천드립니다. 이러한 과정을 통해 나와 생각이 같고 실제 일하면 케미가 잘 맞을지를 확인하는 것이 면접 준비라 생각합니다. 만약 그 사람이 인터뷰한 내용이 나와 달랐다면 왜 다른지 알고 깨달아야 좋은 면접입니다.

이처럼 면접은 나를 보여주는 자리인 동시에 나와 맞는 사람들을 찾아가는 과정입니다.




* 한 번 하기로 했다면 끝까지 책임져야 한다.


과거 차장님, 부장님, 실장님들이 업무할 때 새로운 시도를 안하셔서 답답한 것이 많았는데 아마 이러한 배경에서 그러신 것이 아닌가 싶습니다. 그것은 한 번 하기로 했다면 끝까지 책임질 생각을 해야 한다는 것입니다. 제 스타일 상 새로운 것을 좋아하고 시도하는 것에 두려움이 없다보니 협업 툴과 프로세스를 많이 도입해보았는데 정말 하자라고 하는 순간 말한 사람이 모든 것을 책임져야하고 인정 받을 생각을 하지 않아야 된다 생각됩니다. 좋은 것이고 모두에게 도움이 되니까 내가 말하면 누군가 도와주겠지 라는 생각으로 무엇인가 시도를 하면 결국 아무도 안하고 레거시가 됩니다. 했으면 좋겠다는 일이 있다면 도전 대비 가치를 먼저 파악하고 목적을 구체화하고 기간을 정할 수 있다면 기간별로의 세부 달성 목표도 수립를 추천드립니다. 또한 나만 할 수 있는 일 보다는 모두가 같이 할 수 있는 일부터 시도하기를 추천드립니다.

 


url thumbnail

2023년 4월 1주차 회고

‎* 첫 커피챗, 그리고 우수 과제 선정 이번 주에는 좋은 일 2가지가 있었습니다. 우선 하나는 저에게도 드디어 첫 커피챗 요청이 들어왔습니다. 커피챗을 신청한 경우는 많았는데 실제 제가 커피챗 요청을 받아보니 감회가 새로왔습니다. 20분의 짧은 통화 시간이었지만 누군가에게 도움이 되어 정말 감사하다는 말을 듣는 것은 항상 큰 동기부여가 됩니다. 두번째로는 제가 멘토링을 했던 팀 중 한 팀이 우수 과제 수행 팀으로 선정된 것입니다. 제가 한 것은 별로 없지만 아무 생각없이 멘토링을 시작한 멘토링인데 좋은 결과까지 얻을 수 있어서 더 기쁩니다. 확실히 저는 누군가에게 베푸는 것을 좋아한다는 것을 또 한 번 깨달았습니다. ‎* 무조건 아끼는 것이 좋을까? 아시다싶이 요새 스타트업은 불황입니다. 거의 모든 회..

https://wikilog.tistory.com/65


4
0
Learning by Doing

Learning by Doing

2023년 3월 3주 회고

  • 매니징해야 할 것은 사람이 아니라 일. 

모든 회사가 그렇듯 풍부한 인력풀이 있어 하고 싶은 것을 자유롭게 할 수 있는 상황은 아닙니다. 그렇다보니 하고 싶은 많은 일들 중에서도 할 수 있는 것을 고르고, 할 수 있는 것들 중에서도 우선 순위를 정합니다. 이러한 과정 속에서 정말 지양하는 것 중 하나는 개개인의 일정까지 관리하는 것이라 생각합니다. 물론 프로젝트가 끝나고 다음 프로젝트가 정해질 때까지 공백이 길어진다는 것은 회사나 개인에게 안 좋은 현상이라 봅니다. 또한 잠깐의 공백에 우선순위가 낮은 일을 빨리 처리할 수 있다면 정말 좋다 생각합니다.

하지만, "누가 언제 어떤 프로젝트가 끝나니 우선순위가 낮은 일을 중간에 끼워넣자", "이 일은 금방할 수 있으니 짧게 빠르게 해보자" 라는 판단은 굉장히 위험하다 생각합니다. 아무리 작은 기능이더라도 실제 하면 큰 일로 변하는 것이 다반사이고, 정말 작다 하더라도 릴리즈 후의 만에 하나 발생할 수 있는 버그까지 고려한다면 사람의 일정보다 해당 기능이 정말 작은지 더 쪼갤 수는 없는지 고민하는 것이 합리적입니다. 

그래서 결국 매니징해야 할 것은 사람이 아니라 일이라 생각합니다. 앞선 회고에서 작성하였듯 일을 아주 잘게 작게 쪼개는 것이 모든 일의 핵심입니다. 

 


 

* 효율적으로 일한다는 것은 무엇일까?


작년 한 해에 3번의 이직을 하면서 제가 정말 무엇을 하고 싶은가에 대해 많은 고민을 했고 제가 하고 싶은 것을 더 정확하게 알게 되었습니다. 3번의 이직을 통해 저는 효율적으로 일하는 팀에 들어가서 일하고 싶고 혹은, 현재 효율적이지 않더라도 변화를 필요로 하는 팀에 들어가 제가 그러한 효율적으로 일한다는 소리를 듣는 팀을 꾸리고 싶습니다. 그렇기 때문에 요새 새로 공부하는 영역은 일하는 방식(매니지먼트, 스크럼, 애자일)입니다.


효율적으로 일한다는 것은 상당히 막연합니다. 회사마다 효율에 대한 정의도 다를 것이고, 효율적으로 하는 업무에 대해서도 다를 것이기 때문입니다. 또한 그렇기 때문에 단순히 책을 본다고, 자격증이 있다고 해서 인정받기 어렵다 생각합니다. 그럼에도 이 분야에 관심가는 이유는 좋은 제품을 만들기 위해서는 효율적으로 일해야 하기 때문입니다. 효율적으로 일한다고 좋은 제품을 만든다는 것은 보장할 수 없지만 좋은 제품을 만들기 위해서는 우리 모두가 효율적으로 일해야 합니다. 



 

‎* 나는 일이 되게 하는 사람일까? 무엇이든 할 수 있는 사람일까?


Chief Executive Officer와 Chief Product Officer의 차이는 무엇일까요? 창업에 대한 고민을 해보았음에도, 여러 회사를 다녀보았음에도 단순하게 CEO는 회사 전반을, CPO는 제품 전반을 책임진다는 것 외에는 크게 와 닿지 않았던 것 같습니다. 그 외 구체적으로 어떤 마인드여야 하는지, 어떤 사람이 CEO에 적합한지, 유능한 CPO인지 명확하진 않았던 것 같습니다. 


요근래 창업하신 분들을 만나고, 관련된 책들을 읽고나서 조금씩 CEO와 CPO에 대한 차이를 알아가고 있는 것 같습니다. CEO, CPO 모두 좋은 제품을 만들고 사회를 바꾸고 싶다는 생각을 가진 사람이지만, CEO는 내 회사를 위해 어떠한 일도 하는 사람이라는 점에서 차이가 있는 것 같습니다. 물론 창업자인 분들도 내 회사를 위해 모든 일을 할 생각을 가지고 있겠지만 CEO라는 직책이 주는 책임이 다른 것 같습니다. 


조금 더 넓고 깊은 관점에서 일을 바라보고 회사를 위해 어떠한 일도 해야한다는 점에서 저는 아직까지는 일이 되게 하는 사람이 맞지 않나 생각합니다. 



url thumbnail

2023년 3월 3주 회고

* 매니징해야 할 것은 사람이 아니라 일. 모든 회사가 그렇듯 풍부한 인력풀이 있어 하고 싶은 것을 자유롭게 할 수 있는 상황은 아닙니다. 그렇다보니 하고 싶은 많은 일들 중에서도 할 수 있는 것을 고르고, 할 수 있는 것들 중에서도 우선 순위를 정합니다. 이러한 과정 속에서 정말 지양하는 것 중 하나는 개개인의 일정까지 관리하는 것이라 생각합니다. 물론 프로젝트가 끝나고 다음 프로젝트가 정해질 때까지 공백이 길어진다는 것은 회사나 개인에게 안 좋은 현상이라 봅니다. 또한 잠깐의 공백에 우선순위가 낮은 일을 빨리 처리할 수 있다면 정말 좋다 생각합니다. 하지만, "누가 언제 어떤 프로젝트가 끝나니 우선순위가 낮은 일을 중간에 끼워넣자", "이 일은 금방할 수 있으니 짧게 빠르게 해보자" 라는 판단은 굉장..

https://wikilog.tistory.com/63


2
0
Learning by Doing

Learning by Doing

2023년 3월 2주 회고

  • 좋은 제품이란?


PM을 맡은 다음부터 끊임없이 스스로에게 묻는 한 가지 질문은

과연 좋은 제품은 무엇인가?

라는 것입니다. 잘 팔리는 제품이 좋은 제품일 수도 있고 사용성이 편한 제품이 좋은 제품일 수도 있습니다.


개인적으로는 좋은 제품이란 사용자 문제를 해결함에 있어서 선택과 집중을 잘한 뾰족함을 느낄 수 있는 제품이라 생각합니다. 제품에 뾰족함이 있다는 의미는 사용자가 제품을 사용하자마자 기획한 기능의 의도에 맞게 사용하며, 달리 설명이 없더라도 "어떻게 사용해야겠다.", "아, 이 기능은 이럴 때 사용해야 하는구나" 라는 것을 바로 알 수 있는 것 입니다.


좋은 제품을 만든다는 것은 정말 어렵지만 어떻게 보면 한 끗차이란 생각도 듭니다.

 


* 기능은 작게, 작게, 더 작게


좋은 제품을 만들기 위해서 중요한 것이 무엇일까요?


저는 기능 단위를 잘게 쪼개는 것이 시작이라 생각합니다. 대부분 회사들은 한정된 인력을 운영할 수 밖에 없습니다. 그렇다보니 어떤 일을 하기 전부터 리소스에 대한 고민을 먼저 합니다. 이는 순서가 바뀌었다 생각합니다.


우선 기능을 작게, 아주 작게 린하게 움직일 수 있도록 쪼개고 그 다음 리소스를 고민해야 합니다. 물론 린하게 움직인다는 것이 무조건 좋은 점만 있는 것은 아니지만, 제품을 많이 검증해볼 수 있다는 점에서 기능을 작게 하는 것이 좋은 제품을 만들 수 있는 확률이 올라갑니다.

 


 

‎* 공유를 잘하는 조직 vs 공유가 안되는 조직

‎

공유를 잘한다는 것은 정말로 어렵습니다.


"이걸 왜 이야기하지?" 라는 생각부터 "이건 왜 이야기 안하지?" 라는 생각 사이의 모든 내용을 정말 잘 버무려야 하기 때문입니다.  또한 이러한 기준이 단순히 개인과 개인이 아닌, 팀과 팀, 부서와 부서를 넘어 회사 자체의 ‎하나의 문화로 자리가 잡혀 있어야 합니다. 하지만 단순히 공유를 잘한다고 공유 잘하는 조직이라는 이야기를 들을 수 없습니다.


모든 것을 투명하게 공개하는 것도 중요하지만 공유해야 할 내용이 잘 정리되어 반드시 들어야 할 사람에게 전달되는 것이 더 중요합니다.


 

* 반쪽짜리 프로세스/시스템


하나의 새로운 프로세스를 도입하고자 할 때는 ‎도입보다 운영, 관리 측면에서 더 많은 부분을 고민하고 리소스를 투입해야 합니다. 도입보다 운영, 관리가 중요한 이유는 도입 당시 상황과 운영, 관리하는 상황이 매우 달라지기 때문에 용두사미가 될 확률이 크기 때문입니다.


만약 회사에 반쪽짜리 프로세스/시스템이 있다면 운영, 관리의 영역이 필요하다고 생각해야 합니다. 예를 들어 A 라는 툴을 도입했다 할 경우 2주 단위 혹은 한 달 단위로 관심있는 사람들을 모아 운영 회의를 지속해야 소위 반쪽짜리 프로세스/시스템으로 남겨지지 않게 됩니다. 

 

* 물들어간다는 두려움


회사 생활을 하면서 경계해야 할 것들 중 하나가 동화되는 것입니다.


나의 동료, 나의 사수, 나의 회사에게 동화된다는 것은 성장에 도움을 주지만 성장에 저해되기도 하기 때문입니다. 동료에 대해, 회사에 대해 객관성을 잃어간다는 것만큼 나 스스로에 대한 객관성을 잃어가기 때문입니다.


고이면 결국 썩는다는 사실이 변하기 않기 때문입니다.



url thumbnail

2023년 3월 2주 회고

* 좋은 제품이란? PM을 맡은 다음부터 끊임없이 스스로에게 묻는 한 가지 질문은 과연 좋은 제품은 무엇인가? 라는 것입니다. 잘 팔리는 제품이 좋은 제품일 수도 있고 사용성이 편한 제품이 좋은 제품일 수도 있습니다. 개인적으로는 좋은 제품이란 사용자 문제를 해결함에 있어서 선택과 집중을 잘한 뾰족함을 느낄 수 있는 제품이라 생각합니다. 제품에 뾰족함이 있다는 의미는 사용자가 제품을 사용하자마자 기획한 기능의 의도에 맞게 사용하며, 달리 설명이 없더라도 "어떻게 사용해야겠다.", "아, 이 기능은 이럴 때 사용해야 하는구나" 라는 것을 바로 알 수 있는 것 입니다. 좋은 제품을 만든다는 것은 정말 어렵지만 어떻게 보면 한 끗차이란 생각도 듭니다. * 기능은 작게, 작게, 더 작게 좋은 제품을 만들기 위해..

https://wikilog.tistory.com/62


3
0
Learning by Doing

Learning by Doing

2023년 3월 1주 회고


  • 하나의 해결책으로 여러 개의 문제를 해결하지 말자.


회사에서 일을 하다보면 아래와 같은 일들이 많이 벌어집니다. 


A라는 문제를 해결하기 위해 Z라는 해결책을 찾습니다. Z를 가만히 보니 B도 해결할 것 같습니다. 해서 원래 A만 하려 했다가 B도 같이 처리하기로 합니다. 


예전에는 여러 문제를 해결할 수 있는 해결책을 내는 사람이 뛰어나다 생각했는데 요새는 1개의 문제에 집중하여 1개의 해결책을 만드는 사람이 뛰어나다라는 생각합니다. 그 이유는 1개의 해결책으로 여러 개의 문제를 해결할 때 생각지도 못하게 구현 공수가 늘어나거나 릴리즈해도 Side effect이 많이 발생하기 때문입니다. 또한 문제에 대한 뾰족하지 못한 타켓이나 범위로 인해 성과 측정도 쉽지 않습니다. Lean하게 일하기 위해서는 생각하는 법도 바꿔야 한다 생각합니다.



  • 나태함은 나도 모르게 다가온다.


이번 주 우연한 기회로 다른 회사의 CPO와 커리어에 대한 이야기를 나눌 일이 생겼습니다. 솔직하게 개발자에서 PM으로 전향한 이후 "1등 제품을 만들고 싶다", "그 제품이 제가 만든 회사의 제품이었으면 좋겠다" 정도만 생각하고 지내다가 막상 진지하게 진로에 대해 이야기를 나니 그 전의 생각들을 입 밖으로 말할 수가 없었습니다. 이야기 하는 내내 "이렇게 살아도 되나?" 라는 불안과 걱정이 앞서 왔었습니다. 바쁘게 살았다 생각했는데, 절박하게 살았다 생각했는데 많이 긴장이 풀려있었음을 느꼈고 단순히 하고 싶다의 열정과 패기만으로는 어떤 것도 할 수 없음을 깨달았습니다. 


https://wikilog.tistory.com/61

7
1
Learning by Doing

Learning by Doing

프로젝트 협업 도구 도입을 도와드리고 싶습니다

안녕하세요

PM으로 업무를 하면서 프로젝트 관리 도구가 생각보다 중요하다는 것을 알게 되었습니다. 저의 경우 거의 모든 회사에서 Jira를 사용해왔는데요. 그러다보니 자연스레 Jira에 대해 많이 배우게 되었습니다.

이를 바탕으로 Jira가 궁금하신 분들에게 어떻게 사용해야하는지 혹은 사용하면서 아쉬운 점은 무엇인지 듣고 해결해드리고자 합니다.

또한 우리 회사에 어떤 협업 툴이 도입되면 좋을지도 같이 고민해드리니 혹시나 관심 있으신 분들은 댓글 남겨주세요!

감사합니다!

4
4
Learning by Doing

Learning by Doing

하루만에 노코드로 앱 만들어보기 & 느낀 점


노코드에 대해 알게 되다.

노코드는 2020년부터 익히 들어 알고 있었지만 직접 관심을 가지고 사용해보기 시작한 것은 올해 8월이다. flutterflow 라는 서비스를 통해 노코드의 동작방식을 이해했으며, 앱을 만들어보기 보다는 flutter를 이해하는 방법 중 하나로 활용하였다. 따로 노코드를 활용해 앱을 만들지 않았던 이유 중 하나는 내가 원래 개발을 할 줄 알다보니 노코드라는 생태계를 이해하는데 생각보다 오래걸렸다는 것이 한 몫 했다.


이거 그냥 API 하나 만들면 되는데..

서버에 DB 하나 띄워놓고 이 가격이라고...?



그럼에도 노코드로 앱을 만들어보기로 결심하다.

3 ~ 4개월 정도 노코드 공부를 하면서 노코드로 구현하면 좋을 만한 아이템들을 고민하기 시작했다. 아이템을 고민하면서 계속 든 생각은 애매하다 였다. 어느 정도 사이즈로 가야할지 감이 안 잡혔고, 직접 개발하는 게 더 빠를 것 같은 느낌이 계속 들어서 엄청 힘들었던 것 같다. 결국 아주 작은 스펙인 CRUD만 활용하는 게시판 형태의 서비스를 노코드로 구현해보기로 했다.



노코드로 앱을 만들다.

CRUD 형태의 게시판이다보니 생각했던 것보다 더 빨리 만들 수 있었다. 사전에 기능 정리 및 어떤 노코드 툴을 사용할 것인지 미리 정리해서 그런지 총 6시간만에 간단한 앱을 만들 수 있었으며 테스트까지 모두 완료하였다. 실로 엄청나게 빠른 수준으로 앱을 만들었던 것 같다.



노코드로 앱을 만들고 난 후 느낀 점

  • 나에게 맞는 노코드 툴을 찾아라!
  • 3 ~ 4개월 glide, webflow, flutterflow, softr, parabola 등 다양한 노코드 툴을 공부하면서 느낀 점은 노코드로 만들 수 있는 서비스의 범위가 굉장히 제한적이기 때문에 노코드를 통해 서비스를 만들고 운영하고자 할 경우 스펙을 굉장히 잘 정리해야 한다는 점이다. 또한 이렇게 정리된 스펙을 기준으로 해당 기능을 가장 빠르고 쉽게 구현할 수 있는 노코드 툴을 잘 찾아야 한다는 점이다. 3개월 정도 여러 개의 노코드 툴을 많이 사용해본 이유도 여기에 있었다.
  • 노코드는 디자이너들이 필요하다는 생각을 더 늘릴 수 밖에 없을 것이다!
  • 노코드로 앱을 만들고 난 후 내가 가장 먼저 들었던 생각은 아... 디자이너 필요하다.. 이거였다. 대부분의 노코드 툴이 기본 제공되는 UI 위에 색상을 바꾸는 수준이다보니 디자인을 입히지 않으면 너무 이상했다. (컴공 1학년 1학기 과제 느낌 물씬...) 그러다보니 메인 컬러는 어떻게 할 것이며 글자 크기는 어떻게 할 것인지 등등 디자인 요소들이 난제였다.
  • 노코드는 개발자들이 더 필요하다는 생각을 더 늘릴 수 밖에 없을 것이다!
  • 노코드 공부하고 있다고 했을 때 대부분의 사람들이 했던 말은 개발자들의 밥그릇이 사라지는 것 아니냐라는 말이었는데 하면 할수록 결국 노코드로 서비스를 만든 순간부터 더욱 더 개발자들이 필요해질 수 밖에 없겠구나란 생각만 들었다. 그 이유는 노코드는 MVP 수준의 서비스를 검증하기 위한 것이기 때문이다. PMF 검증에 성공했다면 결국 서비스 유지보수와 운영을 위해서는 개발자들이 필요해지기 때문이다. (사람마다 생각의 차이는 있을 수 있을 것 같다.)
  • 이와 더불어 사실 지금까지도 고민이 되는 부분은 확장성이다. 개발을 할 때 더 많은 트래픽, 더 많은 기능을 포함하기 위해 코드의 확장성을 많이 고민했는데 노코드로 하다보니 이 모든 것이 다 돈이거나 포기를 해야 했다. (대부분 포기했다.)




결국 현재 시중에 나와있는 노코드 툴은 내 가설이 시장에서 의미가 있음을 검증하는 수준의 서비스를 만드는데 의미가 있으며 너무 많은 욕심을 부린다면 이도저도 되지 않는다는 것을 알았다. 이를 기반으로 다음 노코드 서비스를 만들어 볼 예정이다.


ps. 노코드로 서비스를 개발하고 운영한다는 것에 대해 사람마다 의견이 다를 수 있을 것이다. 이 글은 개인적인 의견임으로 잊지 않았으면 좋겠다.

9
2
Learning by Doing

Learning by Doing

[P터지는 Mㅏ켓 Fit 찾아내기] 후기


🧐 참여 동기

PO/PM 이라는 직군으로 일하기 시작하면서 1등 제품을 만들고 싶단 생각이 들었다.

왜 이 제품에 열광하는 거지? 이 제품은 뭐가 다른 걸까? 어떻게 고민했을까? 등등

이러한 문제들은 혼자 해결할 수 없다보니 '해당 분야에서 인기가 있는 것들을 최대한 많이 사용해보면 공통점을 찾을 수 있겠다'라는 생각으로 접근하기 시작했다.

그러면서 Product Hunt 라는 사이트를 알게 되었고 더불어 Typed 라는 제품도 알게 되었다.

일주일 정도 사용해보면서 '오 재밌는 제품이네?'란 생각이 있었지만 현재 사내에 사용하고 있던 툴로도 버거웠던 시기였기 때문에 제대로 사용해보진 못하였다.

그렇게 1년 정도 시간이 지난 뒤 디스콰이엇에서 PMF에 대해 웨비나를 한다는 것을 알게 되었고 한 번 들어볼까라는 생각에 신청하게 되었다. 마침 사이드 프로젝트나 창업에 대한 생각이 늘어났기 때문이기도 하다.



📆 참여 후기

결론부터 말하자면 참석하길 정말 잘했다.

화요일 저녁에 하는 거라 솔직히 조금 부담은 있었지만 참석하지 않았다면 몰랐을 내용이 한 두 가지가 아니었다. 두 가지 부분에서 크게 인상을 받았다.


1️⃣ Product Market Fit을 찾는 방법 : User를 Fan으로 만들어 Team이 되도록 해라

"User → Fan → Team"

블록체인이 붐이었을 시절 ICO를 입에 달고 살았던 말이었지만 Typed 팀(비지니스캔버스)의 내용을 들으면서 몰입, 전략 모든 측면에서 부족했구나라는 것을 바로 느낄 수 있었다. 다녔던/다니는 회사가 대부분 파트너가 제품을 대신 팔아주는 B2B2C 영역이었고 리더들이 항상 이상주의자처럼 일하지 말라는 말을 늘상 했기 때문이다.

그래서 항상 제품을 기획할 때 문제를 파악하는 방식이 고객 중심이 아닌 회사 중심이었고 사용자보다는 돈을 벌어주는 파트너가 원하는 기능만 넣게 되었다.

나 또한 점차 고객 중심으로 생각하는 방법을 잊고 편하게 가려고 했단 생각이 들었다.


2️⃣ Go To Market 전략 : 지기 어려운 로직을 만들어라

성향 상 대기업이 맞지 않았기 때문에 많아야 300명 정도의 스타트업을 다니면서 느낀 점이 있다면 지금은 정말 투자 혹한기라는 것이다. 스타트업의 거품이 빠졌다라는 표현이 맞을 것 같다. 결국 기업은 영리 집단이며, 돈을 벌지 못한다면 망한다는 것이다.

하지만 말 그대로 스타트업은 모든 면에서 시작하는 조직이다. 제한된 인력과 비용 때문에 투자는 어느정도까지 필수적인 요소이다. 그렇기 때문에 스타트업에는 생존 전략이 필요하다. 2번째 발표를 들으면서 크게 공감했던 부분이 성공한 회사에 대해 정말 철저하게 분석했다는 점이었다.

"부자가 되고 싶으면 부자가 어떻게 했는지 알아봐라"라는 말이 있다. 그들의 성장을 보면서 실패를 덜할 수 있을 뿐만 아니라 우리에게 맞는 전략을 세울 수 있기 때문이다. Typed 팀(비지니스캔버스)은 실제 이런 스터디를 했고 그 결과가 지금의 성공한 모습이라 생각이 든다.



▶︎ 마무리

Typed 팀(비지니스캔버스)이 진행한 [P터지는 Mㅏ켓 Fit 찾아내기] 웨비나는 여러 가지로 좋은 자극이 되었고 사이드 프로젝트를 시작하는 나에게는 더할 나위 없는 좋은 자극이 되었다. 무엇이 필요한지 부족한지 어렴풋이나마 감을 잡을 수 있었고 이제 실천을 하냐 마냐는 온전히 나에게 달렸다는 생각이 들었다.

좋은 시간을 만들어준 디스콰이엇과 Typed 팀(비지니스캔버스)에게 감사하다는 말을 끝으로 남긴다.







11
3