이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제품 로드맵을 설정할 때 가장 먼저 보는 건 현재 사용자가 어디서 막히는가입니다. 비전이 아무리 좋아도, 지금 사용자가 이탈하는 지점을 방치하면 그 위에 무언가를 쌓아도 흔들린다고 봅니다. 팀 프로젝트에서 커뮤니티 서비스 기능 우선순위를 논의할 때, 팀원들 각자 중요하다고 생각하는 기능이 달라서 의견이 모이지 않았습니다. 저는 *실제 테스트 사용자 5명의 세션 녹화를 돌려보면서 어느 화면에서 멈추는지 기록한 다음, 그 데이터를 공유했습니다. 이탈이 집중된 2개 흐름을 먼저 개선하는 걸로 팀 합의가 됐고, 이후 논의 속도가 빨라졌습니다. 로드맵 우선순위는 의견보다 사용자 행동 데이터*로 정하는 게 팀 내 합의도 쉽고 방향도 흔들리지 않는다는 걸 그때 배웠습니다.
로드맵을 세울 때 저는 무엇을 넣을지보다 무엇을 제외할지를 먼저 결정합니다. 팀 프로젝트에서 기능 요청이 한꺼번에 11개 쌓인 상황이 있었습니다. 전부 담으면 릴리스가 15주로 늘어나는 계산이 나왔고, 팀 집중력이 그전에 흐트러질 것 같았습니다. 저는 각 기능에 예상 사용자 임팩트와 개발 공수 비율을 숫자로 매긴 다음, 비율이 낮은 항목 7개를 다음 분기로 밀었습니다.
상위 4개만 집중한 결과 팀은 6주 안에 첫 버전을 냈고, 피드백도 예상보다 빠르게 모였습니다. 그 경험 이후 저에게 비전 수립의 첫 단계는 범위를 압축하는 일이 됐습니다. 방향이 아무리 올바르더라도 담으려는 것이 많으면 아무것도 마무리되지 않는다는 걸 숫자로 확인했습니다. 지금도 로드맵 리뷰 때는 우선순위를 올리는 기준보다 내릴 기준을 먼저 합의합니다.
비전을 설정할 때 저는 기능 목록이 아닌 달성하려는 상태로 방향을 정합니다. 기능을 나열하면 중간에 시장이 바뀌었을 때 로드맵 전체를 다시 써야 하는 상황이 생기기 때문입니다. 수업 팀 프로젝트에서 6개월짜리 서비스 기획을 맡았을 때, 초반에 기능 위주로 로드맵을 잡았다가 두 달째에 타깃 사용자 정의가 바뀌면서 기획 절반을 다시 해야 했습니다. 이후 저는 목표를 '3개월 안에 재방문율 30% 달성'처럼 측정 가능한 상태로 바꾸고, 기능은 그 목표를 달성하는 수단으로만 위치시켰습니다. 그 뒤로 팀원이 새로운 아이디어를 제안할 때 '이게 재방문율에 영향을 주나?'라는 공통 판단 기준이 생겼고, 논의가 훨씬 빠르게 수렴됐습니다. 목표가 명확하면 방법은 교체될 수 있어도 방향은 흔들리지 않는다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.