[Chapter 2. 일하는 방식] 어떻게 생각하고 행동하나요?
PM으로 일하면서 가장 뿌듯했던 순간을 꼽으라면, 이직한 지 얼마 안 되었을 때 참여한 프로젝트가 끝난 다음 팀원들이 "2년 차였어요?"라며 놀라 했던 때다. 복잡한 플랫폼 프로젝트를 주도하면서 연차가 아니라 일하는 방식으로 평가받는다는 걸 느꼈고, PM으로서 제대로 역할을 해냈다는 자신감이 생긴 순간이었다.
예전 회사에서 일할 때, 내부에 정착되지도 않았고 외부 경쟁사에는 있지만 우리 회사에는 적용되지 않았던 기능을 처음부터 설계해야 하는 상황이 있었다. 플랫폼 기능 정의를 처음부터 하고, 복잡한 구조를 설계해야 했다. 2년 차였던 나한테는 꽤 큰 도전이었다.
처음엔 막막했다. 무엇부터 시작해야 할지, 어떤 방식으로 설계해야 할지 감이 안 잡혔다. 그래서 경쟁사 케이스 스터디부터 시작했다. 비슷한 기능을 제공하는 회사들의 제품을 분석하고, "왜 이렇게 설계했을까?", "우리 제품에는 어떻게 적용할 수 있을까?"를 고민했다.
케이스 스터디를 하면서 필요한 기술적인 내용들을 정리했고, 우리 제품에 맞는 커스터마이징까지 해서 요구사항을 정의했다. 경쟁사 기능을 그대로 베끼는 게 아니라, 우리 사용자에게 맞는 방식으로 재해석하는 게 중요했다.
개발팀과 협업하면서 기술적 제약도 고려했다. "이 기능을 만들려면 어떤 아키텍처가 필요한가?", "기존 시스템과 어떻게 연동할 것인가?"를 개발자와 함께 논의하면서 설계를 다듬었다. 디자이너와는 "사용자가 이 기능을 어떻게 이해하고 사용할 것인가?"를 고민하면서 UX를 만들었다.
테스트하고 가설을 검증할 때도 나름 노력을 많이 했다. 베타 사용자를 모집해서 피드백을 받고, A/B 테스트로 여러 방식을 비교하고, 데이터를 분석해서 개선점을 찾았다. 작은 문제들이 계속 나왔지만, 하나씩 해결하면서 기능을 다듬었다.
프로젝트는 성공적이었다. 출시 후 사용률도 예상보다 높았고, 사용자 만족도도 좋았다. 팀 내부에서도 "이 기능 덕분에 경쟁사와 차별화됐다"는 평가를 받았다.
가장 기억에 남는 건 프로젝트가 끝나고 회식 때였다. 팀장이 "사실 처음엔 걱정했는데, 2년 차라 부족할 수 있었을 텐데 잘 따라와 줘서 고맙다"라고 말했다. 그 순간 팀원들이 엄청 놀라는 표정이었다. "2년 차였어요?", "시니어인 줄 알았는데"라는 반응이 나왔다.
그때 느낀 건, PM은 연차로 평가받는 게 아니라는 거였다. 문제를 정의하고, 요구사항을 명확히 하고, 팀과 소통하는 방식이 제대로 됐다면 경력이 짧아도 신뢰를 얻을 수 있다는 걸 배웠다.
가장 뿌듯했던 순간은 복잡한 플랫폼 기능을 성공적으로 만들었을 때가 아니라, 팀원들이 내 연차를 듣고 놀라 했을 때였다. 케이스 스터디, 요구사항 정의, 테스트, 검증까지 하나하나 제대로 해냈고, 그 과정에서 팀의 신뢰를 얻었다. PM은 연차가 아니라 일하는 방식으로 평가받는다는 걸 느낀 순간이었다.
* 전체 내용을 정리한 전자책은 아래에서 확인할 수 있습니다.
* 관련 실제 합격 포트폴리오를 확인하고 싶으시다면 아래에서 확인할 수 있습니다.