합격자 아니어도 주어지는 PM의 '더블 다이아몬드' 치트키

 

더블 다이아몬드 기법

서비스나 제품을 기획할 때 적당히 인터뷰도 끝내고, 데스크 리서치도 끝냈겠다! 이제 묻지도 따지지도 않고 경험에 기반한 기능들을 쓸 때가 많습니다. 하지만, 부실 공사가 장기적으로 큰 사고를 불러일으키는 것처럼추후 눈덩이처럼 팀 전체에 큰 리스크를 안겨 줄 수 있습니다. 그래서 우리는 가정, 가설을 세우고 그것을 검증하는 과정을 거친 후 다음 단계(기능 개발, 서비스 콘셉트 정의 등)로 나아가곤 합니다. 그렇다면 이런 튼튼한 '기초 공사'를 어떻게 하면 될까요?
 
정답은, 💎 더블 다이아몬드 💎 에 있습니다.
다이아몬드 같은 서비스를 기획하고 싶으시다면 꼭 하셔야 합니다

 

 

---

더블 다이아몬드가 뭐예요?

#튼튼한기초공사 #문제정의치트키

더블 다이아몬드 기법은 문제 발견부터 솔루션 전달까지의 전 과정을 4단계로 나누어 확산-수렴의 논리로 체계화한 디자인 방법론입니다. 곧, 프로젝트의 기초를 설계할 때 헛된 삽질을 막고 리스크를 관리하는 가장 확실한 설계도인 셈입니다.

 
사실 구글에만 검색하면 더블 다이아몬드는 서비스 기획, 제품 개발뿐만 아니라 비즈니스 계획 등 여러 분야에서 사용하게 된다는 걸 알 수 있을 겁니다! 그만큼 어떤 것을 0에서 만들어내야 하는데 맨 땅에 헤딩할 순 없을 때, 이 기법을 많이 참고하곤 합니다. 아래 제가 그린 사진을 보고 천천히 더블 다이아몬드 기법이 왜 필요한지, 어떻게 이 4단계를 바르게 따라야 하는지 살펴보겠습니다.

더블 다이아몬드 기법

---

💎 왜 ‘더블 다이아몬드’로 시작해야 할까? 

🔥 합격자 아니어도 주어지는 PM의 '더블 다이아몬드' 치트키

 

애써서 만든 기능이나 서비스가 소비자 또는 사용자에게 외면받을 때 감정적으로 우리는 허탈함을 느끼죠... (저도 경험 있음) 우리는 분명 좋은 기능을 만든 것 같은데, 정작 현실에서는 '쓸모없다'고 생각이 될 때 말입니다.

더블 다이아몬드(Double Diamond) 는 바로 그 허탈함을 막고, 사용자가 사랑할 수밖에 없는 제품을 만드는 가장 안전하고 확실한 프레임워크입니다.

특히 경험이 적은 PM일수록 엄청난 성공을 하는 것보다, 실패 리스크 획기적으로 축소하는 것이 중요한데, 이 기법을 사용한다면! 실패 리스크를 최소로 낮출 수 있답니다

 

---

Just Do It 🙅‍♀️ , Just Do Right 👌

부실 공사는 결국 팀 전체를 무너뜨린다
서비스나 제품을 기획할 때, 적당히 인터뷰도 끝내고, 데스크 리서치도 끝냈겠다! 이제 묻지도 따지지도 않고 경험에 기반한 기능을 냅다 개발에 던질 때가 많죠. (솔직히 시간 앞에 장사 없어서 저도 그랬습니다) 하지만, 앞서 말한 것처럼 '가정(Assumption)'만으로 프로젝트를 설계하는 것은 눈덩이처럼 팀 전체에 큰 리스크를 안겨 줄 수 있습니다. 우리가 하는 모든 기획 작업은 결국 가설(Hypothesis)을 세우고 그것을 체계적으로 검증하는 과정이어야 합니다. 이 검증 과정을 건너뛰면 곧바로 일단 만들어! 가 보자고! 같은 함정에 빠지게 되죠.

  💡 튼튼한 기초 공사를 위해서는 우리가 '무엇'을 해결해야 하는지 명확히 해주는 설계도가 필요합니다

 

만약, 체계적인 문제 정의를 건너뛰게 된다면?

