07. 대학생 PO가 직원들의 신뢰를 얻기까지 上 - 업무에서 신경썼던 것
12월, 회사에 들어온 지 1달이 지나고 CPO 님께서 Product 하나를 나에게 맡겼다.
그것은 바로 "테이블 오더"라는 서비스였다. (그때는 몰랐다. 이 서비스가 앞으로의 나의 회사 일상에서 대단한 애증의 관계가 될 것이라는 것)
이번 글과 다음 글에선 해당 서비스를 맡고 난 뒤 1 달간, 나름의 노력을 통해 직원분들의 신뢰를 얻어갔던 과정에 대해 써보고자 한다.
1. 서비스 소개 (테이블 오더?)
테이블 오더? 라는 워딩을 들으면 대체 뭐지?라고 낯설게 느낄 사람이 많을 것 같다. (나도 이름만 듣고는 뭐 하는 서비스인지 잘 몰랐었다.) 하지만 설명을 듣고 나면 다들 아~ 할 거다. 아마 한 번도 안 써본 사람은 거의 없을 것이라고 생각한다.
바로 위 사진 처럼, 술집/식당 등에서 태블릿으로 음식을 주문/결제하는 서비스를 말한다.
식당에선 주문/결제를 받는 인건비를 줄이는데에 효과적이기 때문에 해당 서비스의 사용률이 점점 높아지고 있는 상황이었다. 그에 따라 관련 시장에 여러 회사들이 뛰어들고 있었다. 페이히어도 기존엔 POS만을 가지고 사업을 했지만 여러 가지 내외부적 이유(해당 시장의 성장, 회사 매출 상승 목표) 등으로 11월 중 해당 서비스를 출시했다.
정말 빠르게 출시했기에, 내가 해당 서비스를 맡게된 12월 초에는 소프트웨어적으로도 완전 핵심 flow만 존재하는 MVP 단계(Minimum viable product) 라고 할 수 있었고, 소프트웨어 외 적으로 내부 운영 체계/하드웨어 관리 측면에서도 아직 프로세스가 덜 잡혀있는 상태였다.
2. 처음 서비스를 맡고서의 느낌
CPO님이 같이 봐주시겠다고 했다고는 해도, 어떤 한 서비스, 그리고 한 스쿼드에 소속되어 팀을 PO로서 리딩한다는 게 약간은 부담스럽긴 했었다. 인턴이라는 신분과, 대학생이라는 딱지가 있긴 하니까... 또 당시에 해당 Product가 회사에서 매우 중요했기에 부담감이 더 컸었다.
하지만 한편으론, 이전부터 원했던 주도적으로 해볼 수 있는 환경, 그리고 이제 단순 리서치나 공통 정리 업무가 아니라 정말 PO가 되어서 디자이너/개발자와 협업을 통해 it 서비스를 만들어나갈 수 있다는 생각에 설렜다.
내가 업무를 맡고 나서 결심했던 것은 "인턴, 대학생, 무경력" 의 딱지를 떼고, 진짜 1명의 PO로서 인정을 받고 싶다는 것이었다. 나에게 있어 여러 우려하는 인식(대학생, 인턴, 무경력) 이 있을 수 있기 마련이니, 처음에 가장 중요하게 느낀 것은 직원분들로부터 "신뢰"를 얻는 것이라고 생각했다. 이런 부분을 의식했는지는 모르지만, 신뢰를 얻고자 업무과정에서 하나하나 세세한 부분까지 신경을 쓰면서 노력을 했었다.
자잘하게 느껴질 수 있고, 지금 10개월간 PO업무를 해본 입장에선 어떻게 보면 PO로서 당연한 것들이다.
그래도 그 당시 제대로 PO가 된지 1개월 동안 업무시 노력했던 부분을 적어보면 다음과 같다.
3. 업무시 노력했던 것들
1) 디자이너와의 협업
스쿼드엔 디자이너 1명 , 백엔드 1명, 프런트 1명, PO 1명(나), CPO 이렇게 멤버가 구성되어 있었다.
그중 디자이너분과는 PRD(기획서) 리뷰 후, 디자인 시안 제작과정에서 특히 소통이 많았다. 특정 UI/UX제작, UX 라이팅 설계 등에 있어서 디자이너가 기획자에게 기획의도를 물어보거나, 특정 시안/워딩에 대한 의견을 묻는 일들이 많았다.
디자이너 분과의 의견 논의 과정에서 가장 신경썼던 것들은 아래 3가지였었다.
1) 꼼꼼히 보는 것
2) 의견 제시에 있어서 근거를 같이 대는 것
3) 끊어갈 부분에 대한 합의
1) 꼼꼼히 보는 것
디자이너 분들은 디자인에 집중하시다보니, 디자인 시안 제작 시 세세한 정책적인 부분까지는 놓치기가 쉽다. (PO가 쓴 기획서의 글만으로는 전달력이 떨어졌을 수도 있고)
실제 이런 부분들을 시안 제작과정에서 제대로 안잡고 넘어갈 시, 서비스의 통일성/완성도가 낮아질 수 있고, 추후 정책관리가 더 어려워질 수 있기에 더 신경을 썼었다.
물론, 우리 스쿼드의 디자이너 분께서는 처음 이 서비스를 만들 때부터 디자인을 하셨기 때문에 당시에 나보다 서비스 히스토리/정책 히스토리를 더 잘 알고 계셨다. 하지만 그럼에도 디자인 리뷰 시 특히 정책적인 부분들을 더 꼼꼼히 보려 했다.(모르는 정책은 물어봐 가면서 더블 check도 했었다)
Ex)
나(PO): 다른 모달에선, 창 자동닫힘이 15초인데 이 화면만 20초로 그려져 있는 이유가 있을까요?
나(PO): 다른 화면과의 통일을 위해, 여기서도 "~세요" "~니다" 체로 워딩을 표현하는 게 더 통일성이 있지 않을까요?
=> 나는 엄청난 경력, 실력이 있었던 것은 아니기에 최대한 꼼꼼히 보는 것이 내가 할 수 있는 최선의 노력이라 생각했다.
한편으론, 이 정도의 디테일까지 체크하는 게 너무 과하게 느껴지실까?라는 생각에 처음엔 우려하기도 했었다.
하지만 우려와 달리, 사람이다보니 디자인 과정에서 놓칠 수 있는 부분들을 있기에, 이를 최대한 꼼꼼히 보면서 체크해 주려는 노력이 디자이너 분께는 좋게 인식되었던 것 같다. (실제로 나중에 따로 "두범 님은 되게 꼼꼼히 봐주셔서 좋아요!"라고 칭찬도 해주셨었다.)
또 이 과정에서, 서비스의 초기 기획자가 아니다 보니 모를 수 있는 정책적인 부분들에 대한 인지가 좀 더 높아졌었다.
2) 의견 제시에 있어 근거를 같이 대는 것
디자인 리뷰 시 단순히 의견 제시가 아니라, 최대한 그 의견에 대한 근거를 같이 제시하려 노력했다.
Ex 1)
디자이너: a워딩과, b워딩 중에 뭐가 더 나을까요?
나(PO): 실제로 서치해 보니, a워딩의 경우 이런 일반적인 앱 보단 특정 상황에서만 주로 사용되더라고요. 또 워딩 자체가 좀 더 어려운 편이라, 사장님이 쓰는 관점에선 b가 더 쉽게 느껴질 것 같아요.
Ex 2)
나(PO): 더치페이시, 특정 화면으로 되돌아가게 될 시 더치페이 인원이 늘어날 때마다 유저의 화면전환수/클릭수가 (n*2) 회 씩 증가하는데, 그걸 줄이기 위해 ~~ 이렇게 해보는 건 어떨까요? 최대한 유저의 depth를 줄이는 게 좋을 것 같아서 제안드려요.
=> 디자이너 분께 신뢰를 주기 위해서, 의견에 있어서 최대한 근거를 제시하려 노력했다. 이 의견을 내기 위해 나름의 고민을 많이 거쳐서 낸 것이고, 아무렇게나 기획하고 의견내는 사람이 아니란 걸 나타내고 싶었다. 또 서로간의 의견 논의를 원활하게 하기 위해서는 근거를 제시해야 해당 근거를 바탕으로 추가 논의가 가능하기 때문에 더 근거를 제시하려고 했다. (ex. 말씀해 주신 근거 중 ~~~ 부분은 xxx 방식으로 했을 때 더 잘 나타나지 않을까요? )
3) 끊어갈 부분에 대한 합의
디자인 과정에서 UX적인 완성도를 위해서 "있으면 좋을 부분" 이 생길 수 밖에 없다. 하지만, 스타트업/초기 서비스에서는 리소스도 한정되어 있고, 앞으로 만들어야 할 기능도 많기 때문에 그럴 부분들에 대해 잘 자르고 가는 게 중요하다. 특히 내가 맡은 테이블 오더 서비스가 더 그랬다. 그렇기 때문에, 실제 디자이너 분이 납득할 수 있는 근거와 함께 끊어갈 부분에 대해 합의를 하려고 노력했다.
Ex)
디자이너: 결제 실패가 일어나는 경우에, 직원을 호출 할 수 있는 버튼을 해당 결제 실패 모달에도 넣으면 좋지 않을까요? 손님입장에서 결제 실패가 일어났을 때, 해당 화면에서 바로 직원을 부르는데 도움이 될 것 같아요.
나(PO): 좋은 의견인거 같습니다. 다만, 일단은 결제실패 모달을 창닫기 한 후에 직원호출을 할 수 있는 대안적인 기능이 이미 존재해요. 또, 화면에 버튼이 많아지면 UI가 복잡해질 수도 있어요. 일단은 그대로 가고, 결제 실패가 빈번하게 일어나고 그에 따른 불만 cx 문의가 잦게 들어와서 필요성이 느껴질 때 기능 개발을 고려해 보는 게 어떨까요?
=> 서비스의 완성도나 UX 적인 측면에서는 아쉬울 수 있지만, 개발속도를 고려해서 쳐내야할 부분이 있었고 이런 부분에 대해서 최대한 잘 설득을 할 수 있도록 노력했었다. 해당 부분들은 유저보이스 수를 바탕으로 고려하거나, 추후 다른 기능 개발 시 작은 기능 개선으로 중간중간 끼워 넣는 식으로 진행을 했었다.
2) 개발자와의 협업
개발자 분들과의 작업에 있어서는 3가지를 신경썼었다.
1) 최대한 여러 case를 고려한 기획
2) 지속적인 질문을 통한 구조 이해
3) 이슈대응 앞선 처리
1) 최대한 여러 case를 고려한 기획
물론 서비스 이해도가 완전하진 않았기에 부족한 부분들도 많았지만, 최대한 다양한 case를 다 고려해서 기획을 할 수 있도록 노력했다. 또 여러 case가 나오는 경우에는 아예 "표"를 잘 활용해 보려고 노력했다.
Ex 1)
a. 사용자가 본인 전용 대기이미지를 1) 등록했을 때 2) 안 했을 때,
b. 내부 어드민에서 3) 광고송출을 했을 때 4) 안 했을 때
이에 따른 4개 (2x2)의 case가 나올 수 있고, 이에 대해 세부적인 부분까지 적어보려고 노력하는 것
Ex 2)
- 더치페이 결제 과정에서 happy flow만 있는 것은 아니고 특정 단계에서 실패를 하거나, 뒤로 가기 시 어떻게 할 것인가?
중간 이탈을 허용할 것인가? 허용한다면 어디까지 허용할 것인가?
=> 최대한 꼼꼼하게 여러 case까지 고려해서 기획해서, 개발자 분들이 쉽게 개발에 들어갈 수 있도록 고민을 많이 했었다. 내가 꼼꼼하게 기획할 수 있는 사람, 개발자 분들이 쉽게 개발할 수 있도록 노력하는 사람이라는 걸 보여주려고 했었다.
2) 지속적인 질문을 통한 구조 이해
개발적인 구조에서든, 혹은 도메인(소상공인, 결제, 주문)적인 차원에서든 당연히 모르는 사항이 있을 수밖에 없었다. 물론 모바일 어플리케이션을 1번 만들어봤었지만, 이 회사에서 쓰는 스펙은 또 다를 수 밖에 없기 때문이다. (아마 경력자 분들도 어느 회사를 가든, 마찬가지의 상황이 벌어질 것이다.)
그렇기에 최대한 계속 물어보려 노력했던 것 같다
(특히 옆자리에 앉았던 백엔드 개발자 분께 많이 물어봤었다..ㅎㅎ 지금도 매우 감사해하고 있다.)
Ex)
- 푸셔/폴링 차이가 뭐예요?
- 결제 프로세스에서 이 단계에선 어떻게 처리되는 거예요? 언제 어떤 데이터가 생기나요?
=> 처음에 부끄러울 수 있어도, 결국에 내가 이 로직을 완벽하게 이해해야 추후에 타 부서에서 개발적인 질문이 있을 때 개발자 분들 귀찮게 안 하고 내가 대응을 할 수 있을 것이라 생각했다. 또 추후 기획에서도 도움 될 부분이기 때문에 최대한 신경을 썼던 것 같다.
3) 이슈 대응 앞선 처리
회사 서비스 특성상(주문, 결제) 버그/기능 문의를 포함한 다양한 것들이 슬랙을 통해 꽂힌다. 특히 CX 팀에서 해결이 안 되는 기술적 문의(Tech operation이라 통칭)의 경우, Product팀에서 나서서 같이 빠르게 해결해 고객만족도를 높이는 회사문화를 가지고 있었다.
물론 서비스에 대해서 완벽히 이해한 상태는 아니었지만, 최대한 개발자 분들이 뒷단의 작업(정말 개발자 분들만 볼 수 있는 사항)만 할 수 있도록 앞단에서 운영적으로 체크해 줄 수 있는 부분들을 체크했던 것 같다.
초반에는 이해도가 높지 않아, 이슈 해결에 있어 불필요한 것들을 물어보기도 하고 했었다. 하지만, 이런 과정을 여러 번 거치면서 나름의 체화가 됐던 것 같고 나중에는 오히려 개발자 분들보다도 어떤 면에선 더 빠르게 대응이 가능했었다.
- 추후 퇴사 전에 개발자 분이 해주셨던 말:
저였으면 이슈 나왔을 때 로그 먼저 까봤을 것 같은데, 두범 님이 로그 까보기도 전에 착착 먼저 체크해야 할 것 체크해서 개발자가 볼 것 없이 바로 문제가 해결됐네요.
3) 운영팀과의 협업
초기 서비스고, 빠르게 출시하다 보니 운영적 체계가 덜 갖춰져 있는 부분도 있었고 운영인력도 충분한 상황이 아니었다.
그렇기 때문에 더더욱 "운영은 무조건 운영팀의 일이야"라고 생각하는 게 아니라 "운영도 Product의 일부"라는 생각을 했었다. 결국에 운영적인 부분에 의해 고객 만족도가 높아지고, 낮아질 수도 있기 때문에 Product와 분리된 게 아니라고 생각했다. 또한, 지금 인력이 부족해서 운영적 해결이 불가능한 거라면 나라도 해결을 하려고 노력했다.
그래서 운영상으로 빈틈을 채워야 할 것들이 발견되면, 어떻게든 그것들을 해결하려고 노력했다. 해당 부분을 담당하고 있던 담당자분께서 놓쳤을 때 역으로 제안을 드리기도 하고, 놓칠 수 있는 타임라인/업무 들을 운영팀 분께 하나하나 세세하게 챙겨드리고, 리마인드 해 드리면서 운영적인 부분을 놓치지 않으려고 노력했다.
Ex)
- 특정 광고가 특정 서비스 유형에는 뜨면 악영향이 있을 것 같아. 광고로 인한 혜택을 해당 서비스 유형에선 사용할 수 없으니까요! 광고 게재 정책 만들어서, 처음 게재 시 때부터 이 부분을 유의할 수 있도록 해봐요. 기존 매장에 대한 처리는 백엔드 개발자 분께 부탁해서 일괄처리 해볼게요.
- 이용가이드에 특정 내용이 추가되면 설치/운영 시에 더 편할 것 같은데 이 부분 추가해 보는 거 어떨까요?
- 혹시 신규 서비스 설치 일정을 알려주실 수 있을까요? 해당 부분을 개발자 분들께 공유해드리면 혹시나 이슈발생 시 대응이 좀 더 수월할 거 같아요
4) 그 외
a. 리서치
맡았던 서비스가 우리 회사에선 기능 상 초기 상태였지만, 시장엔 이미 디벨롭되어 있는 타사의 서비스들이 많았다. (아마 여러분들도 식당/술집 갈 때마다 거의 다른 회사의 테이블오더를 썼을 거다.)
그렇다 보니, 추후 기능개발을 위한 사전조사로 타사의 레퍼런스/정책들을 서치 해야 하는 경우가 꽤 있었다.
C-level분들이 서치를 부탁하셨을 때, 책상 앞에만 앉아서 리서치를 하지 않았다. 단순 서치로 원하는 정보를 알 수 없는 경우, 실제 해당 서비스를 쓰려하는 사장님인 것처럼 타사 고객센터에 연락해 필요한 정보를 서치해왔었다.
지금 생각해 보면 이런 발로 뛰는 모습들이 C-level을 비롯한 윗분들에게 "얘 그래도 좀 쓸만한데?"라는 생각이 들게 했을 수도 있겠다는 생각을 한다.
b. 공유와 정리
여러 업무에서 공통적으로 신경을 많이 썼던 것이 공유와 정리였었다.
예를 들어 업무요청에 있어서는
1) 텍스트로 해당 내용 정리/요약해 메신저로 공유
2) 해당 정리 내용에 대해, 찾아뵙고 간단히 구두로도 설명드리기
회의 완료 후에는
1) 회의 내용 + 앞으로 해야 할 action에 대한 정리 후 공유
소위말해서 "오버 communication"을 했다. (의도했던 것은 아니었다.)
처음의 생각은 특히 타 부서 분들의 경우 업무가 바쁘시기도 해서, 슬랙(메신저)으로 업무 공유/내용 정리를 드려도 놓치실 수도 있겠다는 생각이 있었다.(특히 리더급들)
그래서 짧게 구두로라도 설명을 드리러 가서, 놓치지 않으시게 노력을 하려 했다.
또 내가 나름 노력해서 적었지만, 텍스트가 완벽히 이해가 안 되실 수도 있겠다는 생각이 있었다. 그래서 한번 자리로 찾아뵙고 간단히 맥락설명을 드리려 했던 것 같다. 맥락설명을 드리고, 나중에 텍스트를 보시면 더 파악이 쉬우실 테니까.
그리고 업무 요청의 경우, 바쁘신데 일을 부탁하는 것일 수도 있으므로(일을 받는 사람입장에서는 별로 안 좋을 수도) 최대한 얼굴을 보면서 업무 필요성/목적에 대한 설명과 업무사항에 대해 간략하게라도 구두로 설명드리려 했던 것 같다.
=> 실제로 PO를 맡고 1달 후 CPO님이 주셨던 피드백 중에 "이 공유와 정리 부분을 진짜 잘해주는 것 같다. 나보다도 잘하는 것 같다"라고 얘기해주셨다. 라는 것이 있었다. (빈말일지도 모르지만..ㅎㅎ)
나중에 퇴사할때 같이 많이 일한 개발자 분으로부터도 그렇고, 운영팀, BD 팀으로부터도 이런 "오버 communication"에 대한 긍정적인 피드백을 꼭 해주셨던 걸 보면 의도했든 의도하지 않았든 좋게 작용했던 부분이 아닐까 싶다.
4. 정리하면
정리하면 꼼꼼함, 세세하게 챙기는 부분들 이게 1달간 PO로서 일하며 좋게 봐주셨던 부분들이었던 것 같다.
어떻게 보면 PO로서의 경력이 없던 내가 노력으로 취할 수 있는 유일한 부분중에 하나였지 않았을까 싶다. 한편으론 지금보면, 이부분이 PO로서의 거의 대부분일수도 있지 않을까? 라는 생각도 한다.
이렇게 1달간 나름대로 업무에서 노력하며, 조금씩 같이 일하는 직원분들께 신뢰를 얻어갔던 것 같다. 열심히 하는 모습을 보이면서 점차 여러 색안경(대학생, 인턴) 들에서 벗어날 수 있었던 것 같다.
물론 이번 글에 적은 이런 업무적인 노력들도 물론 있었지만,
무엇보다 신뢰를 얻는 데 직빵이었던 것은 12월에 있었던 하나의 사건이었다.
그 사건 이후로 회사에서의 나에 대한 신뢰도가 거의 수직 상승했다고 생각하는데, 그 내용에 대한 것은 다음글
"대학생 PO가 직원들의 신뢰를 얻기까지 下" 편에서 적어보겠다.
Profile: