‘좋은 문제’ 정의하는 꿀팁 🍯

사례로 살펴보는 나쁜 문제 정의 vs 좋은 문제 정의

Lewin.Parker

Published in

DelightRoom

7 min readApr 7, 2024

생각을 위한 생각중.gif

문제 정의가 중요하다는데..

제품을 공부하다 보면 문제 정의가 가장 중요하다는 얘기를 자주 듣곤 합니다. 그럴 때마다 ‘아 그럼 맞지, 문제 정의 중요하지’하고 끄덕이곤 했지만 막상 ‘좋은 문제 정의가 그래서 뭔데’라고 물어보면 정확하게 뭐라고 말하기 쉽지 않았죠.🥲

이 어려움은 딜라이트룸에 합류한 후에도 계속 되었습니다. 3개월의 프로베이션 기간 동안에도 문제 정의만 제대로 잘 배우면 전환에 통과하지 못해도 얻어가는 거라고 생각하며 대표 제이와 다른 PO분들을 괴롭혔습니다.

1년이 지난 지금도 좋은 문제 정의를 하는 것은 여전히 어렵습니다. 하지만 최소한 좋은 문제 정의와 나쁜 문제를 구분할 수 있는 역량은 얻을 수 있었습니다. 결론적으로 좋은 문제 정의는 누가 봐도 ‘간단 명료’합니다.

이제부터 어떻게 이런 결론을 내릴 수 있었는지, 몸으로 맞으며 배운 레슨을 소개해보려합니다. 좋은 문제 정의를 위한 팁도 있으니 놓치지 마시길! 👏

간단, 명료하지 않았던 사례와 해결 방안

딜라이트룸에서는 기획서를 WWH(what/why/how) 형태로 작성하고 있습니다. 현상 속 핵심 문제가 무엇인지 정의하고 문제의 크기가 얼마나 큰지 살펴본 후, 그 문제를 해결하기 위한 솔루션을 작성하는 형태로 구성하고 있죠.

가장 중요한 건 가장 처음에 ‘문제’를 정의하는 것입니다. 기획이란 결국 유저의 어려움을 초래하는 본질적인 문제를 찾아서 해결해주는 것이기 때문입니다. 따라서 기획서의 ‘Problem’이라고 정의된 란에 한 줄로 문제를 명확히 정의하는 것에 굉장히 많은 노력을 기울입니다.

슬프게도 아니 부끄럽게도 저는 이 과정에서 항상 난관에 부딪혔습니다. 정말 노력해서 문제 정의를 했지만 잘 이해하지 못했죠. 그래서 한 때는 좌절을 하기도 하였습니다. 하지만 다른 딜라이터 분들께서 처음에는 모두 어렵다며 위로와 함께 조언을 주신 덕에 나아질 수 있었습니다.

이때 가장 많이 받은 피드백은 문제를 너무 추상적으로 정의한다는 것이었습니다. 감을 잡는 데도 고치는 데도 가장 시간이 오래 걸렸죠. 그래서 오늘은 이런 사례를 소개해드리고 수정해가며 팁을 드려보도록 하겠습니다.

사례 1 : 추상적인 단어

해당 문제 정의를 보면 대략적인 의미는 이해가 되지만, 명확하지 않다는 느낌을 받을 수 있습니다. 일단 “정신적인 건 뭐고 육체적인 건 무엇인지”에 대한 부분이 추상적입니다. 예를 들어 양팔을 드는 건 육체적으로 깼다고 말할 수 있을까요? 잠시 앉았다가 다시 자면 몸은 움직인거니까 육체적인 건 깼다고 말할 수 있을까요?

또한 “일어날 때”라는 표현도 마찬가지로 구체적이지 않고 추성적입니다. 예를 들어 엄마가 “8시야 회사 가야지”하고 깨울 수 있고 배고픈 고양이가 얼굴 위로 올라가서 일어날 수 도 있습니다. 어떤 느낌인지 대략 감이 오실 겁니다.

사실 정의한 문제가 설득이 잘 안될 것이라는 건 정의하는 과정에서 이미 스스로 느낄 수 있습니다. 그렇기에 문제를 부연 설명하는 배경에 이론, 논문 등을 덧붙이며 논리의 설득을 높이기 위해 시간을 더 보내곤 합니다.

