녹호두

제품 관리자(PO,PM)의 Product 일정관리 노하우!

https://youtu.be/gg56Z_LlXvE

워터폴 : 프로세스에따라 단계적으로 구현

애자일 : 최소단위제품MVP를 빠르게 출시해 개선하는 방식

->  프로젝트 성격에따라서 워터폴/애자일 둘 중 하나가 잘 맞을 수 있음

금융 플랫폼, 운영체제와 같이 한번에 완제품을 출시해야 하는 경우에는 워터폴이 적합

고객을 사로잡아야 사업의 성패가 결정되는 프로덕트의 경우 애자일 방식이 적합

backlog에 1) 로드맵 2) 내부 이슈, 기술 부채 3) 고객 요구사항 기록

- 고객 → 사용성 개선, 신규기능 추가, 버그

- 개발 → 우리만 아는 내부 이슈, 기술 부채

- 경영진 → 비즈니스 관련 task

* 기술부채 : 현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영 / 기술적으로 해결되어야할 문제들을 뒤로 미루고 비즈니스 문제를 해결하는 것을 앞당기는 것

backlog page

Inbox → pending (요구사항 정리, 분류, 그룹화 → new sprint 형성) → ready (정리된 task 모아둠)

weekly page

• goal - 모든 task는 목표를 기준으로 함
• in progress
  • backlog를 고르게 분배해 In progress를 잘 만들어야 한다.
  • 담당자 배정, 업무 진행 시 pm이 우선순위를 결정하기 때문에 1) 로드맵 2) 내부 이슈, 기술 분배 3) 고객 요구사항 세 가지의 밸런스를 잘 맞춰야 한다. 단, 회사와 협의한 goal 또한 하나의 기준이 되어야 한다.
  • → 중간에 끼어서 스트레스받는 경우가 많긴 하다.. 단, pm이 잘못 결정하면 프로덕트가 산으로 가는 경우가 많다.
  • 기재 시 각 과업마다 사용하는 이유를 함께 기재
• 여러 개의 sprint를 만들고, 운영단에서 발생하는 문제를 위한 sprint( ops )를 별도로 운영하며 비율은 80% 20%로 유지함

회고

• 스프린트 종료 후 각자 잘한점/개선할 점 각자 정리
• 개선할점 미안해서 안 쓰는 경우도 있는데 무조건 적게 해야 함
• 회고 진행 → 회고 미팅 → 최종 정리(by pm) → 다음 스프린트에 반영
  • ex. 000 프로세스 개편 ~

애자일의 핵심은 고객의 피드백을 듣고 원하는 제품을 만드는 것

수행주체는 사람이기에 팀 세팅이 가장 중요

소모되고 있다는 느낌보다는 의미 있는 일을 하고 있다는 동기부여

정체되어있기보다는 함께 성장하고 발전하는 과정

서로 신뢰하는 팀을 만들어야 한다.

→ 좋은 팀에서 좋은 프로덕트가 나온다.

잘하는 기획자의 기준은 무엇인가?

https://youtu.be/A5yHcKrgTHk

1. 기획을 잘한다는 것 = 업무 스타일이 맞는다는 것

• 넓게 트인 시야로 구체화
• 정리의 신
• 체계적인 위계 정리
• 일정관리의 신

2. 기획을 못한다는 것 = 쟤랑은 일 못하겠어

그게 아니라면, 어느 정도 기획을 하는 범주에 들어오는 것 → 그렇게 되면 업무 스타일이 생기게 된다.

ex. 잘하는 기획자 = 자신과 손발이 잘 맞는 기획자

ㄴ 여러 역량 중에, 동료들과 손발이 잘 맞느냐로 동료들에게 평가받을 수 있다.

ㄴ 기획을 잘한다는 객관적 지표는 없다. 누구와 손발이 잘 맞는가가 잘한다의 기준을 판단하는 것이고 그것은 개인마다 차이가 있을 수 있다.

if 내가 기획을 못하는 거 아닐까란 생각이 들 때

1. 정말 자질이 없을 때
2. 지금 이 팀이 안 맞을 때. 자신의 기획자로서의 성향과 안맞을때 → 조직 또는 팀을 바꿔보자

PO : 프로덕트를 이끄는 전문가

기획자 : 프로덕트의 완성도를 높여주고 현실화해주는 전문가

Con. 잘하는 기획자?

