🥰 좋은 PM이 반드시 알아야 할 우선순위 정하기 기법 4가지 ✔ PM으로서 성장하기 위해 우리는 무엇을 노력해야 할까요? 아니, 여러분은 어떤 노력을 하고 있나요? 저는 현업 PM은 아니지만, 과거 PM으로서 업무를 했다고 말하기도 애매하지만, 우선순위 정하는 일이 중요하다고 생각해요. 그만큼 어려운 일이고, 중요한 임무라고 할 수 있죠. ✔ 여튼, 저는 현업은 아니지만 PM으로서 세 가지가 중요하다고 생각합니다. 첫째, 우리의 목표가 무엇인지 명확하게 파악하는 일입니다. 우리가 처한 비즈니스 환경 위치에 따라, 유저에 따라 취해야 하는 전략과 방향이 달라지기 때문입니다. ✔ 둘째, 목표를 달성하기 위해 가장 중요한 기회가 무엇인지 찾는 일입니다. 이를 위해서는 유저의 행동지표에 따라 변화하는 결과가 어떤 원인에서, 어떤 상관관계 속에서 발생하는지 가설을 세우고 빠르게 실행하여 결과를 도출하는 일입니다. ✔ 셋째, 중요한 기회를 찾는 방법은 빠르게 반복하는 일입니다. 스타트업에서 '일'은 완벽하기 어려워요. 하면서 수정하고, 가설을 재정립하고 결과를 만드는 것이 중요하죠. 즉, 짧은 호흡을 통해 우리가 나아가야 할 지표를 만드는 일이 중요해요. 이 과정을 통해 성공 경험도 쌓고, 팀도 리드하고 조율하고 하는 것이죠. 그럴 경우 우리는 더 나은 PM이 될 수 있다고 생각합니다. ✔ 여기까지는 제가 생각하는 PM의 지향점(?)이고요. 다음으로는 기사에 나온 우선순위 정하기 기법 4가지를 요약해드리겠습니다. 1️⃣ MoSCoW(모스코우) : 작고 복잡하지 않은 프로덕트/서비스를 위한 가장 간단한 접근 방법 ✅ MoSCoW는 네 가지 우선순위 범주의 약어인데요. 모음 'o'를 뺀 M, S, C, W를 의미합니다. - Must have: 이 기능(features)를 빼고 제품 딜리버리/서비스 론칭을 생각할 수 없는 것들 - Should have: 높은 우선순위를 지니는 기능이 분명하지만, 그것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때 사용 - Could have: 여러분이 충분한 자원을 가지고 이다면, '할 수 있었을' 것들이지만, 성공을 위해 꼭 필요한 것은 아닐 때 이 순위를 사용 - Won't have: '이번 버전에는 포함되지 않을 것이다'를 의미하는 것으로, "다음 버전에 포함시키도록 신중하게 검토하게습니다."를 의미 ⭕ 장점 - 깊은 이해나 복잡한 계산 필요X - 팀 전체가 빠르고 쉽게 적응할 수 있는 우선 순위 지정 기법 - 필수 항목 제외 엄격한 시간제한 X - 기능별로 적절한 시간 배분 O ❌ 단점 - 구현 범주 일관성 X 그래서 전체적 시스템적인 릴리즈 계획 세우기 어려움 - 필요한 것가 멋진 것 사이 불균형 발생 - 범주 간 흐릿한 구분이 종종 필수 목록에 들어가는 경우 발생 2️⃣ 워킹 스켈레톤 (Walking Skeleton) : 기본 아키텍처의 PoC(Proof of Concept:기술 검증 버전) ✅ 사용자 스토리에 초점을 맞추어 우선순위 결정 1. 먼저 필요한 사용자 스토리에 순위를 매김 2. 필수 기능의 구현에 중점을 두기 때문에 주요 기능이 완전하게 동작하는 제품의 형태를 갖고 있어야 함 3. 비즈니스 가치를 충분히 보여주는 형태를 갖고 있어야 함 4. 딜리버리와 배포까지의 모든 과정을 포함하기 때문에 제품 기능 테스트도 과정에 포함 ⭕ 장점 - 핵심 기능 우선 순위 정의 시 많은 시간이 필요하지 않음 - 실제 동작하는 MVP를 목적 - 사용자로부터 우선순위 결정에 대한 피드백 신속 ❌ 단점 - 주요 기능 동작 프레임워크 형태를 띠지만, 중요한 다른 기능을 포함하고 있지 않을 수 있음 - 주요 기능 동작 프레임워크 완성이 필요하기 때문에, 첫 릴리즈까지 시간이 필요함 - 출시 가속화를 위해 주요기능 우선순위 조정 할 수 있기 때문에, 최초 실행 가능 제품 버전은 시장 출시 준비가 되지 않음 프로토타입으로 나올 위험이 있음 3️⃣ 라이스(RICE: Reach, Impact, Confidence and Effort): 우선순위를 설정하기 위해 등급 점수 모델 방법 사용 ✅ RICE: Reach, Impact, Confidence 및 Effort를 나타냄 - Reach: '도달 범위', 특정 기간 동안에 이 기능을 사용할 수 있는 사용자 수를 반영 - Impact: 사용자가 이 기능을 사용함으로써 어떤 영향을 받을지 생각, 상대값을 입력하여 평가 - Confidence: '신뢰도', 이 기능이 사용자에게 얼마만큼의 혜택을 주는지에 대한 추정 값 - Effort: 제품, 디자인 및 엔지니어링 팀이 소요한 시간 *공식: RICE = (Reach*Impact*Confidence)/Effort, RICE값이 클수록, 우선순위가 높다는 뜻 ⭕장점 - 큰 그림 확인 가능 - 실제 제품 릴리즈 과정에서 나오는 데이터와 KPI 기반이기에 실제로 매우 의미 이는 평가 지표 - 사용자 만족도에 충분히 기여 ❌단점 - 모든 메트릭 동일시를 위해 백 로그 항목별 계산 시 많은 시간 필요 - 모든 데이터 준비 못할 경우, 출시 연기 결정 만들 가능성 높음 - 책임에 대해 불명확 4️⃣ Kano 모델: 고객기반의 우선순위 지정 방법, 프로덕트/서비스의 기능에 대해 사용자들의 만족도와 행동이 다르다는 사실부터 시작 ✅ 백 로그 포인트를 4가지 기주(Must-be, Performance, Attractive, Indifferent)으로 나눕니다. - Must-be: MoSCoW의 Must Have와 같은 의미 - Performance: 프로덕트/서비스가 동작하기 위해 반드시 필요한 것은 아니지만, 고객이 필요로 할 경우로, 고객의 요구와 기대치를 예측하는 것과 매우 밀접하게 관련 - Attractive: MoSCoW의 Could Have와 같은 의미 - Indifferent: 고객 만족에 미치는 영향이 거의 없는 것으로, 고객은 관심이 별로 없는 기능 ⭕장점 - 제품의 잠재적인 장점과 단점을 강조 - 가치 제안 관점에서 제품을 평가하고 사용자의 요구에 맞게 조정 ❌단점 - 고객의 입장에서 프로덕트/서비스를 구상하는 방법 즉, 고객은 특정 릴리즈나 특정 기능에 필요한 시간과 비용을 고려하지 않음 - 잠재 고객 대상 설문조사를 포함하기 때문에 많은 시간 필요하여, 출시 시기 늦추거나, 프로덕트 팀의 개발 집중도를 떨어뜨릴 가능성 있음 - 고객의 의견과 지식에 의해 제한될 가능성 있음