제품 속도에 대한 원칙

# Product Velocity를 위한 원칙

 

1. ‘덜 하기’가 필요함
일반적으로 속도와 품질 사이에는 트레이드오프가 존재함
대부분의 회사는 요구사항과 기한을 정하고 품질은 결과물로 취급하지만, 우리는 반대로 품질 기준을 정하고 60일 안에 무엇을 출시할 수 있는지 고민함

중요한 것은 모든 요구 사항을 다 충족하려 하기보다는, 중요한 것만 빠르게 완성하는 것임
요구사항을 제거하고 필요한 일만 하면 속도와 품질을 모두 높일 수 있음
Elon Musk도 비슷한 접근 방식을 제안하며, “먼저 요구 사항을 덜 멍청하게 만들어라”고 말함

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

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

4. 그냥 만들어라
우리는 제품 개발을 위한 프로세스가 없음. 피그마 목업, PRD, 디자인 시스템, 애자일, OKR, 확실한 제품 로드맵, A/B 테스팅, 그로스 해킹 등을 하지 않음

고객이 엔지니어이기에 우리 엔지니어가 제품, 디자인 등을 모두 처리할 수 있다고 기대함
빠르게 제품을 만들어보고 고객의 반응을 살피는 방식을 선호함

 

5. 재작성은 필요할 때 함
회사들은 종종 기술 부채를 가능한 오래 미룰수록 더 빨리 움직일 수 있다고 생각하지만, 우리는 필요할 때 대규모 재작성을 하는 것을 불편해하지 않음

때로는 올바른 것을 만들기 위한 가장 빠른 길이 잘못된 것을 만들고, 그것이 잘못되었다는 것을 깨닫고, 올바른 것으로 대체하는 것임
기술 부채를 제거하는 것이 유용해 보인다면 그렇게 할 것임

6. 가능하면 외주를 활용함
가능하다면 사내에서 만드는 대신 외부 벤더의 솔루션을 구매함. 예를 들어 Fern이라는 업체를 통해 SDK를 생성함
물론 공급업체를 이용하는 것은 상당한 초기 비용이 들고 자유도를 제한하지만, 일반적으로 옳은 선택임

우리는 엔지니어링 리소스가 매우 제한적이고 비싼데, 엔지니어 일주일치 시간이 약 5천 달러의 비용이 듦. 기회비용을 고려하면 그 가치는 훨씬 더 높음
실제로 만들 가치가 있는 것은 상대적으로 적음

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

 

---

얼마전, 답답함에 못이겨 제품팀을 떠났다. 

슬프게도 나의 권한으로는 바꿀 수 없는 것들이 많다. 대신에 다른 부분에서 속도를 내가면서 차이를 보여줄 생각이다.

최근에 공감했던 내용과 아주 비슷하다.