프로덕트가 만들어지는 진짜 과정: 아이디어에서 출시까지
프로덕트를 만들고 결정하고 선택하는 과정이 궁금하다는 요청이 있었습니다. 기초적인 내용 같지만, 이 과정을 구체적으로 설명할 수 있는 PM은 많지 않아요. Product School CEO가 2026년 1월에 발행한 11 Product Management Trends Shaping 2026은 Slack, Miro, Google 등의 CPO·VP가 직접 밝힌 우리 팀은 이렇게 결정한다를 모아놓은 글입니다.
15초 요약
핵심 한 줄: 좋은 제품은 한 번의 결정이 아니라, 매일의 작은 선택이 쌓여서 만들어진다.
기능 하나가 세상에 나오기까지, PM은 수십 번의 선택을 합니다. 이 문제를 풀 건지, 어떤 방식으로 풀 건지, 지금 풀 건지, 어디까지 만들 건지. 이 선택들이 회의 한 번에 정해지는 게 아니라, 일상의 대화·데이터·실험 속에서 점진적으로 쌓인다는 게 핵심입니다.
알아두면 좋은 용어
- 프로덕트 트리오(Product Trio): PM·디자이너·엔지니어 리드 3명이 함께 뭘 만들지를 결정하는 최소 의사결정 단위
- 디스커버리(Discovery): 뭘 만들지를 탐색하는 과정. 고객 인터뷰, 데이터 분석, 경쟁사 조사 등 개발 전 단계
- 트레이드오프(Trade-off): A를 선택하면 B를 포기해야 하는 상황. 제품을 만든다는 건 결국 뭘 안 만들지를 정하는 것
- 랜딩 리뷰(Landing Review): 출시 후 실제로 효과가 있었나?를 점검하는 회고. Google이 launch가 아니라 landing이 중요하다며 도입한 개념
Y's Insight
오늘의 Y's Insight는 쿠팡·그린랩스·무신사에서 10년간 PM으로 일하며 제품 조직의 일하는 방식을 직접 설계해 온 멘토 율(Yul)님이 작성했습니다.
기획서 쓰면 제품 나오는 거 아니에요?
많은 분이 제품이 만들어지는 과정을 이렇게 생각합니다.
아이디어 → 기획서 → 디자인 → 개발 → 출시
틀린 건 아닌데, 이건 공정표이지 의사결정 과정이 아닙니다. 진짜 어려운 건 각 단계 사이에 숨어 있는 수십 개의 선택이에요.
- 이 문제를 지금 풀어야 하나, 다음 분기로 미룰 수 있나?
- 해결 방법이 3가지인데 어떤 걸 선택하지?
- 기능을 어디까지 만들지? 완벽하게? 최소한으로?
- 이 결정을 누가 내리지? 내가? 리드가? 대표가?
코칭하다 보면 기획서는 잘 쓰는데 의사결정에서 막힌다는 분이 정말 많아요. 기획서 작성은 실행이고, 그 전에 벌어지는 탐색과 판단이 제품의 방향을 결정합니다.
실제로 기능 하나가 나오기까지: 5단계
추상적인 이야기 대신, 모바일 앱에 영수증 자동 스캔 기능을 추가하자는 결정이 나오기까지를 예시로 풀어볼게요.
1단계. 문제 발견 — 뭐가 불편한 거지?
기능은 아이디어에서 시작하지 않습니다.
문제에서 시작합니다.
- CS팀 로그: 영수증 수동 입력이 귀찮다는 문의가 월 200건
- 사용자 인터뷰: 출장 후 정산할 때 영수증 찾느라 30분 쓴다
- 이탈 데이터: 영수증 입력 화면에서 40%가 이탈
❌ 영수증 스캔 기능 만들면 좋겠다 (해결책부터 생각)
✅ 영수증 수동 입력 때문에 사용자가 이탈하고 있다. 이 문제의 크기가 얼마나 되지? (문제 크기부터 확인)
2단계. 기회 평가 — 지금 이걸 해야 하나?
문제를 찾았다고 바로 만드는 게 아닙니다.
PM이 실제로 하는 질문들이에요.
- 해결하면 핵심 지표가 얼마나 움직이나? → 정산 완료율 60%에서 80%로 기대
- 다른 프로젝트보다 임팩트가 큰가? → 이탈률 40%면 최우선
- 우리만의 강점이 있나? → 이미 법인카드 데이터 보유, 영수증 매칭 가능
- 리스크는? → OCR 정확도 낮으면 오히려 수정 작업 증가
이 정리가 되어 있어야 왜 이걸 지금 하는지를 팀과 이해관계자에게 설명할 수 있습니다.
3단계. 해결책 설계 — 어떻게 풀지?
여기서 프로덕트 트리오가 함께 움직입니다.
- PM: 영수증 입력 이탈을 줄이는 게 목표. 해결 방식은 열려 있어요.
- 디자이너: 카메라로 찍으면 바로 인식? 갤러리에서 선택?
- 엔지니어: 외부 OCR API 쓰면 2주, 자체 개발하면 6주.
이 대화에서 트레이드오프가 발생할 수 있어요.
- A. 외부 OCR API — 2주 완성, 빠른 검증 가능. 단, 정확도 80%이고 비용 발생.
- B. 자체 OCR 개발 — 정확도 95%, 장기 경쟁력 확보. 단, 6주 소요에 다른 프로젝트 지연.
- **C. 사진만 첨부 **(OCR 없이) — 1주 완성. 단, 근본 해결이 안 됨.
✅ PM의 판단: 가설 검증이 우선이니 A로 가되, 정확도 90% 이하면 B로 전환하는 기준을 미리 잡자.
이게 결정하고 선택하는 과정입니다. 정답이 있는 게 아니라, 조건과 맥락 속에서 가장 합리적인 판단을 내리는 것.
4단계. 만들기 & 검증 — 진짜 되나?
- 1주차: 외부 OCR API 연동, 내부 10명 테스트 → 한국어 인식률 72% (기대 이하)
- 2주차: 전처리 로직 추가 → 86%
여기서도 선택이 필요합니다: 86%면 출시해도 되나?
❌ 100% 될 때까지 기다리자 (완벽주의 함정)
✅ 86%로 출시하되, 인식 실패 시 수동 수정 플로우를 매끄럽게 만들자
5단계. 출시 & 학습 — 다음에 뭘 할지
- 1주차 데이터: 이탈률 40% → 22%로 감소
- 예상 못한 발견: 사용자 60%가 갤러리에서 사진 선택 → 카메라 촬영만 최적화했음
- 다음 액션: 갤러리 플로우 개선 우선순위 상향
제품을 만드는 과정은 여기서 끝이 아니라, 다시 1단계로 돌아갑니다. 출시 데이터가 새로운 문제를 알려주고, 그 문제가 다음 기능의 시작점이 됩니다.
2026년, 달라지고 있는 3가지
프로세스 자체가 바뀐 게 아니라, 각 단계의 속도와 판단 기준이 달라지고 있어요.
1. 로드맵 대신 원칙으로 결정한다
Slack CPO Rob Seaman은 고정된 기능 로드맵은 끝났다고 말합니다. 대신 3~5개의 프로덕트 원칙을 세우고, 매일의 선택을 그 원칙에 비춰 판단해요. 디자이너 1명 + 엔지니어 1명의 초소형 스쿼드가 AI로 프로토타입을 빠르게 만들고, 작동하지 않으면 즉시 폐기합니다.
❌ 로드맵에 있으니까 만들자
✅ 우리 원칙에 비춰봤을 때, 이게 지금 만들 가치가 있나?
2. 출시가 아니라 '착지(Landing)'를 본다
Google의 Lisa Kamm(현 Dow Jones의 Head of Product and Design)은 Google은 launch 이야기를 멈추고 landing 이야기를 시작했다고 합니다. 출시 2~3개월 후 채택률·행동 변화·비즈니스 임팩트를 점검하고, 반복 개선(iterate), 확대(scale), 또는 폐기(retire) 중 하나를 결정합니다. 분기에 기능 12개 출시가 아니라 효과 있었던 게 몇 개냐가 진짜 성과입니다.
3. 학습 속도가 경쟁력이다
Miro CEO Andrey Khusid는 학습 속도가 진짜 제품의 해자라고 합니다. 강한 부정 시그널이 보이면 2주 만에 프로젝트를 중단해요. 로드맵을 가설 기반 베팅으로 다루고, 각 베팅에 킬/더블다운 기준을 미리 정합니다. (DAU 1000 미달이면 중단, 전환율 5% 이상이면 확대)
이런 액션을 취해보세요
조직 안에서든, 혼자 하는 사이드 프로젝트든, 지금 만들고 있거나 최근 출시한 기능 하나를 골라, 아래 질문에 답해보세요.
- 문제: 어떤 문제를 해결하려고 만들었나요? 그 문제를 어떻게 발견했나요?
- 기회: 다른 문제 대신 이걸 선택한 이유는 뭐였나요?
- 해결책: 다른 방법은 없었나요? 왜 이 방식을 골랐나요?
- 트레이드오프: 이 기능을 만들면서 포기한 건 뭔가요?
- 검증: 출시 후 예상과 달랐던 건 뭔가요?
답하다 보면, 나는 어디까지 의식적으로 결정했고, 어디서부터 관성으로 진행했는지가 보입니다.
근데 말이죠
Slack의 스쿼드 구조를 따라 하고, Miro의 2주 킬 기준을 도입한다고 좋은 제품이 나오는 건 아니에요. 프로세스는 좋은 팀이 더 잘 일하게 도와주는 도구이지, 나쁜 팀을 좋은 팀으로 바꿔주진 않아요.
문제 먼저 정의하세요, 트레이드오프를 명확히 하세요 — 다 아는 이야기처럼 들리죠? 그런데 실제로 해보면, 문제 정의가 제일 어렵고, 트레이드오프를 인정하는 게 제일 불편합니다. 다 할 수 있어요라고 말하는 게 편하니까요. 기초를 아는 것과 하는 것의 간극이 PM 역량의 차이입니다. 완벽한 프로세스를 찾는 게 아니라, 왜 이걸 만드는지를 팀 전체가 같은 언어로 설명할 수 있는 상태를 만드는 게 중요합니다.