성공적인 제품을 만들며 배운 50가지 교훈 [번역글]

1. 소규모 팀(6명 이하)은 훌륭한 제품을 만들 수 있지만, 목표 설정, 로드맵 우선순위화, 메트릭 선택, 사용자 소통, 빠른 코드 배포 등 모든 자율권을 부여받아야 한다.

2. 제품의 성공은 그 제품을 만드는 사람들에 달려 있다. 채용 기준을 높게 잡는 게 핵심인데, 인재의 역량은 누적되기 때문이다. 잘못된 채용은 어떤 요인보다 팀 속도를 가장 크게 늦춘다.

3. 훌륭한 제품을 만드는 데는 신뢰가 필수다. 신뢰 부족은 팀의 가장 큰 병목 중 하나인데, 이는 보통 수준 미달 인재를 뽑았거나 그 사람에게 개선 피드백을 제대로 주지 않은 결과다.

4. 신뢰는 투명성으로도 쌓인다. 공개적으로 일하고, 토론을 열린 공간에서 하며, 작업 내용을 문서화하라. 이렇게 하면 모두가 필요한 맥락을 공유하고, 많은 회사에서 발생하는 정치적 다툼을 없앨 수 있다.

5. 프로세스가 아니라 신뢰와 피드백에 의존하라. 이는 우리 핵심 가치 중 하나다. 사람들이 원하는 것을 만들고 키우는 일은 미묘한 문제이므로, 직원들의 판단을 믿는다. 잘못되면 직설적으로 피드백을 준다.​

6. 경영진은 회사 목표를 공유하고, 제품 팀(엔지니어)은 이를 달성할 빌드 대상과 자체 목표를 정한다. 양측 모두 메트릭과 사용자 피드백으로 실제 영향을 검토해야 한다.

7. 제품은 이상 고객 프로필(ideal customer profile, ICP)에 종속된다. ICP가 바로 빌드 대상이며, 무엇을 만들지 결정하는 가장 중요한 요소다. 정확한 ICP는 타겟 고객뿐 아니라 제품과 시장 진입 전략의 모든 측면을 정의한다.

8. ICP를 찾으려면 먼저 추측하고 테스트하라. 가입 시 질문을 던지고, 유지율을 비교하며, 파워 유저를 식별하고, NPS 설문조사를 실시한다. 정보와 확신이 쌓이면 세부 사항을 더해가라.

9. 제품 원칙을 만들어라. 우리는 “성공 평가에 필요한 모든 도구 제공, 선점, 고객 및 제품 데이터의 진실 원천 역할”을 원칙으로 삼는다. 이는 아이디어 논의와 결정에 공통 언어를 제공한다.

10.사용자들이 원할 수 있는 모든 것을 매핑하라. 로드맵 우선순위를 정할 때 필요하다. 이렇게 해야 지평선 너머의 훌륭한 아이디어를 놓치지 않는다.

11. 제품은 단순한 기능 이상이다. 바로 브랜드와 타인에게 주는 제품 경험이다. 각 기능에 투자하는 규모, 채용하는 사람들, 빌드 결정, 주도 기능, 고객 소통, 가격 정책 모두가 독창성을 만든다.

12. 웹사이트는 제품의 첫인상이다. 지루하고 템플릿 같은 사이트는 뒤의 제품과 팀이 약하다는 신호를 보낸다. 자신만의 독특한 사이트를 이상 고객 프로필에 맞춰 만들면 이를 막고 사용자 유입을 촉진한다.

13. 때로는 제품 문제가 아니라 시장 문제다. 예를 들어 Monzo 창업자이자 YC 파트너인 Tom Blomfield가 대학 친구용 청구서 분배 서비스를 만들 때, 빌드 중단하고 사용자 유치에 집중하라는 조언을 받았다. 4주 콜드콜링 끝에 한 명 유치했을 때 피벗 시점임을 알았다.

14. 피벗한다면 대대적으로 하라. Stewart Butterfield는 두 게임 회사를 Flickr와 Slack으로 바꿨다. LinkedIn 공동창업자 Reid Hoffman은 스타트업 창업자들이 실패에서 성공으로 피벗하려면 사업 나머지를 ‘slash and burn’ 해야 한다고 말한다. 비슷해 보이면 더 멀리 가라.

15. 37signals의 Jason Fried가 말하듯 “아이디어를 검증할 수 없다. 존재하지 않으므로 실제로 만들어야 한다. 시장이 검증해줄 것이다.”

16. 계획은 유용하지만 엄격히 따르는 건 아니다. 좋은 실행은 특정 계획 이행이 아니라 가장 중요한 일을 반복하는 것이다. “계획 준수” 여부가 아니라 배포물, 배포 빈도, 영향으로 사람을 평가하라.

