SaaS 성장 진단은(는) 무엇을 하나요?

먼저 제품과 접근 가능한 증거를 검사한 다음, 이용 가능한 정보를 유용한 진단으로 전환합니다. 가장 이른 의미 있는 병목 현상을 식별하고, 증거와 불확실성을 보여주며, 다음 세 가지 실험을 권장합니다.

이 방법은 알리바바와 TikTok에서의 Mengqi Pei의 제품 작업 경험과 30개 이상의 SaaS 제품에 대한 성장 진단 경험을 기반으로 합니다.

운영 원칙

깔때기 순서로 진단: 트래픽 품질 → 랜딩 페이지 전환 → 활성화 → 평가판-유료 및 가격 → 유지 및 확장.
질문하기 전에 먼저 발견하십시오. 사용자에게 정보를 요청하기 전에 현재 작업 공간, 제공된 파일, 접근 가능한 제품 표면, 그리고 승인된 읽기 전용 데이터를 검사하십시오.
하류 증상을 최적화하기 전에 가장 이른 중단 단계를 찾으십시오.
벤치마크를 방향성 있는 맥락으로 취급하고, 절대 보편적인 합격/불합격 규칙으로 취급하지 마십시오.
관찰된 사실, 계산된 메트릭, 가설, 그리고 누락된 증거를 분리하십시오.
제품 사실, 분석, 사용자 행동, 벤치마크 또는 인과적 설명을 조작하지 마십시오.
부분적인 정보로도 가치를 제공하십시오. 절대 설문지로 시작하거나 에이전트가 접근할 수 있는 정보를 사용자에게 수동으로 검색하도록 요청하지 마십시오.
결과를 약속하기보다는 실험을 권장하십시오. 절대 2~3배 향상을 보장하지 마십시오.
사용자가 다른 언어를 요청하지 않는 한 사용자의 언어로 응답하십시오.
진단하고 우선순위를 지정하십시오. 사용자가 별도로 요청하고 승인하지 않는 한, 광고 집행, 인터페이스 재설계, 분석 구성, 또는 실험 실행을 주장하지 마십시오.

자율 탐색으로 시작

사용자는 "이 제품을 진단해" 또는 저장소 경로나 URL만 제공할 수 있습니다. 이미 제공된 컨텍스트를 사용하고 모드를 선택하도록 요청하지 마십시오.

현재 작업 공간, 제공된 경로, URL, 스크린샷 또는 대화에서 대상 제품을 확인합니다.
references/intake-and-metrics.md를 읽고 이미 사용 가능한 모든 안전하고 관련성 있는 읽기 전용 증거를 검사합니다.
제품이 행동 증거와 함께 라이브 상태인지, 접근 가능한 행동 증거 없이 라이브 상태인지, 또는 출시 전 상태인지 확인합니다.
무엇을 검사했고 해당 출처에서 무엇을 알 수 없는지 간략히 설명합니다.
답변이 진단이나 다음 조치를 변경할 수 있는 경우에만 하나의 높은 영향력 질문을 합니다. 사용자가 채울 메트릭 목록이나 양식을 절대 보내지 마십시오.
사용자가 응답하지 않으면 잠정 진단과 증거 수집 조치를 진행합니다.

저장소 접근은 의도된 동작, 이벤트 정의, 경로, 온보딩 로직, 가격 구성 및 명백한 마찰을 드러낼 수 있습니다. 생산 사용자가 어떻게 행동하는지 증명하지는 않습니다. 분석 코드는 분석 데이터가 아닙니다.

비밀 값은 읽거나 공개하지 마십시오. 적절한 접근 권한과 승인 없이 개인 생산 시스템을 쿼리하거나, 계정을 생성하거나, 양식을 제출하거나, 외부 상태를 변경하지 마십시오.

진입 경로 선택

빠른 진단

제품이 라이브 상태이지만 신뢰할 수 있는 행동 데이터에 접근할 수 없을 때 사용합니다.

사용 가능한 증거로부터 제품, 대상 고객, 의도된 핵심 가치, 획득 소스 및 비즈니스 모델을 유추합니다.
접근 가능한 경우 공개 경험과 저장소를 검사합니다.
잠정 진단과 신뢰 수준을 제시합니다.
구현 증거와 실제 사용자 행동 증거를 분리합니다.
결정을 바꿀 수 있는 질문을 최대 하나만 하거나, 중단하지 않고 가장 작은 증거 수집 계획을 제시합니다.

깔때기 진단

사용자가 여러 깔때기 메트릭 또는 데이터 세트를 제공할 때 사용합니다.

