'어떻게 하면 우리가(How Might We)' 질문의 정의와 활용

리서치가 기대만큼 성과를 내지 못하는 이유, 혹시 데이터가 부족해서라고 생각하시나요? 사실 대부분의 경우, 데이터는 충분해요. 문제는 인사이트가 아이디어로 자연스럽게 이어지지 않는다는 점이에요. 바로 이 간극을 메우기 위해 만들어진 프레임워크가 “어떻게 하면 우리가(How Might We, HMW)” 질문법이에요.

이 가이드에서는 HMW 질문법의 개념부터 실전 활용, PRD·로드맵 연결까지 전 과정을 다뤄볼게요. HMW가 무엇이고, 왜 강력한 도구인지부터 시작해서, 효과적인 질문 작성법, 실전 사례 분석, 그리고 PRD와 로드맵에 연결하는 방법까지 살펴볼게요.

1. 리서치 인사이트가 사라지는 흔한 문제

몇 주간 UX 리서치를 진행한 뒤, 팀은 보통 두 가지 문제 중 하나에 부딪혀요.

(1) 인사이트가 너무 추상적으로 남는 경우

“사용자가 불안감을 느낀다”, “온보딩이 헷갈린다” 같은 인사이트는 의미 있어 보이지만, 구체적인 행동으로 이어지기 어렵죠.

(2) 팀이 곧바로 해결책을 만드려고 뛰어드는 경우

디자이너와 PM이 서둘러 기능을 제안하기 시작해요.

“툴팁을 추가하자”
“대시보드를 새로 디자인하자”

결과적으로 근본 원인이 아닌 증상만 치료하는 솔루션이 나오게 되는 거예요.

로드맵 회의가 질문이 아닌 기능 목록으로 시작된다면, 아이디에이션 단계를 건너뛰고 있을 가능성이 높아요. 좋은 질문이 빠진 로드맵은 방향 없는 지도와 같아요.

그런데 막상 설계하거나 만들 단계가 되면, 팀은 “당연해 보이는” 솔루션으로 바로 뛰어들곤 하죠. 바로 이 지점에서 “어떻게 하면 우리가(How Might We)” 질문이 등장해요.

HMW는 단순한 UX 활동이 아니에요. 인사이트에서 잠재적 콘셉트로 넘어가는 다리 역할을 하며, 디자인 아이디에이션 과정에서 가장 실용적인 도구 중 하나이기도 하죠.

2. “어떻게 하면 우리가(How Might We)”란 정확히 뭘까?

“어떻게 하면 우리가(How Might We)” 개념은 IDEO를 비롯해 Nielsen Norman Group 등 디자인 씽킹 분야에서 폭넓게 사용되고 있어요.

핵심을 한마디로 정리하면, 인사이트를 생산적이고 창의적인 질문으로 바꾸는 구조화된 방법이에요.

각 단어에 담긴 의미를 살펴볼게요.

단어	의미
어떻게(How)	해결 방법이 존재한다고 전제해요
하면(Might)	완벽이 아닌 탐색을 권장해요
우리가(We)	개인이 아닌 팀의 협업을 강조해요

HMW는 인사이트를 확산적 사고(Divergent Thinking)를 유도하는 질문으로 재구성하면서도, 초점을 잃지 않게 해주죠. 그래서 UX 리서치와 아이디에이션 사이에 딱 맞는 위치에 놓이는 거예요.

좋은 질문은 답을 정하지 않으면서도 방향을 잡아줘요. HMW가 바로 그런 질문이에요. 팀원 모두가 같은 방향을 바라보되, 각자 다른 길을 탐색할 수 있게 만들어주는 출발점이죠.

3. “어떻게 하면 우리가?” 질문이 프로덕트 팀에 강력한 이유

HMW 질문은 팀에게 다음과 같은 효과를 가져다줘요.

