왜 우리는 쓸데없는 기능을 만드는가?
처음부터 쓸데 없는 기능을 만들고 싶은 경우는 없다. 분명 요청사항대로 했는데 만들고보니 요청한 사람이 원하는 것이 아니라고 해서 당황한적이 있었는가? 그럼 왜 그런 경우가 생기는 걸까?
여기서는 비즈니스 기회를 찾기 위한 제품만들기 과정이 아닌 고객 혹은 협업팀의 ‘분명한’ 요청사항에서부터 출발하는 제품 만들기에 대해서 한정해서 이야기 하고자 한다.
1989년도 Total Quality Management 책에 최초로 등장한 [나무 그네 그림]고객으로 부터 받은 요청 사항에서 산출물에 이르기까지 다양한 팀을 거쳐 어떻게 말도 안되는 엉뚱한 제품이 나오게 되었는지를 보여주는 유명한 그림이다. 각각의 단계를 담당한 각 직군들의 특징들이 절묘한것이 이 그림이 오래도록 인용되는 이유일 것이다. (혹은 30년이 지나도 이 문제가 해결되지 않았기 때문일지도)
위의 그림에서 알 수 있는 이 상황의 원인은 “문제 정의를 제대로 하지 못했다.” 이고, 추가적으로 “제품을 만들어내는 다양한 팀들의 얼라인Align도 되지 않았다”라고 볼 수 있다. 즉, 문제 정의가 제대로 했다고 하더라도 다양한 팀들의 얼라인Align이 맞지 않았다면 결과는 상황은 동일 했을 수 있다. 그렇기 때문에 제대로 정의 된 문제에 대해 모두가 싱크Sync되어야 마침내 고객이 원하는 제품을 만들어낼 수 있다.
하지만 우선 이번 글에서는 우리가 쓸데 없는 기능을 만드는 이유를 “고객이 설명한 요건”인 첫번째 칸과 두번째 칸 사이에서 찾아보고자 한다.
가장 중요한 순간쓸데 없는 기능을 만드는 이유는 간단하다. 쓸데 없는 기능을 만드는지 몰랐기 때문이다. 처음부터 쓸데 없는 기능이라는 것을 알아차렸다면 결과는 바뀌었을 것이다. 하지만 슬프게도 우리가 필요 없는 기능을 만들었다는 사실은 만들고 나서야 알게 된다. 그렇다면 왜 처음부터 그 사실을 알기가 어려운 걸까?
고객이 와서 설명했다. “의자가 3개 달린 독특한 그네가 필요해요”
PM은 질문 대신 속으로 생각한다. ‘독특이라…’
고객이 돌아간 뒤로, PM은 기획서에 이렇게 적었다.
기존 시장에 없는 독특한 그네의 형태를 구성
- 양쪽 가지에 한줄씩 연결된 그네
- 벤치마칭 결과 위와 같은 그네는 시장에 없음
그리고, 다 적은 요구사항은 디자이너에게 건네졌다. 디자이너는 기획서에서 중요한 리스크를 발견했다.
“양쪽으로 그네를 연결하면서 독특함은 확보했지만, 이러면 그네가 앞뒤로 움직이기 어려운거 같아요.”
PM은 당황함을 숨기고 프로답게 대처 했다.
“그 부분은 디자인적으로 잘 해결 부탁드려요.”
그래서, 디자이너는 막힌 나무의 일부를 제거하여 그네가 충분히 움직일 수 있는 공간을 확보 했다.
두둥!사람들은 생각보다 본인들의 문제가 뭔지 모른다.
아이가 세명 있던 남자 고객은 와이프와 이야기 중 마당에 아이들과 놀 수 있도록 그네를 만들 필요가 있다고 생각했다. 비슷한 또래의 아이들은 그네를 무척 좋아했고, 같이 타기를 즐겨했다. 고객은 아이 3명이 동시에 놀 수 있는 튼튼한 그네가 필요했다.
남자는 마당의 그네를 생각하면서 이왕이면 조금 그네가 위트 있었으면 좋겠다고 생각했다.
“의자가 3개 달린 독특한 그네가 필요해요”
(이정도면 고객이 힌트를 많이 준 편이긴 하지만) 이건 “문제”가 아니라 “수단 혹은 해결방안”이다.
이때, 혹시 어떤 문제 때문에 의자 3개가 달린 독특한 그네가 필요한거냐고 묻는다면 답변이 아래 처럼 돌아올 확률도 높다.
“의자가 3개 달린 독특한 그네가 없는게 문제예요.”
실제로 회사에서도 비일비재하게 발생하는 일이다. 어떤 화면의 정보를 다운로드 할 수 있는 기능을 넣어달라는 요청이 왔다. 요청을 준 세일즈팀 직원에게 그 기능이 왜 필요하냐, 문제가 뭐냐고 물어봤더니, 황당한 표정과 함께 답이 돌아왔다.
다운로드 기능이 없는게 문제죠고객의 이야기를 듣는 PM은 고객이 말한 해결방안 자체를 문제라고 봤을 수도 있고(그네가 없는 것이 문제) 혹은 문제나 해결방안의 구분 없이 요청 사항을 그대로 받아드렸을 수도 있다. 이 지점이 우리가 쓸데 없는 기능을 만드는 가장 중요한 원인이다. 그네가 필요한 것 자체가 문제가 아니므로, PM은 그네가 필요한 이유 즉 고객이 진짜 해결하고 싶은 문제가 무엇인지 물어봤어야 했다.
“그네가 필요한 이유가 뭔가요?”
“의자가 왜 3개가 필요하신 건가요?”
“독특함이 필요하신 이유는요?”
잘못된 문제정의에서 제대로된 해결책이 나올 수 없다.
질문의 형태나 방법은 상황에 따라 바뀌어야 할테지만, 결국 PM는 “무엇이 문제인지” 알아야 한다. 질문이 있어야 답이 있는 것처럼, 문제가 있어야 답이 있다. 인생에 있어 질문이 중요한 것처럼 제품을 만들어가는데 있어서도 질문이 전부다. 즉, 문제 정의가 전부다.
문제
마당에 비슷한 또래의 아이들이 동시에 놀 수 있는 놀이기구가 없다.
해결 방안
비슷한 또래의 아이들이 동시에 놀 수 있는 안정감을 갖춘 + 마당에 설치 할만한 놀이기구
고객의 마당의 크기나 상황들을 고려해서, 놀이 기구 중 충족할만한 것이 “그네” 정도라고 한정한다면 PM은 문자 그대로의 “의자 3개” 라던가 “독특”이라는 표면적인 요청사항 안에서만 방안을 찾는 것이 아니라, 고객들의 입에서 그 단어들이 왜 나오게 되었을까에 집중해야 한다.
세일즈팀에서 요청한 필요한 다운로드 기능을 만들어서 배포했더니, 고객이 막상 사용하지 않았다. 왜 사용하지 않느냐고 세일즈팀을 통해 물어봤더니, 필요한 모든 데이터가 파일에 없다는 답변이 돌아왔다(파일에는 고객이 화면에서 볼 수 있는 모든 데이터가 그대로 담겨 있었다). 고객이 파일 다운로드 기능이 필요했던 이유는 고객이 추가로 필요한 데이터를 화면에서 볼 수 없어 파일을 다운로드 받은 다음 스스로 계산하고자 했기 때문이다. 하지만 막상 파일로 받으니 본인이 계산하기가 귀찮고 어려워 고객은 쓰지 않았다.
하....PM은 고객의 말로 표현하지 않는 원인에 대한 고민 없이 고객의 말을 그대로 받아들인 뒤, 의자 3개라는 힌트를 “독특”을 강조하는 수식어 정도로 마음대로 생각했다. PM이 그 당시 개인적으로 독특함으로 시장에서 두각을 타나낸 서비스들에 빠져있던 것도 한몫 했다.
문제 정의를 건너뛰고(Why), 심지어 고객이 말한 해결방안이 정확히 무엇인지(What)까지 건너뛰고, PM은 잘못된 전제, 정확히는 어떠한 것도 정의되지 않은 전제 위에 어떻게 만들지(How)를 고민하기 시작했다.
그 결과 그 영향은 당연하게 디자이너에게도 이어진다. 잘못된 전제 위에 심지어 제대로 파악 조차 못한 고객의 요청 사항을 기반으로 PM이 자유롭게 상상해버린 불완전한 아이디어를 그대로 받아들였다. 불완전한 포인트에 대해서는 용케 찾아냈지만, 해결 방법은 실현 가능성Feasibility이 제로에 가까운 방법을 택했다. 문제 정의를 놓친 문제에 대해서도 디자이너도 자유롭지 못하다.
서로가 같은 생각을 한다고 착각한다.
최소한, 고객이 말한 것 자체가 그대로 만들어지지 못했다는 지점도 문제다. 평범하고 일반적인 단어를 사용할 때 아이러니하게도 오해의 여지는 커진다. 의식도 못한 사이에 공통의 맥락이라고 여겨버리고 차이점에 대해서 질문할 기회조차 없이 넘어 간다.
모두 똑같은 생각을 하고 있을거라 확신할 수 있을까요?예를 들어, 독특하다라는 뭉특하고 추상적인 정의를 해석하는 방법은 사람마다 다를 것이다. 정의 레벨에서야 비슷하게 생각할 수 있겠지만, 특정 대상에 대해 “독특”을 대입한다면 그 결과는 상상하는 사람들 수 만큼의 다른 결과가 나올 것이다.
그렇다면 그네를 그대로 가지고 돌아간 남자는 행복했을까?
위의 프로젝트 진행 상황과 달리 고객이 실제로 바랬던 그네를 가지게 되었다고 상상해보자.
드디어 집 마당에는 그가 설명하진 못했지만 꼭 바랬던 그네가 설치 되었다. 하지만 만족한 남편과 달리 아내의 표정은 밝지 않았다.
과연 남편은 처음 나눴던 아내와의 대화를 통해 과연 문제 정의를 잘 한 것일까? 어쩌면 아내는 그네를 바란 것이 아니라, 남편이 아이들과 마당에서 자주 놀아주길 바랬는지도 모른다. 그녀에게 그네는 하나의 예시였을 뿐이었다. 결국 그 예로 말했던 결과가 마당 뒤편에 검고 커다랗고 못생긴 타이어 그네가(남편은 독특해서 마음에 쏙 든) 설치된 상황이 기가 막혔다. 아내의 말대로 한 남편은 억울하고, 아내는 제대로 맥락을 짚지 못한 남편이 답답했다. 결국 부부는 크게 싸우고, 남편은 다시 PM을 찾아와서 말했다.
“결국 이놈의 그네가 우리 부부관계를 망쳤어!”
만족하며 떠난 고객의 분노와 난데 없는 부부싸움이라는 단어에 PM은 당황하는 것 밖에 할 수 없었다.
어디서부터 잘못된걸까실제 이런 상황은 흔하게 일어난다. 이 상황은 PM이 해결하고자 하는 문제 정의 과정에서 중요한 이해관계자를 파악하는 것을 놓쳤을 수도 있다. 그렇다면, 문제 정의만 제대로 한다면 이 문제는 해결 될 수 있다.
최악의 상황
하지만 가끔은 문제 정의를 잘하고, 해결방안을 잘 찾았다 하더라도 조직 내의 정치적 이슈로 잘못 해석 되기도 한다.
세일즈팀에서 가불기를 시전했습니다.역량이 부족한 세일즈팀이 있다고 가정해보자! 부족한 역량에 집중하기 보다 세일즈팀은 조금 더 쉬운 정치적 해결 방법을 찾을 수 있다. 세일즈를 못하는 이유를 제품에 필요한 기능이 없음과 제대로된게 없음이라는 프레임을 만들어 세일즈팀에서 해야할 책임까지 제품팀 탓을 하는 상황이라고 볼 수 있다.
이런 상황을 극복하려면 제품을 잘 만들기 위한 고민보다는 제품팀 탓을 할만한 구실을 줄이기 위하는 것에 시간을 쓸 수 밖에 없게 되고, 이 의미는 제품팀이 제품을 위한 고민을 할 시간이 줄어들게 된다는 의미이다.
분명, 고객의 소리를 들었고 이해관계자들과 충분하게 소통을 했음에도 결과적으로 고객이 사용하지 않거나 이해관계자팀들로부터 원하는 것이 그게 아니었다! 라는 소리를 들어 억울한 경험이 있었다면 문제 정의를 제대로 했는지를 고민해보자. 문제 정의만 제대로 된다면 해결 방안은 찾는 것은 상대적으로 쉽다.
만약, 위에 언급한 최악의 상황에 빠져있다면 흠… 행운을 빈다.
