한국어
내가 개발자 주도 성장 제품을 추진하면서 배운 5가지 시장 진출 교훈
개발자와 함께 Logto의 성장을 추진하면서 배운 교훈과 실천 사례입니다.
Guamian
Product & Design
Product & Design
개발자와 함께 Logto의 성장을 추진하면서 배운 교훈과 실천 사례입니다.
Logto는 오픈 소스, 개발자 중심 제품입니다. 다음은 우리의 시장 진출 타임라인입니다:
생산성 도구를 위한 제품 주도 성장 경험을 바탕으로, 팀과 나는 Logto에 다양한 시장 진출 전략을 시도했습니다. 2년 후, 나는 그 노력과 우리가 취한 단계들을 반성했습니다. 나는 그 여정의 일부를 공유하고 그 당시 왜 어떤 것들이 작동하지 않았는지를 설명하고 싶습니다. 이것들은 "실수"가 아니라 우리 경험에서 나온 귀중한 교훈입니다. 이 통찰이 비슷한 프로젝트나 스타트업을 진행하고 있는 다른 사람들에게 도움이 되길 바랍니다.
제품을 처음 출시할 때, 특히 제품 성장 마인드나 약간의 경험을 가지고 있을 때, 여러 흥미로운 아이디어를 생각하기 쉽습니다: 멋진 온보딩 흐름, 웹사이트에서의 훌륭한 데모, 사용자에게 가치를 강조하는 멋진 방법, 그리고 그들을 빠르게 "아하" 순간에 도달하게 하기. 나는 우리 제품이 상업화할 준비가 되어 보이기 위해 두 가지 활성화 전략을 구현했습니다:
이 전략들은 과거 경험에서 매우 성공적이었습니다. 그래서 Logto가 클라우드 호스팅 버전을 출시했을 때, 나는 그것들을 즉시 적용했습니다. 그러나 혼란과 도전에 직면했습니다:
개발자 제품의 경우, 진정한 자기 서비스가 가능하더라도 단시간에 문제를 해결하는 것은 어렵습니다. 단일 개발자에게조차도 올바른 기술 스택과 통합, 개념 증명 생성, 개발 환경에서의 테스트, 그리고 생산으로의 이동이 포함된 여러 단계를 포함합니다. 이 여정의 어느 시점에서나 사용자는 탈락할 수 있습니다. "해야 할 일"은 간단한 한 단계 작업이 아닙니다. 개발자의 요구는 종종 복잡하며, 생각이 깊은 기존의 능력을 활용해야 하는 다양한 기능이나 기술 시나리오를 필요로 합니다. 이러한 문제를 해결하는 데에는 시간이 걸리며 서둘러서는 안 됩니다.
돌이켜보면, 왜 이 접근법이 성공하지 못했는지 명백합니다. 처음 출시했을 때, 우리의 일일 가입자 수와 유기적 트래픽은 매우 낮았습니다. 대부분의 트래픽은 오픈 소스 커뮤니티에서 왔으며, 자연스럽게 더 큰 규모의 고객을 데려오지 않았습니다. 초기 단계에서 대규모 고객들이 통화를 예약하는 것을 기대하는 것은 비현실적이었습니다. 낮은 트래픽과 사용자 출처로 인해 초기 통화 예약 기대는 현실적이지 않았습니다.
사용자 활성화에 필요한 시간을 기준으로 제품에 맞는 모델을 선택하세요. 업계 규범에 구애받지 마십시오.
SaaS 제품을 구축할 때, 주요 시장 진출(GTM) 질문 중 하나는 프리미엄 또는 무료 체험을 선택해야 한다는 것입니다. 일반 지식은 다음과 같습니다:
우리는 처음에 빠른 출시를 위해 프리미엄 모델을 선택하고, 무료 및 유료 계획 사이에 명확한 결제 벽을 설정했습니다. 그러나 개발자들은 무료 계층에서 SSO나 조직과 같은 고급 기능에 접근할 수 없었습니다.
온라인에는 어떤 모델이 더 나은지에 대한 많은 논쟁이 있지만, 제품의 활성화 타임라인을 고려하는 것이 중요합니다. Logto의 경우, 실제로 테스트 단계는 최대 6개월까지 지속될 수 있음을 확인했습니다. 이는 Logto의 복잡성 때문이 아니라, 엔지니어의 작업 일정, 프로젝트 계획, 팀 워크플로우 및 우리가 예상하지 못한 기타 요소 때문입니다.
이 긴 활성화 기간을 감안할 때, 개발자에게 테스트를 위해 모든 기능에 대한 완전한 접근을 제공하는 것이 중요합니다. 이는 개발자 도구에서는 흔한 관행이지만, 전통적인 프리미엄 또는 무료 체험 전략이 왜 우리에게 맞지 않는지를 설명합니다.
선택은 제품의 특성과 채택 타임라인에 맞아야 합니다. 제품의 고유한 특징을 이해하고, 사용자들을 너무 빠르게 전환하게 하는 모델이 아니라, 맞는 모델을 선택하십시오.
하향식 전략으로 GTM을 실행할 때 SEO, 제품 마케팅, 콘텐츠 마케팅이 자주 포함됩니다. 우리는 모두 초기에 시작하는 것이 중요하다는 것을 알고 있으므로, 오픈 소스 버전 출시 직후부터 콘텐츠 생성에 착수했습니다. 하지만 기사를 쓰기로 처음 결정했을 때, 큰 질문이 있었습니다: 무엇을 써야 할까?
제품 디자이너로서, 내 본능은 우리가 특정 기능을 설계한 이유, 생각 과정 및 그것들이 설계된 철학을 설명하는 것이었습니다.
"이 기사에서는 '로그인 경험'의 역사를 소개하고, 개념, 설계 결정, 제품 트레이드오프를 다룰 것입니다. 성공적이고 원활한 로그인 또는 가입 경험을 구축하는 방법을 더 잘 이해할 수 있습니다."
- 2년 전 우리의 블로그 포스트 원활한 로그인 경험을 위한 설계 고려 사항 (첫 번째 장)
내가 우리의 기능과 설계에 대해 생각을 공유하고 싶은 이유는 그것에 많은 노력을 기울였기 때문이었습니다. 그러나 돌이켜보면 이것이 "자기 흡수적" 콘텐츠라고 부를 수 있는 것임을 깨달았습니다. 강력한 EPD(엔지니어링, 제품, 설계) 문화를 가진 잘 확립된 회사들에서 흔한 일입니다.
제품 주도 성장을 하고 있다면(PLG), 특히 당신의 제품이 "사람들이 당신에 대해 이야기하는" 단계에 도달하지 않았다면, 콘텐츠가 청중에게 명확한 가치와 목표를 가지고 있는지 확인하는 것이 필요합니다. 너무 자기 중심적이지 않도록 하십시오.
예를 들어, 기능이 왜 설계되었는지에 초점을 맞추는 대신 특정 용어를 설명하는 교육적 기사 또는 일반적인 기술 문제를 해결하기 위한 멋진 기술이나 도구를 통합하는 방법을 보여주는 튜토리얼을 작성하십시오.
제품과 고객에 대해 더 많이 알게 되면, 자연스럽게 청중에게 무엇이 정말 중요한지에 대한 강한 의견이 형성됩니다. "고객 중심" 접근 방식을 유지하면 콘텐츠 품질을 향상할 수 있습니다. 시간이 지나면서 청중의 공감을 받는 콘텐츠를 작성할 수 있게 됩니다. 그렇지 않으면 콘텐츠가 자기 중심적으로 느껴질 위험이 있습니다.
전통적인 마케팅은 종종 "최선의 실무" 또는 "솔루션"을 강조하여 기업이나 개인에게 판매합니다. 이는 SaaS 제품이 주로 효율성과 생산성을 높인다는 아이디어에 기반합니다. 많은 전략이 금융 절약을 강조하는 데 초점을 맞추어 이점을 강조합니다. 성숙한 고객 기반을 갖춘 회사에서는 이것이 잘 작동할 수 있지만, 개발자에게는 불편을 줄 수 있습니다.
2년 전, 나는 제품을 위한 가치 제안과 큰 그림 내러티브 구축에 집중했습니다. 그러나 이 접근법은 개발자 청중과 항상 연결되지 않았습니다.
2년 전의 웹페이지를 보세요—"미래를 만들다"… 와우!
개발자를 만족시키고 그들의 문제를 해결하기 위해서는 매우 실용적이고 기반이 있어야 합니다. 개발자는 웅장한 이점에 의해 영향을 받지 않으며, 고이적 절차에 대한 유연성을 중요하게 생각합니다—특히 당신의 제품이 기존 기술 스택에 얼마나 쉽게 통합될 수 있는지. 그렇지 않다면 팔지 마십시오.
이제, 우리의 콘텐츠 전략은 훨씬 더 명확해졌습니다. 우리가 제공하는 특정 기능을 강조하여 사용자가 처음 화면에서 우리가 제공하는 내용을 빠르게 이해할 수 있게 합니다. 버즈워드나 높은 수준의 메시지에 의존하지 않고 말입니다.
호스팅된 상업용 버전을 처음 출시했을 때, 팀 내에서는 항상 열띤 토론이 있었습니다: 오픈 소스가 무료이기 때문에 개발자를 주요 고객으로 삼아 우리의 호스팅된 버전에 손해를 끼칠까요? 우리는 또한 오픈 소스 버전에서 일부 고급 기능을 제한할지 논의했습니다.
현재까지, 우리는 오픈 소스 및 호스팅된 버전의 핵심 기능을 거의 동일하게 유지하고 있습니다. 오픈 소스 커뮤니티의 성장은 기업 고객들과의 신뢰를 크게 구축했으며, 더 많은 대기업들이 합류하고 있습니다. 흥미롭게도, 이러한 기업들 중 일부는 우리 커뮤니티의 개발자 출신입니다. 이는 우리에게 자신감을 주었습니다. 대를 통해 개발자 문제를 해결하는 한, 성공은 자연스럽게 이루어질 것입니다.
결국, 문제 해결을 통해 개발자의 문제를 해결하는 데 주력하십시오. 인내하고 집중을 잃지 않으면 모든 것이 자연스럽게 해결될 것입니다.
읽어주셔서 감사합니다. 비슷한 작업을 진행 중이시면 경험과 생각을 자유롭게 공유하세요!