이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
0에서 1단계 프로덕트 경험으로는 학부 캡스톤에서 일정 관리 앱을 처음부터 출시까지 만든 것이 있습니다. 가장 어려웠던 건 무엇을 먼저 만들지 결정하는 일이었습니다. 기능 아이디어가 너무 많아서 모두 넣으려다 3개월 안에 아무것도 완성 못 할 뻔했습니다.
핵심 사용 시나리오 하나만 집어서 그것을 완성하는 데 집중하고 나서야 출시가 가능했습니다. 출시 후 사용자 피드백으로 실제 필요한 기능이 설계 때 생각했던 것과 많이 달랐다는 걸 알게 됐습니다. 낮은 완성도로 빠르게 출시하는 것이 방향을 검증하는 데 가장 효과적이었습니다. 이 경험이 0→1 프로젝트에서 가장 중요한 건 범위 압축이라는 걸 알려줬습니다.
0에서 1단계 프로덕트를 만들고 나서 출시 후 실제 사용자 반응이 설계 가정과 얼마나 다른지 확인하는 과정이 가장 인상적이었습니다. 핵심 기능으로 잡았던 일정 공유 기능은 거의 쓰이지 않았고, 알림 기능이 가장 자주 언급됐습니다. 설계 단계에서는 공유가 핵심이라고 확신했는데, 실제 사용 데이터는 달랐습니다. 그 차이가 0→1 프로젝트에서 가설 검증이 왜 중요한지를 실감하게 해줬습니다.
출시는 완성이 아니라 검증의 시작이라는 것을 그때 이해했습니다. 이후 새로운 기능을 추가할 때 어떤 행동 변화로 성공을 확인할지를 먼저 정의하는 방식을 쓰고 있습니다.
0에서 1단계 프로덕트 작업에서 가장 큰 실수는 사용자 인터뷰 없이 기능을 먼저 정의한 것이었습니다. 팀원들이 생각하는 문제를 모아서 기능 목록을 만들었는데, 개발 3주 차에 실제 타겟 사용자를 인터뷰하고 나서 우리가 해결하려는 문제를 그들은 크게 느끼지 않는다는 것을 알게 됐습니다. 방향을 전환하면서 3주 치 작업 일부를 버려야 했습니다. 그 이후로 기능을 논의하기 전에 타겟 사용자 3명과 30분씩 인터뷰하는 것을 첫 번째 단계로 정했습니다. 인터뷰는 시간이 걸리지만 잘못된 방향으로 달리다 방향을 바꾸는 비용보다 훨씬 저렴하다는 것을 그때 배웠습니다. 0→1에서는 만드는 속도보다 올바른 문제를 찾는 속도가 더 중요합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.