이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 졸업 프로젝트로 교내 도서관 좌석 예약 앱을 기획했을 때의 실패 사례를 말씀드리겠습니다.
저는 "자리가 부족할 것"이라 짐작하고 기능을 정했습니다. 그런데 막상 만들어보니 사람들이 거의 안 썼습니다. 짐작이 빗나간 것입니다.
그 실패 뒤 저는 학우 열 명을 직접 인터뷰했습니다. 그제야 진짜 불편은 "자리 수"가 아니라 "빈자리가 어디 있는지 모르는 것"임을 알았습니다. 저는 이 실패에서 제품 기획은 짐작이 아니라 사용자의 진짜 문제에서 출발해야 한다는 점을 뼈저리게 배웠습니다. 그 뒤로 저는 기획 전에 어김없이 사용자를 먼저 만납니다. 실패는 아팠지만, "내 머릿속 문제"와 "사용자의 진짜 문제"가 다르다는 걸 가르쳐준 가장 값진 경험이었습니다.
제가 졸업 프로젝트로 교내 중고 거래 앱을 기획했을 때의 성공 사례를 말씀드리겠습니다.
"거래가 자꾸 취소된다"는 문제가 있었습니다. 처음엔 제가 그 문제를 통째로 붙들고 한 주를 헤맨 적이 있었습니다. 그 뒤 저는 문제를 세 조각으로 쪼갰고, 취소 사유 데이터를 모아 보니 절반 이상이 "연락 문제"였습니다.
저는 거기에만 집중해 앱 안 채팅 알림 기능을 다듬었습니다. 그러자 취소율이 눈에 띄게 떨어졌고, 사용자 만족도도 올랐습니다. 저는 이 성공에서 제품 기획은 모든 문제를 다 손대는 게 아니라, 데이터로 진짜 원인 하나를 짚어 거기에 집중하는 일이라는 점을 배웠습니다. 작은 한 곳을 정확히 고치면 큰 변화가 온다는 걸, 그 프로젝트에서 직접 확인했습니다.
제가 5명 팀의 졸업 프로젝트에서 제품을 기획했을 때의 사례를 말씀드리겠습니다.
프로젝트 방향을 두고 팀원들의 생각이 갈렸습니다. 처음엔 제가 제 기획안을 밀어붙이려다, 팀원들이 따라오지 않아 진행이 멈춘 적이 있었습니다.
그 실패 뒤 저는 여러 안의 장단점을 표로 정리해 모두 앞에 놓았습니다. 사람 대신 사실을 가운데 두자, 토론이 모였고 절충안에 모두가 동의했습니다. 그 뒤 기획은 빠르게 진행됐고, 결과물도 좋았습니다. 저는 이 사례에서 제품 기획은 좋은 아이디어 하나가 아니라, 팀이 같은 방향을 보게 만드는 데서 성공한다는 점을 배웠습니다. 혼자 옳은 안을 갖는 것보다, 팀과 합의한 안을 만드는 게 실제로 일을 굴린다는 걸 익혔습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.