brunch

매거진 일잘러의 한 끗 차이

라이킷 12 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by kaily Apr 28. 2024

후회없는 프로젝트를 위한 5가지 문제 해결 방법

PM의 깊이 있는 고민이 없다면 우리 '모두'의 리소스가 낭비된다.

시간이 얼마나 빠른지, 벌써 1분기가 끝나고 2분기에 한 달도 지나갔다. 2분기 플래닝을 고민하면서 1분기에 진행했던 프로젝트를 하나하나 꺼내어 다시 한번 쭉 살펴보는데 아쉬움이 들었다.

'이 프로젝트할 때 배경을 좀 더 고민했으면 좋았을 텐데..'

'모니터링 지표로 A, B 등의 지표를 더 봤으면 좋은 인사이트를 얻을 수 있지 않았을까?'

'이 프로젝트 문서는 완성도가 좀 떨어지네..조금 더 신경써서 업데이트 해놓을걸..'

출처 : giphy

PM이라면 당연히 Cross-functional 한 업무 수행을 할 수 있어야 하는데, 기간 내 생각보다 많은 프로젝트를 리딩하게 되면 아쉬움이 남는 프로젝트가 생긴다. 이번 글에서는 '이러한 문제를 해결하기 위한 방법과 기획 시 PM이 꼭 집중해야하는 5가지'에 대해 이야기해보려고 한다.

위에서 말했듯 제품을 담당하다 보면 특정 기간 동안 하나의 프로젝트만 진행되지 않는다. 인력과 시간은 한정되어 있고, 해야 할 일은 산더미처럼 쌓여있다. 그래서 보통 복수개의 프로젝트를 같이 진행하곤 하는데 그러다 보면 모든 프로젝트를 완성도 있게 고민하지 못하고 '빠른 속도'에만 집중하여 진행하게 된다. 그러다 보니 지나고 나면 '더 잘할 수 있었는데..' 하는 아쉬움이 드는 프로젝트가 생긴다.

이 문제를 해결하기 위해선 아래 3가지 방법을 고민해 볼 수 있다.

1) 정해진 기간 동안 우선순위 높은 프로젝트를 순차적으로 진행한다.
2) 업무 외 시간 투자로 해야하는 업무를 정해진 기간 내 모두 처리한다.
3) PM이 꼭 고민해야 하는 것에 집중하고, 이 외 업무는 적절히 배분한다.

경험상 1번은 우선순위 높은 프로젝트를 순차적으로 진행하자고 협의하고 시작했다 해도, 진행하다 보면 각 부서에서 Sustain 업무 요청이 지속적으로 요청된다. 요청 건을 확인해 보면 중요도와 시급도 둘 다 급한 건이 분명 존재하므로 결국엔 특정 기간 동안 하나의 프로젝트만 하기는 힘들어진다.

"이거 진짜 급한데, 다음 주까지 처리해 주실 수 있으실까요?"

"계약상 이 부분 낼모레까지 처리해야 하는데 기획 검토 해주실 수 있으실까요?"

정해진 기간 동안 우선순위 높은 '프로젝트만' 순차적으로 진행하기는 매우 어렵다. 그래서 적절한 방법이 될 수 없다.

2번은 프로젝트를 병렬로 진행할 때 가장 쉽게 택할 수 있는 방법이다. 정해진 업무 시간 외 시간을 투자하여 짧은 기간 안에 프로젝트를 병렬로 진행한다. 명확하고 쉽고 빠르게 선택할 수 있는 선택지다. 그렇지만 본인의 여가시간을 모두 업무 하는데 쓰는 데는 한계가 있다. 몇 개월이야 할 수 있겠지만 지속 가능성이 떨어진다. 매번 여가시간을 끌어다 업무에 쓰다 보면 결국 지치게 된다. 따라서 짧게는 쓸 수 있는 방법이긴 하지만 장기적으로 길게 가져가기는 어려운 방법이다.

3번은 위 3개 방법 중 가장 합리적인 방법이다. PM이라면 모든 영역을 다 컨트롤해야 한다고 생각하기 쉬운데 이러다 보면 결국 본인 스스로가 Botteleneck 이 된다. 본인의 업무는 해도 해도 끝이 없고 산더미 같이 쌓여있는데, 같이 일하는 메이커들은 상대적으로 여유롭다. PM이 보틀넥(Bottleneck)이 되면 메이커들의 시간을 효율적으로 사용하고 관리할 수 없으므로 방법을 찾아야 한다. 이때 세 번째 방법을 사용하면 생각보다 일이 쉽게 풀린다.

