기획자의 문제 해결 커뮤니케이션

프로덕트와 비즈니스 사이 차이와 갈등을 다루는 방법

기획자로 일하다 보면 유관 부서로부터 개발 요구사항을 전달받게 됩니다. 공감을 패시브 스킬로 장착하고 있는 저는 이야기를 듣다 보면 어느새 그들의 업무적 어려움과 필요에 대해 공감하게 되더라고요. 이러다가 기능 요구사항을 주렁주렁 매달고 다니는 건 순식간입니다.

하지만 우리에겐 한정된 시간과 리소스라는 넘기 어려운 거대한 벽이 있죠.

납득이 되는 요구사항을 어떻게든 빈자리에 요구사항을 욱여넣어 볼까요?

아니면 우리 로드맵 상 남는 리소스가 없으니 안된다고 돌려보내야 할까요?

사실 그 고민보다 선행되어야 하는 한 가지가 있습니다.

요구사항을 프로덕트 관점에서 소화해 봅시다.

요구사항... 너를 있는 그대로 받아줄 수는 없어

중요도와 긴급도의 초점 다시 맞추기

사실 사업부서 담당자 입장에서 모든 요구사항은 긴급하며 중요합니다. 이거 언제까지 개발돼야 하나요?라고 물어보면 ASAP이라고 하지 않을 사람이 있을까요. 빨리 해결하고 싶어 지는 탐스러운 요구사항, 지금 당장의 상황에서 한 걸음 물러서 초첨을 다시 맞추어 봅시다.

1) 비즈니스 목표에서 정말 중요한 사항이 맞으며, 프로덕트 핵심 가치를 저해하지 않는가

단기적인 실적 개선에 대한 조급함이나 VoC가 담당자의 마음을 다급하게 만듭니다. 기능 수정이 오히려 사용자의 불편을 초래하거나, 별로 중요한 기능이 아니거나, 비즈니스 목표와도 상관없을 수 있습니다.

사업부서 담당자 입장에서 업무 효율을 개선하고 싶어 하더라도, 요구사항을 수용하느라 드는 기획자, 디자이너, 개발자의 리소스>요청자가 반복 작업을 조금 더 하게 되는 시간비용인 경우를 종종 마주치게 되죠.

2) 프로덕트의 핵심 지표를 끌어올려 줄 수 있는 강력한 비즈니스 부스터인가

신규 회원 유입이나 리텐션을 높이기 위한 시스템 개발처럼 유입, 리텐션, 전환 등 프로덕트 지표에 긍정적인 효과를 줄 수 있는 부스터는 프로덕트의 관점에서도 중요도와 긴급도가 높다고 할 수 있겠네요.

방법과 범위를 재정의하기

요구사항은 요청자가 구체적인 액션까지 자기 사고의 틀 안에서 생각해 낸 것입니다. 프로덕트 전체적인 관점에서, 우리 서비스의 기술적인 환경을 고려하면 그 요구사항이 바로 딱 맞는 해결책이 아닐 수 있습니다.

1) 요구사항의 액션이 나오게 된 핵심으로 파고들어 봅니다. Why를 나의 관점에서 이해합니다.

2) 그 핵심의 "Why" 에서부터 방법과 범위를 다시 써봅니다.

이 과정에서 결론은 처음 요구사항과 달라질 수 있습니다. 다른 곳을 수정해야 하는 수도 있고요. 운영적으로 풀어나가거나, 이슈가 되는 부분을 단순 수정으로 땜질하고 다음 로드맵에 포함해 근본적인 문제를 해결할 수도 있습니다.

소화한 내용은 다시 비즈니스 관점으로 통역해 봅시다.

모두들 자신의 목표가 가장 우선입니다. 요구 사항이 조정되었을 때 내 팀의 실적이 나빠질 것에 대한 두려움, 내 업무의 중요도가 다른 데에 비해 낮아지는 것에 대한 두려움 - 이 두려움 때문에 갈등이 발생할 수 있습니다.

왜 그리고 어떻게를 설명하기

기획자, PM은 "왜"를 중심에 두고 소통해야 한다지만, 함께 일하는 사람들은 그렇다면 "어떻게" 자신의 문제를 풀어나갈지에 더욱 집중합니다. 그들에게 "왜"만 설명하는 것은 반쪽짜리 커뮤니케이션입니다.

중요도/긴급도/방법/범위를 다시 판단한 내용과 그 이유에 대해서 비즈니스 관점에서 설명합시다. 그리고 대안을 제시해 봅시다.

- 추후 확장성을 고려하면 제안주신 A 방법보다는 B방법으로 개발하는 게 장기적인 KPI 달성에도 도움이 될 것 같아요. (중요도/방법/범위)

- 반영 가능한 시점은 가장 빠른 시점은 N주 후인데, 이미 시의성이 떨어졌거나 문제가 해결됐을 가능성이 높아 보여요. 운영 프로세스 중 C 방법을 추가해 보거나, 웹사이트의 단순 문구변경으로 기본 안내 문구에 노출하는 게 즉각적으로 효과가 있을 것 같습니다. (긴급도/방법/범위)

- 우리 공동 목표의 달성을 위해 굉장히 중요한 제안이네요. 다만 지금 로드맵 운영에도 리소스가 벅차다 보니 태스크를 쪼개서 핵심적이고 긴급한 영역인 D부터 빠르게 반영하고, 내년 로드맵 계획 시에 E, F, G 도 포함해 전체 관점에서 활용도를 더 높일 수 있게 개발해 볼게요. (중요도/범위)

기획자의 커뮤니케이션은 통역과 비슷합니다. 통역사가 통역하는 쌍방의 언어와 문화를 모두 잘 알아야 하는 것처럼, 비즈니스와 프로덕트의 사고방식과 언어 사이를 오가며 소통해야 합니다.

처치곤란한 요구사항을 마음의 짐처럼 안지 말고, 미움받는 기획자가 되지도 말고, 차이와 갈등을 잘 다루는 연습을 작게 시작해 봅시다.