프로덕트 디자인에서 우선순위를 정하는 네 가지 방법론

 세상에 완벽한 제품은 없다. MVP는 말할 것도 없고, 만반의 준비를 하고 나왔다고 하더라도 생각하지 못했던 사용상의 문제나 빠르게 변하는 시대의 흐름에 맞춰 지속적인 업데이트가 필요하다. 서비스 개선이나 문제점이 게임의 레벨처럼 하나 깨면 다음이 나오면 좋겠지만 보통 우리가 해결해야 할 문제는 한두 가지가 아니다. 또한 ‘당장 눈에 보이는 이 문제부터 해결하자!’라고 바로 결론이 나기도 힘들다. 한정된 인력과 시간, 그리고 비용 사이에서 어떤 것이 가장 긴급한지 판단하는 것이 필요하다. 이러한 우선순위 선정을 위한 방법 네 가지를 정리해보았다.

1. Value vs Effort

: 해결해야 할 과제나 업무들의 특성을 성과와 노력이라는 투자 대비 효과로 평가하는 기법이다.

성과노력 대비표_페이오프 메트릭스_pay off/effort Metrix

Grand Slam 적은 노력 / 높은 성과

낮은 노력임에도 높은 성과를 낸다는 것은 대단히 효율적인 아이디어. 지속적인 유지와 관리를 해나가면 됨.

Extra Innings 많은 노력 / 높은 성과  

성과가 높은데 비해 많은 시간과 노력이 필요한 영역으로 장기적인 전략과 실행 계획이 필요.

 

Stolen Base 적은 노력 / 낮은 성과

낮은 노력에 낮은 성과라면 지속 여부를 고민해 볼 영역. 어쩌면 중요하지 않을 수도 있으니 다시 한번 점검 필요.

Strikeout 많은 노력 / 낮은 성과

피나는 노력을 했음에도 낮은 성과를 보인다면 과감한 결단이 필요.

[진행방법]

1) 의사결정을 위한 목록들을 포스트잇에 작성.

2) 가로 두 칸, 세로 두 칸의 사분면 격자를 그리고 가로축에는 노력, 세로축에는 성과를 기재.

3) 포스트잇 별 아이디어들이 목적을 달성하는 데 높은 성과를 낼 것인지, 낮은 성과를 낼 것인지를 참여자들에게 확인.

4) 또한 해당 아이디어를 실행하는데 필요한 노력(시간, 비용, 난이도 등)이 많이 들 것인지, 적게 들 것인지 확인하며 배치.

5) 참여자의 반응을 종합하여 사분면 중 한 영역에 대안을 배치.

6) 제시된 모든 대안의 배치가 끝나면 만루홈런과 연장전 영역의 대안을 중심으로 우선순위를 확정.

7) 두 영역의 대안이 너무 많아 숫자를 줄여 선택해야 하는 경우, 다른 평가 방법을 추가로 사용하여 결정에 참고.

2. MoSCoW (모스코우)

 작고 복잡하지 않은 프로덕트/서비스를 위한 가장 간단한 접근 방법이다. 애자일 프로덕트 관리법에서 중요한 것과 그렇지 않은 것을 구별하고 이해하기 위해 활용한다.

M - Must have

: 이 기능(features)을 빼고 제품 딜리버리/서비스 론칭을 생각할 수 없음. (법적, 보안 문제 또는 비즈니스 이유 등 여러 가지가 있음.) 만약 이 기능이 사용자들에게 약속되어 있거나 제품의 킬러 피쳐(killer feature)로 정의되었다면 이것이 제품/서비스의 생사여부를 결정한다고 생각해야 함. 어떤 것이 ‘머스트 해브’가 될 만한 자격이 있는지 알아내는 가장 쉬운 방법은 그것을 포함하지 않는 최악의 시나리오와 최선의 경우를 생각해보는 것. 만약 그것 없이는 프로덕트/서비스의 성공을 상상할 수 없다면, 그것은 ‘머스트 해브’.

S - Should have

: 높은 우선순위를 지니는 기능이지만, 그것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때.

C - Could have

: 많이 이야기하는 ‘나이스 투 해브(Nice to have)’에 해당. 충분한 자원이 있다면 ‘할 수 있었을’ 것들이지만, 성공을 위해 꼭 필요한 것은 아닐 때. * Could have와 Should have 사이가 헷갈리는 경우 - 각 요구 사항(requirements)이 사용자 경험에 어떤 영향을 미칠지 생각해 보고, 영향이 적을수록 우선순위를 낮추기.

W - Won’t have

: 다음 버전에 포함하도록 신중하게 검토하는 대상. ‘Won’t have’라고 말할 때 ‘이 요구 사항은 생각할 가치도 없어서 절대 포함되지 않을 것이다’를 의미하는 것이 아니라, ‘이번 버전에는 포함되지 않을 것이다’를 의미. 주로 시간, 비용, 인원 등 개발 자원의 부족 같은 이유 때문이며, 리더십, 사용자 등 이해 관계자가 이번 릴리즈(출시)에서 이 기능은 포함되지 않을 것이라는 사실에 동의하는 데 도움이 되며, 이는 PM/PO로서 기대치를 관리하는 데 도움이 됨.

