왜 길고 복잡한 것에 이끌리는가
단순하고 간결한 길을 선택하지 않는 이유에 대해서
1. 제품팀 PM의 업무 중 하나는 주변 유관 부서의 협업 요청사항에 대해 기민하게 대응하는 일이다.
누구는 슬랙으로 또 누구는 구두로 전달한 내용을 "요청사항을 제품팀에 공유했다"라고 말하곤 한다.
이를 방치했다가는 추후 수많은 업무 홍수 속에서 일하는 제품팀을 만들 수도 있다. 각별한 주의가 필요하다.
2. 그래서 일정한 형태로 요구사항 문서를 전달할 수 있도록 템플릿을 만들었다. Problem - Solution - Benefit - Appendix로 끝나는 매우 간결하고 단순한 형태의 템플릿이다. (아마존의 6 Pager에서 영감을 얻었다)
3. 이런 템플릿을 활용하면, 요구사항 분석시 전체를 읽을 필요도 없다. Problem만 읽고 지금 해야 할 일인지, 아닌지 판단한다. '문제상황'이 잘못된 경우 뒤에 이어지는 '해결방법'이나 '기대효과' 역시 100% 잘못된 내용이기 때문이다. 왜 이 문제가 중요하고 긴급한지 설득할 수 있어야 제품팀과의 협업이 가능하다.
4. 작은 스타트업이기 때문에 커머스팀도 마케팅팀도 HR팀도 제품팀의 자원을 필요로 한다. 그런 이유로 6개월 간 100건의 요구사항 문서를 받게 되는데, 텍스트가 길고 내용이 복잡한 문서들이 꽤 눈에 보인다. 읽다 보면 작성자의 노력은 느껴지지만 도대체 무엇이 문제인지 갈피를 잡기 어렵다. 높은 확률로 길고 복잡하게 쓴 요청사항 문서는 제품팀과의 협업으로 이어지지 않는다.
5. [불변의 진리]를 쓴 모건하우절은 이렇게 말한다.
"단순함은 무지함으로 착각하기 쉬운 반면, 복잡함은 상황을 잘 통제하고 있다는 느낌을 준다"
6. 복잡한 데이터를 달고, 많은 요인과 선택지를 함께 제공하면 상황을 적극적으로 통제함고 있다는 느낌을 준다. 반면 상황을 단순화시키는 것은 그 외 요인에 대해서는 무지한 사람처럼 보일 수 있다.
모든 질문에 " 아 그건 이렇고 이렇습니다" 대답할 수 있는 것이 스마트해 보인다.
(그렇게 보이는 것과 별개로, 그 모든 것을 아는 것이 과연 문제 해결에 도움이 되는가?)
7. 하지만 대부분 분야에서 거의 모든 문제는 소수의 요인과 변수가 결과를 크게 좌우한다. 오히려 많은 요인을 통제하려는 시도는 문제의 본질을 흩트리고 해결책으로 가는 길을 베베 꼬아둔다.
제품팀을 설득하는 가장 중요한 한 문장은 "고객은 0000 상황에서 ----- 한 문제를 겪어 고통받고 있습니다"가 전부다.
그 한 문장에 초점을 고정하고 글을 전개해 나가면 저절로 협업하고 싶은 마음이 동한다.
반대로 고객의 문제가 중심이 아닌, 부서 내 이해관계나 매출, 경쟁사와의 기능 비교에서 시작되는 글은 복잡하고 뭔가 더 중요한 일인 듯 보이지만 사실, 우리 서비스를 이용하는 진짜 고객의 당면한 문제보다 중요한 적은 단 한 번도 없었다.
8. 단순한 것은 복잡한 것보다 명료하다. 짧은 것은 긴 것보다 처음과 끝이 단번에 보인다. 단순하고 짧은 글을 복잡하고 길게 쓰는 사람을 '일을 잘한다'라고 느낀 적이 없다. 오히려 그 반대일 것이다.
9. 부서 간 한 다리만 건너가도 서로가 쌓는 지식과 정보의 결이 매우 다르다. 제품팀이 마케팅팀만큼 CTA , LTV, ROAS 등 지표를 설명하는 것은 불가능하다. 그 반대로 마케팅팀이 제품팀의 개발방법론이나 테스트방식을 설명하는 것은 불가능하다. 서로 경험하는 지식이 다를 때일수록 복잡하고 긴 과점을 단순하게 만드는 것이 협업을 촉진한다.
10. "제가 잘 몰라서 질문드리는 것인데요.." 타 부서에서 이런 멘트와 함께 질문이 왔다면, 질문자의 무지함을 탓할 것이 아니라, 협업 과정에서 불필요하게 복잡한 내용은 없었는지 스스로를 점검해야 하는 이유다.
조직에서 우리는 늘 의견이 충돌할 수밖에 없다. 심리적 불편함이 없을 때 건강한 충돌이 가능하고, 비로소 협업으로 이어진다.
