어떤 직무든 어떤 전공이든 프로덕트 매니져를 해보고싶은사람, 프로덕트를 맡았지만 더 명확한 정체성을 가지고 싶으신분

PM의 직무와 개념 : 코드를 다루는 엔지니어가 아니다 제품의 실무에 직접 기여 사용자에게 가치를 주는 제품을 만들고 싶은사람, 프로덕트의 가치를 극대화 하는 방법을 찾아 실현해내는 사람

해야할 업무목록을 가지고 나열하여 이것이니면 안되 라기보다는 본질과 원칙을 가지고 유연하게

기능조직 : 프로덕트 매니져만 모인 팀을 말함 한명의 pm이 여러개의 프로덕트와 서비스를 관리 퀄리티 높은 기획, 체계적인 업무 시스템, 부서대 부서로 소통 , 단정: 넓은 시각의 의사결정 너무많은 업무와 디펜스 노력,

사일로/ 스퀴드 조직 : 토스가 예. Pm, 디자이너, 개발자, 등등 관련 인원들이 모두 한조직에서 활동, 하나의 프로덕트에 집중 빠른 개발속도 구성원의 높은 개발 이해도, 단점 : 개발에 의존, 못하는 조직 차별, 인력의 매니징 부제(선임 이없어 능력상승이 힘이듬)

프로덕트가 어떤 중심으로 가야되는가?

제품중심: B2C와 같이 명확한 프로덕트가 회사를 견인하는 경우 또는 B2B 지만 명확한 프로덕트로 시작을 한 경우

제품중심으로 의사결정이 쉬움

비즈니스 중심: B2B 와같이 고객관계 중심으로 비즈니스가 선립되는 경우, IT프로 젝트가 아닌 본업의 캐시카우가 있는 경우

사업개발에 조금더 집중

일 잘하는 프로덕트 매니저의 조건: 문제 해결 역량, 시각화(말이 아닌 일목요연하게 시각화하면서 직접 드러냄), 책임감(필요한 것을 직점 물어봐야되며 남한테 왜 하지 않았냐? 왜 주지 않았냐? 왜 하지 않았냐를 하면 안됨)