제품을 직접 사용하는 것은 강력한 무기입니다

제품을 마지막으로 직접 사용해본 적이 언제인가요? 신규 가입을 하고, 온보딩을 거치며, 기본 기능을 사용해본 적이 언제인가요? 만약 기억이 가물가물하다면, 너무 오랫동안 사용하지 않았을 가능성이 큽니다. 그 사이에 많은 것을 놓치고 있을지도 모릅니다.

PostHog의 모든 팀원은 제품을 직접 사용해보는 “dogfood”를 실천하고 있습니다. 마케팅과 세일즈 같은 비제품 팀도 예외는 아닙니다. 이를 통해 우리는 다음과 같은 이점을 얻고 있습니다:

• 더 빠르게 출시합니다. 팀원들로부터 받는 피드백은 사용자로부터 받는 것보다 훨씬 빠르고 쉽습니다. 이는 우리가 빠른 속도로 회사를 운영하는 방법 중 하나입니다.
• 문제를 빠르게 해결합니다. 사용자들이 문제를 보고하기 전에 거의 항상 사용성 문제나 버그를 발견하고 수정합니다. 이로 인해 시간 절약은 물론 제품의 품질도 향상됩니다.
• 동기부여가 됩니다. 제품이 좋다면 팀의 자신감이 상승합니다. 반면, 제품이 부족하다면 팀은 이를 개선하기 위해 더욱 노력하게 됩니다.
• 제품을 깊이 이해합니다. 우리는 교차 기능 문제를 식별하고 해결하며, 흥미로운 사용 사례를 발견하고, PostHog를 더 잘 홍보할 수 있습니다.
• 사용자와의 공감을 형성합니다. 우리 스스로가 불편함을 느낀다면, 사용자들은 훨씬 더 큰 불편을 느낄 것입니다. 이를 통해 우리는 고객 중심의 사고를 유지할 수 있습니다.

하지만 이러한 이점들은 우연히 얻어지는 것이 아닙니다. 피드백, 투명성, 간단하고 반복 가능한 프로세스가 강력하게 뒷받침되는 문화를 필요로 합니다. 이처럼 우리는 이러한 문화를 실천하고 있습니다.

언제 dogfood를 실천해야 할까요?

간단한 답변은 항상 실천해야 한다는 것이지만, 우리는 다음과 같은 상황에서 특히 유용하다고 느낍니다:

1. 아무도 대신할 수 없는 상황

HogQL, PostHog의 SQL 버전(전체 쿼리 서비스 포함)은 주로 dogfooding을 통해 발전했습니다. 쿼리 언어는 채택하기에 많은 노력이 필요한 고급 도구이기 때문에 대부분의 사용자는 이 노력을 기울이지 않았을 것입니다.

대신, 우리는 HogQL을 모든 인사이트의 기본 쿼리 엔진으로 삼아 내부에서 사용을 강제했습니다. 이를 통해 많은 기능 부족, 성능 문제, 고급 사용 사례들을 발견할 수 있었습니다.

예를 들어, Michael은 대시보드가 평균 몇 번 조회되는지 계산하려고 할 때 HogQL이 OFFSET 지원을 놓치고 있다는 것을 발견했습니다.

내부적으로 HogQL을 도입하면서 현재 시스템의 한계를 파악할 수 있었고, 이는 궁극적으로 사용자들에게 도움이 되었습니다. 만약 사용자 피드백에만 의존했다면 출시까지 더 오랜 시간이 걸리고, 사용자와 우리 모두에게 더 나쁜 경험이 되었을 것입니다.

2. 자신의 필요를 해결해야 할 때

우리 제품 팀은 사용자 인터뷰 예약을 번거롭게 느꼈습니다. 사용자를 식별하고, 이메일을 보내고, 시간을 조정한 후에야 피드백을 얻을 수 있었기 때문입니다. 수백 번의 인터뷰에서 이는 상당한 시간을 소비합니다.

이를 해결하기 위해, 그들은 사이트 앱 기능을 활용해 기능 플래그를 사용하여 적절한 사용자에게 Calendly에서 미팅을 예약할 수 있는 버튼이 포함된 팝업을 만들었습니다.

이로 인해 상당한 시간을 절약할 수 있었고, 지금의 설문조사 기능의 중요한 사용 사례를 검증할 수 있었습니다. 이처럼 dogfooding은 그 순간에도 도움이 되었고, 장기적으로는 로드맵을 안내하는 데에도 기여했습니다.

3. 제품을 사용해야 하지만 사용하지 않는 경우

우리 전략의 핵심 부분은 제품과 고객 데이터를 위한 진실의 출처가 되는 것이지만, 여전히 고객 분석을 위해 PostHog 외의 도구가 필요했습니다.

이를 식별하고 수정한 것이 바로 데이터 웨어하우스 개발의 영감이 되었습니다. 이를 통해 사용자는 Stripe, Hubspot, Zendesk와 같은 외부 소스의 데이터를 연결하고 쿼리할 수 있습니다. 이렇게 해서 우리는 외부 도구 대신 우리의 솔루션을 dogfood할 수 있게 되었습니다.

기본 버전을 구축한 후, 세일즈와 제품 팀의 요구와 쿼리가 추가 개발을 이끌었고, 알파 테스트 중에 발생한 문제와 사용성에 대한 피드백의 대부분은 내부 팀에서 나왔습니다.

어떻게 실천할 수 있을까요?

