CB Insights는 스타트업이 실패하는 이유에 대한 연간 분석을 발행합니다. 수년간 이유는 같습니다: "시장 수요 없음." 나쁜 실행이 아닙니다. 돈이 떨어진 것이 아닙니다. 나쁜 팀이 아닙니다. 제품은 단순히 사람들이 행동을 바꾸기에 충분하게 신경 쓰는 문제를 풀지 않았습니다.
그 통계는 제품 구축에 얼마나 많은 노력이 들어가는지를 고려할 때 놀랍습니다. 팀은 수개월 — 때때로 수년 — 시스템을 설계하고, 코드를 작성하고, 아키텍처에 대해 논쟁하고, 흐름을 완벽하게 하고 있습니다. 그리고 가장 흔한 이유는 아무도 그 모두가 실제 문제를 풀고 있는지 묻지 않았다는 것입니다.
사람들이 정말로 원하는 제품을 구축하는 것은 재능이 아닙니다. 그것은 규칙입니다. 그것은 방법을 가지고 있고, 그 방법을 배울 수 있습니다.
가장 흔한 제품 실수는 문제를 깊게 이해하기 전에 해결책에 빠지는 것입니다. 이는 거의 첫 번째 창립자에게 보편적이고 경험 많은 사람들에게도 놀랍게도 흔합니다. 패턴은 항상 같습니다: 누군가 아이디어를 가지고, 그들이 그것을 설득력 있다고 찾고, 구축을 시작합니다. 고객은 사후 생각입니다 — 설득할 누군가, 이해하지 않을.
해독제는 복잡하지 않지만 규칙이 필요합니다: 모든 해결책을 고려하기 전에 문제보다 더 많은 시간을 보냅니다. 문제를 가진 사람들과 이야기하세요. 그들이 일하는 방식을 보세요. 오늘 그들이 사용하는 대안을 이해하고 그 대안들이 불완전한 이유를 이해하세요. 그때만 당신은 정말로 맞는 것을 설계할 충분한 문맥을 가집니다.
좋은 제품 개발은 직선이 아닙니다 — 그것은 루프입니다. 루프의 각 반복은 가정을 증거로 대체할 기회입니다. 사람들이 원하는 제품을 구축하는 팀은 이 루프를 빠르게 그리고 자주 완성하는 팀입니다.
루프는 형식이 아닙니다. 각 단계는 다음의 입력이 되는 구체적 결과를 가집니다. 단계를 건너뛰기 — 가장 일반적으로 문제에서 구축으로 직접 건너뛰기 — 표준을 놓친 제품을 생성합니다.
모든 문제가 풀 가치가 있는 것은 아닙니다. 좋은 제품 문제는 3가지 품질을 가집니다: 그것은 자주 발생합니다(사람들에게 자주, 드물게 영향), 그것은 강합니다(사람들이 완화를 원할 정도로 느낍니다), 그리고 기존 해결책은 정말로 부족합니다(당신이 구축할 것과 약간 다른 것이 아닙니다).
실수는 첫 번째 품질에 최적화하고 다른 두 개를 무시하는 것입니다. "사람들은 회의에서 시간을 낭비합니다"는 자주입니다. 하지만 고통이 낮으면 — 사람들이 충분히 좋은 대안을 찾았으면 — 문제는 상업적으로 풀 가치가 없을 수 있습니다. 그리고 12개의 도구가 이미 당신이 하고 싶은 것을 하고 있으면, 당신의 것을 선택할 매우 구체적인 이유가 필요합니다.
조사는 제품 원으로 나쁜 평판을 가집니다 — 느린 컨설턴시, 두꺼운 보고서, 아무도 읽지 않는 발견과 연관됩니다. 그것은 실행의 실패이지 실천의 실패입니다. 좋은 제품 조사는 빠르고, 구체적이고, 당신이 구축하는 것을 바꿉니다.
조사의 목표는 문제가 실제임을 확인하는 것이 아닙니다. 당신은 무거운 투자를 하기 전에 이미 그것을 믿어야 합니다. 목표는 좋은 해결책이 무엇처럼 보일지 알 정도로 문제를 깊게 이해하는 것입니다: 정확히 누가 문제를 가지고 있고, 어느 문맥에서, 그들이 이미 시도한 것, 그들이 그것을 설명하기 위해 사용하는 단어, 그리고 "풀다"는 무엇처럼 보일 것입니다 그들에게.
가설은 당신이 참이라고 믿는 것에 대한 구체적이고 거짓임이 입증 가능한 예측입니다. 그것은 명확함을 강제합니다. 명확한 가설을 작성할 수 없으면, 당신은 아직 문제를 충분히 이해하지 못했습니다 해결책을 구축합니다.
유용한 제품 가설은 3가지 부분을 가집니다:
신호가 가장 중요한 부분입니다 — 그리고 가장 흔히 생략됩니다. 미리 정한 신호 없이, 모든 실험이 "조금 작동했습니다." 팀은 모호한 데이터를 호의적으로 해석하는 방법을 찾습니다. 거짓임이 입증 가능한 조건이 없는 가설은 단지 바람입니다.
구축 단계는 대부분 팀이 너무 많은 시간을 보내는 곳입니다. 목표는 제품을 구축하는 것이 아닙니다 — 당신의 가설에 신호를 주는 최소 것입니다. 이들은 다른 목표이고 그들은 매우 다른 결과를 생산합니다.
대부분의 초기 단계 가설에 대해, 최소는 팀이 생각하는 것보다 훨씬 적습니다. 소프트웨어가 할 것을 10명을 위해 수동으로 할 수 있습니까, 그들이 결과를 소중히 여기는지 테스트하려고? 구축하기 전에 기존 도구를 꿰고 작업 흐름을 테스트할 수 있습니까? 코드를 작성하기 전에 프로토타입을 스케치하고 5명의 사용자와 함께 걸을 수 있습니까?
규칙은 무엇을 구축하기 전에 물어보는 것입니다: "나는 배우기 시도하고 있으니?"와 "나에게 그것을 배우게 할 최소 것은 무엇인가?" 답변은 거의 항상 팀이 구축하기를 원하는 것보다 작습니다.
발행 후 — 프로토타입이든, 수동 파일럿이든, 배포 기능이든 — 측정 단계는 팀이 자신을 가장 흔히 속이는 곳입니다. 그들은 사용자에게 그것을 좋아했는지 묻습니다. 사용자는 예라고 합니다. 팀은 실험을 검증으로 표시합니다.
감정은 신호가 아닙니다. 유일한 신뢰할 수 있는 신호는 행동입니다: 사람들이 그 일을 했습니까? 그들이 돌아왔습니까? 그들이 지불했습니까? 그들이 다른 누군가에게 말했습니까?
정량적 측정을 위해, 발행 전에 기구를 설정합니다. 어떤 구체적 행동을 추적하고 있는지 알고 있습니다. 미리 임계값을 설정합니다 — "우리는 X%의 사용자가 Y를 Z일 내에 완료하면 이것을 검증으로 고려합니다." 정성적 측정을 위해, 개방 종료 만족 설문이 아닌 구조화된 후속 면접을 진행합니다.
배우기 단계는 사용자와 문제에 대한 당신의 정신 모델을 업데이트하는 것이고, 다음에 무엇을 구축할지만이 아닙니다. 팀이 이 단계를 건너뛰면 데이터를 수집하지만 이해를 축적하지 않습니다. 빠르게 실행하지만 시간에 따라 판단을 개선하지 않습니다.
좋은 배우기 세션은 물어봅니다: 우리가 무엇을 예측했습니까? 무엇이 실제로 일어났습니까? 간격이 우리의 가정에 대해 말하는 것은 무엇입니까? 이제 우리가 알 필요가 있는 가장 중요한 것은 무엇입니까?
배우기 단계의 결과는 더 날카로운 문제 정의, 수정된 가설, 또는 — 실험이 명확히 실패하면 — 완전히 다른 방향을 추구하기로의 결정입니다. 이 모든 결과는 가치 있습니다. 최악의 결과는 모호함입니다: "우리는 어떤 것을 배웠지만 다음에 무엇을 할지 확실하지 않습니다." 그것은 실험이 충분히 구체적이지 않았다는 신호입니다.
제품 개발은 결코 이 루프를 실행하는 것을 멈추는 단계에 도달하지 않습니다. 질문은 바뀝니다 — 초반에 당신은 문제가 실제임을 검증하고 있고 나중에 당신은 특정 해결책 요소가 작동하는지를 검증하고 있습니다 — 하지만 구조는 항상 같습니다. 관찰, 가정, 테스트, 배우기.
사람들이 원하는 제품을 구축하는 팀은 가장 영리한 초기 통찰을 가진 팀이 아닙니다. 그들은 루프를 가장 빠르게 그리고 가장 정직하게 완성하는 팀입니다. 배우기의 속도, 배송의 속도 아닙니다, 초기 단계 제품 개발에서 경쟁 장점입니다.