문제 범위를 의도적으로 확장하거나 좁힐 수 있어요
너무 넓은 문제를 다루고 있다면 좁히고, 반대로 좁은 시야에 갇혀 있다면 넓힐 수 있어요.
여러 직군의 이해관계자를 정렬할 수 있어요
같은 질문 아래 모이면 엔지니어, 디자이너, 마케터가 같은 맥락에서 대화할 수 있어요.
솔루션 편향을 피할 수 있어요
답이 아닌 질문에서 시작하면, 열린 탐색이 가능해져요.
문제에 대한 공통 이해를 유지할 수 있어요
프로젝트가 길어져도 팀이 핵심 문제를 놓치지 않아요.

추상적인 리서치 결과를 실행 가능한 창의성으로 바꿔주는 것, 이것이 HMW의 본질이라고 할 수 있어요.

4. “어떻게 하면 우리가?” 질문으로 리프레이밍하기

초기 인사이트는 보통 이런 형태예요.

“신규 사용자가 제품을 이탈하는 이유는 첫 설정 과정이 너무 부담스럽기 때문이다.”

HMW는 여기서 한 발 멈추게 해요. 바로 솔루션으로 뛰어드는 대신, 이렇게 질문을 재구성하는 거예요.

“어떻게 하면 우리가 신규 사용자가 첫 설정 과정에서 자신감을 느끼도록 도울 수 있을까?”

무엇이 달라졌는지 살펴볼게요.

문제는 그대로 남아 있어요
설정 과정의 부담이라는 핵심은 변하지 않았어요.
솔루션 공간이 열렸어요
특정 기능에 얽매이지 않고, 다양한 방향을 탐색할 수 있어요.
팀이 여러 방향을 탐색할 수 있어요
한 가지 답이 아닌, 여러 가능성을 동시에 고려할 수 있어요.

같은 문제라도 질문을 어떻게 던지느냐에 따라 팀이 탐색하는 방향이 완전히 달라져요. 인사이트를 “문제 진술”로 끝내지 말고, “탐색 가능한 질문”으로 전환해 보세요.

5. 효과적인 “어떻게 하면 우리가?” 질문 만드는 단계

5-1) 정리된 리서치에서 시작하기

HMW는 탐색적 리서치가 끝난 후에 작동하는 도구예요. 날것의 데이터가 아닌, 정리된 인사이트에서 출발해야 하죠.

좋은 시작을 도와줄 수 있는 자료들은 다음과 같아요.

문제 정의서(Problem Statement)
핵심 인사이트
디자인 브리프(Design Brief)
정성·정량 데이터에서 발견된 패턴

인사이트가 명확하지 않으면, HMW 질문도 명확해질 수 없거든요.

요리에 비유하면, 인사이트는 손질이 끝난 재료예요. 재료가 제대로 준비되지 않으면 어떤 레시피를 써도 결과물이 좋을 수 없듯, 리서치 정리가 HMW의 품질을 결정해요.

5-2) 하나의 인사이트에서 여러 버전의 질문 만들기

하나에서 멈추지 마세요.

하나의 인사이트로부터 여러 HMW 질문을 작성해 보세요.

넓은 버전 — 사고를 확장하는 질문
좁은 버전 — 나중에 초점을 맞출 수 있는 질문

예를 들어볼게요.

버전	HMW 질문
넓은 버전	어떻게 하면 우리가 첫 사용자의 불안감을 줄일 수 있을까?
중간 버전	어떻게 하면 우리가 첫 설정 과정을 가볍게 느끼게 할 수 있을까?
좁은 버전	어떻게 하면 우리가 사용자가 처음 5분 안에 성공 경험을 하도록 도울 수 있을까?

“딱 맞는” HMW 질문은 보통 토론을 거친 뒤에 나타나요. 처음부터 완벽한 질문을 만들려고 하지 않아도 괜찮아요.