[모스코우의 장점]

 깊은 이해나 복잡한 계산이 필요하지 않다. 팀 전체가 빠르고 쉽게 적응할 수 있는 우선순위 지정 기법이다. 리더십팀, 고객 간 상호 이해관계도 쉽게 끌어낼 수 있고, 투명하게 진행이 가능하다.

 필수 항목 범주를 제외하고 엄격한 시간제한이 없으므로 기능별로 적절한 시간 배분 가능하다. 덕분에 팀 리소스를 상황에 맞도록 유연하게 조정 가능하다.

[모스코우의 단점]

 구현의 범주에 일관성이 결여될 수 있음. 우선순위가 쉽게 설정될 수 있지만 작업의 시퀀스가 없으므로 전체적 시스템적인 릴리즈 계획을 세우기 힘들다. 요구 사항과 기능을 중요도 순서로 정렬해 보여 준다고 해도, 전체 그림을 보기는 어렵다. 비즈니스에 중요한 큰 기능이 중요도에 따라 나누어져 있는 경우, 낮은 우선순위가 무시되거나 빠지면 전체 기능이 완성되지 않을 수도 있다. 이런 경우 경험 많은 PM/PO가 비즈니스 목표에 따라 우선순위를 그룹화해서 진행해야 한다.

 필요한 것과 멋진 것 사이에 불균형이 있다. 범주 간의 흐릿한 구분이 종종 필수 목록에 들어가는 기능을 결정하기 어렵게 만든다. 의존관계나 종속관계를 잘 구분해 우선순위 지정에 반영하는 것이 중요하다.

[모스코우, 언제 사용할까?]

 모스코우 방법은 간단하지만 항상 효과적인 것은 아니다. 릴리즈 시간에 민감한 프로젝트라면, 시간에 대해 포괄적인 우선순위 접근 방식을 사용해 모스코우를 보완한다. 앞서 말했듯이 기술적 제약과 의존성이 크지 않은 소형 제품으로 모스코우를 사용하는 것은 합리적이다.

3. RICE (라이스)

 RICE (Reach, Impact, Confidence and Effort의 약자) 방법은 우선순위를 지정할 때 각 기능을 평가하기 위한 입력값을 말한다.

Reach

: ‘도달 범위’, 특정 기간에 이 기능을 사용할 수 있는 사용자 수를 반영. 일별 활성 사용자(DAU-Daily Active Users) 또는 월별 활성 사용자(MAU-Monthly Active Users) 등의 실제 프로덕트 지표로 평가. 예를 들어 고객 지원 페이지의 개선 사항을 평가하면 월별 이 페이지를 방문하는 사용자 수가 당신의 리치 지표가 됨.

Impact

: 사용자들이 이 기능을 사용함으로써 어떤 영향을 받을지에 대한 척도. 임팩트를 측정하는 절대 과학적인 방법은 없으므로 상대적인 값을 사용. ‘매우 큰 임팩트’의 경우 3점, ‘높음’의 경우 2점, ‘중간’의 경우 1점, ‘낮음’의 경우 0.5점, 마지막으로 ‘최소’의 경우 0.25점을 사용.

Confidence

: ‘신뢰도’ 값. 현재의 상황에서 이 기능이 사용자에게 얼마만큼의 혜택을 주는지에 대한 추정 값. ‘고 신뢰도’ 100%, ‘중간 신뢰도’의 경우 80, ‘낮은 신뢰도’의 경우 50 등 객관식 척도를 사용하는 것이 좋음.

Effort

: 제품, 디자인 및 엔지니어링 팀이 소요한 시간. ‘인 월(person-month)’이나 ‘시간’ 등으로 계산.

공식: RICE = (Reach*Impact*Confidence)/Effort

다른 입력치의 곱을 시간(노력 Effort)으로 나누는 것. 라이스 값이 클수록, 우선순위가 높다는 뜻.

[라이스의 장점]

 큰 그림을 볼 수 있다. 여러 요소를 포함할수록 제품의 비전, 성공적인 론칭, 추가 프로모션 등 다양한 관점을 보는 데 도움이 된다. 실제 제품 릴리즈 과정에서 나오는 의미 있는 숫자와 KPI를 기반으로 하기에, 실제로 매우 의미 있는 평가지표다. 사용자 경험을 매우 중요하게 생각하기에 사용자 만족도에 충분히 기여할 수 있다.

