프로덕트 매니지먼트 목록으로
프로덕트 매니지먼트

프로덕트 솔루션 도출: 문제에서 해법으로

디스커버리를 통해 올바른 문제를 찾았다면, 이제 그 문제를 풀 차례입니다. 그런데 여기서 많은 팀이 성급해집니다. 문제를 발견하자마자 처음 떠오른 해결책으로 직행하는 것이죠. 하지만 첫 번째 아이디어가 최선인 경우는 드뭅니다. 좋은 솔루션은 여러 가능성을 탐색한 끝에 나옵니다. 이 글에서 문제를 좋은 해결책으로 바꾸는 솔루션 도출 과정을 정리하겠습니다.

솔루션 도출이란 무엇인가

솔루션 도출은 디스커버리에서 찾은 고객의 문제나 기회를 풀 방법을 만들어 내는 일입니다. 프로덕트 팀이 “이 문제를 어떻게 풀 것인가”에 답을 내는 과정이죠.

핵심은 솔루션이 문제에서 출발해야 한다는 것입니다. 멋진 기능 아이디어에서 시작해 문제를 억지로 갖다 붙이는 것이 아니라, 명확히 정의된 문제를 풀기 위한 최선의 방법을 찾는 것입니다. 문제가 먼저, 해결책이 나중입니다.

첫 번째 아이디어를 경계하라

솔루션 도출에서 가장 흔한 함정은 처음 떠오른 아이디어에 안주하는 것입니다.

문제를 보면 대개 즉시 해결책이 떠오릅니다. 그리고 그 첫 아이디어에 애착이 생겨, 다른 가능성을 진지하게 탐색하지 않게 되죠. 하지만 첫 아이디어는 대개 가장 뻔한 것이고, 더 나은 해결책이 그 너머에 있는 경우가 많습니다.

그래서 좋은 팀은 의도적으로 여러 해결책을 탐색합니다. “이것 말고 다른 방법은 없을까?”, “완전히 다르게 접근하면 어떨까?“를 물으며 가능성을 넓힙니다. 하나의 문제에 여러 해결책을 나란히 놓고 비교할 때, 진짜 좋은 것이 드러납니다.

발산과 수렴

솔루션 도출은 흔히 ’발산’과 ’수렴’이라는 두 단계로 이루어집니다. 영국 Design Council의 ’더블 다이아몬드’가 이 펼치고 좁히는 흐름을 그림으로 보여 주는 대표적인 틀입니다.

발산 단계에서는 판단을 미루고 최대한 많은 아이디어를 냅니다. 좋고 나쁨을 따지기 전에, 다양한 가능성을 폭넓게 펼치는 것이죠. 이때는 “말이 안 되는 것 같은” 아이디어도 환영합니다. 엉뚱한 아이디어가 뜻밖의 좋은 해결책으로 이어지기도 하기 때문입니다.

수렴 단계에서는 펼쳐진 아이디어들을 평가하고 좁혀갑니다. 어떤 것이 문제를 가장 잘 풀고, 실현 가능하고, 가치가 큰지를 따져 최선을 선택합니다.

이 두 단계를 분리하는 것이 중요합니다. 아이디어를 내면서 동시에 평가하면, 비판이 두려워 좋은 아이디어가 나오지 못합니다. 먼저 마음껏 펼치고, 그다음에 냉정하게 좁히는 것이 효과적입니다.

좋은 솔루션의 기준

여러 솔루션 중에서 무엇을 선택할지는 몇 가지 기준으로 판단합니다.

문제를 잘 푸는가. 가장 근본적인 기준입니다. 이 해결책이 정의된 문제를 실제로 해결하는가.

사용자가 원하고 쓰기 좋은가. 아무리 문제를 잘 풀어도 사용자가 쓰기 어렵거나 원하지 않으면 소용없습니다.

실현 가능한가. 우리의 기술과 자원으로 만들 수 있는가.

사업적으로 가치 있는가. 이 해결책이 사업 목표에 기여하는가.

앞서 다룬 PM의 세 축, 즉 사용자, 기술, 비즈니스가 여기서 다시 등장합니다. 좋은 솔루션은 이 셋이 만나는 지점에 있습니다. 사용자가 원하는지(desirability), 만들 수 있는지(feasibility), 사업이 되는지(viability)를 함께 보는 이 세 기준은 디자인 회사 IDEO가 널리 알린 틀입니다.

솔루션도 가설이다

한 가지 기억할 것은, 선택한 솔루션도 완성된 정답이 아니라 하나의 가설이라는 점입니다. “이 해결책이 문제를 풀고 사용자에게 가치를 줄 것이다”라는 가설이죠.

그래서 솔루션을 곧바로 완전히 만들기보다, 프로토타입이나 작은 실험으로 먼저 검증하는 것이 현명합니다. 솔루션이 실제로 효과가 있는지 값싸게 확인한 뒤, 본격적으로 만드는 것입니다. 이 검증 방법은 다음 글에서 다루겠습니다.

마무리

프로덕트 솔루션 도출은 디스커버리에서 찾은 문제를 풀 방법을 만드는 활동으로, 문제에서 출발해 여러 가능성을 탐색해야 합니다. 첫 아이디어에 안주하지 말고, 발산으로 폭넓게 펼친 뒤 수렴으로 좁히며, 사용자, 기술, 비즈니스가 만나는 지점의 해결책을 선택합니다. 선택한 솔루션도 가설이므로 검증이 필요합니다.

솔루션의 방향을 잡았다면, 그것을 사용자가 실제로 경험하는 형태로 설계할 차례입니다. 다음 글에서는 UX 디자인 기초를 다루겠습니다.

목록으로 돌아가기