한 장의 사진을 여러 각도에서 찍어보는 것과 같아요. 같은 인사이트라도 질문의 폭을 조절하면 전혀 다른 아이디어가 나올 수 있어요.

5-3) HMW를 브레인스토밍의 출발점으로 활용하기

HMW 질문이 정해지면, 이 질문이 아이디에이션의 닻(Anchor) 역할을 해요.

HMW 기반 브레인스토밍의 규칙은 간단해요.

처음에는 양(Quantity)을 우선시해요
초반에는 판단을 유보해요
파격적인 아이디어를 적극 권장해요

모든 참여자가 같은 질문에 대해 응답하기 때문에, 아이디어가 제각각이더라도 방향은 정렬돼요. 이 지점이 디자인 아이디에이션 과정에서 HMW가 빛나는 순간이죠.

브레인스토밍이 산발적으로 흩어지는 경험, 한 번쯤 해보셨을 거예요. HMW는 “우리가 답해야 할 질문”이라는 공통의 닻을 제공해서, 자유로운 발산 속에서도 방향을 유지하게 해줘요.

5-4) 수렴하기: 아이디어 우선순위 정하고 다듬기

확산(Divergence) 다음에는 수렴(Convergence)이 와야 해요.

팀이 할 수 있는 작업은 다음과 같아요.

비슷한 아이디어를 클러스터링하기
영향력 대비 노력(Impact vs. Effort) 기준으로 순위 매기기
제약 조건(기술, 비즈니스, 일정)에 비추어 아이디어 검증하기

새로운 정보가 나타나면 HMW 질문도 업데이트하세요. 좋은 HMW는 학습과 함께 진화해요.

6. 좋은 HMW 질문 vs. 나쁜 HMW 질문

모든 HMW 질문이 같은 효과를 내는 것은 아니에요. 잘못 작성된 HMW는 솔루션으로 바로 뛰어드는 것만큼이나 제약이 될 수 있거든요.

6-1) 이렇게 쓰면 안 돼요 (나쁜 예시)

(1) 솔루션에 이미 초점이 맞춰진 경우

어떻게 하면 우리가 신규 사용자를 위한 튜토리얼 팝업을 추가할 수 있을까?

문제점	설명
솔루션을 전제함	팝업이라는 특정 방법을 이미 정해버렸어요
창의적 탐색을 차단함	다른 접근법을 고려할 여지가 없어요
아이디에이션을 너무 일찍 좁힘	다양한 가능성을 열기도 전에 닫혀버려요

(2) 너무 모호하거나 추상적인 경우

어떻게 하면 우리가 사용자 경험을 개선할 수 있을까?

문제점	설명
구체적인 사용자나 맥락이 없음	누구의 어떤 경험인지 알 수 없어요
의미 있는 브레인스토밍이 어려움	너무 넓어서 시작점을 잡기 어려워요
일반적인 아이디어만 나옴	실행 가능한 수준의 아이디어가 나오기 힘들어요

(3) 너무 광범위해서 실행이 불가능한 경우

어떻게 하면 우리가 모든 사람을 위해 제품을 더 좋게 만들 수 있을까?

문제점	설명
제약 조건이 없음	범위가 무한대여서 우선순위를 정할 수 없어요
우선순위 설정 불가	무엇부터 해야 하는지 판단할 수 없어요
불명확한 사고를 드러냄	문제를 충분히 파악하지 못했다는 신호예요

6-2) 이렇게 쓰면 좋아요 (좋은 예시)

(1) 솔루션이 아닌 결과에 초점을 맞춘 경우

어떻게 하면 우리가 첫 사용자가 설정 완료에 자신감을 느끼도록 도울 수 있을까?

장점	설명
사용자의 감정에 집중	“자신감”이라는 구체적인 결과를 명시했어요
다양한 솔루션의 여지가 있음	특정 방법을 강제하지 않아요
아이디에이션하기 쉬움	이 질문 하나로 다양한 아이디어를 이끌어낼 수 있어요

