이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기획을 제품 성과 책임 역할로 인식한다는 것은, 기획서를 완성하는 것이 일의 끝이 아니라는 뜻이라고 이해합니다. 기획이 개발되고 배포된 뒤 실제 사용자 지표가 목표에 도달했는지까지를 기획자의 책임 범위로 본다는 의미입니다. 인턴 때 온보딩 기능을 기획했는데, 배포 이후 D7 완료율이 목표치에 미치지 못하는 상황이 있었습니다. 그때 팀장님이 '기획자가 데이터를 보고 원인을 분석해야 한다'고 하셨고, 저는 인앱 이벤트 로그를 분석해 어느 단계에서 이탈이 집중되는지를 정리했습니다. 이 분석을 바탕으로 한 화면 수정으로 완료율이 8%p 올랐습니다. 기획을 성과 책임으로 본다는 것은 기능을 내보낸 뒤에도 데이터를 보는 사이클을 끊지 않는 것이라고 생각합니다.
기획을 성과 책임 역할로 본다는 것은 제게 기능을 출시했다는 것이 일의 끝이 아니라는 뜻입니다. 무언가를 만들어 내보낸 것 자체가 성과가 아니라, 그것이 실제로 사용자 지표를 움직였는지가 진짜 성과라고 봅니다. 인턴 때 온보딩 기능을 기획했는데, 배포만으로 끝났다면 잘한 것처럼 보였겠지만, 정작 완료율이 목표에 못 미쳤습니다. 그때 기능을 냈다는 것과 성과를 냈다는 것은 다르다는 것을 배웠습니다. 그래서 저는 기획할 때부터 무엇을 만들지보다 어떤 지표를 어떻게 움직일지를 먼저 생각합니다. 출시 자체에 만족하면 정작 목표를 놓칩니다. 기획을 성과 책임으로 본다는 것은 만든 것이 아니라 그것이 만들어낸 결과로 평가받는 것을 받아들이는 것이라고 생각합니다.
기획을 성과 책임으로 본다는 것은 제게 기능을 낸 뒤에도 데이터를 보는 사이클을 끊지 않는 것입니다. 인턴 때 기획한 온보딩 기능이 배포 후 완료율이 목표에 못 미쳤을 때, 저는 그것을 남의 일로 넘기지 않고 인앱 로그를 분석해 어느 단계에서 이탈이 집중되는지를 찾았습니다. 그 분석으로 한 화면을 수정해 완료율을 올릴 수 있었습니다. 만약 출시로 끝냈다면 왜 안 됐는지조차 몰랐을 것입니다. 그래서 저는 기능을 낸 뒤 지표가 움직였는지를 확인하고, 안 움직였으면 왜인지를 추적해 다음 결정을 고치는 학습 루프를 도는 것이 성과 책임의 핵심이라고 봅니다. 다만 이런 책임을 지려면 우선순위나 실험을 결정할 권한도 함께 있어야 한다고 생각합니다. 책임만 있고 권한이 없으면 작동하지 않기 때문입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.