CB Insights는 스타트업이 실패하는 이유를 매년 분석해 발표합니다. 수년째 1위 이유는 같습니다. 바로 "시장 수요 없음"입니다. 실행력이 부족해서도, 자금이 바닥나서도, 팀이 나빠서도 아닙니다. 제품이 사람들이 행동을 바꿀 만큼 절실하게 느끼는 문제를 풀지 못했기 때문입니다.
제품을 만드는 데 얼마나 많은 노력이 들어가는지 생각하면 이 통계는 충격적입니다. 팀들은 몇 달, 때로는 몇 년 동안 시스템을 설계하고, 코드를 짜고, 아키텍처를 두고 논쟁하고, 사용 흐름을 다듬습니다. 그런데 실패의 가장 흔한 이유는 그 모든 일이 실제 문제를 풀고 있는지 아무도 묻지 않았다는 것입니다.
사람들이 정말로 원하는 제품을 만드는 것은 타고난 재능이 아니라 훈련으로 익히는 방법론입니다. 방법이 있고, 그 방법은 배울 수 있습니다.
가장 흔한 제품 실수는 문제를 깊이 이해하기도 전에 해결책에 빠져 버리는 것입니다. 처음 창업하는 사람에게는 거의 예외 없이 나타나고, 경험 많은 창업자에게도 의외로 흔합니다. 패턴은 늘 같습니다. 누군가 아이디어를 떠올리고, 그 아이디어가 근사해 보여서 만들기 시작합니다. 고객은 뒷전이 되어, 이해할 대상이 아니라 설득할 대상이 됩니다.
해법은 복잡하지 않지만 절제가 필요합니다. 해결책을 생각하기 전에, 적절하다고 느끼는 것보다 더 오래 문제에 시간을 들이십시오. 그 문제를 겪는 사람들과 이야기하고, 그들이 일하는 모습을 지켜보십시오. 지금 그들이 쓰는 임시방편이 무엇이고 왜 그것이 불완전한지 파악하십시오. 그래야 비로소 정말 들어맞는 제품을 설계할 만큼의 맥락을 갖추게 됩니다.
좋은 제품 개발은 직선이 아니라 루프입니다. 루프를 한 바퀴 돌 때마다 가정을 증거로 바꿀 기회가 생깁니다. 사람들이 원하는 제품을 만드는 팀은 이 루프를 빠르고 자주 도는 팀입니다.
루프는 형식적인 절차가 아닙니다. 각 단계에는 구체적인 산출물이 있고, 그것이 다음 단계의 입력이 됩니다. 단계를 건너뛰는 것, 특히 문제에서 곧바로 제작으로 건너뛰는 것이 빗나간 제품을 만들어 냅니다.
모든 문제가 풀 가치가 있는 것은 아닙니다. 좋은 제품 문제에는 세 가지 특성이 있습니다. 자주 발생하고(드물게가 아니라 사람들에게 자주 영향을 주고), 강도가 높으며(사람들이 해소하고 싶을 만큼 절실히 느끼고), 기존 해결책이 정말로 부족합니다(우리가 만들 제품과 조금 다를 뿐인 정도가 아닙니다).
흔한 실수는 첫 번째 특성만 최적화하고 나머지 둘을 무시하는 것입니다. "사람들은 회의에서 시간을 낭비한다"는 자주 발생하는 문제입니다. 하지만 고통이 크지 않거나 사람들이 이미 충분히 쓸 만한 대안을 찾았다면, 그 문제는 사업적으로 풀 가치가 없을 수 있습니다. 또 이미 비슷한 일을 하는 도구가 열두 개나 있다면, 왜 우리 제품이 선택되어야 하는지 매우 구체적인 이유가 필요합니다.
리서치는 제품 업계에서 평판이 좋지 않습니다. 느린 컨설팅 업체, 두꺼운 보고서, 아무도 읽지 않는 결과물이 연상되기 때문입니다. 하지만 이는 리서치라는 방법이 아니라 실행의 실패입니다. 좋은 제품 리서치는 빠르고 구체적이며, 무엇을 만들지를 바꿔 놓습니다.
리서치의 목표는 문제가 실재한다는 것을 확인하는 것이 아닙니다. 리서치에 많은 투자를 하기 전에 이미 그렇게 믿고 있어야 합니다. 목표는 좋은 해결책이 어떤 모습일지 알 만큼 문제를 깊이 이해하는 것입니다. 구체적으로 누가 어떤 맥락에서 그 문제를 겪는지, 이미 무엇을 시도해 보았는지, 그 문제를 어떤 말로 설명하는지, 그리고 그들에게 "해결됐다"는 어떤 상태인지를 알아야 합니다.
가설은 무엇이 참이라고 믿는지에 대한 구체적이고 반증 가능한 예측입니다. 가설은 명확성을 강제합니다. 명확한 가설을 쓸 수 없다면, 해결책을 만들 만큼 문제를 아직 충분히 이해하지 못한 것입니다.
유용한 제품 가설에는 세 부분이 있습니다.
신호가 가장 중요한 부분이지만 가장 자주 빠지는 부분이기도 합니다. 미리 정해 둔 신호가 없으면 모든 실험이 "어느 정도는 효과가 있었던" 것이 됩니다. 팀은 모호한 데이터를 유리하게 해석할 방법을 찾아냅니다. 반증 조건이 없는 가설은 그저 희망 사항일 뿐입니다.
제작 단계는 대부분의 팀이 너무 많은 시간을 쓰는 곳입니다. 목표는 제품을 만드는 것이 아니라, 가설에 대한 신호를 얻을 수 있는 최소한의 것을 만드는 것입니다. 이 둘은 목표가 다르고, 결과물도 매우 다릅니다.
초기 단계의 가설 대부분은 필요한 최소한의 범위가 팀이 생각하는 것보다 훨씬 작습니다. 소프트웨어가 해 줄 일을 열 명을 위해 직접 수작업으로 해 보며 그들이 그 결과에 가치를 두는지 확인할 수 있을까요? 새 인프라를 만들기 전에 기존 도구를 이어 붙여 워크플로를 테스트할 수 있을까요? 코드를 한 줄 쓰기 전에 프로토타입을 스케치해 사용자 다섯 명과 함께 살펴볼 수 있을까요?
무엇이든 만들기 전에 스스로 물어야 할 질문은 "나는 무엇을 알아내려 하는가?"와 "그것을 알아내기 위한 최소한의 것은 무엇인가?"입니다. 답은 거의 언제나 팀이 만들고 싶어 하는 것보다 작습니다.
출시 후, 그것이 프로토타입이든 수작업 파일럿이든 배포한 기능이든, 측정 단계는 팀이 가장 흔히 스스로를 속이는 곳입니다. 사용자에게 마음에 들었는지 묻고, 사용자는 그렇다고 답하며, 팀은 그 실험을 검증된 것으로 표시합니다.
감정은 신호가 아닙니다. 유일하게 믿을 만한 신호는 행동입니다. 사람들이 실제로 그 일을 했는지, 다시 돌아왔는지, 돈을 냈는지, 다른 사람에게 알렸는지를 보십시오.
정량적 측정을 하려면 출시 전에 측정 장치를 갖추십시오. 어떤 구체적인 행동을 추적할지 정하고, 기준값도 미리 설정합니다. "사용자의 X%가 Z일 안에 Y를 완료하면 검증된 것으로 간주한다"처럼요. 정성적 측정에는 열린 만족도 설문 대신 구조화된 후속 인터뷰를 진행하십시오.
학습 단계는 다음에 무엇을 만들지 정하는 것만이 아니라, 사용자와 문제에 대한 머릿속 모델을 갱신하는 일입니다. 이 단계를 건너뛰는 팀은 데이터는 모으지만 이해는 쌓지 못합니다. 실행은 빠르지만 시간이 지나도 판단력이 나아지지 않습니다.
좋은 학습 세션에서는 이런 질문을 던집니다. 우리는 무엇을 예측했는가? 실제로는 무슨 일이 일어났는가? 그 차이는 우리의 가정에 대해 무엇을 말해 주는가? 지금 우리가 모르는 것 중 가장 중요한 것은 무엇인가?
학습 단계의 결과물은 더 날카로워진 문제 정의, 수정된 가설, 또는 실험이 분명히 실패했다면 완전히 다른 방향을 추구하겠다는 결정입니다. 이 결과는 모두 가치가 있습니다. 최악은 모호함입니다. "몇 가지를 배우기는 했는데 다음에 무엇을 할지는 잘 모르겠다"는 것은 실험이 충분히 구체적이지 않았다는 신호입니다.
제품 개발에는 이 루프를 그만 돌려도 되는 단계가 없습니다. 질문은 달라집니다. 초기에는 문제가 실재하는지 검증하고, 나중에는 특정 해결책 요소가 효과가 있는지 검증합니다. 하지만 구조는 늘 같습니다. 관찰하고, 가설을 세우고, 테스트하고, 학습합니다.
사람들이 원하는 제품을 만드는 팀은 처음에 가장 기발한 통찰을 가진 팀이 아닙니다. 루프를 가장 빠르고 가장 정직하게 도는 팀입니다. 초기 단계의 제품 개발에서 경쟁 우위는 출시 속도가 아니라 학습 속도에서 나옵니다.