(2) 범위와 사용자가 명확한 경우

어떻게 하면 우리가 온보딩 첫 5분 동안의 불확실성을 줄일 수 있을까?

장점	설명
시간 제한이 있음	“첫 5분”이라는 구체적 맥락이 있어요
상황이 특정됨	온보딩이라는 구체적 맥락에서 출발해요
집중된 창의성을 유도함	제약 안에서 오히려 더 창의적인 아이디어가 나와요

(3) 적절한 개방성을 가진 경우

어떻게 하면 우리가 온보딩 과정에서 사용자를 안내하면서도 부담을 주지 않을 수 있을까?

장점	설명
긴장(Tension)이 명시적	“안내”와 “부담 방지”라는 상충 요소가 드러나 있어요
트레이드오프가 보임	양쪽을 동시에 고려해야 한다는 점이 분명해요
더 풍부한 논의로 이어짐	단순한 답이 아닌, 깊이 있는 토론을 유도해요

좋은 HMW 질문의 공통점은 “답을 하나로 정하지 않으면서도, 팀이 같은 방향을 보게 만든다”는 거예요. 범위가 너무 넓지도, 너무 좁지도 않은 그 사이 어딘가를 찾는 연습이 필요해요.

7. 바로 쓸 수 있는 HMW 템플릿

HMW 질문을 처음 작성할 때 막막하다면, 구조화된 템플릿이 도움이 돼요.

7-1) 기본 템플릿

어떻게 하면 우리가 [특정 사용자]가 [원하는 결과]를 [특정 맥락]에서 [핵심 제약 조건] 없이 달성하도록 도울 수 있을까?

예시:

어떻게 하면 우리가 신규 사용자가 첫 세션에서 성공적인 초기 설정을 부담감 없이 달성하도록 도울 수 있을까?

이 템플릿은 다음을 강제해요.

명확성 — 누구를 위한 것인지, 무엇을 달성해야 하는지 분명해져요
트레이드오프의 명시 — “~없이” 부분이 핵심 제약을 드러내요
솔루션 편향 방지 — 방법이 아닌 결과에 집중하게 돼요

7-2) 간소화 템플릿 (빠른 워크숍용)

빠르게 진행하는 세션에서는 이 템플릿을 활용하세요.

어떻게 하면 우리가 [사용자]가 [상황]에서 [행동 또는 결과]를 할 수 있게 만들까?

예시:

어떻게 하면 우리가 신규 사용자가 제품을 처음 열었을 때 자신감을 느낄 수 있게 만들까?

템플릿은 보조 바퀴 같은 거예요. 처음에는 템플릿을 채우는 것만으로도 훨씬 구조적인 질문이 나와요. 익숙해지면 자연스럽게 자기만의 스타일이 생기게 돼요.

8. “어떻게 하면 우리가?” 질문을 잘못 이해하면 발생하는 함정

8-1) HMW 질문을 너무 일찍 확정하는 경우

초기 HMW 질문은 탐색적(exporative)이어야 해요. 최종 확정본이 아니거든요.

고정된 HMW는 다음을 놓치게 만들어요.

새로 발견된 리서치 결과
중간에 드러나는 제약 조건
예상하지 못한 인사이트

해결법: HMW 질문은 학습이 진행됨에 따라 계속 다시 방문하고 발전시키세요.

첫 번째 초안에 집착하는 건 지도를 한 번 그려놓고 새로운 길이 생겨도 업데이트하지 않는 것과 같아요. 리서치가 진행될수록 더 나은 질문이 보이기 마련이에요.

8-2) 이미 정해진 솔루션을 정당화하기 위해 HMW를 사용하는 경우

미묘하지만 위험한 함정이에요. 팀이 이미 “정답”을 알고 있다면, HMW는 형식적인 절차에 불과해지죠.

해결법: 아이디에이션이 억지스럽게 느껴진다면, 멈추고 점검해 보세요.