17. 뭔가를 “한 주만 더” 미루는 건 거의 나쁜 생각이다. 이런 태도가 몇 달 쌓이면 모멘텀 대폭 감소다. 사용자 손에 빨리 넘길수록 그 가치를 배우고 개선할 수 있다.

18. 진행 중 작업을 줄여라. PR은 하루 안에 끝나야 하고, 하루를 타인 리뷰 요청 응답으로 시작하며, 언제든 머지하고 기능 플래그 뒤로 배포하며 프로덕션에서 테스트하라. 이 모든 게 작업 맥락 부담을 줄인다.

19. 빠른 배포는 우리 제품 개발 철학의 핵심이지만 트레이드오프가 있다. 기술 조달, 계획 미팅, 애자일 의식, 메트릭 리뷰는 뒷전이다. 비동기 작업이 이를 더 가능하게 한다.

20. 제품에 신기술 도입은 과도 비용, 스케일링 문제, 고객 요구 같은 급박한 문제에서만 하라. 해결 기술은 팀이나 타팀이 직접 풀었던 방식을 물어보면 찾을 수 있다.

21. 인위적 데드라인은 팀을 빠르게 만들지 않는다. 오히려 기술 부채 산더미와 번아웃을 부르는 파국 루프를 초래한다. 팀을 늦추는 프로세스를 제거하고 소규모 팀에 빠른 배포 자율권을 주라.

22. 더 빠른 배포를 위한 또 다른 방법은 기본 디자인을 없애는 것이다. 디자인 시스템을 가동한 뒤 엔지니어에게 빌드를 맡겨라. 필요 시 디자인 리뷰로 이미 배포된 것을 다듬어라.

23. 기능 플래그는 제품 엔지니어가 변경을 빠르게 배포하고 프로덕션에서 테스트하며 실제 사용자 피드백을 받게 한다. 예상대로 작동 안 할 때 킬 스위치 역할로 위험도 줄인다.

24. PostHog에서 최고의 커뮤니케이션은 풀 리퀘스트다. 메시지나 이슈와 달리 피드백을 즉시 영향으로 바꾼다. 행동 우선 성향과 맞고 더 타이트한 피드백 루프를 만든다.

25. 소유권을 명확히 하라. 빌드 대상을 결정하는 게 훨씬 명확하고 빠르다. 소유권 회피 팀은 배포 대신 계획, 브레인스토밍, 미팅, 프로젝트 관리에 시간을 낭비한다.

26. 엔지니어들은 빌드 대상을 결정할 능력이 있다. 기술 제약 이해, 기능 패턴 파악, 문제 해결 방법을 알기 때문이다. 다만 사용자 요구에 대한 정보 병목이 있을 수 있다.

27. 엔지니어를 통제하는 대신, 제품 매니저는 제품 분석, 사용자 리서치, 경쟁사 조사 등으로 제품 팀에 맥락을 제공해야 한다.

28. 대부분은 Steve Jobs가 아니다. 처음부터 ‘알아서’ 빌드할 비전이 없고 거대 그림을 그리지도 않는다. 대신 배포하고 사용자에게 주고 피드백 반복한다. 이 속도가 빠를수록 제품이 좋아진다.

29. 제품 엔지니어를 채용하고 의지하라. 제품 빌드에 필요한 풀스택 기술과 고객 집착을 겸비했다. 사용자 대화, 인터뷰, 신기능 테스트 모집, 피드백 수집, 지원 처리, 인시던트 대응까지 해야 한다.

30. The Mom Test를 읽어라. 잠재 사용자 문제에 대해 대화하는 법을 가르친다. 핵심은 사용자 인터뷰 두 유형: 문제 탐색과 솔루션 검증. 전자는 미래 제품 결정 안내, 후자는 현재 작업 개선에 도움이 된다.

31. 사용자 인터뷰에서 최대 효과를 보려면 사용자(ICP)가 누구인지, 제품 사용 방식, 다음 빌드 대상이 무엇인지 미리 파악하라. 이렇게 하면 인터뷰가 다음 단계 초점을 명확히 하고 혼란을 주지 않는다.

32. 잠재 빌드 대상 중 지원 요청이 가장 ‘실제적’이다. 특정 사용자가 구체적 문제를 겪고 있으므로, 해결하면 제품이 즉시 개선된다. 다른 변경은 이처럼 직관적이지 않다.

