PM에 관하여 - Part 10

PM이 개발자와 소통을 한다는 것은..

프로덕트를 제작하면서, PM이라는 직무는 개발자와 떼려야 뗄 수 없는 관계이다.
모든 산업군에서 개발자가 담당하는 부분이 핵심 동력으로 작용하고 있기 때문인데,
이러한 상황에 발 맞춰 PM도 개발자의 역할에 알맞게 변화해야 한다. 

그렇다면 PM은 개발자와 의사소통을 어떤 식으로 진행해야 할까?
그냥 개발자가 알고 있는 지식을 전부 통달하여 개발자처럼 대화하면 되는 것일까?

아니다. 사실 그랬으면 PM이 그냥 개발자도 같이 하고 있었겠지.
프로덕트 내에서도 각각의 역할 분담이 중요하고, 효율적인 협업을 위해서
원활한 커뮤니케이션 능력을 기르는 것이 PM에게 필수적일 것이다.

이번 파트에서는 개발자와 PM이 의사소통을 할 때 중요한 점과
주의 사항 등을 정리하는 시간을 가져보기로 한다.

---

내 뜻대로 되는게 하나도 없숴!

프로덕트 매니저와 개발자 간의 의사소통은 프로덕트의 품질과 성공에 매우 중요한 부분이다.

클라이언트가 원하는 부분을 캐치해서, 그 부분을 개발자들에게 확실하게 전달하는 것이
프로덕트 매니저의 가장 중요한 미션이다.

 

개발자와의 의사소통에서 중요한 부분을 체크해 보면 이렇다.

 

1. 명확한 요구사항 정의
   프로덕트 매니저는 클라이언트가 제시한 제품의 요구사항을 명확하게 정의하고 문서화해야 한다.
   개발자들은 보통 상세한 명세와 스펙을 필요로 하고, 이러한 요구사항을 충족시키기 위한 구체적인 방법을 제시해야 한다.
   
   
2. 개발자와의 미팅
   프로덕트 매니저와 개발자는 잦은 미팅을 통해 의사소통을 유지해야 한다.
   PM은 개발자들의 피드백을 받고 수집하여 빠르게 적용할 수 있는 역량을 가져야 한다.
   평소에 사소한 정보 공유라도 습관적으로 피드백을 진행하면서,
   많은 의견을 수용하는 정리, 회고하는 태도가 필요하다.
   이를 통해서 프로덕트를 제작하는 단계를 좀 더 탄탄하게 할 수 있다.
   
   
3. 기술적 이해
   프로덕트 매니저는 제품 개발에 필요한 기술적 지식을 보유해야 한다.
   개발자들은 상세한 내용과 기술적인 용어를 이해하고 사용한다.
   개발 능력을 키우라는 것이 아닌, 만들어진 코드 및 사용하는 용어들을 보고 이해할 수 있는 정도만 돼도 상관없다.
   이를 통해 개발자와의 의사소통이 원활해지고, 기술적 제약 사항에 대한 이해도 높아지게 될 것이다.
   
   
4. 문서화
   개발 프로세스와 제품 개발 과정을 문서화하여 개발자와 프로덕트 매니저 모두가 이해하기 쉽게 만들어야 한다.
   최우선적으로 기술적인 이슈를 이해하고 질문하는 것이 중요하다.
   이후 스프린트 및 마일스톤과 같은 프로젝트 관리 도구를 사용하며 모든 단계를 추적하고 계획하는 것, 그리고 이러한 전반적인 부분들을 문서로 정리해 함께 아이데이션을 할 수 있도록 하는 것이 중요하다.

11화 명확하고 논리적인 제품 요구사항을 작성하자

[Column] Sprint, 왜 할까?

---

추가적으로, 개발자들과의 의사소통 시 주의 사항도 함께 정리해 본다.

 

