대부분의 제품 아이디어는 팀이 그것을 만들지 못해서 실패하는 것이 아닙니다. 불만 사항을 시장으로 오해했기 때문에 실패합니다.

공개된 앱 리뷰는 특정 기능에 전념하기 전에 유용하지만, 이는 리뷰를 투표수(vote count)가 아닌 **조사를 위한 증거(evidence to investigate)**로 취급할 때만 유효합니다. 별점 1점짜리 리뷰는 망가진 경험을 드러낼 수는 있지만, 새로운 제품이 구매될 것인지 여부는 알려주지 못합니다.

다음은 제가 SaaS 기능을 만들기 전에 리뷰를 더 나은 고객 인터뷰 질문으로 전환하기 위해 사용하는 가벼운 워크플로우(workflow)입니다.

1. 키워드가 아닌 결정사항부터 시작하세요

내려야 하는 선택을 한 문장으로 적으세요.

“도구 X에서 이동하는 팀들을 위해 온보딩 체크리스트(onboarding checklist)를 만들어야 할까?”

그런 다음 3~5개의 인접한 경쟁사를 선택하세요. 한 카테고리의 모든 리뷰를 수집하지 마세요. 핵심은 거대한 감성 대시보드(sentiment dashboard)를 만드는 것이 아니라, 제품 전반에 걸쳐 동일한 작업(job)을 비교하는 것입니다.

2. 낮은 평점을 읽되, 원래 표현을 유지하세요

별점 1개에서 3개 사이의 리뷰부터 시작하세요. 다음 사항을 저장하세요:

• 리뷰 텍스트
• 평점 및 날짜
• 가능한 경우 앱 버전
• 링크 또는 출처 식별자
• 리뷰가 나타난 경쟁사

원문(raw text)을 그대로 유지하세요. 불만 사항을 즉시 깔끔한 기능 요청(feature requests)으로 의역하고 싶은 유혹이 들겠지만, 그렇게 하면 나중에 인터뷰나 랜딩 페이지 카피(landing-page copy)에서 필요하게 될 언어를 잃게 됩니다.

3. 실패한 작업(job)별로 클러스터링(Cluster)하세요

“로그인이 안 돼요”와 “결제 후 계정에 접속할 수 없어요”는 서로 관련 없는 두 개의 버그가 아닙니다. 이 둘은 모두 작업의 실패입니다: 내가 결제한 것에 대해 신뢰할 수 있는 접속 권한을 얻는 것.

유용한 클러스터 레이블(cluster label)은 세 부분으로 구성됩니다:

1. Job (작업): 사용자가 하려고 했던 것
2. Breakdown (장애): 무엇이 사용자를 막았는가
3. Consequence (결과): 그로 인해 어떤 비용(손실)이 발생했는가

예시:

이를 통해 모든 부정적인 형용사에 대응하는 기능을 만드는 흔한 실수를 피할 수 있습니다.

4. 개별 리뷰가 아닌 패턴에 점수를 매기세요

각 클러스터(cluster)에 대해 다음 네 가지 질문을 1점에서 5점 사이로 점수 매기세요:

• 빈도 (Frequency): 리뷰와 경쟁사 전반에 걸쳐 반복되는가?
• 심각도 (Severity): 의미 있는 작업을 차단하는가, 아니면 단순히 짜증을 유발하는 수준인가?
• 구체성 (Specificity): 테스트 가능한 해결책(workaround)이나 결과를 명시할 수 있는가?
• 이탈 의도 (Escape intent): 리뷰어가 해지, 전환, 또는 대안 결제를 언급하는가?

불만은 많지만 결과(consequence)가 없는 클러스터는 고객 지원(support) 문제일 수 있습니다. 반면, 규모는 작더라도 명확하고 반복적인 결과가 따르는 클러스터는 더 날카로운 제품의 쐐기(product wedge)가 될 수 있습니다.

5. 기능 아이디어를 내기 전에 반대 가설을 작성하세요

“사람들이 이것을 싫어한다”에서 바로 “우리가 저것을 만들어야 한다”로 건너뛰지 마세요. 먼저 대안적인 설명을 작성하십시오.

예시:

• 관찰: 여러 경쟁사 리뷰에서 반복적인 AI 출력 실패에 대해 불평함.
• 쉬운 결론: 더 나은 AI 생성기(AI generator)를 만든다.
• 반대 가설 (Counter-hypothesis): 사용자는 더 많은 생성을 원하는 것이 아니라, 사용 가능한 출력을 확인, 재시도, 미리보기 및 확정할 수 있는 방법이 필요하다.

반대 가설은 리뷰 클러스터를 성급한 로드맵 항목이 아닌, 인터뷰 질문(interview prompt)으로 전환해 줍니다.

6. 각 클러스터를 5가지 질문의 인터뷰로 전환하세요

가장 높은 점수를 받은 클러스터에 대해, 최근에 해당 문제를 겪은 사람들에게 다음을 질문하십시오:

1. 무엇을 완료하려고 시도 중이었나요?
2. 기존 제품이 실패했을 때 무엇을 시도했나요?
3. 그 실패로 인해 시간, 비용, 리스크 또는 평판 측면에서 어떤 손실이 발생했나요?
4. 현재 어떤 해결책(workaround)을 사용하고 있나요?
5. 어떤 조건이 충족된다면 다른 방식으로 전환하거나 비용을 지불하시겠습니까?

리뷰는 시작을 위한 언어를 제공합니다. 인터뷰는 그 고통(pain)이 현재 진행형인지, 비용이 발생하는지, 그리고 구매 능력이 있는 사람의 문제인지를 알려줍니다.

7. 한 페이지 분량의 증거 메모를 작성하세요

개발에 착수하기 전, 다음 내용을 포함한 한 페이지를 유지하십시오:

• 클러스터 이름 및 원문 예시
• 해당 문제가 반복되는 경쟁사
• 당신의 반대 가설 (counter-hypothesis)
• 인터뷰 증거 및 반증 사례 (disconfirming evidence)
• 다음에 실행할 수 있는 가장 작은 규모의 테스트

이 메모는 긴 기능 목록(feature list)보다 더 가치 있습니다. 이 메모는 왜 특정 문제를 테스트할 가치가 있는지 설명하기 쉽게 만들어 주며, 증거가 약해질 때 매력적인 아이디어를 쉽게 포기할 수 있게 해줍니다.

첫 번째 검토를 더 빠르게 수행하는 방법

저는 이 워크플로우(workflow)의 기계적인 부분을 위해 Review2Idea를 구축했습니다. 이 도구는 App Store 및 Google Play의 공개된 불만 사항들을 출처와 연결된 클러스터(cluster)로 그룹화하고, 기회 메모(opportunity memo)를 위한 시작점을 생성합니다. 첫 번째 경쟁사 보고서는 무료이며 카드 정보가 필요하지 않습니다.

클러스터링(clustering)에는 원하는 어떤 도구든 사용해도 좋습니다. 중요한 원칙은 변하지 않습니다: 출처를 유지하고, 경쟁사 전반에 걸쳐 반복되는 패턴을 찾으며, 반대 가설(counter-hypothesis)을 작성하고, 제품을 만들기 전에 사람들을 통해 이를 검증하십시오.

당신이 즉시 기능(feature)으로 전환하는 대신, 조사해 보기로 결정했던 마지막 경쟁사 불만 사항은 무엇인가요?