진짜 다른 대안에 열려 있는가?
아니면 이미 내린 결정을 확인하려는 건 아닌가?

이미 결론을 내려놓고 질문을 던지는 건, 정해진 답을 맞추는 퀴즈를 내는 것과 다르지 않아요. HMW의 힘은 “무엇이 나올지 모른다”는 열린 자세에서 나와요.

8-3) 아이디에이션 후 수렴 단계를 건너뛰는 경우

HMW는 확산적 사고를 가능하게 해주지만, PM은 반드시 수렴을 이끌어야 해요.

수렴 없이 진행하면 이런 일이 벌어져요.

브레인스토밍은 재미있었는데 결과가 없음
팀이 프로세스 자체에 대한 신뢰를 잃음

해결법: 항상 다음을 미리 계획하세요.

아이디어를 어떤 기준으로 묶을지
의사결정을 어떻게 내릴지
인사이트를 로드맵의 어떤 항목에 연결할지

발산만 있고 수렴이 없는 브레인스토밍은 산책은 즐겼지만 목적지에 도착하지 못한 여행과 같아요. 아이디어를 모으는 것만큼, 정리하고 선택하는 과정이 중요해요.

9. 실전 사례: B2B CRM 제품에서 질문을 단계별로 구체화하기

이론만으로는 감이 잘 안 올 수 있어요. 실제 제품 상황을 예시로, HMW 질문을 점진적으로 좁혀가는 과정을 살펴볼게요.

제품 배경

항목	내용
제품	B2B SaaS CRM 도구
타겟 사용자	소규모 비즈니스 오너
핵심 순간	가입 후 첫 로그인
관찰된 문제	다수의 사용자가 첫 연락처를 생성하지 않고 이탈

1단계: 초기 리서치 인사이트 정리

사용자 인터뷰와 퍼널 데이터에서 다음 인사이트를 얻었어요.

“신규 사용자가 로그인 후 무엇을 해야 할지 몰라서 제품을 떠난다. 빈 대시보드 앞에서 머뭇거리다가 연락처를 추가하지 않고 이탈한다.”

이 인사이트는 더 이상 추상적이지 않아요. 다음을 알 수 있거든요.

어디서 발생하는지 — 빈 대시보드
무엇이 일어나지 않는지 — 첫 연락처 추가
언제 발생하는지 — 첫 로그인 시점

2단계: 넓은 HMW 질문 설정

어떻게 하면 우리가 CRM 사용자의 온보딩을 개선할 수 있을까?

이 질문은 인사이트와 관련이 있긴 하지만, 실전에서는 거의 쓸모가 없어요. 팀이 튜토리얼부터 이메일까지 모든 방향을 브레인스토밍하게 될 거예요. 많은 팀이 이 수준에서 멈추는데, 여기서 멈추면 안 돼요.

3단계: 약간 나아졌지만 아직 넓은 질문

어떻게 하면 우리가 신규 사용자가 CRM을 시작하는 걸 도울 수 있을까?

조금 나아졌지만, 여전히 모호해요.

“시작한다”는 말이 사람마다 다르게 해석될 수 있어요
명확한 성공 기준이 없어요
아이디어가 여전히 분산될 거예요

4단계: 구체적인 사용자 행동에 기반한 질문

관찰된 행동 데이터를 활용해서 질문을 날카롭게 만들어 볼게요.

어떻게 하면 우리가 신규 사용자가 첫 연락처를 추가하도록 도울 수 있을까?

여기서 크게 개선됐어요.

개선 포인트	설명
명확한 행동	“연락처 추가”라는 구체적 액션이 있어요
이탈 지점과 직접 연결	퍼널 데이터에서 발견한 문제와 맞닿아 있어요
측정이 쉬움	성공 여부를 데이터로 확인할 수 있어요

그런데 아직 맥락이 부족해요.

5단계: 핵심 순간 추가

