미쿡 블라인드에 올라온 흥미로운 글입니다. mircoservice 아키텍쳐의 백엔드 PM에 기대하는 바가 무엇인가? 라는 질문에 개발자들의 답변은 필요없거나, 오히려 속도를 늦추기만 할 뿐이라는

미쿡 블라인드에 올라온 흥미로운 글입니다. mircoservice 아키텍쳐의 백엔드 PM에 기대하는 바가 무엇인가? 라는 질문에 개발자들의 답변은 필요없거나, 오히려 속도를 늦추기만 할 뿐이라는 댓글이 많네요 ㅋㅋㅋㅋㅋㅋ 탐라를 종종 도는 PM 무용론과는 좀 다른 결로, 백엔드 서비스의 PM은 일반적인 consumer-facing PM과 다르게, A/B 테스트, 유저리서치 등등 PM의 전문성(?)이 필요없거나 매우 작다보니, 현실적으로는 project management 역할을 수행하게 되는데, 개발자 출신이면 그나마 낫지만, 그렇지 않으면 개발 외의 잡일+문서정리가 주업무가 되어버릴 공산이 큰 것도 사실이긴 합니다. Roadmap이나 feature 우선 순위 선정에도 개발자들에 의해 사실상 결정될 공산이 매우 크구요. 그래서 가능하다면, 특히나 본인이 non-tech 기반이라면, end-user를 바라보는 프로덕트의 PM을 하는게 바람직합니다. ㅋㅋㅋ 저 역시 여러 회사를 거치면서 end-user 서비스와 back-end / platform PM을 다 해봤지만, 개발자 출신임에도 확실히 end-user 서비스 PM이 PM 커리어나 성장, 일의 보람, 내외부 인정 등 모든 면에서 훨씬 낫긴 하더라구요. 어째거나 그럼에도 불구하고 Back-end나 API PM을 해야 된다면, 개인적인 의견으로는, 1. 해당 프로덕트의 유저는 무조건 있을테니, 유저가 누구인지, 그들이 원하는게 뭔지를 정의하는 것에서 부터 시작해야 되고, 2. PM이 역할이기도 한 product roadmap, feature 정의 및 우선순위, user story에 최대한 집중하고, 3. 이해관계자 관리 (라고 쓰고 정치라고 읽는..)의 중심에 서서 앞서 정의한 로드맵과 user story를 잘 정립하고 이해시키는 과정을 계속 반복해나가면서, 4. response time이 되었건 failure rate가 되었건, end-user까지 사용량이 되었건 의미있는 지표를 정해서 tracking하면서 개선해나가는 과정을 반복해나가보면, 먼가 의미있고 배울 수 있고, 기여할 수 있는게 있지 않을까 싶긴 합니다. 덧붙여서, 장기적으론 특히나 내부 이해관계자만의 back-end 시스템이더라도, 잘 조합해서 B2B 솔류션화까지 할 수 있다면 매우 금상첨화겠죠? (물론 한국에선 현실적으로 매우 어렵겠지만..)