우선 어떤 업무를 할 때 더뎌지고 시간을 많이 쓰는지 구체적으로 생각해 본다. 내 경우엔 기획 단계에서 PRD 작성 시 모든 케이스에 따른 정의와 세부 정책을 정의하는데 시간이 오래 걸렸다. 그래서 바로 다음 작업을 이어서 하는 UX 디자이너와 업무 범위를 재합의했다.

기획: PRD 내 배경, 목적, 목표, 기능정의를 모두 포함하되 대정책 위주로 작성한다.
디자인: 디자인 가이드 작업 시, 발생할 수 있는 케이스와 세부정책 위주로 작업한다.
-> 케이스별 정의와 세부 정책을 디자이너가 담당하게 됐다.

이렇게 업무 분담을 하니, 기획에서 사용하는 시간이 훨씬 줄어서 효율적으로 업무를 할 수 있었다. 또, 좋은 점은 기존에 세부정책까지 다 잡아줄 경우 UX에도 일부 관여하게 되어 디자이너의 생각을 제한하는 경우가 있었는데 대정책만 정해주니 디자이너가 생각할 수 있는 폭이 넓어져 디자이너도 만족스러워했다.

업무 범위가 협의 되어 고민할 수 있는 시간이 확보됐다면 기획 시 '꼭 고민해야 하는 것'에 철저히 집중해야 한다. 그래야 지나고 나서도 아쉬움 없는 '프로젝트'로 기억될 것이다.

고민해야 하는 부분은 아래와 같다.

1. 어떤 문제를 해결할 것인가?

데이터를 봤거나, 누군가 요청을 했거나, VoC를 보다가 여러 가지 문제를 발견했다면 어떤 문제의 우선순위가 높은지 고민해야 한다. 어떤 문제를 해결했을 때 고객의 만족도가 높을까? 어떤 문제를 해결했을 때 더 임팩트 있을 것인가? 를 고민하며 해결할 문제에 대해 깊이 고민한다. 다양한 데이터를 통해 '문제'의 근거를 찾고, 사이즈를 예측한다. 그렇게 해결해야 할 '문제를 뾰족하게 정의한다.'

2. 이게 왜 문제라고 생각했는가?

1번을 통해 어떤 문제를 해결할 것인지를 정의했다면 '이게 정말 문제인지?'를 이어서 고민해 본다.

아래 이미지는 홈 지면에 상품이 노출되는 '위젯(또는 컴포넌트라 불리는)'이다. 위젯에는 총 6개의 상품이 노출되는데 2개의 상품이 중복되어 노출되고 있다. 그래서 문제를 '위젯 내 중복 상품이 노출되고 있다.'라고 정의했다고 가정해 보자. 그럼 '중복 상품 노출이 왜 문제인가?'에 대한 고민이 이어져야 한다. 이게 문제인지 아닌지 판단을 위해 정량, 정성 데이터를 기반으로 고민해야 한다.

아래 예시를 보자.

1) 위젯에 중복상품이 노출될 땐 인당 상품 클릭수가 2개였고, 중복상품이 노출되지 않을 땐 인당 상품 클릭수가 3개였다. 즉, 보여주는 상품의 개수는 6개로 동일한데 중복 상품을 보여주니 클릭하는 상품의 수가 적어졌다.

2)인당 상품 클릭수가 적어지는 게 왜 문제인가?를 판단하기 위해선 추가 데이터를 확인해봐야 한다. 같은 위젯에서 인당 상품 클릭수가 적고 많음에 따라 어떤 영향을 미치는지 파악해 본다. 예를 들어, 인당 상품 클릭수에 따라 장바구니 담기 전환이나 구매전환 등을 비교해 볼 수 있다. 만약, 인당 상품 클릭수가 적을수록 구매나 장바구니 담기 전환이 낮아진다면 이것은 문제라고 정의할 수 있다.

위와 같은 흐름으로 왜 문제인지에 대해 고민해 보고, 이 과정에서 필요하다면 추가 데이터를 확인한다.

3. 문제를 해결하기 위해 어떤 액션을 할 것인가?

위와 같이 하나의 위젯에 중복 상품이 노출되는 게 문제라고 정의한 경우, 문제를 해결하기 위해 취할 수 있는 액션은 '위젯 내 중복 상품이 노출되지 않도록 처리' 하는 것이다. 이처럼 정의한 문제를 해결하기 위해서 어떤 액션을 취할지에 대해 정의해야 한다. 이 부분을 PRD에선 '기능 정의'라는 항목으로 기재해 둔다.

