문제를 발견하는 5가지 사례

효과적인 프로덕트 매니저의 팀이 빛나게 만드는 힘

효과적인 프로덕트 매니저가 가진 가장 과소평가된 능력 중 하나는 엔지니어와 디자이너가 최고의 결과물을 낼 수 있도록 돕고 끌어주는 힘입니다.

저는 커리어 초반에 흔한 함정에 빠졌습니다. 미팅에 들어가기 전에 이미 머릿속에 해결책을 정해두고 있었죠. - 와이어프레임, 사용자 흐름, 기능 구현방식 전부요.

결과는 어떠했을까요? 엔지니어와 디자이너들은 단순히 버튼만 누르는 사람 처엄 느꼈고 창의적으로 기여할 여지가 없다고 느꼈습니다. 예살할 수 있듯, 최종 결과물은 사용자에게 정말 필요한 경험과는 거리가 멀었습니다.

시간이 지나면서 저는 중요한 사실을 깨달았습니다.

가장 뛰어난 해결책은 정해진 솔루션이 아닌 강력한 문제에서 시작한다는 것입니다.

문제의 배경과 맥락을 명확히 설명하고 팀에게 열린 질문을 던지면, 정말 기발하고 깊이 있는 아이디어들이 나오기 시작하죠. 디자이너들은 제가 상상하지 못한 방식으로 사용자 흐름을 개선하고 엔지니어들 보다 효율적 접근을 제안했습니다.

그 순간 저는 스토리 텔링을 비장의 무기로 사용했습니다. 사람은 본능적으로 이야기에 끌리기에 문제를 이야기로 풀어내면 모두가 몰입하게 되고, 자연스럽게 더 나은 솔루션을 찾게 됩니다.

 

미완성 이야기 프레임워크

협업을 성공적으로 이끌려면 무대를 잘 세팅하는 것이 중요합니다.

저는 문제정의를 스토리처럼 만들어 공유합니다. 단, 해결책은 일부러 생략합니다. 왜냐면 솔루션은 함께 만드는 것이기 때문이죠.

이 프레임워크는 기능 기획 초기, PRD, 유저스토리, 심지어 작은 태스크 정의에도 활용할 수 있습니다. 신규 기능개발이든, 기존 기능 개선이든 유용하게 쓸 수 있죠.

5단계 스토리 구성

1) 도입

2) 배경과 이유

3) 문제 정의

4) 사례 및 흐름

5) 미완의 결말

 

1) 배경 및 맥락(도입)

정의

팀원들이 몰랐을 수 있는 배경 정보를 제공합니다. 

이야기의 주인공, 즉 기능을 사용할 최종 사용자를 소개합니다.

시장 변화, 사용자 행동 변화 등 비즈니스 맥락도 함께 전달합니다.

 

예시)

신용카드 고객은 수수료나 이자가 부과되는 것을 매우 꺼려하기 때문에, 미리 결제를 예약하고 철저하게 확인합니다. 

모바일 앱에서 결제를 예약하면, 시스템은 지정된 날짜에 결제를 처리합니다.

하지만, 은행 간 거래는 보통 1~3 영업일이 걸리기 때문에, 사용자들은 결제가 실제로 처리되었는지 헷갈려 하죠.

실제로 가장 많은 고객센터 문의가 "결제가 제대로 된 건가요?"입니다.

 

2) 문제의 중요성 & 비즈니스 영향

정의

사람은 문제의 크기를 알 때 동기부여가 됩니다.

해결하지 않으면 생기는 손해, 또는 해결하면 얻게 될 이득을 수치화 해서 보여줍니다.

 

예시)

이 문제는 고객센터 문의 중 가장 높은 비중(25%)을 차지합니다. 매달 약 2,000건이 이에 해당하죠.

고객센터 응대 부담이 커지면서 운영 비용이 증가하고 대기 시간도 길어집니다.

설문 결과, 신용카드를 다른 회사로 옮긴 고객의 20%가 앱 내 결제 확인의 불편함을 주로 원인으로 꼽았습니다.

3) 문제의 정점

정의

이야기의 클라이맥스입니다. 주인공이 겪는 가장 핵심적 갈등을 뚜렷하게 제시합니다.

문제를 구체화하고, 왜 이게 진짜 문제인지에 대한 인사이트를 줍니다.

 

예시)

사용자는 결제를 예약했지만, 그 결제가 실제로 처리됐는지 명확히 확인할 수 없습니다.

불확실한 상태에 불안함을 느끼고 결국 고객센터에 전화하게 됩니다.

 

4) 사용 사례 및 흐름 분석

정의

주인공이 어떤 경로를 거쳐 문제를 경험하는지 다양한 시나리오로 풀어냅니다.

이 과정에서 제품 흐름의 맥락과 다양한 유스케이스를 공유해, 실제 기능 설계에 도움이 되도록 합니다.

이 단계는 프로젝트과 진행됨에 따라 계속 업데이트됩니다.

 

예시)

P1 - 사용자가 결제일 하루 전에 전체 잔액을 결제함. 성공적으로 처리되고 수수료 없음

P1 - 결제 실패(잔고 부족, 잘못된 계좌). 수수료 및 이자 발생

P1 - 시스템 오류로 결제 실패 - 사용자는 수수료를 내지 않아야 함

P2 - 예약 결제를 다음날 취소함

P3 - 여러 예약 결제를 등록했는데, 총합이 잔액을 초과함

 

5) 미완의 결말

목적

여기서는 해피엔딩을 적지 않습니다.

왜냐하면 엔지니어와 디자이너가 함꼐 결말을 만들어야 하기 때문이죠.

각 유스케이스가 모두 고려되었는지 점검하면서, 자원 제한 속에서 우선순위를 결정하는 것도 팀의 몫입니다.

 

주의) 

문제를 정의하는 과정에서 무심코 해결책을 명시하지 않도록 주의해야합니다.

=> 사용자가 결제가 되었는지 모른다 -> 문제 메시지와 앱에 미래 결제 내역 화면을 추가하자.(X)

=> 사용자가 결제가 되었는지 모른다 -> 해결 방법은 함께 고민(O)

 

결론

스토리텔링 프레임워크를 활용하면 문제를 더 깊이 있게 정의하고 팀 전체의 창의성을 끌어낼 수 있습니다. 이 방식은 팀을 솔루션의 수동적 구현자가 아닌 능동적 공동창작자로 만듭니다.

사용자의 진짜 문제를 함께 고민하고, 더 나은 방향을 함꼐 찾아가는 팀은 결국 최고의 경험을 만들어냅니다.