[프롶로그1.] 일 잘하는 PM과 일 한다는 것
BD 가 바라본 이슈 대응 잘하는 PM
Tech BD 6년 차.
여러 종류의 PM과 일하면서 느낀 점이 있다. 사실은 어제 어떤 이슈 대응하느라 12시간을 달달 볶인 후 새벽 1시에 퇴근하면서 이 혼또니 카오스를 어떻게 정리하면 좋을까 생각하다가 글을 쓰기로 마음먹었다. 무한의 질타와 수없는 자책보다, 객관적 판단과 인사이트를 밟고 앞으로 나아가기.
[프롶로그]는 professional + log 를 이은 말로, 회사에서 일하는 professional 한 자아가 쌓아가는 log (개발적으로 - 코드에 로그가 심어져 있어야 데이터를 추후에 발췌할 수 있음)를 기록한 여정입니다.
좋은 PM과 나쁜 PM은 이렇게 나뉜다. 자기 프로덕에 대한 명확한 답을 해주면 좋은 PM, 답을 모르고 횡설수설하면 나쁜 PM.
이렇게 심플하면 얼마나 좋을까. 모든 세상 아이스크림이 셀렉션처럼 딸기맛 초코맛으로 나뉘면 얼마나 삶이 편할까? 하지만 세상에 수만가지의 아이스크림 맛처럼 문제의 맥락과 해결책에도 다양한 색깔이 있다. 복잡한 사안에 대한 질문을 찰떡같이 대답해주는 PM 들과 대화할 때 '사이다를 마신 듯 속이 시원'한 느낌을 받는데, 그 이유가 뭔지 나도 고민해보기로 했다.
"저희 지금 파트너 서비스 런칭해야 하는데요, 초록 버튼을 눌렀을 때 다음 페이지로 안 넘어가요."
파트너는 대게 vague 한 질문을 던지기 마련이다.
(1) 질문은 알아만 들어도 절반은 간다
내부 주체 정의 단계
어제 어떤 버그에 대한 원인과 해결책을 파악하기 위해 약 10명의 사람한테 문의를 했다. (이해가 안 될 수도 있지만, 그것을 해결해줄 수 있는 담당자가 누구인지조차 명확하지 않은 상황이었다.)
1. 한시간동안 대화를 했는데 결국 자기가 해결할 수 없는 문제라는 사람.
2. 듣자마자 자신의 영역이 아니라고 말하고, 아마도 이쪽에 문의해보셔라고 던지는 사람.
3. ㅇㅇ의 문제일수 있으니, ㅇㅇ의 ㅇㅇ쪽에 ABC라는 워딩으로 질문해보라는 사람. (더 감동이었던 건 아예 단톡방 만들어서 함께 질문해줌)
4. 해결책을 안다면서 '륑가디움 레디오사'를 추가해 다시 코드 반영을 해보라는 사람. 하지만 그 정보의 소스는 끝내 알려주지 않음.
5. 계속해서 새로운 해결책을 던졌지만 하나도 워킹하지 않았고 결국 다른 팀에 넘겨야 한다는 사람.
계속해서 다른 사람에게 질문을 하면서, 같은 내용과 같은 영상을 계속 forward 해야 했다. 나에 대한 반성은 아예 하나의 링크에 내용을 넣고 그 링크를 계속 전했다면 어땠을까? 10명의 다른 사람에게 다른 레벨의 정보를 전달했는데, 하나의 문서에서 축적되는 정보들 + 이거이거까진 테스트해봤는데 그래도 안 됬다는 프로그레스를 공유했다면 좋았을 것 같다. (왜냐면 특정 두 팀이 결국에는 나중에 한 단톡방에서 만남ㅋㅋㅋㅋ....)
===> 결론
GOOD 내가 해결해줄 수 있는 질문인지 아닌지를 ... 아는 것만으로... BD 에게는 좋은 PM
BETTER 내가 해결해줄 수 없다면, 누구에게 물어봐야 하는지 아는 PM
BEST 누구에게 어떤 언어로 (특히 개발용어가 포함될 경우) 물어보면 되는지 알려주는 PM (단체방에서 투명하게 소통해주면 더 좋지만 그건 ownership 등등의 영역이 있을테다.)
(2) 빠른 파악을 도와주는 좋은 질문
문제 정의 단계
"어떤 디바이스로 테스트 하셨죠? 안드로이드? 아이폰? / 앱 버전은 몇이죠? 앱 업데이트는 하셨나요? 어카운트는요? 국가 설정은요? 앱은 설치되어 있나요? 어떤 루트로 진입하셨죠? 어떤 브라우저를 사용하셨죠? "
문제 발생자의 테스트/환경 파악을 하는 질문이다. 이게 내가 생각할 때 정말 baseline, minimum requirement 라고 생각한다. 이런 질문도 해내지 못하면 그것은... 기본부터.... 그런데 그것을 물어보는 방식에도 차이가 있다.
1. 기기는 어떤 거로 하셨나요? 아이폰이요.. 앱 버전은요? 3.4요... 계정은 뭐로 쓰셨죠..?
2. 디바이스 종류 / 계정 설정 / 앱 버전 / 메인화면부터 어떤 루트로 진입하셨는지 영상으로 알려주시면 검토해볼게요.
나는 파트너 소통을 하다보니 PM과만 대화하는 게 아니라 그걸 잘 정리해 파트너에게 다시 질문을 해야한다. 나는 보통 PM 이 물어본 것을 그대로 전달하지는 않는데, 종합적인 상황판단을 하고 한번에 문제 원인 파악을 위한 질문 리스트 + 해결 가능 여부 + 해결 소요 예상 시간 등을 한꺼번에 답장하고 싶기 때문이다.
이런 질문이 많이 쌓이면 보통 FAQ 를 만들어 던지기도 한다. 그게 Best...
=> 결론
GOOD 좋은 PM은 문제 파악을 위해 파트너에게 뭘 물어봐야 하는지 안다.
BETTER 좋은 PM은 상황 파악을 위한 다양한 질문을 한꺼번에 던진다.
BEST 좋은 PM은 내가 rephrase 할 필요 없도록 말끔한 불렛포인트로 확인 필요사항을 한.꺼.번.에 전달해준다. **** (내 시간을 아껴주고, 모두가 클리어하게 소통 가능, 파트너에게 바로 포워드 가능)
(3) 그래서 해결이 된다는 거에요 안 된다는 거에요?
'확인 중' 대기 단계
보통 파트너는 애타게 기다리기 마련이다. 나는 중간에서 PM 과 개발의 논의를 지켜보고라도 있지 파트너는 내 이야기만 들으며 답답하기 마련이다.
1. 확인해볼게요. (묵묵부답) (3시간 후) 이렇게 다시 시도해봐주실래요?
2. ㅇㅇ 팀이랑 ㅇㅇ 를 확인 중인데, 3시간 정도 후에 답변드릴 수 있을 것 같습니다.
3. 3시간 후에 답변드릴 수 있는데, 그때 드릴 수 있는 답변은 해결 가능 여부고요, 해결까지 걸리는 시간은 그 이후에 알 수 있어요.
결론 => 좋은 PM 은 자신이 처한 상황이나 하고 있는 액션에 대해서 잘 설명한다.
타임라인 별로.. 그리고 문제를 파악 중인 건지 아님 이미 해결중인건지... 버스정류장에서 엄마를 애타게 기다리지 않게..... 엄마 8시에 올거니까 그때까지 떡볶이 집에 있어..라고 말해주면 얼마나 좋냐 이거야.
1. 링가디움레디오사 를 헤르미온느 한테 부탁해볼게요.
2. 링가디움레디오사 코드 (서버 로직을 외부에서도 접근가능하게 코드)를 헤르미온느 (플랫폼 개발팀 담당)에게 문의해 수정 중입니다. 이건 클라이언트 문제가 아니라 서버 문제여서요.
누가 이렇게 말하나 싶지만 생각보다 많은 사람들이 이렇게 대화한다. 나는 1번처럼 얘기하는 개발자나 PM 을 정말*** 많이 만났다. 나는 그렇다 치고 (내부자라 이해한다 치고) 파트너가 그걸 어떻게 이해할 수 있단 말인가?
결론 => 좋은 PM 은 내부/ 개발 용어 대신 외부 / 시장 common term / 문과 이해 가능 용어로 설명함 !!!!!
(3) 같은 해결책도 다르게 답하는 사람들
테스트 / 파트너 요청 단계
1. a=1 로 입력한 링크를 a=2로 수정해보세요. 그래도 안 되나요?
2. 이건 서버가 아닌 클라이언트의 문제입니다. 브라우저간 연동이 안 되는 거니까 링크 뒤에 예외 코드를 적용해보세요. a=2
3. 두가지 측면이 있어요. (1) 정책적으로 막혀있을 수 있고요. 이건 클라이언트 팀과 확인해보세요. (2) 기술적으로 해결하려면 예외코드 반영이 필요한데 a=2로 시도해보시겠어요?
결론 => 좋은 pm은 액션이 아니라 맥락을, 결론이 아니라 과정을 설명해준다.
1. banana 말고 apple 로 시작하는 링크를 파트너에게 요청해주세요.
2. banana로 되어 있으면 정책상 앱이 다른 브라우저로 넘기는 것 같아요. apple 형태의 링크로 추가 생성 요청 가능할까요?
결론 => 좋은 pm 은 파트너 요청할 때 가정과 이유를 함께 설명해준다.
(그래야 파트너도 더 잘 도와주고, 오히려 파트너가 창의적인 솔루션을 제안해주기도 함)
(4) 이제 모든 정보는 있고.. 어떻게 액션 하면 좋을까요?
의사 결정 단계
urgent 한 이슈 대응에 대해 중요한 것은? 1. 정확성 2. 신속성 이다.
아무리 옳은 답을 줬더라도 10시간을 끌어 파트너를 화나게 하면 BD 로서는 굉장히 난감하다.
차라리 5시간 후에 해결 가능여부를 알 수 있고, 그중에 A / B / C 에 대한 확인이 필요, 그게 안 될경우 대안은 D 뿐이다. 라고 말해줄 수 있는 사람이 되어야 한다. (나도 어려운 부분)
<파트너가 해결 vs 우리가 해결>
1. 그건 파트너가 따른 페이지 제작해주면 되는 거 아닌가요? 저는 클라이언트니까 서버 담당이 해결하는 게 빨라요. (분명 클라도 다르게 도울 수 있는 방법이 있는데도....)
2. 저희가 소스 코드 변경 하는 게 가능은 한데요. 파트너가 할 수 있는 방법 없나요?
3. 저희가 코드 변경하려면 다음 배포 일정에 맞춰야 해서 15일이 소요 돼요. 파트너가 하면 소요일정/리소스가 많이 드나요?
결론 => 좋은 PM은 해결책/해결 주체에 대한 장단점을 설명해준다.
< 파트너와 우리 해결 분배 / 장기 vs 단기 솔루션>
1. 저희가 하면 한달이 걸리는데요. 파트너가 하는게 빠르지 않을까요?
2. 단기로는 파트너가 ㅇㅇ 삽입해주고, 15일 후 배포일정에 저희가 장기적으로 소스코드 반영하면 어떨까요. 저희가 혼자 다 하려면 가능은 한데 리소스가 너무 많이 필요해서요.
결론 => 해결 가능 여부 뿐만 아니라 각자의 솔루션 / 타임라인을 단기 장기로 나누어 제안한다. (이정도면 거의 BD 역량까지 갖춘 PM 이라고 볼 수 있음)
<해결책이 가지는 의미 : 시장에의 영향>
1. A / B / C 로 해결이 가능한데 어떤 거로 바꿀까요?
2. B / C 로 하면 너무 오래걸리니 A 로 가시죠.
3. A / B / C 로 바꿀 수 있는데 A 로 하면 빠르고, 파트너가 원하는 건 맞춰줄 수 있지만, 갤럭시 보유 유저한테는 노출이 안 되고요. B 로 하면 전체 대상 해결은 가능한데 대신 저희 리소스 7일이 필요해요.
결론 => 좋은 PM 은 해결책의 영향도를 비교해준다.
(단순 우리 입장에서 말고 user 나 partner 입장에서) 고로 내가 파트너와 협상해야할 포인트가 무엇인지 알려준다. 각 솔루션의 user impact 이 어떻게 될지, 우리의 리소스나 비용은 얼마나 드는지 알려준다.
그러는 나는 좋은 비디인가?
사실 이 모든 걸 바라는 건 내 욕심이다.
모든 문항과 답변을 비디로 바꾸면 역으로 내가 일을 잘 할 수 있기 위해 필요한 답을 얻을 수 있다. 아무쪼록 이 많은 걸 잘 파악할 수 있도록, 내가 그 질문을 잘 던질 수 있는 사람이 되자.
나에겐 나쁜 PM이 개발에게는 좋은 PM일 수 있다.
좋고 나쁜 피엠을 떠나서, 문제 해결에 집중하기 위한 좋은 방법을 터득하는 글이 되었으면 한다.
결국은 PM만의 이야기는 아니다.
예시를 PM 으로 들어서 그렇지, 파트너랑 일할 때는, legal/marketing/PM/engineering 아무튼 모든 부서와 무언가를 컨펌해야할 일이 많다. 때론 브랜딩 가이드라인에 맞추려면 마케팅과도 비슷한 소통을 할 때도 있다.
1. 이거는 컬러 빨강 대신 파랑으로 바꿔야해요.
2. 컬러 파랑으로 바꿔야 해요. 브랜딩 가이드라인 문서 투척.
3. 파랑으로 바꿔야 하고, 브랜딩 3번 보시면 빨강은 특정 케이스에만 쓰이기 때문이에요. 브랜등 가이드라인 문서 투척.
4. 파랑으로 바꿔야 하는데요. (브랜딩 3번 해당) 이건 Strict 한 내용이라 무조건 지켜야 하고, 화살표 변경은 파트너가 어려우시다고 하면 예외로 허가는 가능합니다.
5. 이번건 빨강 으로 가셔도 되는데, 그러려면 글로벌 헤드 어프루벌 필요해요. 그렇게 하시거나 아니면 ㅇㅇㅇ 으로 수정해주셔야 합니다.
나로써는 1번만 얘기해주면 파트너에게 요청할 때 정말 짜친다.. 왜 굳이 한 번 더 일해야하는지에 대한 자세하고 친절한 설명이 늘 도움이 된다. 누구나 그렇듯 나에겐 당연한 일이, 누군가에겐 아닐 수 있기 떄문.
결론 => 결론보다 이유를, 불/가 대신 어떤 건 100% 안되고 어떤건 50% 가능한지를 설명해주는 팀원이 최고. 아무튼 나는 요청해야하는 입장이 있고... 전부 파트너와의 관계/협상에 영향을 주기 때문이다.
혼돈의 카오스에서 리더가 할 수 있는 일
쓰다보니 정말 길어졌다. 여러 이슈 보고를 하면서 leadership 임원들도 어떤 질문을 던지는지 보면 똑똑한 임원인지 알 수 있다. 그들은 솔직히 디테일한 걸 알 필요는 없다. 실무가 알아서 해결하면 되니까.내가 생각할 때 리더가 던질 수 있는 이상적인 질문은 이렇다.
(1) 원인이 뭐고, 어떤 팀이 해결해줘야 하는지. 해결 가능 여부.를 묻기 이전에, 이 문제의 규모를 파악.
- 지금 버그로 영향을 받는 유저 규모를 파악 (앱버전/국가/심각성/소비자 불만 여부 - 심각할 경우 더 높은 리더에게 알려야할정도의 사안인지)
(2) 자신이 escalation 해줘야 하는 부분이 있는지 (개발팀이나 프로덕 리더한테 급히 챙겨줄 것 요청 등)
(3) 해결하기 위해서는 어떤 팀의 어떤 리소스가 필요한지 / 파트너가 해결해줄 수 있는 방법은 없는지 / 예상소요시간
(4) *마지막으로* 리더가 해야하는 의사결정 포인트가 무엇인지!
결국 누구를 만족 시키고, 무엇을 포기하냐의 문제다.
- 모든 커다란 문제의 해결책에는 누군가의 비용이나 리소스, 포기해야 하는 대상이 생긴다. 때론 파트너를 만족시키는 대신 우리 개발팀을 혹사시켜야 하고, 때론 우리 정책을 고수하기 위해 파트너에게 양해를 구해야한다. 때론 갤럭시 유저만 해결/아이폰 유저는 포기하거나, 모든 유저에게 애매한 정도의 솔루션을 제공하는 방안 중에 의사결정을 해야하기도 한다. 모든 디테일을 챙길 수 없다면, 의사결정 포인트를 잘 정리하고 이해하는 리더가 똑똑한 리더 아닐까?
특히 어제 이슈에 리더가 전화가 와서 나에게 한 말이, "근데 사전 테스트는 안 해봤나?" 였다. 테스트를 당연히 해봤기도 하고, 당장은 그게 중요한 게 아닌데, 뭔가 '탓'을 하는 것 처럼 느껴졌다. 아무튼 누구의 잘못인지는 나중에 짚고, 당장은 해결에 포커스 해야한다고 생각한다 ....................... 호호호
나에게 아직 남은 시간이 있나요?
어제 어떤 피엠이 나한테 물어봤다.
급한 이슈고 1시간 후 푸쉬발송되니까 제발 부탁한다고 했는데, 결국 그때까지 해결을 못 했다. 피엠이 do i still have time ? 이라고 물어봐줬고, 새벽 한시까지 함께 고민해줬다. 나를 포기하지 않아줘서 고마웠다. 사실 파트너도 저녁 6시쯤 포기를 했기 때문이다. 새벽 한시에 파트너에게 여러가지로 시도해봤지만 실패했다는 메시지를 남기면서, 비디로서 fail 했다는 감각보다 이만큼까지 노력을 해봤다는 것에 의의를 두기로 했다. 사실 어느 순간부터는 아무도 더 시키지 않는데 나와의 싸움이었다.
때론 누군가가 나를 포기하지 않아줘서 내가 더 좋은 비디가 되는 것 같기도 하다.
밤 12시, 그만 포기하고 자자고 하니까 계속 질문 해도 된다는 PM
