section 1

프로덕트 매니저의 역할, PM고유의 전문성 네가지

1. 사용자와 고객 :

   정성+정량적 지식

2. 데이터 : '

   프로덕트가 어떻게 이용되고 있는가?' 를 파악할 수 있어야 함

3. 비즈니스 : 수익 구조, 니즈 등 사업이 어떻게 움직이고 있는지 파악

4. 산업 : 경쟁사 + 산업 동향 파악

즉 PM이란, 단순히 기획안, 정책서 등 문서 작성을 하는 것이 아닌 문제를 파악하고 제품을 통해 해결책을 찾고 시장성을 만들어 내는 사람

• 성공적인 프로덕트의 네가지 조건 : valuable, usable, feasible, viable

프로덕트 매니저가 사업성과를 낸다는 것

프로덕트 마켓 핏 찾기(PMF)

시장(고객)을 만족시키는 제품 → 고객이 문제 해결을 위해 우리 서비스를 사용하고 있다.
ㄴ (좋은)시장이란? : 사업이 성립될 수 있을만큼 많은 잠재고객이 있는 시장(aka 지불 의사가 큰 시장)

Pre-PMF단계 라면 PMF를 찾는 것이 PM의 역할

PMF 이후의 제품 업무

1. feature work : 제품 기능 확장으로 고객가치 창출 + 사업 가치 창출

2. growth work :

   기존 시장 대상으로 더 많은 고객들이 제품을 사용하도록 만들어서 가치 창출
   ㄴ eg : 신규 유저 온보딩

   
   *pmf 를 찾는 과정에서도 제품은 성장을 함. feature work도 제품 성장을 위한 일인데,
   growth work는 좀 다름.

   접근성을 늘려서 수익을 늘리는 일

3. PMF Expansion : 동일 제품으로 신규 시장 or 신규 제품으로 기존시장 or 신규 제품으로 신규 시장에 진출해서 성장하는 일

4. Scail work : 스케일업을 위한

PM이 사업성과, 사업 가치를 낸다는 것은? :PMF을 찾고 Feature Work를 통해 고객에서 가치제공 + 사업에도 가치를 만들고 Growthwork를 통해 사업 성장을 만들고 PMF Expansion을 통해 성장을 만들어내는 것

*기능 기획, 프로젝트 관리가 아니라 큰 맥락을 염두하고 제품 조직이 어떻게 성과를 낼 수 있을지 실행하는 것

mandate levels(*해야 하는 일이 무엇인지 파악하고 미리 선 제안할 때 참고하기)

section 2

문제, PM의 사고 알고리즘 - 문제정의, 문제해결

문제정의

비즈니스 환경에서 우리가 하는 모든 일은 문제를 해결하는 일

문제 정의 : 문제를 명확하고 구체적으로 만들기

문제 해결을 위해 배경을 알아야함 진짜 원인을 알아야 그 방법이 도출된 방식을 알 수 있고 그 방법이 원인 해결을 위해 맞는 해결책인지 알 수 있으니까. → 나도 다른 사람에게 설명할 떄 꼭 배경을 같이 설명하는게 좋겠다.

• problem space/solution space

  • 문제나 해결방법은 딱 떨어지는 것이 아니기 때문에 전방위적으로 사고할 수 있어야 한다.

  • 우리가 정의한 문제는 우리가 의식하지 못한 상위문제의 솔루션을 내포

문제 정의에 도움이 되는 질문

1. 그 문제는 어떤 점 때문에 중요한가?

   1. 해결해야하는 이유

   2. 맥락은 무엇인가?

   3. 누구의 문제이고 어떤 고민이 있는지 파악

2. 그 문제는 정말로 중요한가? → 선택에는 기회비용이 따른다. 기회비용 관점에서 사고하기

   1. 맥락 파악 후 해야할 질문.

   2. 꼭 해결할 필요는 없음

   3. 기대가치 가늠하기 - 얼마나 많은 고객이 문제를 겪는가?

3. (현상 아래) 원인은 무엇일까?

문제해결

문제 정의=분석, 문제 해결 = 창조

아이데이션

1. 팀에 문제의 맥락 커뮤니케이션하기

2. 아이디어는 솔직하게 피드백

3. 논리적으로 말하기 이상의 것이 필요

이터레이션

제품을 만들고 학습하기를 반복함으로써 빠르게 이터레이션 싸이클 반복하기

방법론 : 린스타트업, creative selection, braintrust

린스타트업의 대표적인 오해 : 최소기능제품으로 빨리 출시하자!
ㄴ MVP는 고객과 시장에 대한 가정 검증을 위해 사업적으로 타당한 최소 기능을 갖춘 제품을 말한다.

-> 제대로 하려면?

1. assumption(고객이나 제품에 갖고 있는 추측, 가정 등)을 문서 형태로 명확히 정의하기

   
   : 검증방법도 고객인터뷰, 랜딩페이지 테스트 등 어떤 방법론이 어떤 맥락에서 어떤 가정으로 테스트하는데 좋은지 알고 사용해야함

    

2. 고객 피드백 수집 방법 계획
   : 직관이 아닌 고객의 (정성/정량) 피드백에 의존하기
   ㄴ 특히 정성 데이터를 통해 유저 행동의 why를 알 수 있음

결론

1. 문제는 잘 정의해야 해결할 수 있다(조급하지 말자)

2. 문제 정의 맥락, 기회비용, 현상을 넘어 더 먼곳을 보자

3. 문제 해결은 분석이 아닌 창조의 영역

*팀과 함께 협력적으로 아이디어를 내고 끊임없이 이터레이션
*린 스타트업 오해 금지 가정 검증하기

고객의 모든 문제가 비즈니스가 되진 않는다 - 해결할 가치가 있는 문제

우리가 가정한 문제가 중요한 문제인지 어떻게 알 수 있는가? → 고객가치 판단

1. 적극적으로 해결책을 찾는가

2. 문제 해결을 위해 시간과 돈을 쓰는가?

타당한 비즈니스 모델을 만들 수 있는 문제인가? → 사업가치

1. 많은 사람이 겪는 문제인가?

   b2c 천만, b2b 10만개 조직

2. 문제를 인지하고 신경을 쓰는가?
   :

   인지하지 못한 문제는 시장이 존재하지 않는 것. 문제가 있다고 전도한다면 시장을 만들 수는 있지만 어려운 일

3. 문제 해결을 위한 충분한 예산이 있는가?

4. 반복해서, 자주 경험하는 문제일까?

회고

과제

접근 관점 : PM의 여러 관점을 생성형 AI 등장을 배경으로 상반된 입장을 살펴보고자 함.

종합

• 칭찬하고 싶은 점 : 계획대로 학습을 진행했다.

   

• 아쉬웠던 점 : 과제를 하면서 느낀 점이지만 여전히 자료를 목적에 맞게 작성함에 있어 어려움을 느끼는 것 닽다.

• 보완하고 싶은 점 : 보는 사람의 목적에 맞게 자료를 작성하는 방법에 익숙해지자.

   

   

  총평 : 연차에 비해 잘하고 있는지 늘 의심하던 중이었는데 기준점으로 삼을 수 있을 만한 강의를 만난 것 같아 다행이라는 생각이 든다. 앞으로도 많은 인사이트를 얻을 수 있도록 열심히 배워봐야겠다. 특히 인스파이어드는 초반을 읽고 아직 다 읽어보지 못했는데 이번 스터디를 진행하면서 완독을 목표로 삼아야겠다.. 이번주도 잘 지나갔다! 다음주도 화이팅!