Back_to_Basics

{3줄 요약}

디지털 제품 프로세스는 발견에서 개선까지 반복하며 가치를 만드는 흐름이에요.
좋은 제품은 직선으로 완성되지 않고 중간에 자주 돌아가며 문제를 다시 봐요.
이 단계를 알면 지금 필요한 도구와 판단이 무엇인지 더 정확히 고를 수 있어요.

"아이디어가 생겼으니까 바로 만들면 되지 않나요?"

이 접근의 문제는 만든 후에 "아, 이게 아니었구나"를 발견한다는 거예요.
개발까지 완료한 뒤에 발견하면 수정 비용이 기하급수적으로 커요.

Product Design 프로세스는 "빠르게 틀리고, 빠르게 배우고, 빠르게 수정한다"는 구조예요.
이른 단계에서 문제를 발견할수록 비용이 적어요.

Marty Cagan이 《Inspired》에서 강조하는 것처럼, 최악의 제품 실패는 "잘못된 것을 아주 잘 만들었을 때"예요. 기능이 완벽한데 아무도 원하지 않는 것.

많은 사람들이 Product Design 프로세스를 "디자이너만 쓰는 것"으로 오해해요.
실제로는 PM, 개발자, 마케터 — 제품을 만드는 모든 사람이 이해하고 함께해야 해요.

1단계 — 발견 (Discovery)

어떤 문제를 풀 것인가를 찾는 단계예요.
사용자 인터뷰, 데이터 분석, 시장 조사, 경쟁사 분석이 여기에 들어가요.

이 단계의 핵심 질문: "어떤 사용자가 어떤 상황에서 어떤 문제를 겪고 있는가?"

많은 팀이 이 단계를 건너뛰고 바로 "무엇을 만들까"로 가요.
그러면 팀의 아이디어가 아닌 사용자의 진짜 문제를 해결하기 어려워요.

2단계 — 정의 (Define)

발견한 것을 바탕으로 "우리가 풀 문제"를 명확하게 정의하는 단계예요.
문제 정의, 페르소나, 사용자 여정 지도가 여기서 나와요.

이 단계의 핵심 질문: "우리가 해결하려는 것이 정확히 무엇인가?"

같은 데이터를 보고도 팀마다 다른 문제를 정의할 수 있어요.
이 단계에서 팀이 같은 문제를 보고 있다는 정렬이 필요해요.

3단계 — 설계 (Design)

문제에 대한 해결책을 만드는 단계예요.
아이디어 발산, 와이어프레임, 프로토타입이 여기에 있어요.

이 단계의 핵심 질문: "어떻게 이 문제를 해결할 수 있는가?"

이 단계에서 "하나의 정답"을 찾으려 하지 마세요.
여러 방향을 빠르게 탐색하고, 그중에서 검증할 방향을 선택하는 게 맞아요.

4단계 — 검증 (Validate)

만든 것이 실제로 문제를 해결하는지 확인하는 단계예요.
사용성 테스트, A/B 테스트, 소규모 출시가 여기에 있어요.

이 단계의 핵심 질문: "이 해결책이 실제로 작동하는가?"

검증 없이 출시하면 "만들어봤더니 아무도 안 쓴다"는 결과가 나올 수 있어요.
검증은 확신이 아니라 "이 방향으로 가도 될 것 같다"는 신뢰를 만들어요.

5단계 — 출시와 개선 (Launch & Iterate)

실제 사용자에게 배포하고, 데이터와 피드백을 수집하고, 개선하는 단계예요.

이 단계의 핵심 질문: "실제 환경에서 어떻게 작동하는가?"

출시가 끝이 아니에요. 테스트 환경과 실제 환경은 달라요.
출시 후에 새로운 문제가 발견되고, 그게 다시 1단계로 이어지는 순환이에요.

중요한 오해가 있어요.
"1→2→3→4→5 순서대로 한 번만 하면 된다"는 생각이에요.

실제로는 순환이에요.
4단계(검증)에서 "이 방향이 아니었다"를 발견하면 2단계(정의)로 돌아가요.
5단계(출시)에서 수집한 데이터가 1단계(발견)의 새로운 시작이 돼요.

애자일(Agile) 방법론이 이 순환을 짧은 스프린트로 구조화해요.
2주 단위로 발견→설계→검증을 반복해요.
완벽한 제품을 한 번에 만들려 하지 않아요.

프로세스를 알면 "지금 내가 어느 단계에 있는가"를 알 수 있어요.

발견 단계인데 이미 와이어프레임을 만들고 있다면, 문제 정의 없이 해결책을 만들고 있는 거예요.
설계 단계인데 이미 개발이 시작됐다면, 검증 전에 너무 많이 만들고 있는 거예요.

단계를 알아야 "지금 뭐가 빠진 건가"를 볼 수 있어요.

각 단계의 구체적인 방법은 이어지는 아티클들에서 다뤄요: 문제 발견, 사용자 인터뷰, 요구사항 정의.

Marty Cagan, 《Inspired》(2018) — 제품 발견부터 출시까지의 프로세스를 실무 관점으로 설명해요. "잘못된 것을 잘 만드는" 실패를 피하는 방법을 다뤄요.