33. 엔지니어가 지원을 맡으면 아이디에이션부터 구현, 지속 유지까지 제품 전체 라이프사이클 소유권을 장려한다. 각 단계가 실제 고객 페인 포인트와 이슈 뒤 코드 맥락을 쌓아 서로 연결된다.

34. 엔지니어 지원 처리는 사용자 문제와 배포된 픽스 간 루프를 단축한다. 지원 인력, 제품 매니저, 계획 프로세스가 방해하지 않는다. 보너스로 사용자들은 이를 사랑한다.

35. 자사 제품 사용(dogfooding)은 배포 속도 향상, 사용자 도달 전 문제 차단, 제품 깊이 이해, 사용자 공감 형성에 도움된다. 다만 사용자 대화, 실제 피드백, 사용 메트릭 추적을 대체하지는 않는다.

36. 우리 제품 팀이 인터뷰 팝업으로 자체 요구를 해결한 것처럼, 자사 니즈 해결은 유스케이스 검증에 효과적이다. 자사 제품을 써야 하는데 안 쓰면 뭔가 잘못된 신호이니 고쳐라.

37. 위대한 제품 빌더는 항상 프로토타이핑과 실험 중이다. MVP와 개념 증명 빌드, 미완성 작업 배포, 피드백 수렴, 실패 시 피벗에 익숙해야 한다. 인프라부터 디자인까지 제로 투 빌드 모든 스킬도 필요하다.

38. 성공적 A/B 테스트는 테스트 내용과 이유를 설명하는 좋은 가설이 필수다. 테스트 맥락, 변경점, 메트릭, 기대 결과를 포함하라.

39. 제품 실험 시 실패하고 제거될 수 있음을 알라. 기능 플래그로 제거 쉽게 세팅하고 완벽 유지보수·스케일링 버전 대신 ‘충분히 괜찮은’ 버전을 배포하라. 성공 후 개선하면 된다.

40. 제품 실험은 생각보다 훨씬 ‘멍청하게’ 해도 된다. 전체 기능 빌드 대신 fake door 테스트를 시도하라. 아무것도 없는 옵션이나 버튼을 추가해 클릭 여부를 확인하는 것이다.

41. 제품 실험 실패는 세상 끝이 아니다. Google에서 실험 80-90%가 ‘실패’한다. 시간 낭비로 보일 수 있지만 대규모에서 10% 성공이 모든 실패를 상쇄한다. Bing 헤드라인 표시 A/B 테스트가 수익 12%($1억 이상) 올린 예처럼.

42. 성장 집중 시 성장 엔지니어처럼 생각하고 우선순위화하라. 타겟 영역 식별, 대표 메트릭 선정, 개선 가설 세우고 가능한 최소 실험으로 테스트 구현하라.

43. 분석 도입은 거의 언제나 너무 이르지 않다. 출시 전 제품에는 맞지만 “너무 이르다”며 분석 없이 출시하는 건 거짓 경제다. 출시 후 우선순위는 최대 속도 배포에서 ‘올바른 것’ 최대 속도 배포로 바뀐다.

44. 분석 시작 시 작게 출발하라. 특정 제품이나 기능 선택, autocapture로 사용 추적, 트렌드·유지 그래프로 시각화하고 이를 개선하는 기능 배포를 시도하라. “모던 데이터 스택 산업 콤플렉스”가 실제보다 복잡하게 보이게 한다.

45. 시작 메트릭을 모르겠다면 activation을 추천한다. 다른 메트릭 상위에 있고 엔지니어가 직접 영향 주며 조직 전체에 유용하다.

46. activation 외에 retention은 빌드 영향 이해의 또 다른 핵심 메트릭이다. 주간 변화 추적으로 변경이 사용자 유지에 도움이 되는지 가늠할 수 있다.

47. 제품-시장 적합도 측정 시 사용자 참여가 사용자 성장보다 지수적으로 증가하고 유지율이 평탄화(0% 이상)되는지 확인하라. 그 후 ICP 사용자 유지 우수성과 유료 고객이 ICP에 속하는지 봐라.

48. 성장 리뷰는 팀 빌드가 수익, 제품 분석, 사용자 피드백 등 중요한 메트릭에 영향을 주는지 확인한다. PostHog에서 제품 매니저 주요 책임이다.

49. 여러 제품 빌드 시 각 제품을 미니 스타트업처럼 대우하라. 자체 제품 결정, 가격, 수익, 비용, 고객 대면 팀 조율까지.

50. 흥미로운 제품에 매달려라. PostHog 공동창업자 James가 제품-시장 적합도 가이드에서 쓴 대로: “흥미 없으면 피벗하라. 그게 전부다. 자신만의 느낌 나는 일에 매달릴 때 더 큰 성과를 낸다.”.