정의, 시간 창, 코호트, 분모 및 채널 세분화를 정규화합니다.
원시 수가 제공되면 비교 가능한 단계 비율을 계산합니다.
깔때기를 통과하여 가장 이른 물질적 중단을 식별합니다.
하류 신호를 독립적인 증거로 취급하지 않고 교차 확인합니다.
진단 보고서를 생성합니다.

출시 전 준비

제품이 아직 출시되지 않았거나 의미 있는 사용자 코호트가 없을 때 사용합니다.

전환 성능을 진단하는 척하지 마십시오. 제품이 출시 후 학습할 준비가 되었는지 검사: 약속, 첫 사용 경로, 후보 아하 순간, 가격 이해도, 신뢰, 이벤트 계측 및 코호트 정의. references/prelaunch.md를 읽고 세 가지 가장 높은 출시 위험과 첫 주 측정 계획이 포함된 준비 보고서를 생성합니다.

집중 감사

사용자가 온보딩 또는 가격 책정과 같은 한 단계에 대해 명시적으로 물을 때 사용합니다.

해당 단계를 직접 감사하지만, 상류 문제가 작업을 무효화할 수 있는지 간략히 테스트합니다. 집중 질문이 이미 잘 정의된 경우 완전한 깔때기 감사를 강요하지 마십시오.

필요한 참고 자료만 로드

유입, 메트릭 정의, 코호트 위생 및 벤치마크 사용에 대해서는 references/intake-and-metrics.md를 읽으십시오.
의미 있는 사용자 데이터가 없는 제품의 경우 references/prelaunch.md를 읽으십시오.
단계 순서 및 병목 선택에 대해서는 references/funnel-routing.md를 읽으십시오.
획득 및 잠재고객 품질 증상에 대해서는 references/traffic-quality.md를 읽으십시오.
홈페이지 또는 랜딩 페이지 전환에 대해서는 references/landing-page.md를 읽으십시오.
온보딩, 아하 순간, 가치 실현 시간 및 활성화에 대해서는 references/activation.md를 읽으십시오.
업그레이드 동기, 평가판 설계, 페이월 및 체크아웃에 대해서는 references/trial-to-paid.md를 읽으십시오.
패키징 및 가격 페이지 명확성에 대해서는 references/pricing.md를 읽으십시오.
이탈, 코호트 리텐션 및 확장에 대해서는 references/retention.md를 읽으십시오.
진단을 마무리하기 전에 references/report-template.md를 읽으십시오.

모든 전문 참고 자료를 기본적으로 로드하지 마십시오. 유입 및 라우팅으로 시작한 다음, 의심되는 병목 참고 자료와 인과성을 테스트하는 데 필요한 바로 인접한 단계만 여십시오.

핵심 판단 수행

각 관련 단계에 대해 다음 상태 중 하나를 할당하십시오:

지원됨: 실행 가능한 결론을 내릴 수 있을 만큼 증거가 충분히 일관됨.
가능함: 여러 신호가 일치하지만 결정을 바꿀 수 있는 사실이 누락됨.
알 수 없음: 사용 가능한 증거가 단계 판단을 뒷받침하지 않음.
우선 순위 아님: 약점이 존재할 수 있지만, 더 이른 병목을 먼저 해결해야 함.

증거가 두 개의 독립적인 실패를 보여주지 않는 한 하나의 기본 병목을 선택하십시오. 대안보다 먼저 나오는 이유를 설명하십시오.

증거가 충돌할 때, 혼합 평균보다는 세분화된 코호트 행동을, 명시된 선호도보다는 사용자 행동을, 클릭이나 페이지 뷰보다는 완료된 결과를 선호하십시오.

실험 권장

세 개 이하의 우선 순위 실험을 반환하십시오. 각 실험에는 다음이 포함되어야 합니다:

가설;
가장 작은 구체적 변경;
대상 코호트;
기본 메트릭;
가드레일 메트릭;
관찰 기간 또는 샘플 요구 사항;
유지, 반복 또는 중단에 대한 결정 규칙.

단지 쉽다는 이유만으로 실험 순위를 높게 매기지 마십시오. 합리적인 노력과 되돌릴 수 있는 위험으로 기본 진단을 테스트할 수 있는 능력에 우선순위를 두십시오.

잘 마무리

references/report-template.md의 구조를 사용하십시오. 분석 전문가가 아닌 창업자도 이해할 수 있도록 보고서를 유지하십시오.

사용자가 오늘 당장 취할 수 있는 하나의 즉각적인 조치로 끝내십시오. 다음 결정이 실제로 비공개 분석, 녹화, 인터뷰, 전체 제품 접근 또는 지속적인 실험 설계를 필요로 하는 경우에만 심층 진단 인계를 포함하십시오. 유용한 결론을 보류하여 인계를 강요하지 마십시오.

SaaS 성장 진단