1. 객관적인 기준은 없다.
2. 주변 동료에 의해 평가된다.
3. 나와 손발이 잘 맞는 동료들을 주변에 두면 자연스럽게 잘하는 기획자가 된다.

디자이너와 개발자가 뽑은, 내 인생 최고의 Product Manager!

https://youtu.be/U3JhQlTFxWw

내 인생 최고의 프로덕트 매니저

• 콘텍스트/데이터/리서치 기반으로 커뮤니케이션
• 팀원들과 동등한 위치
• 개발자와 논쟁할 수 있는 지식을 갖춘 pm 이 좋은 pm이다.
• 로드맵을 지속적으로 리뉴얼하는 것이 좋다.
• 마감일보다는 해결책에 초점을 맞춘다 → 마감일도 중요하지만 해결책에 초점을 맞추는 게 중요하다. 마감일을 조금 유연하게 조절했다.
• 고객 중심으로 최고의 제품을 위해 C레벨과 마찰을 이겨냄
• 다양한 이해관계자들과의 커뮤니케이션 ← 디자인과 엔지니어링에 대한 이 해이 필요. 직접 개발/디자인 하진 않더라도 문제를 직접적으로 집어내는 역할은 필요
• 해결책보다는 문제를 찾아내고 소통하는데 더 많은 시간을 사용
• 디자이너와 개발자를 파트너로 대우. 보상보다는 제품 출시에 더 많은 신경을 쓴다.

BEST PM requirement

• 목표와 비전 설정
  • 왜 이 일을 해야 하는지 비전과 목표를 제대로 설명할 수 있다.
  • 지속해서 사용자, 경쟁사, 시장조사를 진행하고 이를 제품에 반영
  • 해결책보다는 문제를 더 깊게 고민
• 의사결정
  • 본인이 아닌 소비자, 비즈니스, 팀을 위한 결정을 내림
  • 중요한 것에 집중하고 불필요한 것들은 걸러낸다
  • 데이터에 기반한 의사결정을 내릴 줄 안다
• 업무지식
  • 해당 산업의 도메인에 대해 깊게 이해
  • 디자인과 엔지니어링을 이해함
  • 데이터를 제대로 사용할 줄 알고, 데이터를 이해하는 사람과 협업할 수 있다.
• 커뮤니케이션
  • 팀원 의견을 경청하고 올바른 실행방안을 만든다.
  • 이해관계자에 따라 상황에 맞는 모자를 쓰고 커뮤니케이션
  • 커뮤니케이션 메시지가 잘 되어있고 일관적이고 명확하다
  • 언더 커뮤니케이션보다는 오버가 낫다.
• 협업
  • 동료를 도구가 아닌 중요한 파트너로 대한다
  • 동료의 업무방식을 존중하고 효율적으로 일할 수 있도록 돕는다 → 마이크로 매니징보다는 역할을 위임함
  • 팀원의 질문 및 요구사항에 제때 답변을 해준다.
• 태도/자세
  • 제품을 더 좋게 만들기 위해 경영진에 의의를 제기할 수 있다.
  • 피드백을 감정적으로 받아들이지 x
  • 자기 아이디어와 사랑에 빠지지 x

프로젝트 매니저와 프로덕트 매니저의 역할
https://youtu.be/pSwnHgh1NzI

프로젝트 매니저와 프로덕트 매니저

프로젝트 매니저 \ 프로덕트 매니저

• 시작과 끝이 있음 \ 제품(지속적인 개선)
• 브랜드 사이트 구축, 시스템 통합(에이전시, SI기업) \ 페이스북 - 타임라인, 채팅 유튜브 - 큐레이션, 검색 (서비스 기업) → 시간이 지날 수록 고도화, 서비스 다양화
• Project \ Product
• 일정내 효율적으로 프로젝트 런칭 → 요구사항(의사결정자의 니즈) 분석이 제일 중요 \ 고객이 원하는 제품 만들기 → 고객의 니즈 발견을 위해 설문, 인터뷰, AB테스트
• 의사결정자에게 보고하고 컨펌하는 과정의 반복 \ 가설 → 실험 → 분석 → 가설의 반복
• pm의 역할 - 매니징(제 시간내에 원활히 런칭될 수 있도록) \ 매니징보다는 협업에 가까움 - 실무 기획에도 참여

>

서비스 기획이더라도, 프로젝트 매니저가 필요한 경우가 있음

초기 제품 출시단계에서도 프로젝트 매니저가 필요한 경우가 있다.

둘다 소화할 수 있는 역량을 갖추자!