• 🤯 치명적인 리소스 낭비: 3개월 동안 열심히 개발한 기능이 출시 후 사용률 1% 미만을 기록합니다. 개발, 디자인, 마케팅에 투입된 모든 시간과 비용이 허공으로 사라지죠.
• 🤯 팀원들의 신뢰 하락: 기획 의도가 명확하지 않은 상태에서 무작정 개발을 시작하면, 디자이너는 갈피를 못 잡고, 개발자는 '계속 바뀌는 기획(Scope Creep)'에 지쳐 팀워크가 무너집니다. 안 그래도 PM은 욕을 가장 많이 먹는 롤인데, 이렇게 될 경우 욕을 더욱 더 많이 먹는 롤이 됩니다. 멘탈 건강에도 안 좋겠죠?

더블 다이아몬드는 사실 이거 괜찮을 것 같은데? 하고 삘 받은 뇌피셜에 STOP을 외쳐 주는, 브레이크 시스템입니다. 프로젝트의 성공은 '얼마나 멋지게 만들었는가 아니라, '얼마나 올바른 문제를 해결했는가'에 달려 있습니다.
 

---

⚙️ 더블 다이아몬드의 핵심 4단계, PM의 의사결정 시계

더블 다이아몬드의 4단계는 우리가 언제 정보를 모아야(확산) 하고, 언제 결정을 내려야(수렴) 하는지 명확히 알려주는 의사결정 시계와 같습니다. 실제로 제가 더블 다이아몬드 단계에 맞추어 협업을 요청할 때? 문서로 액션 가이드를 짰었는데, 이 실무를 가져와서 각색한 버전으로 예를 들어 더 공감해 보자구요.
 

I. 첫 번째: 왓츠 더 프라브럼 (문제 발견 & 정의)

 

단계	사고방식	핵심 목표	PM의 액션 가이드
Discover	확산 (정보 수집)	사용자의 맥락을 이해하는 것	사용자 인터뷰, 경쟁사나 비슷한 산업군 서비스 후기, 로그 분석 등 리서치 백로그(Backlog)를 쌓으세요.후기까지 섭렵해서 최대한 많은 양 모으기
Define	수렴 (문제 좁히기)	해결할 핵심 문제' 하나를 명확히 정의하는 것	가이드: 수집된 데이터를 어피니티 다이어그램 등으로 구조화한 후, 문제 기술문(Problem Statement) 작성 후 5-6 가지 정도로 추려서, 모든 팀원이 동의하는 하나의 문제를 pain point로 정의

 

* 기술문은 어떻게 써야 하나요?

⭐ 문제 기술문(Problem Statement)은 이렇게 쓰세요
X -> 사용성을 개선해야 한다
O -> 채식에 도전하고 싶지만 실패를 경험했던 사람은 채식 식단에 대한 지식 부족, 식습관 변경의 어려움, 채식 가격 문제, 주변 상권이 육식 중심의 레스토랑의 문제로 실패하는 경향이 있다.

 

II. 두 번째: 하우? (해결책 개발 & 전달)

단계	사고방식	핵심 목표	PM의 액션 가이드
Develop	확산 (아이디어 발산)	정의된 문제를 해결할 다양하고 창의적인 아이디어를 모으는 것	브레인스토밍, 와이어프레임 제작 등을 통해 아이디에이션 로그를 기록하세요. 아무거나 떠오르는 것 그리고, 그 중에서 셀렉
Deliver	수렴 (솔루션 결정)	가장 효과적이고 실현 가능한 솔루션을 검증 후 출시하는 것	사용성 테스트(UT)를 통해 프로토타입별 점수를 매기고, 가장 높은 점수를 기반으로 최종 기능과 서비스 콘셉트 결정

 
이렇게 더블 다이아몬드는 두 가지의 테마로 나누어서, 4단계로 이루어집니다. 액션 가이드를 읽어 보면 상당히 구체적이고 꼼꼼하게 이루어지기 때문에, 굳이 이렇게까지 해야 해? 싶겠지만, 우리의 '경험적 가정'은 늘 사용자의 '실제 니즈' 앞에서 무참히 깨지기 마련입니다... 사실 이렇게 기초공사를 크고 꼼꼼하게 해 놔야 최소한 나중에 제품을 통째로 갈아엎는다거나, 별점 1점의 리뷰 테러를 막을 수 있습니다.

