전통적인 스타트업 경로는 문제 검증이라는 중요한 사전 개발 단계를 간과하는 경우가 많습니다. 개발자들은 "만들어야 할까"라는 질문을 던지기 전에 "어떻게" 만들지에 집중하는 경향이 있습니다. 상당한 시간과 자원을 투입하기 전에, 누가 문제를 겪고 있는지, 그들의 현재 해결책은 무엇인지, 문제의 빈도는 어느 정도인지, 그리고 문제의 고통 강도는 어느 정도인지 파악하는 것이 필수적입니다. 비즈니스 아이디어는 코드 변경과 마찬가지로 가설로 취급되어야 하며, 근본적인 가정을 테스트해야 합니다. 이러한 가설을 검증하기 위한 실험은 전체 플랫폼 구축보다 작은 규모의 프로토타입이나 랜딩 페이지와 같은 방법으로 수행될 수 있습니다. 고객 피드백은 분석과 마찬가지로 반복적인 댓글을 통해 패턴을 식별하는 귀중한 데이터로 취급되어야 합니다. 기술적 결정은 본질적으로 비즈니스 결정이며, 코드뿐만 아니라 다양한 측면에 영향을 미칩니다. 수요를 검증하기 전에 인프라에 막대한 투자를 하는 조기 확장(premature scaling)은 흔한 함정입니다. 빌드-측정-학습(build-measure-learn) 주기는 효과적이지만, 코드 품질을 타협해서는 안 됩니다. 모든 노력은 특정 학습 목표를 달성해야 합니다. 제품에 가까이 있는 개발자들은 문제 관련성 및 테스트 효율성에 대한 비판적인 질문을 던짐으로써 제품 전략에 크게 기여할 수 있습니다. 궁극적으로 가치 있는 것을 구축한다는 것은 엔지니어링 노력을 검증된 고객 문제 및 기회와 일치시키는 것을 의미합니다. 가장 효과적인 개발 프로세스는 단순히 코드 생산뿐만 아니라 학습 및 전략적 의사 결정을 촉진합니다.