문제 해결을 위해 어떤 기능을 추가할 것인지, 로직을 어떻게 변경할 것인지, 어떤 부분을 수정할 것인지 등 문제 해결에 필요한 Action을 정의한다.

4. 문제를 해결했다고 어떻게 판단할 것인가?

간단하게는 2번 예시를 통해 '문제라고 정의했을 때 참고했던 데이터'를 문제해결 후 재확인해보면 된다.

문제 : 위젯 내 중복 상품이 나오는 것

해결 : 위젯 내 중복 상품이 나오지 않도록 처리

지표 : 개선 전/후 인당 상품 클릭 수 비교, 인당 상품 클릭수에 따른 전환율 비교

만약, 기능을 추가하거나 아예 새로운 형태로 개편하는 것이라면 문제 정의 시 살펴봤던 지표 외에도 어떤 지표를 봐야 정의한 문제를 해결할 수 있는지에 대해 고민하고 지표를 정의해두어야 한다.

'문제가 해결됐다'라고 말할 수 있는 지표를 정의해 두자.

5. 이 문제를 해결하면 비즈니스에 어떤 영향을 미칠지?

프로젝트 성공 지표까지 정의했다면 조금 더 거시적인 관점에서도 고민해 보자.

앞에서 정의한 중복 상품이 노출되는 문제를 해결하여 인당 상품 클릭수가 증가했다면, 전사적인 관점에서는 어떤 게 좋아지는가? 상품 클릭수가 증가할 경우 구매전환에도 영향을 미쳤다는 데이터를 확인했다면 전사 관점에서는 '전체의 구매전환율'이 얼마나 달라졌는지를 볼 수 있다.

즉, 문제 해결 시 구매전환율이 개선 전에 비해 1% p가 오른다면 전체의 구매전환율에 몇%의 영향을 미칠지를 고민해 본다. 이 부분을 확인하기 위해선 문제 정의 시 해당 위젯이 전체의 구매전환에 얼마나 영향을 미치고 있는지 데이터를 확인해 보면 된다. 그럼 개선 전에 비해 1% p가 오른 구매전환율이 전체 구매전환율에 얼마나 영향을 주는지 예측할 수 있다. 조금 더 큰 문제를 해결한다고 하면 시장에 주는 영향까지 확대해서 생각해 볼 수 있다. '이 문제를 해결하면 커머스 시장 점유율에 얼마나 영향을 줄 수 있는가?' 등의 고민을 해보며 답을 예상해 보자. 그럼 훨씬 더 정교한 문제정의, 목표 설정이 가능해질 수 있을 것이다.

마치며

벌써 2024년 2분기의 한 달이 지나가고 있다. 프로젝트 진행 시 매번 최선을 다해서 진행하는 것은 변함없지만 지나고 보면 매번 아쉬운 부분이 있는 것 같다. 그 당시에는 분명 최선이라 생각하고 기획했는데 다시 문서를 살펴보면 '이 부분을 조금 더 고민해 볼걸' 하는 생각이 든다. 아쉬운 부분을 최소화하기 위해선 '시간을 들여 최대한 깊이 있게 고민하고, 볼 수 있는 데이터는 다 보고 정의하는 것'이 중요하다

시간이 없다는 핑계로 일부 데이터만 보고 퀵하게 진행하며 프로젝트를 '쳐내듯이' 하는 것보다는 시간이 조금 걸릴지라도 '깊이 있게 고민하여 최선을 다하는 것'이 중요한 것 같다.

만약, 깊이 있게 고민할 시간이 적다면 팀 내 해결할 방법을 같이 논의하여 해결하고, 프로젝트를 진행할 땐 생각할 수 있는 한 깊게 고민하여 최선의 방법을 정의해 나가자. 처음엔 시간이 꽤 걸리겠지만 익숙해지면 우리의 뇌도 최적화되어 깊이 있는 고민을 빠른 시간 내 효율적으로 처리할 수 있을 것이라고 생각한다.

나도 2분기에는 조금 더 시간을 들이고 집중해서 1분기 보다 좋은 성과를 내야겠다고 다짐했다.

1분기에 진행한 프로젝트보다 아쉬움은 적고, 임팩트는 크게! 프로젝트를 리딩해나가야지.

keyword