언제 문제가 발생하는지를 명시해 볼게요.

어떻게 하면 우리가 신규 사용자가 첫 로그인 시 첫 연락처를 추가하도록 도울 수 있을까?

이제 팀은 다음을 알게 돼요.

어떤 세션이 중요한지 — 첫 로그인
“성공”이 무엇인지 — 연락처 추가 완료
고민하지 않아도 되는 것 — 이후 사용 단계

6단계: 진짜 중요한 맥락을 드러내기

사용자 인터뷰에서 이런 피드백이 나왔어요.

“이 도구가 쓸 만한지도 모르는데, 먼저 설정을 하라고요?”

이 긴장 관계를 HMW에 반영해야 해요.

날카로운 HMW: 어떻게 하면 우리가 신규 사용자가 시스템 설정 없이도 첫 로그인에서 첫 연락처를 추가하도록 도울 수 있을까?

이 질문이 강력한 이유는 다음과 같아요.

복잡한 초기 설정을 배제해요
CRM의 기본 패턴에 도전해요 — 대부분의 CRM은 설정부터 요구하거든요
창의적인 대안을 유도해요

7단계: HMW을 실행할 수 있는 수준으로 발전시키기

디자인과 엔지니어링 탐색을 위한 질문으로 한 단계 더 가볼게요.

어떻게 하면 우리가 사용자가 빈 대시보드에서 60초 안에, 사전 설정 없이 연락처를 추가할 수 있게 만들까?

이 시점에서는 다음이 가능해요.

엔지니어가 기술적 실현 가능성에 대해 반응할 수 있어요
디자이너가 프로토타입을 만들 수 있어요
PM이 성공 지표를 정의할 수 있어요

이 HMW 질문은 이제 PRD로 자연스럽게 이어질 수 있어요.

왜 이 구체화 과정이 중요한가

처음부터 마지막까지의 변화를 비교해 볼게요.

단계	HMW 질문	평가
2단계	온보딩을 개선하자	❌ 너무 넓음
7단계	빈 대시보드에서 60초 안에, 설정 없이 연락처 추가	✅ 실행 가능

이것이 바로 다음의 차이예요.

문제에 대해 이야기하는 것
문제를 해결할 준비가 되는 것

질문을 구체화하는 과정은 렌즈의 초점을 맞추는 것과 비슷해요. 처음에는 흐릿하던 풍경이, 초점이 맞춰지면 나뭇잎 하나하나까지 선명하게 보이죠. HMW도 마찬가지로, 점진적으로 좁혀갈수록 팀이 무엇을 해야 하는지가 선명해져요.

10. “어떻게 하면 우리가?” 질문에서 PRD, 그리고 로드맵까지

HMW에 대한 가장 큰 오해 중 하나는 “디자인 팀만 쓰는 활동”이라는 거예요. 실제로 HMW가 진짜 힘을 발휘하는 건, PM이 이를 실행으로 연결할 때예요.

그 과정을 단계별로 살펴볼게요.

1) PRD 작성 전, HMW를 문제의 기준점으로 삼기

PRD를 작성하기 전에 PM은 보통 다음 중 하나에서 출발해요.

기능 아이디어
이해관계자의 요청
경쟁사와의 격차

그런데 이런 출발점은 위험할 수 있어요. 솔루션에서 시작하면 문제를 건너뛰기 쉽거든요.

대신 HMW 질문을 문제에 대한 유일한 기준점(Single Source of Truth)으로 삼아보세요.

HMW 예시:

어떻게 하면 우리가 신규 사용자가 첫 세션에서 부담 없이 온보딩을 완료하도록 도울 수 있을까?

이 HMW 하나로 다음이 정의돼요.

사용자가 누구인지 — 신규 사용자
성공이 무엇인지 — 온보딩 완료
감정적 제약 — 부담을 주지 않기

PRD에 담기는 모든 내용은 이 질문으로 다시 추적 가능해야 해요.