1. 의사소통은 명확하게!
   제품 개발에 있어서 모호한 단어나 일반적인 문장 선택, 요구사항 등은
   개발자가 제품에 대한 깊은 이해를 어렵게 만든다.
   따라서 의사소통은 명확하고, 구체적으로 이루어져야 한다.
   예를 들면, 제품 설명에 있어 불필요한 상세 내용을 제공하지 않도록 해야 한다.
   질문 하나에 대한 대답은 하나로 명확하게 답변하며, 여러 가지를 구체적으로 붙이고 싶을 때는
   꼭 문장을 마무리 짓고 다음으로 넘어가며 추가적으로 답변하면 좋다.
   
   
2. 열린 마음과 청취
   프로덕트 매니저와 개발자는 서로의 의견을 존중해야 하며, 개발 프로세스를 함께 토론하고 개선해야 한다.
   또한 의사소통은 양방향적인 과정이기 때문에, 개발자들의 의견을 최대한 귀담아듣고
   적극적으로 수용하는 자세가 필요하다.
   
   
3. 기술적인 용어는 풀어쓰려는 노력을 하자.
   각 직무별로 기술적인 용어가 존재할 수 있다. 같은 직무 사이에서는 기술적인 용어를 서로 이해하고
   수용할 수 있지만, 다른 직무들 사이에서는 이해하지 못할 수 있다. 물론 PM 같은 경우는
   웬만해선 기술적 용어들을 이해하고 있어야 하겠지만, 원활한 의사소통을 위해
   최대한 이해할 수 있도록 단어를 풀어내어 설명하는 것이 서로 간 존중하는 방법일 수 있다.
   
   
4. 개발자들의 시간은 소중합니다.
   개발자는 커뮤니케이션에 쓰는 시간도 중요하지만, 프로덕트를 직접 만들어내는 사람들이기 때문에
   개발에 대한 시간은 충분히 보장해주어야 한다. PM이 개발자들에게 요구사항을 명확하게 제시하고,
   기술적인 이슈를 이해하며, 문제 해결에 노력할 수 있는 능력을 보여준다면 개발자들은 보다 효율적인
   작업을 수행할 수 있다. 또한 모든 의사소통에 있어 지속적인 문서화를 진행한다면
   개발 과정의 추적성도 높이며 적극적인 회고도 함께 진행할 수 있을 것이다.

---

프로덕트 매니징 직무에 관련하여 각종 업계에 종사하고 계신 분들과 질의응답을 통해

PM이 되기 위한 핵심 그리고 PM이 가져야 하는 업무 스킬, 역량등을 정리해 본다. 

 

Part 10 - 교육 업계 서비스 기획자로 일한 경험이 있으며, 사업개발 쪽으로 이직을 했다가
다시 현재 모빌리티 플랫폼에서 서비스 기획자로 일하고 있는 멘토님과 함께한 질의응답

 

Q 1.

교육 관련 도메인에서 업무 진행 및 전문성을 가지다 모빌리티 쪽으로 옮기게 된 계기와

어떤 방향으로 어필을 하여 합격하셨는지 궁금합니다.

 

교육 관련 도메인을 선택한 이유는 대학교 때부터 교육 관련 아르바이트를 계속 해와서 그렇다.

도메인을 선택할 때 교육 도메인을 선택하는 데 망설임은 없었다.

그리하여 입시, 인강 쪽으로 포커싱이 된 곳에 커리어를 시작하게 되었다.

일을 하면서 신규 서비스를 기획할 때 고객군이 확 늘어났었다.

그래서 교육 연령대가 밑으로 내려갈수록 서비스에 대한 명확한 판단을 하기가 어려웠다.

그래서 내가 이용자가 될 수 있는 서비스를 선택해 보면 어떨까?

그리고 내 주변에서도 유저를 쉽게 볼 수 있는 서비스를 만들어보면 어떨까? 란 생각을 했었다.

 

이후 이용자와 공급자를 묶어주는 플랫폼 서비스 기획을 많이 했었다.

공급자를 얻기 위해 어떤 노력을, 이용자를 끌고 오기 위해 어떤 고민을 했는지

