까일 수 밖에 없는 기획안 VS 까이지 않는 기획안
서비스기획자 뿐만 아니라 누구에게도 해당되는 것에 대하여
내가 꿈꿔왔던 이상향의 서비스기획자의 모습이 있다.
쿠팡의 프로덕트오너이신 김성한님. 또 서비스기획자의 입문서로 유명하신 도그냥 이미준님. 서비스기획자라면 모를수 없는 데이먼님까지.
나는 그들의 책을 읽고, 블로그에 기록까지 해가면서 서비스기획자로서 그리는 최종 목적지인 PO의 모습에 대해 열심히 공부하고 있다. 그러나 실전은 실전이다. 책에서 본 것들은 이론일 뿐, 책임감이 부여되지 않는 학생의 모습으로는 결코 회사원의 모습을 감히 상상하기도 어렵다.
왜 상상하기도 어려울까?
첫째, 내가 바라는 회사에서의 나의 모습이 자꾸 미화된다. 예를 들어, 마치 내가 김성한, 이미준, 데이먼님이 된 것만 같다. 하지만 그 실상은 오히려 처참하다. 냉정하고, 혹독하다.
마치 내가 출시한 프러덕트에 대한 시장의 반응*처럼.
*시장의 반응: 회사의 경영진의 반응
여기서 말하는 경영진이 시장의 입장을 무조건 대변할 수도 없는 노릇이다. 하지만 그들은 쉽게 그 자리에 올라선 것도 아니고, 고작 입사 3개월차인 나보다 서비스에 대한 이해도 깊다. 3개월 밖에 되지 않았다고 하더라도, 회사는 냉정하게 나를 판단할 수 밖에 없다.
나는 그들이 가진만큼의 시장에 대한 지식이 없고
고로 "시장을 이해하고 있지 못하다"고 있다는 것이다.
그들(회사 경영진)을 설득할 수 없다면, 서비스를 이용할 고객들도 설득 할 수 없다고 생각된다.
그 날 오전
내가 준비하고 있는 서비스 리뉴얼을 위해 개발 검토가 필요했다. 그래서 AOS 개발을 담당하고 있는 사원 및 대리들과 함께 미팅을 가졌다.
리뉴얼의 목적과 목적에 맞는 기능 제공을 위해 어떠한 개발이 필요한지 프로토타입을 보여주었다.
기능의 존재에 대한 의문을 가지면 타당한 답변을 제시했다. 이에 개발이 가능하다는 확인을 받았다.
그러나, 그 날 오후
팀장 이상급 미팅시, 대부분의 화면에 대한 기능이 기각되었다. 장장 두시간 동안 이어진 회의에서 내가 열심히 기획한 화면의 기능이 기각 되어 망연자실해서 10분을 멍하니 있었다. 하지만, 그들의 이유에는 타당한 이유가 있었고, 그것들에 대해 상기해 볼 필요가 있었다.
내가 그 회의에서 그렇게도 '까인 이유'는 무엇일까?
부제: 서비스에 대한 낮은 이해도와 타당성. 내가 회사에 바라는 방향을 제시했기 때문.
왜? 사원, 대리급 회의에서는 통과된 기획안이 팀장이상급 회의에서는 대차게 까였을까? 그것은 내가 대리급 정도로만 회사의 서비스를 이해하고 있다는 뜻일 것이다. 이제와서 돌이켜보면 오히려 팀장님 급 이상 회의에서 나의 기획안이 대차게 까인것에 대해 감사함을 느낀다.
이전 같았으면, 또 대부분이 생각하는 바는 이와 같을 것이다. 이런 기능이 다른 서비스에도 당연히 있기 때문에 우리 서비스에 있어야 하는거 아니야? 이러니까 이런식으로 악평이 달리지. 이런 서비스를 사람들은 도대체 왜 사용하는거야? 이걸 쓰고 있는 사용자들이 이해가 되지 않을 지경이다. 왜 서비스를 고도화 개발해 발전시킬 생각은 안하는거지? "도대체 뭘 기획하라는거야"라는 생각에 주저 앉았을지도 모르겠다.
하지만, 왜 그런 평가를 받았는지에 대해서 생각해본적이 있나?
생각을 달리하고, 시야를 넓게 가져보자.
생각
어느정도 나이가 들어서일까..
아니면 내 마인드가 달라져서일까..
아니면 이전 회사들이 나로 하여금 정말 불평불만만 하게 만들어서일까..
어쨋든간에 본론으로 돌아가서
까이는 기획안은 어떤 내용을 담고 있는지 몇가지 예시를 통해 알아보고자 한다.
까이는 기획안 예시
내가 그린 기획①: "우리 회사 서비스가 보유하고 있는 DB를 소비자에게 명확하게 보여주자"
임원진의 반박: 우리 회사 서비스(이하 A)의 핵심 DB 수준이 타기업보다 그 질이 떨어진다. 그 질 떨어지는 DB를 사용자에게 어필해서는 안된다. 우리 회사의 핵심가치는 DB를 고객에게 보여주는 것에 그치는 것이 아니다.
덧붙인 나의 생각과 꿀팁: 서비스가 전달하는 핵심 가치가 무엇인지에 대해 명확하게 포인트를 짚어야 한다. 강점을 어필하되, 약점을 어필하지 말자.
내가 그린 기획②: "이러한 정보를 제공하면, 서비스가 풍부해 보이고, 고객이 잘 사용 할 것이다!"
임원진의 반박: 사용자에게 해당 기능을 제공했을때, 정말 잘 사용할 것인가? 테스트 해보았는가? 배포 이후 단계를 보고 버리는 기능을 만들지 말고, 현재 단계에서 생각하는 힘이 필요하다. 고객이 그 기능을 사용함으로 어떤 것들을 얻어갈 수 있는가?
덧붙인 나의 생각과 꿀팁: 보여주기 식의 기능은 고객도 눈치를 채고 사용하지 않는다. 서비스 리소스를 낭비하는 행동은 하지 말자.
내가 그린 기획③: "검색기능은 분명 추후에 사용할 만한 가치가 있을 것이다"
임원진의 반박: 검색할 내용이 많지 않음에도 불구하고 검색이 필요한가? 차라리 가나다 순으로 나열해 개발 리소스를 줄이자.
내가 그린 기획④: "제 나름대로 정해본 '네이밍 결과물'입니다! 어떠세요?"
임원진의 반박: 별로다. 좀 더 참신하고, 고객이 정말 눌러봐야 할 것 같은 느낌을 제공하길 바란다.
덧붙인 나의 생각과 꿀팁: 기능에 대한 이름을 짓기는 정말 어렵다. 네이밍에 대한 아이디어가 없다면 혼자 생각하기보다 다른 사람의 의견도 수렴하자. 몇가지 후보를 지어두고 기획안 발표시 머리를 맞대는 방법도 있다(상급자가 마음에 드는 네이밍을 그 자리에서 결정할 수 있으므로 나의 시간을 아낄 수 있다)
내가 그린 기획⑤: "콘텐츠의 하단에 '좋아요'와 같은 호감을 표현할 수 있는 기능을 제공해, 해당 콘텐츠의 인기 척도를 알아보면 어떨까요?"
임원진의 반박: 하하하하하하. 빼라!!
덧붙인 나의 생각과 꿀팁: 임원진이 이런 반응을 보인다면, 서비스에 대한 이해도가 확실히 낮은게 아닌가 잘 생각해보자. 내가 운영해야할 서비스가 시장의 반응을 수용해야하는지 아닌지에 대한 이해가 필요하다. 또한 수용하는 깊이가 어느정도인지도 이해를 해야한다. 내가 맡고 있는 서비스는 ⭐️콘텐츠 제공자와 수용자간의 교류가 없어도 무방⭐️하다. 오히려 콘텐츠를 교류없이 일방적으로 제공해야한다. 사용자의 호응도를 수집하는게 서비스의 성격에 정말 맞는지 다시 한번 생각해보자. 이런 기능이 아니더라도 체류시간과 같은 로그데이터를 활용해서 추후 서비스를 개선해 나가는데 도움이 될 수 있다.
내가 그린 기획⑥: 사람들이 우리 서비스를 얼마나 애용하고 있는지 확인하고, 평가를 받아 타인에게도 긍정적인 평가를 받을 수 있어야 한다.
인원진의 반박: 우리 서비스는 공개적인 평가 필요 없다. 빼라!
덧붙인 나의 생각과 꿀팁: 서비스의 불리한 것을 앞장서서 보여줄 이유가 없다. 회사 서비스가 어디를 향해 초점을 맞추고 있는지. 또 어디에 돈을 쏟고 있는지. 그 돈의 가치가 어떻게 수익으로 돌아오는지 관찰하라. 그리고 질문하라.
내가 그린 기획⑦: 사용성과 기능을 사용함으로 얻을 수 있는 성취감을 높이기 위해 어떤 기능을 사용했을 때, 게임적인 요소(메달)을 획득하는 식의 UX를 기획했다.
임원진의 반박: 이런 게임적인 요소가 정보전달에 초점을 두고 있는 우리 서비스에 과연 적합한지생각해봐야할 문제이다. 하지만 사용성에 초점을 둔다면 문제가 없다. 그래서 게임적인 느낌을 조금 더 배제한 사용성 증가에 대한 부분으로 입각하여 기능을 개발하는 것으로 결정되었다.
덧붙인 나의 생각과 꿀팁: 공격(?)을 받으면 그 자리에서 대답하기 어려운 경우가 많다. 내가 기획한 것들이 어떠한 이유로 기획되었는지, 미리 준비해가야 내가 의도한 기획을 경영진에 전달 할 수 있다. 목적과 기대효과를 어떤 문서를 작성하든간에 염두해둘것
중요해서 다시 한 번 더 작성한다.
어떤 문서를 작성하든간에 목적과 기대효과를 쓰고 문서를 작성하기 시작하자.
까이지 않는 기획안 예시
부제: 회사가 나에게 바라는 방향.
그 날 회의에서 모든 제안이 까인 것은 아니다. 어떻게 까이지 않았는지 살펴보자.
내가 그린 기획⑧: 유저가 페이지 사용함에 집중할 수 있게 만들어야 하는데, 이 때 페이지를 분리하거나 합칠 필요도 있다. AS-IS 페이지의 한 기능의 화면에서 3가지의 세부 기능메뉴가 있었는데, 그것들의 내용이 꽤나 긴 편임에도 불구하고 하단으로 내려보는 뷰를 유지하고 있었다. 이를 3개의 새로운 페이지로 분리하여 사용성을 높였다. 이 외에도 한 페이지에서 여러기능을 확인하거나 상호작용으로 엮여있던 기능을 두개의 페이지로 구분하여 사용성을 증가시켰다.
내가 내린 결론: 유저 입장에서 고려한 사용성은 객관적으로 봤을때, 수용가능해야한다.
내가 그린 기획⑨: AS-IS 화면에서 제공하는 화면 영역이 비교적 넓은 면적을 차지하고 있어, 일부 소비자에게 부정적인 영향을 끼쳤다. 따라서 기존 대비 50% 영역을 사용한 화면을 제공해 간결하고 정확한 정보를 제공할 것이다. 그러나 이 후의 화면에서는 소비자가 화면을 거슬려해 하기보다는 강력한 메세지를 전달하는데 초점을 맞추어야 하기 때문에 넓은 영역을 사용해 명확한 기능 전달을 해야한다.
내가 내린 결론: 유저 입장에서 유저가 어떤 사고의 흐름으로 서비스를 이용할 것인지에 대한 다양한 케이스를 생각해보고, 그것에 대한 스토리가 있을 때 그 기획물이 호응을 받는다.
내가 그린 기획⑩: 명칭 변경 / 기존에는 만약 2개 정도의 문제가 발견이 되었을때, 개인정보유출(2)라는 표기로 서비스를 제공하고 있었다. 그러나 이것이 정확하게 어떤 것을 전달하고자하는지에 대한 뚜렷한 목적을 가진 단어가 아니었기 때문에 (개인정보유출 2번째인지 개인정보유출 2개인지 명확하게 파악하기가 어렵다고 보여졌다) (2)라는 표기를 명확하개 '2개 발견'이라는 명칭으로 변경했다.
내가 그린 기획⑪: 소비자에게 명확한 선택지 제공하기 / 기존에는 전화번호를 입력하는 란이 전화번호부를 열람할 수 있는 버튼이 한 줄이 있었고, 전화번호를 입력할 수 있다는 안내가 없었기 때문에, 소비자가 전화번호부에 등록되어있는 전화번호만 사용할 수 있는 듯한 느낌을 전달했다. 이에 구성을 달리하였는데, 전화번호부 버튼을 선택하거나 직접입력할 수 있는 란을 명확하게 구분하여 굳이 전화번호부에 저장되지 않은 전화번호라도 기능적으로 활용할 수 있게 구성했다.
내가 그린 기획⑫: ON/OFF 토글 기능 사용시 설정 저장 안내 / 기존에 없던 기능이다. 그래서 추가 기획안을 제시했다. 유저가 기능을 ON/OFF 할 때마다 '설정이 저장되었습니다'라는 토스트 팝업을 띄어 설정을 저장하지 않더라도, 그 화면을 벗어나면 그 설정을 유지하는 것으로 구성했다.
내가 그린 기획⑬: 탈퇴하기 메뉴 / 기존에 존재하지 않았던 탈퇴하기 메뉴에서 사용자가 탈퇴를 다시 한번 고려할 수 있는 장치를 두었다. 개중에 토스를 가장 많이 참고 했는데, 왜 탈퇴를 하는지에 대한 정보도 함께 수집할 예정이다. 또한 이런 기능을 써보았냐는 버튼을 두어 서비스가 주로 제공하는 기능에 대해서 다시한 번 설명할 수 있는 장치가 마련되어있다.
보다시피 서비스의 핵심 기능을 변경하기 보다 주로 UI 기획이 통과되었다. 사실 애초에 회사에서 나에게 이 기획서를 의뢰했을때, 기존에 제공하는 UI가 허접?한 부분이 있어 개선을 요청했다. 내가 애써 부딪혀 보려던 부분들은 회사에서 원하지 않았기 때문에 기각되었다고도 볼 수 있다.
다시 생각해보면, 이 작업물의 목적과 기대효과는 'UI개선으로 사용성 증대'가 더 적합하겠다. 하지만 나는 이 문서를 작성할 때, '서비스 탈퇴율 감소' 였었다. 그래서 더 까일 수 밖에 없는 기획안이었을지도..
또한 서비스의 특수한 환경 때문에 기술적으로 부상할 수 있는 단계는 아니기도 하다.
정리해서
까이는 기획안: 내가 회사에게 기대하는 목적을 제시한 기획안
까이지 않는 기획안: 회사가 나에게 기대하는 목적을 달성한 기획안
이라고 볼 수 있다.
잘하고 싶은 마음으로, 서비스의 가치가 폭발적으로 성장하기를 바라는 마음으로, 문서를 작성했다.
하지만 그것은 회사가 나에게 기대한 바가 아니었다.
사원, 대리급 회의에서 내 기획안이 까이지 않을 수 있었던 이유는
회사에 바라는 방향이 나와 일치했기 때문이라고도 볼 수 있겠다.
그러나 회사는 그렇지 않았다. 그래서 많은 사원, 대리가 회사 욕을 할 수밖에 없을지도..?ㅎㅎ
다시 정리해서,
회사가 나에게 기대하는 목적을 달성하되, 그 안에서 능동적으로 개선할 수 있는 부분을 ⭐️곁들인다⭐️면 까이지 않는 '잘 만들어진 기획안을' 만들 수 있을 것이다.
(완벽한 기획안이란 세상에 존재하지 않을 것이다. 주의할 점은 능동적 개선안은 '곁들여야' 한다.)
슬픈 소식이 있다.
이번 서비스 개편시 가장 기대했던.. 로그데이터를 심을 수 없을 것 같다는 청천벽력같은 소식이 전해져왔다.
로그데이터를 활용한다면, 서버가 터질 수 있다고 한다. 사용자의 약 10%만 이용해도 클릭율을 알아보고자 한다면 몇만명 수준이 될 것이라고 한다.
의문이 드는 것은 몇만명이 단시간에 그것을 클릭한다면, 진짜 서버가 터질 정도일까? 그정도로 허약한 서버를 회사가 가지고 있는걸까..? 하지만 다시. 원점으로 돌아가서(목적과 기대효과를 생각해) 내가 얻어내려고 하는 로그데이터가 정말 서비스에 필요한 것인지에 대해 잘 생각해봐야한다. 정말 필요하다면, 그에 맞는 충분한 가설이 필요할 것이다.
그러나 어떤 채널로 콘텐츠가 많이 공유가 되었는지 아닌지는 확인을 해봐주신다고 했다. 이 점은 정말 놓칠 수 없다. 서비스에서 콘텐츠가 주요 핵심 자산인데, 이것이 어떤 채널로 공유가 많이 되는지 확인을 해야한다. 확인하고 많이 공유된 채널과 제휴를 맺을수 있는 부분이기도해서 이것 만큼은 나도 양보할 수가 없다.
