진짜 해결해야 할 문제가 맞나요?
갑자기 진짜 문제 찾아야 해서 급해진 주니어 기획자
회의는 우리만의 전쟁터입사한 지 한 달이 돼 가던 어느 날, 운영 중인 앱을 개선하자는 의견이 나왔다. "화면의 UI가 이쁘지 않은 것 같아요.", "꼭 필요한 가이드일까요?", 개인적으로 이 기능은 꼭 필요해요." 등 다양한 이유가 있었고, 그렇게 시작한 우리만의 아이데이션이 시작되었다. 그리곤 단숨에 와이어프레임까지 만들어져 팀장님에게 리뷰를 하게 되었다.
리뷰가 거의 끝날 대쯤 팀장님은 한마디를 던졌는데 우리는 그대로 말문이 막힐 수밖에 없었다.
"진짜 해결해야 할 문제가 맞나요?"|
ㄴ ???: 개인적으로 해결해야 할 것 같은데요?(Feat. Agile)
근 몇 년 동안 IT 스타트업의 트렌드가 되어버린 Agile 한 업무는 빠른 변화와 급작스러운 이슈에 유연한 대응이 가능한 효율적인 방법론으로 자리 잡았습니다. 하지만 문제를 추론할 수 있는 데이터, 실무자의 관점, 고객 경험 중 어느 한 곳으로 편향된 사고를 갖고 있다면 이 방법론은 '우리 멋대로 빨리'라는 우물 안 애자일에 불과하게 될 것입니다.
그래서 이번 글에서는 소수의 실무자로 이루어진 팀이 문제를 찾는 과정에서 자칫 놓치거나 간과할 수 있는 부분들, 그리고 가져야 할 마인드를 공유해보려고 합니다.
옮길 내용들은 모두 얼마 전 겪은 저의 경험을 토대로 써 내려간 것들로, 모든 분들에게 정답으로 비칠 수 없기 때문에 '이런 기획자도 있구나~'라는 가벼운 마음으로 읽어주세요:)
우리는 전문가예요.
우리는 고객이기 전에 실무자다.우리는 문제를 발견하고 해결하기 위해 회의를 진행합니다. 하지만, 참여자는 대부분 1. 해당 분야를 많이 경험했고, 잘 아는 고인물이며, 2. 어떤 문제에도 당황하지 않고 해결책을 예상할 수 있는 실무자로 이루어져 있습니다. 따라서 실제 고객이 부딪치는 문제가 실무자 입장에서는 그리 심각한 문제가 아닐 수 있기 때문에 실무자 관점에서의 일방적인 판단은 최대한 내려놓고 회의를 해야 합니다(물론 전부 다 내려놓는 것은 어려울 수 있고, 오히려 특정 상황에서는 실무자 관점의 사고는 도움을 주기도 합니다). 또한 실무자는 문제를 발견했을 때 생각보다 빨리 해결책을 제시할 수 있는데, 이 과정에서 우리는 편향된 하나의 해결책으로 끝까지 가는 것보다 다양한 해결책을 제시하고 검증을 통해 걸러낼 수 있어야 합니다.
발로 뛰어 찾아야 해요.
지극히 실무자 관점의 문제 찾기를 내려놓았다면, 고객의 상황을 직접적으로나 간접적으로나 경험해봐야 합니다. 사실 직접적인 경험은 보통 고객이 되어 서비스를 사용해보면 되는 거지만, 앞서 말했듯 실무자 관점을 0의 수준으로 놓기는 힘들어 전적으로 신뢰할 수 있는 방법은 아닙니다(때문에 저는 경험할 때 마치 서비스를 처음 사용한다는 마음으로 임합니다).
그렇다면 간접적인 경험은 어떤 걸 의미할까요? 네, 제목대로 발로 뛰어 고객의 문제를 찾아 나서는 겁니다.
SNS / 커뮤니티 / 포털 우리는 어떤 환경에서도 [검색] 기능으로 우리 서비스를 이용하는 고객을 찾아 나설 수 있습니다(이 방법은 어느 정도 상용화가 된 서비스에 국한됩니다).
글을 쓰는 지금도 서비스 관련 해시태그를 검색하면 보이는 고객의 서비스 후기가 작성된 피드에, 스토어에 올라온 앱 리뷰에, 오픈채팅방에 올라오는 고객들의 소통에, 카페 등 커뮤니티에서 오가는 수많은 글에서도 고객들은 자신이 부딪친 문제를 공유하는 중입니다. 간혹 어떤 고객은 문제에 대한 해결책을 제시하기도 할 정도로 우리가 해결해야 할 진짜 문제들이 떠다니고 있습니다. 책상 앞에서 머리를 맞대고 무한한 상상의 나래를 펼치는 것보다 직접 움직인다면 더 정확하게 고객의 진짜 문제를 찾을 수 있을 거예요.
데이터를 활용하세요.
데이터에 대한 정보는 이미 차고 넘친다.데이터 분석부터 가설의 수립, 그리고 검증까지 이미 널리 알려진 데이터의 무궁무진한 활용성과 중요성은 사실 제 경험보다 시중에 공유되고 있는 많은 글이 더 유익합니다. 그럼에도 불구하고 내용에 넣은 이유는, 근거로 쓰기엔 다소 부족한 양이거나 분석 환경이 마련되지 않은 곳이 있는데 이럴 경우 데이터 분석을 적극 활용하자는 취지에서 입니다. 데이터는 우리가 발로 뛰며 수집한 고객의 모든 정보를 아우를 수 있는 도구이며 이를 수치화해놓은 증거이기 때문에 고민 끝에 정의한 진짜 문제를 이해관계자들로부터 공감을 얻을 수 있는 주요한 수단이 될 수 있습니다. 저는 다행히도(?) 이전 직장, 현 직장 모두 데이터 활용에 어색한 곳이었어서 이제 막 시작하는 단계고, 지금은 진짜 문제를 찾는 것부터 해결하기까지 많은 경험을 하며 배우고 있습니다.
추측하지 마세요.
앞에서 말한 1~3번을 잘 활용한다면, 추측성 말투를 사용하더라도 신뢰가 생길 수 있겠죠. 하지만 저는 어떤 의견을 낼 때 추측성 말투는 최대한 안 하는 편입니다. 다만, 의견을 낼 때 내 의견에 뒷받침이 되어 줄 근거를 많이 찾아봅니다. 불현듯 툭 던진 의견이 좋은 결과물을 가져오기도 하지만 이런 경우는 드물뿐더러, 제 의견에 제가 자신이 없는 건 책임감이 부족하다고 보거든요. 안 그래도 어떤 문제가 진짜인지 찾아야 하는데, 추측이 난무한 문제들 사이에서 헤매지 않기 위해선 의견 내기 전 조금의 근거라도 내세우는 게 좋습니다.
.
.
.
위의 네 가지 내용을 요약하여 '진짜 문제를 찾는데 필요한 것은 무엇인가?'에 대한 답을 한다면 아래와 같습니다.
실무자의 관점을 최대한 내려놓고 발로 직접 뛰어 고객과의 교감을 통해 문제를 정의하고, 데이터로 정의한 문제의 타당성을 뒷받침해야 한다.
즉, 실무자의 관점, 고객의 경험, 데이터 이들 중 어느 하나에 꽂혀 편향된 과정을 거치는 것보다, 두루두루 활용하여 진짜 문제를 찾기까지 충분한 시너지를 내는 게 보다 긍정적인 결과를 가져올 겁니다.
다음 [기획문서정복하기] 예고
이렇게 고생하며 나온 우리의 문제가 정의되면 우리는 문제를 해결하기 위해 필요한 리소스를 마련해야 합니다. 기간, 인력, 기술 등을 확정하기 위해선 이해관계자들과 소통을 해야 하고, 이때 문제를 정의하기까지 쌓인 많은 정보들을 문서에 정리하여 보여주는 게 좋습니다. 그러면 그들은 쉽게 이해할 것이며 우리에게 적극적으로 협조할 테니까요. 이 문서를 저는 PRD(Product Requirement Documents)라 부르기로 했습니다.