[라이스의 단점]

 모든 메트릭을 동일하게 고려하기 위해 등급을 매기고 각 백 로그 항목별로 계산을 수행하려면 많은 시간이 필요하다. 모든 데이터를 다 준비하지 못하는 경우, RICE 방법은 출시를 연기하게 만들 수도 있다.

 책임에 대해 명확하지 않다. 주어진 우선순위 결정 방법에는 영향과 신뢰도 같은 요소들이 포함되기 때문에, 팀은 결정에 대해 어떤 책임을 져야 하는지 명확하지 않은 경우가 많다. PM/PO의 책임의 한도인지, 팀 전체인지, 리더십이 담당해야 하는 부분인지 애매한 부분이 많이 생길 수 있다.

[라이스, 언제 사용할까?]

 여러 측면에서 제품을 종합적으로 살펴볼 수 있는 매우 효율적인 방법이다. 그러나 모든 우선순위 사례에 적용되는 것은 아니다. 예를 들어 라이스를 이용한 우선순위 지정 방법은 프로덕트/서비스가 출시되고 라이프사이클을 시작할 때는 사용자에 대한 부분이 좀 더 명확하므로 합리적으로 보이지만, MVP를 만드는 경우에는 어울리지 않는 방법이다.

4. Affinity Diagram (어피니티 다이어그램)

 엄밀히 말하면 어피니티 다이어그램은 우선순위를 정하기 위한 방법론은 아니다. 그룹핑의 한 가지 방법으로 수집한 데이터를 효과적으로 정리할 수 있다. 이렇게 정리된 데이터는 우선순위를 판단하는 데 도움을 줄 수 있기 때문에 이 글에 포함시켰다.

 Affinity는 '친화도'라고도 불리며 UX에서 'Affinity를 수집한다'는 것은 '필드 리서치로부터 사용자 경험(UX)과의 연관성을 드러낼 수 있는 단위 데이터(Raw Data)를 수집한다'는 의미로 통용된다. 제품이나 서비스의 콘셉을 도출하는 전 과정은 사용자의 경험들이라는 조각으로부터 퍼즐을 맞추는 것과 비슷하다. 필드 리서치를 통해 빙산 밑에 있는 얼음들로부터 숨겨진 가치들을 발굴하는 것이 중요하다. UX를 판단하고 가치를 정해야 콘셉의 도출이 가능하기 때문이다.

[어피니티 다이어그램의 6단계]

1. 리서치 결과로 나온 니즈 데이터들을 카드 형태로 메모 (포스트잇)

2. 의미론적 연관성, 상호의존성 원칙에 의거하여 비슷한 것끼리 그룹화 (메모들 사이의 패턴, 규칙 찾기)

3. 각 그룹을 대표할 수 있는 레이블, 제목 짓기. (어피니티 노트 중 하나가 헤더가 될 수도 있음)

4. 유사한 니즈를 묶어서 니즈 패턴 만들기.

5. 각 그룹들의 우선순위 매김. 이때, 우선순위는 목표에 따라 다르게 지정될 수 있음을 유의.

6. 단순히 정보를 식별하는 것에 집중하지 말고, 흩어져있을 때는 발견하지 못했던 인사이트 도출.

+ 아이디어나 참고사항을 중간중간 적어서 붙임.

 어피니티 다이어그램의 미덕은 문제가 복잡하면 복잡할수록 효과적으로 사용할 수 있다는 점과 여러 사람이 쉽게 정보를 식별하고 정리할 수 있다는 점이다. 앞서 말했듯이, 데이터를 객관적이고 시각화해서 볼 수 있기에 우선순위를 판단하는 데도 유용하다.

[어피니티 다이어그램 진행 시 중요한 고려사항]

1. 모든 권력은 유저에게서 나온다.

2. 유저의 말과 행동 속에 혁신 가치와 니즈가 숨어있다.

3. 새로운 조합의 그룹이 생겨날 때 혁신의 컨셉이 나온다.

4. 혁신의 컨셉이 곧 상품의 핵심 사용자 경험 요인이 된다.

5. 핵심 사용자 경험 요인 간에 갈등이 있으며, 이를 균형 있게 조화시키는 것이 UX 기획 전략의 본질이다.

6. 추상적인 사용자 경험 요인이 향후 디자인 과정을 통해 오감 인식이 가능하게 구체화된다.

7. 사용자 경험 요인이 사용자 중심 마케팅 전략의 키워드가 된다.

[어피니티 다이어그램 진행 시 '하지 말아야' 할 것]

- 문제점(Problem)만 뽑아내기

- 사전적, 기계적으로 분류하기

- 보이는 것만 정리하기

- 혼자 알아서 그룹핑하기 >> Bias가 생길 수 있다.

[어피니티 다이어그램 진행 시 '해야 할' 것]

- 유저가 진정 원하는 것(Needs)만 뽑아내기

- 어느 정도 직관에 의지하기

- 숨겨진 가치 발굴을 위해 수면 아래의 존재를 발굴하기

- 공감할 수 있는 결과를 위해 팀 토론을 통해 그룹핑하기