교육이든 모빌리티든 그 외 다른 산업이든 크게 다르지 않을 것이라는 걸
스토리를 만들어서 면접관들한테 어필을 했고

또한 내가 했던 서비스의 성격과 내가 지원하려는 도메인에서 성격이 통하는지를 보고

그것을 묶어서 나는 도메인에 크게 영향을 받지 않고 플랫폼을 잘 만드는 사람이야 라는 걸 어필했다.

 

 

 

Q 2.

모빌리티 회사로 이직 시 자동차 회사에 근무해 봤다는 경험이 얼마나 도움이 되고, 또 어떻게 어필이
될 수 있을까요?

 

오히려 자동차라는 이동 수단이라는 교집합을 사용해서 도메인이 다르지 않기 때문에 어필이 가능할 것 같다.

근무해 봤다는 것을 우선순위로 하여 모빌리티에 대한 고민을 녹여내는 것이 좋다.

또한 근무를 하면서 어떤 고민, 어떤 문제를 해결하고자 했는지 강조를 하는 것이 좋다.

1년에 1개의 일을 하는 것이 아닌 여러 가지의 일들을 했을 것이고,

가고자 하는 회사와 업무를 묶어서 어필을 하는 것이 좋다.

 

완성차 업계에서 넘어왔다면, 기술 개발, 기획 쪽으로 많이 넘어가기도 한다.

도메인 자체에서 마이너스는 아니지만, 소프트웨어 쪽으로 가고 싶다면, 소프트웨어 쪽의 경력을 녹여내야 한다.

소프트웨어 쪽의 경험이 많지 않다면, 하드웨어의 경력이 많지만 이와 관련하여 소프트웨어와 어떤 공통점,
차이점이 있는지, 결국 둘 다 상호 보완적인 관계이기 때문에 엮어서 설명하면 오히려 경쟁적으로 보일 수 있다.

 

Q 3.

멘토님께서 기획했던 플랫폼에 한정하여 수요자와 공급자 입장에서 문제 정의를 어떻게 다르게 하셨나요?

 

물론 문제 정의를 하는 법은 다르다.

현재 하고 있는 회사는 이용자, 공급자를 전부 커버하고 있는 서비스를 제공하고 있다.

공급자는 비싸게 파는 것을 원한다. 그렇기에 공급자는 어느 정도 돈으로 만족시켜줄 수 있다.

이용자와 공급자를 둘 다 만족시켜 줄 수 있는 서비스를 만들고 싶다면, 이용자에게는 제품으로 승부하기 때문에

이용자 쪽으로 좀 더 기울어서 가설을 설정하고 맞춤 서비스를 수정하는 방향으로 일하고 있다.

 

Q 4.

고객이 처한 문제를 정의하기 위해 어떤 리서치 방법을 선호하시나요?
적은 시간 대비 효율적인 인사이트를 얻기 위한 멘토님만의 꿀팁?

 

나는 무조건 가장 첫 번째로 데이터를 뽑아 본다.
2주의 시간이 있다고 한다면 유저 인터뷰는 시간이 너무 적다.
유저와 컨택하고 어떻게 보상할 지에 대해 생각하는 것 자체도 시간이 많이 걸린다.
데이터는 우리 서비스를 이용한 퍼널, UV, PV, 전환율일 수 있다.

두 번째는 CX 데이터다. 어떤 불만들이 있었는지 확인해 보고. 커뮤니티를 검색해보기도 한다.

 

서비스 기획에 관심이 있다면, 데이터로 접근하는 것을 추천한다.

그것이 사람들을 설득할 때 큰 힘을 발휘한다.

 

Q 5.

서비스기획 업무하시면서 데이터나 개발 쪽으로 부족하다고 느껴진 적이 있었는지,
어떤 식으로 부족함을 채워나가셨는지 궁금합니다.

 

아직까지도 부족하다고 느끼고 있다.

그러나 일을 할 때 걸림돌이 된다고는 생각하지 않는다.

