제품 속도에 대한 원칙

• 많은 회사들이 복잡한 프로세스나 장황한 요구 사항에 얽매여 개발 속도가 느려지지만, 실제로 중요한 것은 빠르게 ‘올바른 제품’을 만드는 것임
• 제품 개발 과정에서 불필요한 요소들을 제거하면 제품 개발 속도가 매우 빨라짐. 올바른 제품을 만드는 것 자체는 본질적으로 빠른 과정임
• 제품 팀의 속도를 늦추는 것은 프로세스, 의사 결정자와 실행자 간의 거리, 과도한 명세서 등의 불필요한 요소들임

[Product Velocity를 위한 원칙]

1. ‘덜 하기’가 필요함

• 일반적으로 속도와 품질 사이에는 트레이드오프가 존재함
• 대부분의 회사는 요구사항과 기한을 정하고 품질은 결과물로 취급하지만, 우리는 반대로 품질 기준을 정하고 60일 안에 무엇을 출시할 수 있는지 고민함
• 중요한 것은 모든 요구 사항을 다 충족하려 하기보다는, 중요한 것만 빠르게 완성하는 것임
• 요구사항을 제거하고 필요한 일만 하면 속도와 품질을 모두 높일 수 있음
• Elon Musk도 비슷한 접근 방식을 제안하며, “먼저 요구 사항을 덜 멍청하게 만들어라”고 말함

2. ‘바보 모드’가 종종 효과적임

• ‘midwit meme’을 예로 들면, 똑똑한 사람과 바보는 간단한 해결책에 동의하는 반면, 평균적인 사람은 불필요하게 복잡한 문제를 만듦.
• 우리는 종종 ‘바보 모드’로 문제를 접근하며, 복잡하게 생각하는 대신 단순한 해결책을 찾으려고 노력함.
• 실수를 했을 때는 대개 생각이 너무 많았던 것임, 간단한 방법이 더 자주 효과적임
• "내가 바보라면 어떻게 할까?"라고 자문하면 실행 가능한 해결책에 도달하곤 함

3. 모든 문제가 중요한 것은 아님

• 소수의 문제들만 매우 중요함. 보안과 같은 중요한 문제는 반드시 해결해야 하지만, 모든 문제를 다 해결할 필요는 없음.
• 예를 들어, 모바일 UI가 좋지 않지만 고객이 모바일 사용을 거의 하지 않기 때문에 이를 개선하지 않고 있음.
• 이처럼 고객이 크게 신경 쓰지 않는 문제는 무시할 수 있음.

4. 그냥 만들어라

• 우리는 제품 개발을 위한 프로세스가 없음. 피그마 목업, PRD, 디자인 시스템, 애자일, OKR, 확실한 제품 로드맵, A/B 테스팅, 그로스 해킹 등을 하지 않음
• 고객이 엔지니어이기에 우리 엔지니어가 제품, 디자인 등을 모두 처리할 수 있다고 기대함
• 빠르게 제품을 만들어보고 고객의 반응을 살피는 방식을 선호함

5. 재작성은 필요할 때 함

• 회사들은 종종 기술 부채를 가능한 오래 미룰수록 더 빨리 움직일 수 있다고 생각하지만, 우리는 필요할 때 대규모 재작성을 하는 것을 불편해하지 않음
• 때로는 올바른 것을 만들기 위한 가장 빠른 길이 잘못된 것을 만들고, 그것이 잘못되었다는 것을 깨닫고, 올바른 것으로 대체하는 것임
• 기술 부채를 제거하는 것이 유용해 보인다면 그렇게 할 것임

6. 가능하면 외주를 활용함

• 가능하다면 사내에서 만드는 대신 외부 벤더의 솔루션을 구매함. 예를 들어 Fern이라는 업체를 통해 SDK를 생성함
• 물론 공급업체를 이용하는 것은 상당한 초기 비용이 들고 자유도를 제한하지만, 일반적으로 옳은 선택임
• 우리는 엔지니어링 리소스가 매우 제한적이고 비싼데, 엔지니어 일주일치 시간이 약 5천 달러의 비용이 듦. 기회비용을 고려하면 그 가치는 훨씬 더 높음
• 실제로 만들 가치가 있는 것은 상대적으로 적음

7. 채용하지 않음

• 인력을 늘리면 팀의 산출량이 늘어날 것이라 기대하지 않음. 채용은 느리고 어려우며, 온보딩과 인력 관리는 시간을 소모함
• 특히 많은 지원 없이 기여할 수 있는 유능한 사람을 데려오기가 어려움
• 따라서 대규모 엔지니어링 팀을 구축할 자원이 있음에도 불구하고, 소규모로 유지하기 위해 최선을 다함. 이는 삶을 훨씬 더 쉽게 만듦

마무리 생각

• 우리가 이전에 깨닫지 못했던 정도로, 제품 개발은 그렇게 오래 걸리지 않아야 한다는 것을 깨달았음
• 고객에게 필요한 것을 알고, 강력한 팀을 보유하고 있으며, 주의를 산만하게 하는 불필요한 요소를 배제하면 높은 속도로 제품을 개발할 수 있음