PRODUCT
고객 인터뷰, 원하는 기능보다 최근 경험을 물어보세요
고객 인터뷰, 원하는 기능보다 최근 경험을 물어보세요
새 기능이 좋겠다는 답만으로 실제 사용을 예상하기는 어렵습니다. 최근 경험과 현재의 대처 방법을 묻는 질문을 만들고, 참여자의 발언과 팀의 해석을 나눠 다음 검증으로 연결하는 방법을 살펴봅니다.
새 기능이 좋겠다는 답만으로 실제 사용을 예상하기는 어렵습니다. 최근 경험과 현재의 대처 방법을 묻는 질문을 만들고, 참여자의 발언과 팀의 해석을 나눠 다음 검증으로 연결하는 방법을 살펴봅니다.
기능에 대한 호감과 실제 사용은 다를 수 있습니다
고객에게 새 기능을 설명했더니 좋겠다는 답이 돌아옵니다. 팀은 안심하고 개발을 시작합니다. 그런데 출시 뒤에는 기대만큼 쓰이지 않습니다. 인터뷰에서 얻은 호감을 실제 사용 의사로 받아들인 것은 아닌지 살펴볼 필요가 있습니다.
고객 인터뷰에서는 사람이 겪은 문제와 당시의 판단을 듣습니다. 미래에 무엇을 쓸지 묻는 질문만으로는 그 기능이 일상에 들어갈 이유를 알기 어렵습니다. 어떤 상황에서 막혔고 지금은 어떻게 처리하는지부터 확인해야 다음에 검증할 해결안을 정할 수 있습니다.
가상의 회의실 예약 서비스를 준비한다고 해보겠습니다. 팀은 예약을 잊는 문제를 줄이려고 알림 기능을 생각합니다. 바로 기능을 소개하기 전에 최근 예약을 직접 맡은 사람을 만나 예약부터 회의 당일까지 무슨 일이 있었는지 듣습니다. 아래 질문과 기록은 이 가상 상황을 설명하기 위한 예시입니다.
인터뷰에서 들은 경험과 직접 관찰한 행동도 구분해야 합니다. 참여자가 기억해서 설명한 예약 과정은 자기보고 자료입니다. 실제 화면에서 예약을 수행하는 모습을 보거나 당시 기록을 확인한 것과 같은 증거로 취급하지 않습니다. 인터뷰만으로 수요와 전환율, 결제 의사까지 검증됐다고 결론 내려서도 안 됩니다. NN/G 사용자 인터뷰 안내
질문 목록보다 이번에 알아낼 것을 먼저 정합니다
조사 목표를 실제 업무에 연결합니다
알림 기능이 필요한지 알아본다는 목표로 시작하면 질문도 알림의 장점을 확인하는 쪽으로 흐르기 쉽습니다. 회의실 예약 후 어떤 일을 잊거나 다시 확인하는지 알아본다고 정하면 기능을 전제로 삼지 않고 경험을 들을 여지가 생깁니다.
참여자 조건도 목표에 맞춥니다. 서비스를 좋아할 것 같은 사람보다 최근 회의실을 예약한 경험이 있고 실제로 예약이나 일정 조율을 맡는 사람이 이번 조사에 적합합니다. 예약 신청자와 승인 담당자는 보는 문제가 다를 수 있으므로 어떤 업무를 조사할지도 정합니다.
준비한 질문 옆에 무엇을 알아내려는 질문인지 적어보세요.
예약을 시작한 계기: 어떤 업무 때문에 회의실이 필요했는가?
예약 과정: 어디에서 무엇을 확인하고 선택했는가?
예약 이후: 누구에게 알렸고 어떤 일을 다시 처리했는가?
기존 대처: 문제가 생겼을 때 어떤 방법을 썼는가?
질문지를 순서대로 읽는 데 집중하면 뜻밖의 단서를 놓칠 수 있습니다. 조사 목표를 유지하되 참여자가 구체적인 일을 꺼내면 그 경험을 따라 후속 질문을 합니다. NN/G 인터뷰 가이드 작성 안내
자료를 함께 볼 때는 먼저 동의를 구합니다
예약 화면이나 당시 메시지를 함께 보면 기억을 구체화하는 데 도움이 될 수 있습니다. 공유를 강요하지 않고 무엇을 확인하려는지 설명한 뒤 동의를 구합니다. 이름, 연락처, 다른 사람의 일정과 회사 기밀은 가리도록 안내합니다. 녹음이나 화면 저장도 별도로 허락받고 동의한 범위에서만 진행합니다.
막연한 답이 나오면 최근 한 번의 경험으로 돌아갑니다
기능을 제안하는 질문을 경험 질문으로 바꿉니다
“알림 기능이 있으면 쓰실 건가요?”에는 어떤 상황의 알림인지, 현재 무엇이 불편한지 빠져 있습니다. 참여자는 기능이 유용해 보인다는 인상을 말할 수 있지만 실제로 사용할지는 여전히 알 수 없습니다.
“가장 최근 회의실 예약 과정을 말씀해 주세요”로 시작해 보세요. 대답에서 중요한 사건이 나오면 “그때 무엇을 확인했나요?”, “예약을 마친 뒤 어떻게 진행됐나요?”처럼 이어갑니다. 문제가 있었다고 먼저 정해두지 않고 순서를 듣습니다.
“예약을 자꾸 잊어서 불편하시죠?”처럼 원인과 감정을 질문에 넣으면 답을 유도할 수 있습니다. “예약 후 다시 확인한 일이 있었나요?”라고 묻고 있었다면 어떤 일이었는지 듣는 편이 낫습니다. 문제가 없었다는 답도 남깁니다. NN/G 유도 질문 안내
지금 쓰는 대처 방법을 묻습니다
참여자가 예약 후 팀 채팅방에 일정을 다시 적었다고 설명했다면 그 이유를 묻습니다. 회의실을 잊지 않으려는 행동일 수도 있지만 다른 참석자에게 장소를 알려주려는 목적일 수도 있습니다. 같은 행동에도 서로 다른 이유가 있으므로 알림 기능이 답이라고 바로 정하지 않습니다.
후속 질문은 해결안을 제시하기보다 빠진 맥락을 채우는 데 씁니다.
그 방법을 선택한 이유는 무엇인가요?
그때 함께 확인한 사람이나 자료가 있었나요?
다시 처리한 일이 있다면 어떻게 마무리했나요?
참여자의 설명만 들었다면 설명으로 기록합니다. 인터뷰 중 예약 과정을 직접 보여줬다면 그때 관찰한 행동을 따로 적습니다. 보여주기 위해 수행한 과정과 과거 일상에서 한 행동에도 차이가 있을 수 있습니다.
원발언과 팀의 해석, 다음 검증을 따로 남깁니다
인터뷰가 끝나면 인상적인 한마디를 기능 목록으로 옮기기 전에 기록을 나눠봅니다. 원발언에는 실제로 한 말을 보존하고 요약했다면 요약이라고 표시합니다. 팀의 해석에는 그 말에서 어떤 문제를 추정했는지 적습니다. 후속 검증에는 아직 모르는 점과 확인할 방법을 남깁니다.
가상 사례에서 참여자가 예약 정보를 채팅방에 다시 공유했다고 말했다면 팀은 참석자에게 장소를 전달하는 과정이 번거로울 수 있다고 해석할 수 있습니다. 하지만 예약을 잊는 문제가 크다는 결론까지 뒷받침하지는 않습니다. 다른 예약 담당자도 같은 과정을 거치는지 확인하거나 공유 동선을 직접 관찰하는 검증을 이어갈 수 있습니다.
여러 인터뷰에서 비슷한 이야기가 나와도 얼마나 많은 고객에게 해당하는지는 별도 확인이 필요합니다. 해결안의 사용 여부는 프로토타입 과업이나 실제 사용 실험으로 살펴보고 결제 의사는 그에 맞는 후속 검증을 설계합니다. 인터뷰에서 다루지 못한 질문을 분명히 남겨두는 편이 다음 판단에 도움이 됩니다.
고객의 기능 요청은 조사할 단서로 보관하되 요청이 나온 상황과 기존 대처를 함께 읽어보세요. 기능 이름만 쌓인 목록보다 어떤 일을 해결하려는지 설명된 기록으로 팀이 다음 작업을 논의하기 쉬워집니다.
4PS와 새 서비스를 준비한다면 만들고 싶은 기능과 함께 아직 확신하기 어려운 가정도 알려주세요. 조사 목표와 참여자 조건, 인터뷰 질문을 정리하고 들은 경험을 후속 검증과 제품 범위로 연결하는 과정을 함께 설계하겠습니다.
Latest Blogs
PRODUCT
고객 인터뷰, 원하는 기능보다 최근 경험을 물어보세요
고객 인터뷰, 원하는 기능보다 최근 경험을 물어보세요
새 기능이 좋겠다는 답만으로 실제 사용을 예상하기는 어렵습니다. 최근 경험과 현재의 대처 방법을 묻는 질문을 만들고, 참여자의 발언과 팀의 해석을 나눠 다음 검증으로 연결하는 방법을 살펴봅니다.
새 기능이 좋겠다는 답만으로 실제 사용을 예상하기는 어렵습니다. 최근 경험과 현재의 대처 방법을 묻는 질문을 만들고, 참여자의 발언과 팀의 해석을 나눠 다음 검증으로 연결하는 방법을 살펴봅니다.
기능에 대한 호감과 실제 사용은 다를 수 있습니다
고객에게 새 기능을 설명했더니 좋겠다는 답이 돌아옵니다. 팀은 안심하고 개발을 시작합니다. 그런데 출시 뒤에는 기대만큼 쓰이지 않습니다. 인터뷰에서 얻은 호감을 실제 사용 의사로 받아들인 것은 아닌지 살펴볼 필요가 있습니다.
고객 인터뷰에서는 사람이 겪은 문제와 당시의 판단을 듣습니다. 미래에 무엇을 쓸지 묻는 질문만으로는 그 기능이 일상에 들어갈 이유를 알기 어렵습니다. 어떤 상황에서 막혔고 지금은 어떻게 처리하는지부터 확인해야 다음에 검증할 해결안을 정할 수 있습니다.
가상의 회의실 예약 서비스를 준비한다고 해보겠습니다. 팀은 예약을 잊는 문제를 줄이려고 알림 기능을 생각합니다. 바로 기능을 소개하기 전에 최근 예약을 직접 맡은 사람을 만나 예약부터 회의 당일까지 무슨 일이 있었는지 듣습니다. 아래 질문과 기록은 이 가상 상황을 설명하기 위한 예시입니다.
인터뷰에서 들은 경험과 직접 관찰한 행동도 구분해야 합니다. 참여자가 기억해서 설명한 예약 과정은 자기보고 자료입니다. 실제 화면에서 예약을 수행하는 모습을 보거나 당시 기록을 확인한 것과 같은 증거로 취급하지 않습니다. 인터뷰만으로 수요와 전환율, 결제 의사까지 검증됐다고 결론 내려서도 안 됩니다. NN/G 사용자 인터뷰 안내
질문 목록보다 이번에 알아낼 것을 먼저 정합니다
조사 목표를 실제 업무에 연결합니다
알림 기능이 필요한지 알아본다는 목표로 시작하면 질문도 알림의 장점을 확인하는 쪽으로 흐르기 쉽습니다. 회의실 예약 후 어떤 일을 잊거나 다시 확인하는지 알아본다고 정하면 기능을 전제로 삼지 않고 경험을 들을 여지가 생깁니다.
참여자 조건도 목표에 맞춥니다. 서비스를 좋아할 것 같은 사람보다 최근 회의실을 예약한 경험이 있고 실제로 예약이나 일정 조율을 맡는 사람이 이번 조사에 적합합니다. 예약 신청자와 승인 담당자는 보는 문제가 다를 수 있으므로 어떤 업무를 조사할지도 정합니다.
준비한 질문 옆에 무엇을 알아내려는 질문인지 적어보세요.
예약을 시작한 계기: 어떤 업무 때문에 회의실이 필요했는가?
예약 과정: 어디에서 무엇을 확인하고 선택했는가?
예약 이후: 누구에게 알렸고 어떤 일을 다시 처리했는가?
기존 대처: 문제가 생겼을 때 어떤 방법을 썼는가?
질문지를 순서대로 읽는 데 집중하면 뜻밖의 단서를 놓칠 수 있습니다. 조사 목표를 유지하되 참여자가 구체적인 일을 꺼내면 그 경험을 따라 후속 질문을 합니다. NN/G 인터뷰 가이드 작성 안내
자료를 함께 볼 때는 먼저 동의를 구합니다
예약 화면이나 당시 메시지를 함께 보면 기억을 구체화하는 데 도움이 될 수 있습니다. 공유를 강요하지 않고 무엇을 확인하려는지 설명한 뒤 동의를 구합니다. 이름, 연락처, 다른 사람의 일정과 회사 기밀은 가리도록 안내합니다. 녹음이나 화면 저장도 별도로 허락받고 동의한 범위에서만 진행합니다.
막연한 답이 나오면 최근 한 번의 경험으로 돌아갑니다
기능을 제안하는 질문을 경험 질문으로 바꿉니다
“알림 기능이 있으면 쓰실 건가요?”에는 어떤 상황의 알림인지, 현재 무엇이 불편한지 빠져 있습니다. 참여자는 기능이 유용해 보인다는 인상을 말할 수 있지만 실제로 사용할지는 여전히 알 수 없습니다.
“가장 최근 회의실 예약 과정을 말씀해 주세요”로 시작해 보세요. 대답에서 중요한 사건이 나오면 “그때 무엇을 확인했나요?”, “예약을 마친 뒤 어떻게 진행됐나요?”처럼 이어갑니다. 문제가 있었다고 먼저 정해두지 않고 순서를 듣습니다.
“예약을 자꾸 잊어서 불편하시죠?”처럼 원인과 감정을 질문에 넣으면 답을 유도할 수 있습니다. “예약 후 다시 확인한 일이 있었나요?”라고 묻고 있었다면 어떤 일이었는지 듣는 편이 낫습니다. 문제가 없었다는 답도 남깁니다. NN/G 유도 질문 안내
지금 쓰는 대처 방법을 묻습니다
참여자가 예약 후 팀 채팅방에 일정을 다시 적었다고 설명했다면 그 이유를 묻습니다. 회의실을 잊지 않으려는 행동일 수도 있지만 다른 참석자에게 장소를 알려주려는 목적일 수도 있습니다. 같은 행동에도 서로 다른 이유가 있으므로 알림 기능이 답이라고 바로 정하지 않습니다.
후속 질문은 해결안을 제시하기보다 빠진 맥락을 채우는 데 씁니다.
그 방법을 선택한 이유는 무엇인가요?
그때 함께 확인한 사람이나 자료가 있었나요?
다시 처리한 일이 있다면 어떻게 마무리했나요?
참여자의 설명만 들었다면 설명으로 기록합니다. 인터뷰 중 예약 과정을 직접 보여줬다면 그때 관찰한 행동을 따로 적습니다. 보여주기 위해 수행한 과정과 과거 일상에서 한 행동에도 차이가 있을 수 있습니다.
원발언과 팀의 해석, 다음 검증을 따로 남깁니다
인터뷰가 끝나면 인상적인 한마디를 기능 목록으로 옮기기 전에 기록을 나눠봅니다. 원발언에는 실제로 한 말을 보존하고 요약했다면 요약이라고 표시합니다. 팀의 해석에는 그 말에서 어떤 문제를 추정했는지 적습니다. 후속 검증에는 아직 모르는 점과 확인할 방법을 남깁니다.
가상 사례에서 참여자가 예약 정보를 채팅방에 다시 공유했다고 말했다면 팀은 참석자에게 장소를 전달하는 과정이 번거로울 수 있다고 해석할 수 있습니다. 하지만 예약을 잊는 문제가 크다는 결론까지 뒷받침하지는 않습니다. 다른 예약 담당자도 같은 과정을 거치는지 확인하거나 공유 동선을 직접 관찰하는 검증을 이어갈 수 있습니다.
여러 인터뷰에서 비슷한 이야기가 나와도 얼마나 많은 고객에게 해당하는지는 별도 확인이 필요합니다. 해결안의 사용 여부는 프로토타입 과업이나 실제 사용 실험으로 살펴보고 결제 의사는 그에 맞는 후속 검증을 설계합니다. 인터뷰에서 다루지 못한 질문을 분명히 남겨두는 편이 다음 판단에 도움이 됩니다.
고객의 기능 요청은 조사할 단서로 보관하되 요청이 나온 상황과 기존 대처를 함께 읽어보세요. 기능 이름만 쌓인 목록보다 어떤 일을 해결하려는지 설명된 기록으로 팀이 다음 작업을 논의하기 쉬워집니다.
4PS와 새 서비스를 준비한다면 만들고 싶은 기능과 함께 아직 확신하기 어려운 가정도 알려주세요. 조사 목표와 참여자 조건, 인터뷰 질문을 정리하고 들은 경험을 후속 검증과 제품 범위로 연결하는 과정을 함께 설계하겠습니다.
Latest Blogs
PRODUCT
고객 인터뷰, 원하는 기능보다 최근 경험을 물어보세요
고객 인터뷰, 원하는 기능보다 최근 경험을 물어보세요
새 기능이 좋겠다는 답만으로 실제 사용을 예상하기는 어렵습니다. 최근 경험과 현재의 대처 방법을 묻는 질문을 만들고, 참여자의 발언과 팀의 해석을 나눠 다음 검증으로 연결하는 방법을 살펴봅니다.
새 기능이 좋겠다는 답만으로 실제 사용을 예상하기는 어렵습니다. 최근 경험과 현재의 대처 방법을 묻는 질문을 만들고, 참여자의 발언과 팀의 해석을 나눠 다음 검증으로 연결하는 방법을 살펴봅니다.
기능에 대한 호감과 실제 사용은 다를 수 있습니다
고객에게 새 기능을 설명했더니 좋겠다는 답이 돌아옵니다. 팀은 안심하고 개발을 시작합니다. 그런데 출시 뒤에는 기대만큼 쓰이지 않습니다. 인터뷰에서 얻은 호감을 실제 사용 의사로 받아들인 것은 아닌지 살펴볼 필요가 있습니다.
고객 인터뷰에서는 사람이 겪은 문제와 당시의 판단을 듣습니다. 미래에 무엇을 쓸지 묻는 질문만으로는 그 기능이 일상에 들어갈 이유를 알기 어렵습니다. 어떤 상황에서 막혔고 지금은 어떻게 처리하는지부터 확인해야 다음에 검증할 해결안을 정할 수 있습니다.
가상의 회의실 예약 서비스를 준비한다고 해보겠습니다. 팀은 예약을 잊는 문제를 줄이려고 알림 기능을 생각합니다. 바로 기능을 소개하기 전에 최근 예약을 직접 맡은 사람을 만나 예약부터 회의 당일까지 무슨 일이 있었는지 듣습니다. 아래 질문과 기록은 이 가상 상황을 설명하기 위한 예시입니다.
인터뷰에서 들은 경험과 직접 관찰한 행동도 구분해야 합니다. 참여자가 기억해서 설명한 예약 과정은 자기보고 자료입니다. 실제 화면에서 예약을 수행하는 모습을 보거나 당시 기록을 확인한 것과 같은 증거로 취급하지 않습니다. 인터뷰만으로 수요와 전환율, 결제 의사까지 검증됐다고 결론 내려서도 안 됩니다. NN/G 사용자 인터뷰 안내
질문 목록보다 이번에 알아낼 것을 먼저 정합니다
조사 목표를 실제 업무에 연결합니다
알림 기능이 필요한지 알아본다는 목표로 시작하면 질문도 알림의 장점을 확인하는 쪽으로 흐르기 쉽습니다. 회의실 예약 후 어떤 일을 잊거나 다시 확인하는지 알아본다고 정하면 기능을 전제로 삼지 않고 경험을 들을 여지가 생깁니다.
참여자 조건도 목표에 맞춥니다. 서비스를 좋아할 것 같은 사람보다 최근 회의실을 예약한 경험이 있고 실제로 예약이나 일정 조율을 맡는 사람이 이번 조사에 적합합니다. 예약 신청자와 승인 담당자는 보는 문제가 다를 수 있으므로 어떤 업무를 조사할지도 정합니다.
준비한 질문 옆에 무엇을 알아내려는 질문인지 적어보세요.
예약을 시작한 계기: 어떤 업무 때문에 회의실이 필요했는가?
예약 과정: 어디에서 무엇을 확인하고 선택했는가?
예약 이후: 누구에게 알렸고 어떤 일을 다시 처리했는가?
기존 대처: 문제가 생겼을 때 어떤 방법을 썼는가?
질문지를 순서대로 읽는 데 집중하면 뜻밖의 단서를 놓칠 수 있습니다. 조사 목표를 유지하되 참여자가 구체적인 일을 꺼내면 그 경험을 따라 후속 질문을 합니다. NN/G 인터뷰 가이드 작성 안내
자료를 함께 볼 때는 먼저 동의를 구합니다
예약 화면이나 당시 메시지를 함께 보면 기억을 구체화하는 데 도움이 될 수 있습니다. 공유를 강요하지 않고 무엇을 확인하려는지 설명한 뒤 동의를 구합니다. 이름, 연락처, 다른 사람의 일정과 회사 기밀은 가리도록 안내합니다. 녹음이나 화면 저장도 별도로 허락받고 동의한 범위에서만 진행합니다.
막연한 답이 나오면 최근 한 번의 경험으로 돌아갑니다
기능을 제안하는 질문을 경험 질문으로 바꿉니다
“알림 기능이 있으면 쓰실 건가요?”에는 어떤 상황의 알림인지, 현재 무엇이 불편한지 빠져 있습니다. 참여자는 기능이 유용해 보인다는 인상을 말할 수 있지만 실제로 사용할지는 여전히 알 수 없습니다.
“가장 최근 회의실 예약 과정을 말씀해 주세요”로 시작해 보세요. 대답에서 중요한 사건이 나오면 “그때 무엇을 확인했나요?”, “예약을 마친 뒤 어떻게 진행됐나요?”처럼 이어갑니다. 문제가 있었다고 먼저 정해두지 않고 순서를 듣습니다.
“예약을 자꾸 잊어서 불편하시죠?”처럼 원인과 감정을 질문에 넣으면 답을 유도할 수 있습니다. “예약 후 다시 확인한 일이 있었나요?”라고 묻고 있었다면 어떤 일이었는지 듣는 편이 낫습니다. 문제가 없었다는 답도 남깁니다. NN/G 유도 질문 안내
지금 쓰는 대처 방법을 묻습니다
참여자가 예약 후 팀 채팅방에 일정을 다시 적었다고 설명했다면 그 이유를 묻습니다. 회의실을 잊지 않으려는 행동일 수도 있지만 다른 참석자에게 장소를 알려주려는 목적일 수도 있습니다. 같은 행동에도 서로 다른 이유가 있으므로 알림 기능이 답이라고 바로 정하지 않습니다.
후속 질문은 해결안을 제시하기보다 빠진 맥락을 채우는 데 씁니다.
그 방법을 선택한 이유는 무엇인가요?
그때 함께 확인한 사람이나 자료가 있었나요?
다시 처리한 일이 있다면 어떻게 마무리했나요?
참여자의 설명만 들었다면 설명으로 기록합니다. 인터뷰 중 예약 과정을 직접 보여줬다면 그때 관찰한 행동을 따로 적습니다. 보여주기 위해 수행한 과정과 과거 일상에서 한 행동에도 차이가 있을 수 있습니다.
원발언과 팀의 해석, 다음 검증을 따로 남깁니다
인터뷰가 끝나면 인상적인 한마디를 기능 목록으로 옮기기 전에 기록을 나눠봅니다. 원발언에는 실제로 한 말을 보존하고 요약했다면 요약이라고 표시합니다. 팀의 해석에는 그 말에서 어떤 문제를 추정했는지 적습니다. 후속 검증에는 아직 모르는 점과 확인할 방법을 남깁니다.
가상 사례에서 참여자가 예약 정보를 채팅방에 다시 공유했다고 말했다면 팀은 참석자에게 장소를 전달하는 과정이 번거로울 수 있다고 해석할 수 있습니다. 하지만 예약을 잊는 문제가 크다는 결론까지 뒷받침하지는 않습니다. 다른 예약 담당자도 같은 과정을 거치는지 확인하거나 공유 동선을 직접 관찰하는 검증을 이어갈 수 있습니다.
여러 인터뷰에서 비슷한 이야기가 나와도 얼마나 많은 고객에게 해당하는지는 별도 확인이 필요합니다. 해결안의 사용 여부는 프로토타입 과업이나 실제 사용 실험으로 살펴보고 결제 의사는 그에 맞는 후속 검증을 설계합니다. 인터뷰에서 다루지 못한 질문을 분명히 남겨두는 편이 다음 판단에 도움이 됩니다.
고객의 기능 요청은 조사할 단서로 보관하되 요청이 나온 상황과 기존 대처를 함께 읽어보세요. 기능 이름만 쌓인 목록보다 어떤 일을 해결하려는지 설명된 기록으로 팀이 다음 작업을 논의하기 쉬워집니다.
4PS와 새 서비스를 준비한다면 만들고 싶은 기능과 함께 아직 확신하기 어려운 가정도 알려주세요. 조사 목표와 참여자 조건, 인터뷰 질문을 정리하고 들은 경험을 후속 검증과 제품 범위로 연결하는 과정을 함께 설계하겠습니다.