작은 팀에서는 dogfooding이 간단해 보이지만, 이를 조직 문화와 개발 프로세스에 깊이 내재시켜야만 규모가 커져도 지속될 수 있습니다.

우리는 이를 위해 다음과 같은 점이 중요하다고 느꼈습니다:

1. 리더십에서 시작됩니다

우리는 정말 모든 사람을 의미합니다. dogfooding의 책임은 특정 개인이나 팀에만 있는 것이 아닙니다. 이는 리더십에서 시작됩니다. 공동 창업자인 James와 Tim도 초기와 마찬가지로 여전히 제품을 직접 사용합니다.

우리는 주간 전체 회의에서 훌륭한 피드백을 공개적으로 축하하며, 모든 피드백은 전용 Slack 채널에서 투명하게 이루어집니다. 또한, 설문조사와 지원 티켓을 통해 얻은 많은 사용자 피드백도 동일한 채널로 전달되어 모든 팀원이 피드백을 항상 읽고 참여할 수 있습니다.

2. 프로세스보다 신뢰와 피드백이 우선입니다

이는 우리 회사의 핵심 가치 중 하나입니다. dogfooding은 이 가치 없이는 효과를 발휘할 수 없습니다. 우리는 팀원들에게 구체적으로 말하고, 긍정적인 의도를 가정하며, 피드백을 인정하고 이를 자신이 원하는 방식으로 활용할 것을 요청합니다. 피드백을 주고받는 방법에 대한 구체적인 지침도 마련되어 있습니다.

3. 팀을 고객처럼 대합니다

"The magic of small engineering teams"을 읽어보셨다면, PostHog에 많은 팀이 있다는 것을 아실 겁니다. 현재 우리는 약 47명이 15개의 작은 팀으로 나누어져 있습니다.

다른 내부 팀을 만족시키는 것은 PostHog에서 dogfooding과 관련된 공통된 목표입니다. 우리는 다른 팀과 인터뷰를 하고 구체적인 피드백을 요청하기 위해 최선을 다합니다. 다른 팀원들과의 인터뷰는 실제 고객과의 인터뷰처럼 진지하게 진행됩니다.

4. 빠른 피드백 루프

피드백을 행동으로 옮기지 않으면 dogfooding은 헛된 일이 될 것입니다. PostHog에서 이를 실천하는 두 가지 방법은 다음과 같습니다:

• 제품 엔지니어: 우리 엔지니어들은 제품에 대한 전적인 책임을 집니다. 이들은 dogfooding을 통해 피드백과 경험을 바탕으로 다음에 무엇을 구축할지 결정하고, 이를 구현하는 코드를 작성합니다.
• 효과를 중시하는 태도: 우리는 이슈나 메시지보다 풀 리퀘스트를 권장합니다. 문제를 해결하는 작은 변경 사항이라도 피드백을 더 빠르게 반영하고 피드백이 잃어버리지 않도록 도와줍니다.

5. 배포와 출시의 분리

기능 플래그 덕분에 모든 사용자에게 기능을 출시하지 않고도 dogfooding을 할 수 있습니다. 이를 통해 실제 운영 환경에서 테스트하고, 문제를 수정하며, 더 다듬어진 제품을 출시할 수 있습니다.

피해야 할 실수

너무 많은 dogfooding은 사용자가 원하는 것을 구축한다고 생각하게 만들 수 있지만, 실제로는 자신이 원하는 것만 구축하는 결과를 초래할 수 있습니다. 이를 방지하기 위해 다음 사항들을 주의하세요:

1. 사용자와의 소통을 대신하는 dogfooding

dogfooding은 제품 개발에 사용하는 유일한 전략이 되어서는 안 됩니다. 사용자와 대화하고, 실험을 실행하고, 업계와 경쟁사를 조사하며, 사용 데이터를 분석하세요. 궁극적인 목표는 여러분 자신만이 아닌 사용자들이 원하는 것을 구축하는 것입니다.

2. dogfooding에 너무 집중하기

dogfooding에 너무 집중하면 속도가 느려지고 사소한 문제들에만 신경 쓰게 될 수 있습니다. 실제 사용 경험과 사용자 피드백은 여러분 자신의 경험이나 팀원들의 피드백보다 여전히 더 중요합니다. 큰 기능을 완전히 준비되지 않은 상태에서 출시하고, 실제 사용자와 대화하는 것에 익숙해져야 합니다.

3. 개인적 및 집단적 편향

팀은 (다행히도) 사용자의 작은 부분만을 차지하며, 사용 사례의 작은 부분만을 대표합니다. dogfooding은 이러한 사용 사례에 대한 편향을 유발할 수 있으며, 제품의 전체 잠재력을 제한할 수 있습니다. 모든 사람이 B2B SaaS를 구축하는 엔지니어는 아닙니다.

4. 팀에게 dogfooding을 강요하기

팀이 하고 싶은 일과 구축하고 있는 제품 간의 근본적인 불일치가 있다는 신호입니다. 올바른 문화를 창출하지 못했거나, 팀이 이상적인 사용자가 아니거나, 제품이 충분히 좋지 않을 수 있습니다. Meta의 Horizon Worlds를 참고하세요.

dogfooding이 여러분에게 맞는 전략이라면, 이를 문화와 관행으로 구현하고, 여기서 언급한 함정을 피하면 더 나은 제품을 구축할 수 있는 강력한 무기를 얻을 수 있습니다. 우리는 이 방법에 크게 의존했으며, 가능할 때마다 이를 활용할 것을 권장합니다.