문제 정의 안못하기
정의가 잘 된 문제의 공통점은?
*생각 정리용으로 쓰는 글입니다.
문제는 뭐고 문제 정의는 어떻게 하는 걸까?
최근 몇 년간 PO, PM 채용 공고를 보면 '문제 정의'라는 키워드가 공통적으로 보이는 것 같다.
- 문제 해결을 위해 정의한 비전, 전략 및 미션부터 비즈니스 임팩트까지 연결되는 과정이 논리적이고 합리적인 분이 필요해요.
- 고객의 입장에서 문제를 정의하고, 해결해 본 경험이 있으면 좋아요.
(출처: 토스 채용공고)
이처럼 '문제 정의'는 PO, PM의 핵심 역량으로 강조되고 있다.
실제로 잘못된 문제 정의 때문에 엄청난 금전적 손해를 보거나 - 경쟁사에게 추월을 허용하는 등 정확한 문제 정의의 중요성은 날이 갈수록 높아지고 있다.
그렇다면 문제 정의란 무엇일까?
고객의 문제를 파악하고, 가설을 세운 뒤, 해결책을 만드는 과정일까?
그럼 문제란 무엇을 의미하는 걸까?
"이 기능이 없어서 불편해요" 같은 요구사항일까, 아니면 "버튼이 클릭이 안 돼요" 같은 버그일까?
영어로는 '문제'라는 단어를 Problem, Needs, Question, Bug 등으로 다양하게 표현하지만, 문제 정의를 가장 잘 설명하는 단어가 무엇인지는 아직도 확신이 서지 않는다. (사실 정답이 있을지도 의문이다.)
그렇지만 경험상 잘 된 문제 정의에는 몇 가지 공통점이 있는 것 같다.
문제를 정의한다
문제에 대한 해결책과 가설을 세운다
정의한 문제에 맞는 해결책을 만들어 배포한다
이후 배포가 완료되면 사용자에게 찾아가서 “이렇게 만들었습니다! 한 번 써보시겠어요?”라고 권하거나, 데이터를 보면서 사용자는 만족했는지, 비즈니스 임팩트가 어떤지를 판단한다.
이 과정이 끝나고 사용자가 만족했을 때, 좋은 지표들이 마구 찍힐 때 비로소 "문제 정의가 잘 되었구나"라는 생각을 한다.
문제 정의를 잘하기 위한 팁
1. 기능 요청 자체를 문제로 받아들이지 말기
B2B SaaS의 경우, 고객이나 이해관계자로부터 직접적인 기능 요청이 들어올 때가 많다. 예를 들어 "이 기능이 없어서 불편해요"와 같은 요구가 있을 때, 이를 곧바로 문제로 받아들이기보다는 *"왜 이 기능이 필요할까?"*라고 스스로 물어보는 것이 중요하다. 이 배경에는 더 큰 불편함이나 숨겨진 요구가 있을 수 있기 때문이다. 문제 정의는 표면적인 요청을 넘어서 그 이면에 있는 진짜 문제를 파악하는 과정이다.
만약 내가 사람들에게 무엇을 원하느냐고 물어봤다면 그들은 더 빠른 말(faster horse)이라고 답했을 것이다. - 헨리 포드
PM으로 일하며 굉장히 공감하는 말이다. 내가 지금 조금 더 빠른 말을 만들고 있는 건 아닐까? 자동차를 만들 순 없을까? 저 사람이 지금 진짜 필요한 건 무엇일까?
광고 대시보드를 다루는 상황을 상상해 보자.
클라이언트 마케터: 상품 성과를 볼 수 있는 대시보드가 필요해요.
PM: 네, 만들어드리겠습니다. 이러이러한 지표들을 막대 차트 형태로 노출시키고, 개발 기간은 3주 걸리겠네요.
개발자: 이걸 꼭 해야 하나요? 지금 다른 우선순위 높은 작업들 하고 있는데...
3주 후: 만들어놨는데 사용하지 않음
요구사항을 명확하게 요청하지 않은 고객의 잘못일까?
만약 같은 상황에서 문제 정의를 잘하는 PM이었다면 다음과 같은 접근을 했을 것이다.
PM: 성과를 볼 수 있는 대시보드 말씀이시군요, 그 대시보드가 필요하다고 느낀 순간은 언제였나요?
클라이언트 마케터: 실적 압박이 있어서 상품을 추가로 광고하려고 하는데, 어떤 상품들이 지표가 좋은지 확인할 수가 없어서요...
PM: (지표가 좋은 상품을 찾고 싶구나! 그런데 지금은 개발 리소스가 부족하고, 클라이언트 쇼핑몰의 상품은 100개 안팍이니, 대충 요런 쿼리로 지표순으로 뽑아드리면 되겠다.)지표가 좋은/좋지 않은 상품들 리스트입니다! C 상품은 구매율이 매우 높은데, 노출이 잘 안 되고 있네요
클라이언트 마케터: (A 지면이 비어있으니까, C 상품을 추가로 광고하면 되겠구나!) 감사합니다~
위 사례에서 PM은 고객이 진짜로 원하는 것을 파악하고, 추가 개발 없이 쿼리 몇 줄만으로 문제를 해결했다. 왜 이 기능이 필요하다고 말했는지를 계속 생각하고, 적절한 대안을 제안하는 것이 좋은 PM이라고 생각한다. 꼭 기획서를 작성하고, 제품으로 개발되어야만 문제를 해결할 수 있는 것은 아니다.
2. 버그를 문제로 착각하지 않기
“버튼이 클릭이 안 돼요”같은 기술적 결함은 그 자체로 문제처럼 보이지만(물론 버그는 당연히 해결해야 할 문제가 맞음), 이 역시 ‘증상’에 불과할 수 있다. 이 경우 문제는 “사용자가 주요 기능에 접근하지 못하는 상황”일 수 있다. 버그를 해결하는 것이 최종 목적이라기보다는 버그로 인해 사용자가 겪는 불편함이나 업무 차질이 문제의 핵심일 때가 많다.
3. 측정 가능한 문제 정의하기
항상 사용자 인터뷰를 통해 문제를 찾을 수 있다면 좋겠지만, 사용자가 적은 서비스거나 특정 산업군이라면 인터뷰를 할 수 없을 때가 있다. 이럴 땐 PM이 내부적인 분석을 통해 문제를 찾아낼 수 있어야 한다. 이 때, 문제를 '측정 가능하도록' 정의하는 것이 중요하다. “사용자가 불편해하는 것 같아요”라는 식의 모호한 정의보다는 “사용자가 이 기능을 사용하지 않아 전환율이 X% 감소하고 있다”는 식의 정량적 접근이 필요하다. 측정이 가능하면 문제 해결의 성공 여부도 명확하게 판단할 수 있다.
4. 문제의 영향 범위를 명확히 하기
문제의 범위를 좁히는 것도 중요하다. 예를 들어, 고객의 요구가 전체 사용자에게 영향을 미치는지 아니면 특정 그룹에만 한정되는지 파악해야 한다. 문제의 영향을 좁히면 더 명확하고, 효율적인 해결책을 마련할 수 있다.
5. 문제에 대한 가설 검증을 통해 정의 보완하기
처음 정의한 문제가 반드시 완벽할 필요는 없다. 초기 정의 이후 해결책에 대한 가설을 검증하며 문제를 수정하고 보완할 수도 있다. 사용자 인터뷰나 피드백을 통해 "정의한 문제의 방향이 맞는지"를 계속 확인하며 문제 정의를 발전시키는 과정이 필요하다.
이와 같이, 표면적인 요구와 증상에 얽매이지 않고 문제의 근본을 파악하고 논리적이며 측정 가능한 정의를 통해 접근하는 것이 PO와 PM의 필수 역량이다. 이렇게 정의된 문제는 자연스럽게 해결책으로 이어지고, 그 과정에서 우리는 "문제 정의가 잘 되었구나"라는 결과를 얻게 된다.
(잘 정의한 문제를 어떻게 잘 풀까? 에 대한 것도 PO, PM마다 다른데, 이건 다른 글을 쓰게 된다면 더 적어보도록 하겠다.)
진짜 문제를 찾고, 올바른 방향으로 나아가는 것 – 그것이 문제 정의의 핵심이자 성공적인 PM의 첫걸음이다. 파이팅~!