---

🚫 하지만,  단계별 '주의해야 할 3가지'

더블 다이아몬드의 단계별로 문제를 정의하고 해결책을 낼 때, 여기에서 PM의 역량이 매순간마다 시험당합니다. 왜냐하면 우리는 지금 리서치 중인데 자꾸만 아이데이션을 하려고 하고, 현실적으로 부딪히는 많은 문제(재정 및 경영)에 회의감을 토로하는 팀원 등.... 아주 많은 갈등 상황을 마주할 수 있기 때문입니다. 그럴 땐, 이 세 가지만 딱 기억해 보세요

1. ❌ 수렴 오염 금지: Discover 단계에서 Define으로 넘어갈 때, 금지어를 정하세요. 그것은... "이거 이렇게 하면 돼" 입니다. 팀원 전체가 문제에 대한 공감과 이해가 끝나기 전의 해결책은 오직 독입니다. ☠️
2. ❌ 비판 금지: Discover와 Develop 단계는 아이디어의 '양'을 모으는 시기입니다. PM이 그건 말이 안 돼라고 비판하는 순간 팀원들의 창의성은 사라집니다. 비판은 오직 데이터 기반의 수렴 단계에서만 허용하세요
3. ❌ 단계별 검증은 MUST ! 필수! : Deliver 단계에서 사용성 테스트를 생략하는 것은 곧 로또 1등에 당첨될 확률에 프로젝트의 성공을 맡기는 것과 같습니다. 적은 인원으로라도 반드시 테스트를 진행하여 객관적인 검증 결과를 확보해야 합니다.

 

---

그래서 나보고 어뜩하라고, 엉뜨 켜라고

제가 여러분들이 실전 예시로 쓸 수 있게끔, 그냥 이 티스토리 블로그를 위해 건강 습관 형성 앱을 하나 러프하게 짜 봤습니다
 

🚀 PM 실전 예시: '건강 습관 형성 앱' 프로젝트

단계	수행 활동 (확산/수렴)	핵심 결과물 (문서화)
Discover	확산: 30대 직장인 15명 심층 인터뷰, 경쟁사 앱 5개 사용성 분석, 기존 건강 앱 사용자 로그 분석.	인사이트: 퇴근 후 피로 때문에 계획된 운동을 미루고, 미루면 다음 날도 심리적 부담감 때문에 실패함.
Define	수렴: 발견된 인사이트를 어피니티 다이어그램으로 정리하여 핵심 문제 도출.	문제 기술문: 야근이 잦은 30대 직장인은 퇴근 후 계획된 운동을 피로와 심리적 부담감 때문에 실패하는 경향이 있다.
Develop	확산: 문제 해결을 위한 아이디어 브레인스토밍: '습관 쪼개기', '퇴근길 미션', '보상 시스템' 등. 3가지 Low-Fi 프로토타입 제작.	아이디에이션 로그: '퇴근길 미션'이 가장 독창적이지만 복잡함. '습관 쪼개기'가 사용자 부담을 가장 낮춤.
Deliver	수렴: '습관 쪼개기' 프로토타입으로 사용자 5명 대상 A/B 테스트 및 사용성 테스트 진행.	UT 보고서: 습관 쪼개기 기능이 운동 시작 성공률을 30% 높임을 확인. (최종 기능 결정)

---

🌟 더블 다이아몬드 = 리스크 관리의 치트키

더블 다이아몬드는 단순히 '좋은 디자인'을 위한 틀이 아니라, 나의 야근을 줄일 뿐만 아니라 성공적인 서비스 출시를 위한 치트키라는 것입니다.... 너도 좋고, 나도 좋은! 그런 윈윈 방법론인 거죠. 그러니까 우리, 복잡하게 생각하지 말고 사용자 입장에서 문제를 먼저 깊이 들여다보는 것부터 시작해 봅시다. 그게 바로 성공하는 제품의 비밀이랍니다.
 
++ 여담으로 제가 학부생 시절 UX 강의를 들어서 과제를 제출하면 '왜'를 정말 많이 물어보셨거든요. 진짜 계속 사소한 것 하나까지 왜냐고 물어보셨슨. 그때는 그게 정말 스트레스받았는데, 이제는 그 문제 정의와 모든 사용자 경험은 'WHY'에서 시작된다는 것을 깨닫습니다....