집을 지을 때 기초 공사가 중요한 것처럼, PRD의 기초가 되는 것이 HMW 질문이에요. 기초가 흔들리면 그 위에 무엇을 쌓아도 불안정해지듯, 명확한 HMW 없이 쓴 PRD는 방향을 잃기 쉬워요.

2) HMW를 PRD의 입력 자료로 변환하기

HMW가 곧바로 기능 명세로 바뀌어서는 안 돼요. 대신 PRD의 기초 자료를 만드는 데 활용하세요.

구체적인 매핑 방법은 다음과 같아요.

(1) 문제 정의(Problem Statement)

HMW에서 간결한 문제 진술을 도출해요.

신규 사용자가 인지적 과부하로 인해 온보딩을 완료하지 못하고, 초기 이탈이 발생하고 있다.

HMW의 _의도_를 유지하면서도 솔루션을 고정하지 않는 게 핵심이에요.

(2) 목표와 성공 지표

이런 질문을 던져보세요: “이 HMW 질문에 성공적으로 답했다면, 무엇이 바뀔까?”

예를 들면 다음과 같아요.

지표 유형	예시
정량 지표	온보딩 완료율 증가
시간 지표	첫 성공까지의 소요 시간 단축
정성 지표	첫 세션 자신감 향상 (사용자 피드백)

이 지표들이 PRD의 성공 기준이 돼요.

(3) 제약 조건과 원칙

HMW에서 “~없이” 조건을 붙이는 부분은 PM에게 특히 유용해요.

온보딩 시간을 늘리지 않으면서
화면 수를 추가하지 않으면서
사람의 도움에 의존하지 않으면서

이런 조건들이 디자인과 엔지니어링의 가드레일이 돼요.

제약 조건은 제한이 아니라 방향이에요. “~없이”라는 조건이 명확할수록, 팀은 무엇을 하면 안 되는지를 알게 되고, 결과적으로 더 창의적인 범위 안에서 솔루션을 찾게 돼요.

3) 아이디에이션 결과를 PRD의 선택지로 활용하기

브레인스토밍이 끝난 후, 즉시 하나의 아이디어를 선택하고 싶은 충동을 참으세요.

대신 다음을 해보세요.

아이디어를 접근 방식 단위로 묶기 (예: 안내, 단순화, 점진적 공개)
테마를 식별하기
각 접근 방식의 트레이드오프 분석하기

PRD에는 이렇게 반영하세요.

탐색한 접근 방식 목록
각 접근 방식의 트레이드오프
선택한 방향과 그 근거

이렇게 하면 다음을 얻을 수 있어요.

효과	설명
더 강한 정렬	팀 전체가 왜 이 방향인지 이해해요
이해관계자 신뢰	충분히 검토했다는 증거가 돼요
명확한 의사결정 이력	나중에 “왜 이 방향이었지?”라는 질문에 답할 수 있어요

아이디어 하나를 고르는 건 쇼핑과 비슷해요. 첫눈에 끌린 물건을 바로 사는 것보다, 몇 가지를 비교해 보고 고른 선택이 후회가 적죠. PRD도 마찬가지로, 여러 접근 방식을 비교한 흔적이 있어야 설득력이 생겨요.

4) PRD에서 로드맵으로 연결하기

로드맵에 “솔루션”을 나열하는 건 좋은 방법이 아니에요. 로드맵은 사용자 문제에 대한 베팅(Bet)을 소통하는 도구여야 하거든요.

HMW는 바로 이 관점을 가능하게 해줘요.

나쁜 로드맵 항목:

“온보딩 플로우 재설계”

좋은 로드맵 항목 (HMW 기반):

“첫 세션 사용자 자신감 및 온보딩 완료율 개선”

실제 내부에서는 다음과 같은 유연성이 생겨요.

구체적인 솔루션은 변경될 수 있어요
범위도 조정될 수 있어요
하지만 문제는 안정적으로 유지돼요