주니어 때는 개발자한테 가서 매달리는 수밖에 없었다.

데이터 뽑아주세요.. 구현해 주세요.. 가능해요?
이런 식으로 혼나면서 배우고 경험했던 것 같다.

구글에 검색하거나 돈 주고 배우는 것엔 한계가 있으므로

추천하는 방법은 나와 페어가 맺어진 개발자한테 가서 물어보는 것이다.

데이터 같은 경우는 개인적으로 교육을 받고 직접 공부하며 배웠다.

 

Q 6.

신규 프로덕트 기획에서 문제 정의할 때 기존 참고할 데이터가 없다면 어떻게 해야 할까요?

 

신규 프로덕트를 기획할 때는 시간이 좀 여유 있게 주어져서 유저 인터뷰를 진행한다.

그러나 유저 인터뷰를 할 때 주의할 점은 유저가 말하는 것이 100% 정답이 아니다.
항상 어느 정도는 틀릴 수 있다는 마음가짐으로 접근해야 한다.

본인은 제품을 소비할 때 유저를 관찰하는 것을 좋아하는데
학원에 가서 애들이 하루종일 어떻게 하는지 관찰했었다.

유저 인터뷰와는 생각보다 많은 점이 달랐다.

인터뷰 + 설문조사 + 관찰을 같이 했었다.

 

필드에서 뛰기 어렵다고 한다면, CX팀을 찾아가서 경험을 물어보는 것도 좋다.

어떤 부분에서 항의하고, 불만이 많은지 체크했을 때 아이디어를 얻을 수 있다.

 

Q 7.

멘토님의 기획서를 작성하는 스타일과 가장 중요하게 생각하는 키워드가 궁금하다.
(ex. 개발자 소통 원활, 목표 일치를 위한 행동 등)

 

최대한 디테일하게 써봤었다.

예를 들면 alert을 만들 때, 노출되는 문구들, 명칭까지 전부 다 정리했었다.

작업서 같은 경우를 굉장히 디테일하게 하는 편이고

기획자들이 봤을 때 정답처럼 보일 수 있도록 기능을 세세하게 작성하는 편이다.

 

중요하게 생각하는 키워드는 협업이다.
개인적으로 기획자, 디자이너, 개발자든 오너십을 갖기를 바란다.
내가 만드는 제품에 대해서 애정을 갖고 잘 됐으면 좋겠어라는 생각을 가지는 것이 좋다.

방향은 가져가되, 구체적인 방법은 개발자, 디자이너와 같이 짠다.

굉장히 세부적이 만 함께 참여할 수 있게 끔 노력을 하는 편이다.

 

Q 8.

사업개발/사업기획에서 다시 프로덕트 사이드로 넘어온 이유?

 

날 것으로 답변하자면

사람보다는 프로덕트에 대해 이야기하는 것에 더 잘 맞겠다는 생각을 했었다.

프로덕트 기능을 구현함에 있어 이렇게 되었으면 좋겠어 이런 것은 답이 명확하다.

기능을 구현하거나, 구현하지 않거나 이기 때문

그러나 사람은 이렇게 답이 딱 떨어지지 않았다.

업체와 미팅을 했던 경험으로는 될 수도, 안 될 수도 있어라는 애매한 답변들이 많이 있었다.

기능 같은 경우는 시간과 리소스가 투자되면 어느 정도 정답으로 가까워질 수 있었다.

그러나 사람 같은 경우는 부정확한 반응이 많아서 나한테는 조금 스트레스였다.

나의 성향상 제품에 있어 구현하고 이용자들을 기술적으로 트래킹 하는 것이 더 성향이 맞았던 것 같다.

그래서 프로덕트 서비스 기획으로 넘어오게 되었다.

 

그래서 오히려 생각해 보면 사업 기획을 해봤기 때문에 내가 어떤 성향인지 확실하게 알 수 있었다.

경험해보지 않았다면, 아직도 어떤 것이 나한테 맞는지에 대해 헤매고 있었을 것이다.