올바르게 문제를 정의하기
나의 문제정의 돌아보기
불명확한 문제정의는 실패로 이어진다.
사이드 프로젝트를 진행하며 팀원들과 함께 '빠르게 출시하고 빠르게 고쳐보자'라는 컨셉으로 단 2개월 만에 서비스를 런칭했습니다. 문제 정의에 시간을 많이 할애하기보다는, 데이터 기반의 빠른 개선을 통해 효율적으로 제품을 발전시킬 수 있을 것이라 생각했습니다. 그래서 속도를 우선시하며, 개선을 위한 데이터 수집에 초점을 맞춰 프로젝트를 진행했습니다.
그러나 서비스 출시 이후 잠재 고객을 타겟으로 한 메타 광고에서 심각하게 낮은 CTR과 높은 이탈률이라는 결과를 직면했습니다. 데이터 분석 및 추가적인 사용자 테스트를 통해 발견한 문제는, 랜딩 페이지에서 사용자가 서비스의 가치를 명확히 인지하지 못하고 있다는 것이었습니다. 그래서 우리는 랜딩 페이지를 개선하기로 결정했습니다.
하지만 진짜 문제는 여기에서 시작되었습니다. 서비스가 해결하고자하는 근본적인 문제해결에 대한 정의가 명확하지 않았기 때문에, 사용자에게 전달할 가치 또한 정의할 수 없었습니다. '사용자가 우리 서비스를 이용하면서 얻을 수 있는 것이 무엇인가?'라는 질문에 스스로 대답할 수 없었습니다. 이 과정을 통해 '불명확한 문제정의는 불명확한 솔루션으로 이어져, 어떤 사용자에게도 기능할 수 없다.'는것을 깨달았습니다.
문제 정의에도 올바른 형태가 있다.
우리 팀은 방향을 전환하기로 했습니다. 단순히 문제를 '느끼는 것'을 넘어, 문제를 명확하게 '정의하는 것'이 필요하다고 판단했습니다. 첫번째 단계는 우리 팀이 실제로 경험했던 불편함을 바탕으로 문제를 탐구하는 것이었습니다. 문제 탐색 중 팀의 PM과 공통적으로 느꼈던 문제인 '피드백'을 첫번째 주제로 선택했습니다. 해당 주제를 바탕으로 팀원들의 경험과 데스크 리서치를 통해 팀 내에서 올바른 형태의 피드백을 주고받는 것이 어렵다는 문제를 정의했습니다. 하지만 팀원들과의 논의 끝에 해당 문제 정의는 올바르지 않다는것을 깨달았습니다.
1. 추상적인 워딩
'올바른 형태의 피드백'이라는 표현은 문제를 정의하는데 적절하지 못합니다. '무엇이 올바른 피드백인가'에 대해 명확히 정의되지 않았기 때문입니다. 피드백의 내용, 전달방식, 타이밍 등의 여러 요소 중 어떤 부분에 문제가 있는지 불분명했습니다.
2. 문제 원인과 결과의 부재
문제 정의에서 피드백을 주고받기 어려운 이유가 무엇인지 구체적으로 드러나지 않았습니다. 팀의 문화, 커뮤니케이션 방식, 피드백 스킬의 부족 등 다양한 요인 중 어떤 것이 진짜 문제인지가 정의되지 않았습니다.
또한, 해당 문제가 팀의 성과, 팀원과의 관계, 업무 프로세스에 미치는 영향도 명시하고 있지 않습니다.
3. 불명확한 대상
해당 문제가 어떤 팀과 어떤 상황에 대해 발생하는지 명시되어 있지 않습니다. 특히 팀의 규모나 피드백의 공식/비공식적 맥락이 문제해결에 중요함에도 해당 부분이 배제되어 있어 '누구의' 문제를 해결할 지 알 수 없습니다.
4. 측정이 불가능함
"어렵다" 라는 문제정의는 추상적이기 때문에 문제의 심각성을 측정하기가 어렵습니다. 해당 문제로 인해 발생하는 불편함이 정의되지 않았기 때문에 솔루션 실행 후 실제로 해결되었는지 확인할 수 없습니다.
해당 문제들로 인해 기존의 문제 정의는 올바르지 않았음을 깨달았고, 후속 질문을 통해서 올바른 형태의 문제정의를 하기로 했습니다.
1. 올바른 형태의 피드백이란 무엇인가?
2. 현재 피드백 과정에서 발생하는 주요 문제는 무엇인가?
3. 피드백에서 문제가 나타나는 상황과 맥락은 무엇인가?
4. 이 문제가 팀에 미치는 부정적인 영향은 무엇인가?
5. 기존 문제 해결을 위해 사용한 방법은 무엇인가?
우리는 위 질문들에 답하기 위해 설문 조사와 인터뷰를 진행하며 문제를 보다 구조적으로 정의해 나가기로 했습니다. 이 과정에서 가장 중요한 것은 문제의 근본 원인과 영향을 명확히 이해하고 구체적인 수치와 워딩으로 구조화시키는 것입니다.