하지만 그 시간에 문장을 더 다듬는게 더 빠른 길이란 걸 잊지 말아야 합니다. 위의 문제를 다듬어 보겠습니다. 먼저 애매 모호한 단어들을 바꿔보겠습니다.

‘일어났을 때’ → ‘알람이 울렸을 때’, ‘정신적인/육체적인’ → ‘눈은 떴지만 밍기적 거리느라 침대에서 나오지 않아서’ 이렇게 몇가지 단어들만 바꿨음에도 좀 더 명료해진 걸 느낄 수 있습니다. 우리 모두는 눈은 떴는데 밍기적대며 침대에서 나오지 않은 경험을 해본 적이 있습니다.

배경 또한 필요 없거나 문제를 읽었을 때 바로 떠오르는 궁금증을 간단하게 써주면 됩니다. 이처럼 좋은 문제 정의를 하면 공감이 잘 되기에 설득의 비용을 줄일 수 있습니다. 다음 두 번째 사례를 살펴보시죠!

사례 2 : 추상적인 표현

이번 문제 정의는 추상적인 표현과 긴 문장 때문에 명료하지 않게 느껴집니다. ‘측정 중인 걸 느낄 수 없어서’라는 표현에서 구체적으로 무엇을 느낄 수 없는지 설명하고 있지 않고 있고, 굳이 필요하지 않은 문장이 뒤에 더 있어서 한 호흡에 읽히는 걸 방해하고 있습니다. 이 문제 정의 또한 다시 정리해보겠습니다.

‘화면에서 느낄 수 없어서’ → ‘분석 화면에 변화가 없어서’로 이해하기 쉽게 바꾸고 ‘그래서 분석이 되고 있는 지 부분에 대한 신뢰가 떨어진다.’는 필요 없는 문장을 과감하게 삭제하니 좀 더 명료해진 걸 느낄 수 있습니다. ‘덜어낸 것이 더한 것이다’는 말처럼 문제 정의에서도 본질을 제외하고 덜어내는 것이 중요하다는 걸 알 수 있습니다.

또한 문제 정의를 했을 때 문장이 너무 길거나 여러 문장으로 작성된다면 다음 2가지를 의심해봐야 합니다. 먼저 대다수가 공감하기 어려운 문제이거나 (임팩트가 낮음) 다음으로 충분히 고민이 안된 문제 정의일 확률이 높습니다.

좋은 문제 정의하는 꿀팁

이제 좋은 문제 정의를 위한 🍯 팁을 드리려 합니다.

먼저 좋은 문제 정의는 스윽 읽어도 이해하기 쉽습니다. 한 두 문장으로 잘 정리가 안된다면 문제가 제대로 정의되지 않았을 확률이 높죠. 그렇기에 문제 정의를 할 때는 추상적인 단어가 아닌 ‘쉽고 익숙한 단어’를 사용해야 하고 ‘필요하지 않은 수식어구’는 최대한 덜어내야 합니다. 즉, 간단 명료해야 하죠.

저 또한 이 단계에서 수많은 실패를 맛봤습니다. 말이 쉽지 결코 쉽게 되지 않았죠. 그래서 항상 문제 정의할 때마다 써먹는 대표 제이에게 배운 꿀팁 하나를 소개해 보겠습니다. 바로 남에게 1~2줄로 문제를 설명하고 이해 및 공감하는 지 살펴보는 것입니다.

혼자 문제를 정의하다보면 너무 잘하려고 힘이 들어가게 되고 너무 구체적이거나 반대로 너무 간소화 되어서 이해하기 어려운 상황이 발생합니다. 문제 정의 직후에는 ‘드디어 잘 정리했다!’고 생각해도 다음날 다시 보면 ‘이게 뭔말이지’하며 자책하곤 하죠.

이럴 때 남에게 한 두문장으로 설명한다고 생각하고 다듬다 보면 어느 순간 스스로 문제 정의를 잘했다 안했다는 감이 찾아오게 됩니다. 그리고 최종적으로 실제로 남에게 설명하고 상대방의 반응을 확인하는 과정을 통해 우리는 좋은 문제 정의를 했는 지를 확인할 수 있습니다. 이건 해보시면 바로 알 수 있다고 확신 또 확신합니다.