우선순위를 정하는 방법
주니어 PM의 스타트업 적응기 #5
PM이 회사에서 꽤 자주 듣는 말이 있다.
"00님 두 가지 이슈가 있는데 둘 중 우선순위가 어떻게 될까요?"
"지금 이 이슈가 더 빨리 끝날 것 같은데, 우선순위를 조금 바꿔도 괜찮을까요?"
개발자, 혹은 디자이너가 처음 나에게 우선순위를 물어봤을 때는 정말 혼란스러웠다.
분명히 다 같이 회의를 하고, 다 같이 결정한 내용인데 왜 하나같이 나한테만 물어보는지 이해가 되지 않았다.
게다가 내가 우선순위를 말해줄 수 있는 의사결정권이 있는지조차 알지 못했다.
처음에는 몰랐지만 하나의 프로덕트에서 우선순위를 결정하는 것은 PM의 업무 범위에 포함된다.
즉, 프로덕트에서 우선순위를 정렬하는 의사결정권은 오로지 PM에게 있다.
그렇기 때문에, PM, 개발자, 그리고 디자이너는 같은 회의에 참여하더라도 회의를 바라보는 관점에서 차이가 있다.
예를 들어, 카카오톡의 신규 기능으로 예약 메시지를 추가하는 회의가 있다고 가정해보자.
예약 메시지 기능을 구현하기 위해서는 아래와 같은 기능들이 구현되어야 한다. (단순 예시다.)
예약 메시지 설정
예약 메시지 취소
...
'예약 메시지'라는 최종 프로덕트 아래에 '설정', '취소' 등 큰 틀이 있을 것이고, 그 아래에는 무수히 많은 이슈들이 존재한다.
이 이슈들에 대해서 이야기할 때, 각 회의 참여자들은 서로 다른 생각을 하게 된다.
우선, 디자이너는 '예약 메시지' 기능과 관련된 여러 아이디어나 정책들을 듣고 검토하면서 최고의 UXUI가 무엇인지에 대해서 고민한다.
예를 들어, 예약 메시지 설정의 '시간 설정'에는 어떤 UXUI를 제공하면 좋을지 등을 고민하는 것이다.
개발자는 여러 아이디어들을 듣고 개발 리소스를 계속해서 고려하게 된다.
예약 메시지를 제대로 보내지 못했을 때, 유저에게 보여주는 에러 메시지를 케이스별로 나누어서 보여줘야 한다면 각 케이스를 어떻게 나눌 것인지에 대해 고민하고 구현하는 데 어느 정도 어려움이 들지 등에 대해 검토한다.
이들과 다르게, PM은 최종 목표인 '예약 메시지'라는 하나의 프로덕트를 기한 내에 최대한 높은 퀄리티로 만들어내기 위해 회의에서 나오는 아이디어들의 맥락을 정확하게 이해한 뒤, '꼭 필요한 기능'과 '중요하지만 당장은 없어도 괜찮은 기능', '있으면 좋은 기능' 그리고 '굳이 필요하지 않은 기능'을 머릿속으로 정리한다.
이와 같은 3가지 분류법 아래 아이디어들을 이해하고 정리한다면 개발자나 디자이너가 문의하는 질문에 유연하게 대답할 수 있다.
또한, 우선순위를 빠르게 정하고 개발자와 디자이너가 어디에 더 집중해야 프로덕트를 기한 내에 출시할 수 있는지 방향성을 제시해줄 수 있다.
그렇다면, '꼭 필요한 기능', '중요하지만 당장은 없어도 괜찮은 기능', '있으면 좋은 기능', 그리고 '굳이 필요하지 않은 기능'을 어떻게 구분할 수 있을까?
가장 중요하게 기준으로 삼아야 하는 것은 유저 경험 즉, 유저 스토리다.
앞서 예시로 들었던 카카오톡 예약 메시지 기능의 유저 스토리를 생각해보자.
'예약 메시지를 사용하는 유저들은 본인이 원하는 시간에 원하는 내용을 원하는 상대에게 보낼 수 있다.'
이렇게 간단한 유저 스토리를 기준으로 프로덕트의 우선순위를 정하면 된다.
회의에서 나온 아이디어가 아래와 같다고 생각해보자.
시간 설정 기능이 필요합니다.
예약 메시지를 설정한 뒤, 설정을 변경하는 기능이 필요합니다.
예약 메시지 전송에 실패했을 때, 유저에게 즉시 알리는 기능이 필요합니다.
예약 메시지 관련 통계 기능이 필요합니다.
유저 스토리를 기준으로 보았을 때, '꼭 필요한 기능'은 첫 번째 기능이다.
시간 설정을 하지 못한다면 '원하는 시간'에 메시지를 보낼 수 없기 때문이다.
즉, 프로덕트가 완성되려면 해당 기능은 무조건 구현되어야 하는 것이다.
다음으로 '중요하지만 당장은 없어도 괜찮은 기능'은 두 번째 기능이다.
한 번 설정한 예약 메시지를 변경할 수 없다면, '원하는 시간'에 '원하는 내용'을 '원하는 상대'에게 보낼 수 없을 수 있다.
그러나, 변경하지 못한다고 하더라도 예약 메시지 자체는 보낼 수 있기 때문에 당장은 없어도 괜찮은 기능으로 분류할 수 있다.
'있으면 좋은 기능'은 세 번째 기능이다.
물론 예약 메시지 전송을 실패했을 때, 유저가 즉시 그 사실을 알면 '원하는 시간'에 보낼 수 있다는 유저 스토리에 부합한다.
그러나, 유저가 전송에 실패한 사실을 나중에 인지하더라도 프로덕트 자체에 큰 영향이 있지 않다.
'굳이 필요하지 않은 기능'은 네 번째 기능이다.
통계 기능은 유저 스토리에 포함되지 않는 기능이기 때문에 굳이 필요하지 않은 기능으로 분류할 수 있다.
지금은 매우 간단한 예시를 들었고, 각 회사의 개발 환경이나 비즈니스 목적에 따라 우선순위의 기준이 조금씩 다를 수는 있다.
그러나, 보통 프로덕트를 만든다고 하면 위와 같은 기준에 따라 우선순위를 결정할 수 있다.
추가적으로, PM이 우선순위를 결정하여 업무를 배분할 때 명확한 기준을 제시할 수 있어야 하기 때문에 위와 같은 기준을 세우는 것이 필수적이다.
명확한 기준 없이 개발자나 디자이너에게 우선순위를 정해준다면 설득력도 없고, 공감을 얻지 못해 각 팀원의 업무 효율성이 떨어지는 문제까지 이어질 수 있다.
(일부 예민한 개발자들에게 왜?라는 질문 폭격을 받을 수 있으니 조심해야 한다.)
이제는 처음에 언급했던 질문과 비슷하지만 조금 더 구체적인 아래 질문에 어떻게 답변하면 좋을지 생각해보자.
개발자 질문
00님, 시간 설정 기능보다 통계 관련 기능을 만드는 데 시간이 더 적게 걸릴 것 같은데, 통계 기능부터 마무리하고 시간 설정 기능 개발 진행해도 괜찮을까요?
답변 A
아니요. 시간 설정 기능 먼저 진행해주세요.
답변 B
아니요. 시간 설정 기능이 '고객이 원하는 시간에 메시지를 보낼 수 있다'는 유저 스토리에 더 필수적인 기능이기 때문에 통계 기능보다는 시간 설정 기능 구현이 우선되어야 합니다. 통계 기능은 프로덕트가 출시된 뒤에 진행해도 무방할 것 같아요. 따라서, 시간 설정 기능 먼저 진행해주세요.
누가 봐도 답변 B가 더 설득력 있고, 정확한 프로덕트 비전을 제시하고 있다.
(더 일 잘하는 PM으로 보일 수 있는 답변이다.)
팀원들에게 프로덕트의 방향성과 비전을 상기시키고 공감하도록 유도하여 더 나은 퀄리티의 프로덕트 생산까지 이끄는 것이 PM의 주요 업무 영역이다.
따라서, PM은 우선순위를 유저 스토리라는 명확한 기준 아래 빠르게 정렬할 수 있어야 한다.
