Back to Blog
SuperPM Blog/Prompt Guide

디스커버리 중심 테스트 및 실험 계획(Discovery-Focused Test & Experiment Plan)

이 프롬프트는 프로덕트 매니저가 제품 불확실성을 줄이기 위한 구조화되고 실행 가능한 테스트/실험 계획을 세우도록 돕습니다. 가장 위험한 가정(LoFA)을 식별하고, lean한 행동 기반 테스트로 이를 검증하고, 언제 정식 가설 실험으로 넘어가야 하는지 판단하도록 안내합니다. 중요도가 높은 제품 의사결정을 다루는 디스커버리 중심 팀에 적합합니다.

Discovery
82 uses·Published 6/12/2025·Updated 3/27/2026

가장 빠른 제품 팀은 기능이 아니라 가정을 테스트한다

제품 개발에는 속도란 빨리 만드는 것이라는 오래된 오해가 있습니다. 하지만 업계에서 가장 빠른 팀은 코드를 가장 빨리 치는 팀이 아닙니다. 한 줄도 쓰기 전에 무엇을 만들지 말아야 하는지 가장 빨리 알아내는 팀입니다.

문제

모든 제품 결정은 가정의 층 위에 서 있습니다. 고객이 이 문제를 갖고 있을 것이라고 가정하고, 이 문제를 해결하려고 돈을 낼 것이라 가정하고, 우리의 해결책이 대안보다 낫다고 가정하고, 제약 안에서 만들 수 있을 것이라 가정합니다. 대부분의 팀은 이 가정들을 사실처럼 다루고, 출시한 뒤에야 틀렸다는 걸 알게 됩니다.

Pendo의 2023 연구에 따르면 평균적인 소프트웨어 제품의 기능 80%는 거의 또는 전혀 사용되지 않습니다. 이것은 개발 문제가 아니라 디스커버리 문제입니다. 검증되지 않은 가정 위에 지어진 기능들이 나중에 틀린 것으로 드러난 결과입니다.

디스커버리 테스트 계획은 엔지니어링 리소스를 투입하기 전에 가장 위험한 가정을 체계적으로 드러내고 검증하기 위해 존재합니다. 속도를 늦추는 일이 아니라, 가장 비싼 낭비를 없애는 일입니다. 즉, 잘못된 것을 만드는 낭비를 줄이는 것입니다.

이 프롬프트의 작동 방식

이 프롬프트는 제품 디스커버리를 위한 구조화된 테스트 계획을 만듭니다. 제품 가설을 받아 네 가지 범주에 걸친 하위 가정으로 분해합니다.

  • Desirability: 고객이 이것을 원하는가?
  • Viability: 이것이 비즈니스적으로 성립하는가?
  • Feasibility: 우리가 이것을 만들 수 있는가?
  • Usability: 고객이 이것을 어떻게 써야 하는지 이해할 수 있는가?

각 핵심 가정마다 이 프롬프트는 가벼운 테스트를 설계합니다. 방법, 타깃 audience, 표본 수, 성공 기준, 일정까지 제안합니다. 테스트는 리스크 순으로 정렬되므로, 아이디어를 죽일 가능성이 가장 높은 가정부터 먼저 다루게 됩니다.

Teresa Torres의 continuous discovery 연구에 따르면, 만들기 전에 가정을 테스트하는 팀은 존재하지 않는 문제에 대한 해결책, 혹은 고객이 사용할 수 없는 해결책을 만드는 일을 피할 수 있기 때문에 time-to-value를 평균 35% 줄입니다.

언제 사용할까

  • 해결책에 커밋하기 전 가장 큰 베팅이 blind spot이 아닌지 확인하고 싶을 때
  • 이해관계자 간 의견이 갈릴 때 의견을 테스트 가능한 가설로 바꾸고 싶을 때
  • 분기 계획 중 어떤 로드맵 항목이 가장 높은 assumption risk를 갖는지 평가할 때
  • 실패한 출시 이후 어떤 가정이 틀렸는지를 사후적으로 식별할 때

흔한 함정

  • 쉬운 가정만 테스트하기. 팀은 자연스럽게 빨리 검증할 수 있는 것에 끌립니다. 하지만 가장 테스트하기 어려운 가정이 보통 가장 테스트할 가치가 큰 가정입니다.
  • 디스커버리와 validation을 혼동하기. 디스커버리는 배우는 과정이고, validation은 확인하는 과정입니다. 모든 테스트를 가설 확인용으로만 설계하면 아무것도 발견하지 못합니다.
  • 테스트를 과도하게 엔지니어링하기. 디스커버리 테스트가 항상 통계적 유의성을 갖춘 A/B 실험일 필요는 없습니다. 5명 usability test나 landing page smoke test만으로도 며칠 안에 가정을 지울 수 있습니다.
  • "그래서 어쩌라고"를 빼먹기. 모든 테스트에는 사전에 정의된 성공 기준이 있어야 합니다. "많이 배웠다"는 결과가 아닙니다. "참가자 10명 중 7명이 핵심 작업을 완료하지 못했다"가 결과입니다.

Harvard Business Review의 2022 분석에 따르면 체계적인 assumption testing을 하는 회사는 출시 기능 수는 30% 적지만, 기능당 매출은 47% 더 높습니다. 더 적게 만들지만, 더 잘 만듭니다.

참고 자료

Sources

Prompt details

Category
Discovery
Total uses
82
Created
6/12/2025
Last updated
3/27/2026

Ready to try the prompt?

Open the live prompt detail page for the full workflow.

View prompt details

More Discovery Guides