이런 로드맵은 다음과 같은 장점이 있어요.

변화에 탄력적 — 솔루션이 바뀌어도 방향은 유지돼요
커뮤니케이션이 쉬움 — 비기술 이해관계자도 이해할 수 있어요
결과 중심 정렬 — 기능이 아닌 성과로 대화해요

HMW 기반의 로드맵은 기능 기반 로드맵보다 오래 살아남아요. 기능은 바뀌지만 문제는 쉽게 바뀌지 않으니까요.

5) HMW를 “아니오”라고 말하는 기준으로 활용하기

“아니오”라고 말하는 것은 피할 수 없는 일이에요. HMW는 이때 중립적인 기준점이 돼줘요.

새로운 요청이 들어왔을 때 이렇게 질문해 보세요.

“이 요청이 우리의 HMW 질문에 답하는 데 어떻게 도움이 되는가?”
“이 요청은 어떤 HMW를 뒷받침하는가?”

명확한 연결이 없다면, 우선순위를 낮추는 결정이 쉬워지고 개인적인 감정이 덜 개입되죠.

“아니오”라고 말하기 어려운 이유는 대부분 기준이 없어서예요. HMW라는 공통 기준이 있으면, “이건 우리 질문에 답하는 일이 아니다”라고 말할 수 있게 돼요. 거절이 아닌 정렬의 문제로 바뀌는 거죠.

11. PM을 위한 간결한 멘탈 모델

전체 흐름을 하나의 모델로 정리하면 이렇게 볼 수 있어요.

+---------------------------+
|  "어떻게 하면 우리가?"    |  →  올바른 질문을 정의
|  (HMW)                    |
+---------------------------+
            ↓
+---------------------------+
|  PRD                      |  →  가능한 답을 탐색
+---------------------------+
            ↓
+---------------------------+
|  로드맵                   |  →  다음에 답할 질문을 결정
+---------------------------+

이 모델을 따르면 팀은 다음을 유지할 수 있어요.

사용자 중심 — 기능이 아닌 사용자 문제에서 출발해요
결과 지향 — 산출물이 아닌 성과를 추구해요
직군 간 정렬 — 디자인, 엔지니어링, 비즈니스가 같은 질문 아래 모여요

12. 마무리: 좋은 프로덕트팀은 기능이 아닌 질문을 관리한다

훌륭한 프로덕트팀은 단순히 기능을 배포하지 않아요. 아이디어가 실행으로 옮겨지는 과정에서 명확성을 유지하는 팀이죠.

아이디에이션에 들어가기 전에, 데이터와 리서치 결과가 아직 정리되지 않은 상태라면 혼자가 아니에요. 정리되지 않은 입력값을 가지고 바로 아이디에이션에 뛰어들면 다음과 같은 문제가 생길 수 있어요.

아이디어는 많은데 공유된 이해가 없음
팀원마다 신호를 다르게 해석함
진짜 사용자 문제를 놓치는 솔루션

HMW 질문이나 브레인스토밍 세션에 들어가기 전에, 먼저 증거를 구조화하고 팀이 실제로 무슨 일이 일어나고 있는지에 대해 합의하는 것이 도움이 될 수 있어요.

“어떻게 하면 우리가?”라는 세 단어가, 팀의 시선을 솔루션에서 문제로, 개인에서 협업으로, 완벽에서 탐색으로 전환시켜 줘요. 단순한 질문법이지만, 이 전환이 만들어내는 차이는 결코 단순하지 않아요.

이 가이드가 도움이 되셨다면, 정리되지 않은 리서치 데이터를 구조화하는 방법이 궁금하실 수 있어요. KJ 기법(KJ Technique) 가이드에서 지저분한 입력값을 명확한 의사결정으로 전환하는 방법을 확인해 보세요.

[HMW] ‘어떻게 하면 우리가(How Might We)’ 질문의 정의와 활용