모든 고객이 커뮤니티를 원한다: 구축 전 범위 설정 가이드

요약

첫 번째 킥오프 콜에서 거의 모든 멤버십 클라이언트는 '커뮤니티를 원합니다'라고 말합니다. 그리고 그 문구는 조용히 프로젝트를 포럼, 이벤트, 코스, 라이브 룸 등 출시 시 아무도 사용하지 않을 포털로 확장시킬 수 있습니다. 이 기사는 에이전시가 그 모호한 요청을 작고 출시 가능한 멤버십 사이트로 바꾸기 위한 반복 가능한 스코핑 대화를 제공합니다. 문장 테스트('멤버들은 ___을 얻기 때문에 돈을 낸다')로 시작하고, 클라이언트를 하나의 비즈니스 모델로 강제하며, 실제 청중이 생길 때까지 커뮤니티 기능을 연기하고, 모든 기능 요청을 변경 주문으로 취급합니다. 이 기사는 전체 커뮤니티를 원했지만 검색 가능한 아카이브와 월간 라이브 Q&A를 출시한 클라이언트의 실례를 하나 포함합니다. 또한 참여를 약속하는 것에 대해 경고합니다: 문을 제공할 수는 있지만 사람들이 그 문을 통과하게 만들 수는 없습니다. 그 결과는 구조 임무가 아닌 제품 라인이 되고, 클라이언트는 당신이 구축하지 않기로 한 것에 대해 감사하게 됩니다.

첫 번째 킥오프 콜에서 클라이언트는 '커뮤니티를 원합니다'라고 말합니다. 당신은 고개를 끄덕이고, 그 단어를 메모에 입력하며, 로드맵이 조용히 두 배로 늘어나는 것을 느낍니다. '커뮤니티'는 포럼, 비공개 채팅 그룹, 페이월, 코스 라이브러리, 이벤트 시리즈, 회원 디렉토리 또는 전부를 의미할 수 있기 때문입니다. 그것이 전부를 의미하게 두면, 아무도 사용하지 않는 것들을 만드는 데 분기를 보내고, 클라이언트가 그것을 사용하지 않는 것을 지켜보는 일에 대해 청구하게 됩니다. 해결책은 더 영리한 플랫폼이 아닙니다. 매번 같은 방식으로 진행되는 더 솔직한 대화입니다. 그래야 다음 일곱 클라이언트 각각이 일회성 맞춤 프로젝트가 되지 않습니다.

이 글은 우리가 실제로 이 작업에서 계속 답하고 있는 질문들을 중심으로 구성됩니다. '어떤 도구를 사용해야 하나'가 아니라 — 그건 나중에 — 프로젝트가 제때 출시되고, 수익을 유지하며, 클라이언트가 당신이 무엇을 하고 있는지 알았다고 느끼게 하는 질문들입니다.

“우리는 커뮤니티를 원합니다” — 우리가 실제로 파는 것은 무엇인가?

플랫폼을 언급하기 전에 클라이언트가 한 문장을 완성하게 하세요: '멤버들은 ___을 얻기 때문에 돈을 낸다.' 그게 전부입니다. 그 빈칸을 구체적인 것으로 채울 수 없다면, 플랫폼을 선택하거나, 페이지를 스케치하거나, 가격을 제시할 준비가 되지 않은 것입니다. 전체 멤버십 사이트 — 페이월, 티어, 켜두는 기능 — 는 그 답을 전달하는 메커니즘일 뿐입니다.

클라이언트가 '커뮤니티'라고 말할 때 실제로 사려는 것은 네 가지 범주로 나뉘는 경향이 있습니다. 우리가 반복적으로 스코프를 정할 때, 그 결정을 그중 하나로 강제합니다:

멤버들이 지불하는 것	실제로 구축하는 부분	안전하게 연기할 수 있는 부분
콘텐츠 (코스, 아카이브, 도구)	게이트된 라이브러리, 결제 흐름, 기본 플레이어	라이브 룸, 이벤트 캘린더, 인증서
액세스 (제품, 서비스 또는 도구)	회원 로그인, 자격, 계정 게이트	공개 포럼 및 소셜 피드
연결 (동료, 책임감, 네트워킹)	하나의 토론 공간, 프로필, 초대	전체 코스 플랫폼, 콘텐츠 드립, 인증서
지위 (내부자, 조기 액세스, 독점 혜택)	계층형 액세스, 배지/라벨 로직, 간단한 혜택	포럼, 사용자 생성 콘텐츠, 라이브 이벤트

이 표는 스코핑 치트 시트이지 메뉴가 아닙니다. 클라이언트는 하나의 버킷만 얻습니다. 두 개를 병합하려고 하면 손을 들고 속도를 늦춰야 합니다. 비용이 올라갔기 때문입니다. 함정은 한 클라이언트를 위해 네 가지를 모두 수행하고 그것을 '참여형 커뮤니티 플랫폼'이라고 부르는 것입니다. 그것은 제품이 아니라 포털이며, 포털은 제때 출시되지 않습니다.

이 표는 의도적으로 작습니다. 멤버십 사이트가 동시에 네 가지가 되도록 허용하는 순간, 당신은 제품을 만드는 것을 멈추고 소규모 미디어 회사를 운영하기 시작한 것입니다. 클라이언트는 미디어 회사를 원하지 않습니다. 그들은 반복 수익을 원합니다. 수익 모델이 홈페이지에서 보일 수 있을 정도로 범위를 작게 유지하세요.

클라이언트가 같은 문장에서 '코스'와 '포럼'을 말하면, 어느 것이 비용을 지불하는지 물어보세요. 답이 '둘 다'라면, 그들은 아직 무엇을 팔고 있는지 모르는 클라이언트입니다. 그들 중 일부는 스코핑 과정에서 그것을 깨닫고 더 명확한 제안을 가지고 돌아옵니다. 그렇지 않은 사람들은 아직 준비가 되지 않았다는 것을 말해줍니다. 그것은 제안서를 작성하기 전에 배우는 것이 유용합니다.

하지만 그들은 이미 '커뮤니티'라고 백 번 말했다

여기 반대 의견이 있습니다. 겸손한 자랑이 아닙니다: 대부분의 멤버십 사이트는 커뮤니티 기능 없이 출시되어야 합니다. '커뮤니티'는 기능이 아닙니다. 그것은 소수의 사람들이 서로에게 반복적인 가치를 얻을 때 나타나는 행동이며, 어떤 플랫폼도 주문형으로 만들 수 없습니다. 그 단어는 '구독 수익'의 대체어가 되었고, 그래서 모든 클라이언트가 그렇게 말합니다. 그들을 위해 다시 번역해주는 것이 더 유용할 것입니다.

범위가 커지기 전에 커뮤니티 현실 확인을 하세요. 세 가지 질문을 하세요:

1. 첫 주에 새 멤버가 하기를 원하는 정확한 행동은 무엇인가요? ('참여'가 아니라 '자기소개 올리기', '댓글 남기기', '첫 번째 레슨 완료하기')
2. 첫 달 동안 당신 팀 중 누가 이 공간에서 시간을 보내며 답변하고, 방향을 잡고, 어수선함을 정리할 것인가요?
3. 이미 이 문제를 가지고 있고 서로 아는 소수의 사람들이 있나요, 아니면 웹사이트가 존재하기 때문에 낯선 사람들이 팀이 되기를 바라나요?

세 가지 모두 모호한 답을 얻으면, 커뮤니티를 만드는 것이 아니라 빈 방을 만들고 건축이라고 부르는 것입니다. 실용적인 방법은 모든 커뮤니티 기능을 연기하고 멤버십 스켈레톤을 출시하는 것입니다. 나중에 토론 공간을 추가할 수 있으며, 이미 나타날 이유가 있는 그룹에 추가하면 작동할 가능성이 있습니다. 이 질문 전체는 더 긴 논의가 필요합니다 — 실제 회원이 확보된 후에 커뮤니티가 와야 합니다 — 하지만 한 문장으로는: 청중이 존재하기 전에 원형 극장을 짓지 마세요.

실제로 작동할 수 있는 가장 작은 것은 무엇인가?

제안을 분류한 후 출시를 스켈레톤으로 설계하세요. 하나의 결제 옵션, 하나의 티어, 하나의 게이트된 자산, 하나의 커뮤니케이션 루프. 플랫폼의 기능 목록을 가져와 다른 모든 것을 꺼두세요. 네, 플랫폼은 라이브 비디오 룸, 회원 프로필, 이벤트 관리, 분석 대시보드를 할 수 있습니다. 그것이 문제입니다.

한 클라이언트가 B2B SaaS 제품을 위한 전체 커뮤니티 비전이라고 부르는 것을 가지고 우리에게 왔습니다. 그들은 포럼, 이벤트 캘린더, 리소스 라이브러리, '회원 스포트라이트' 섹션에 대해 이야기하고 있었습니다. 스코핑 중에 우리는 그들이 문장을 완성하게 했습니다: '멤버들은 ___을 얻기 때문에 돈을 낸다.' 그들의 답은 설립자의 조언에 대한 검색 가능한 아카이브와 월간 라이브 Q&A였습니다. 그래서 우리는 그것을 출시했습니다. 포럼도, 회원 프로필도, 이벤트 캘린더도 없었습니다. 얼마 지나지 않아 아카이브가 사용되었고, Q&A에는 단골이 생겼으며, 클라이언트는 비공개 토론 그룹을 요청했습니다. 회원들이 이미 제품 밖에서 서로 이야기하고 있었기 때문입니다. 그 그룹은 존재할 이유가 생긴 후에 만들어졌습니다. 그것이 작동하는 순서입니다.

전체 비전을 구축했다면, 더 많은 움직이는 부품과 어느 것이 실제로 습관을 만들었는지 알 수 없는 상태로 늦게 출시했을 것입니다. 아카이브는 실제 행동을 가리킬 수 있었지만, 사용되지 않은 라이브 룸은 청구서에 불과했을 것입니다. 교훈은 지루하지만 확실합니다: 출시가 작을수록 클라이언트가 실제로 무엇이 작동하는지 말해줄 가능성이 높아집니다. 슬림한 제품은 또한 다음 일을 잘 할 여지를 줍니다 — 티어 추가, 포럼 열기 — 출시 월에 쫓겨난 급한 추가가 아니라 의도적인 변경 주문으로. 티어와 수익 구조에 대해 반복 가능한 방법을 찾고 있다면, 반복 수익을 위한 멤버십 티어에 관한 글을 참조하세요. 하지만 스코핑이 먼저입니다.

요청이 쌓이면 어떻게 되나?

대부분의 멤버십 프로젝트가 어떻게 죽는지 솔직하게 말해봅시다: 무능력이 아니라 '하나 더'에서 비롯됩니다. 클라이언트가 경쟁사의 커뮤니티 데모를 보고 일치하는 기능을 원합니다. 올바른 반응은 '예'도 '아니요'도 아닙니다. '보류 목록에 추가하자'입니다.

보류 기능 목록을 프로젝트의 일급 산출물로 만드세요. 제안서에 넣고, 계속 보이게 하고, 범위를 벗어난 모든 요청을 추가하세요. 각 항목에 트리거 조건을 부여하세요. '언젠가'가 아니라 '이것은 200명의 활동 회원이 한 달 동안 공간에 있었을 때 출시됩니다' 또는 '클라이언트가 주당 2시간의 직원 시간을 중재에 투입할 때'와 같이. 당신은 어렵게 구는 것이 아니라 기능에 존재할 이유를 주는 것입니다.

이것이 모든 클라이언트를 위해 동일한 멤버십 사이트를 다시 구축하는 것을 멈추는 방법입니다: 모든 새 클라이언트를 이미 출시한 스켈레톤의 구성으로 취급하고, 의도적으로 구축하지 않은 것들의 목록을 포함합니다. 기능이 보류 목록에 있다면 미래 프로젝트이며, 또한 미래 수익입니다. 그렇게 프레임을 잡으면 클라이언트는 보통 동의합니다.

빈 포럼에 대해 클라이언트가 우리를 탓하지 않게 하려면?

통제할 수 있는 것과 없는 것에 대한 기대를 초기에 서면으로 설정해야 합니다. 결제 흐름, 게이팅, 이메일 자동화, 디자인을 제공할 수 있습니다. 사람들이 서로 대화하기로 결정하는 것을 제공할 수는 없습니다. 클라이언트의 '참여 문제'는 구축 문제가 아니라 운영 문제이며, 그것은 그들의 몫입니다.

출시 3주 후에 '커뮤니티'가 조용한 이유를 클라이언트가 은근히 묻기 시작하기 때문에 이것은 중요합니다. 처음부터 경계를 설정했다면 인센티브와 시딩에 대한 유용한 대화를 할 수 있습니다. 그렇지 않다면 고장나지 않은 플랫폼을 디버깅하게 될 것입니다. 그것을 공식화하는 실용적인 방법: 유지보수 리테이너에 '커뮤니티 호스팅 및 시딩'에 대한 별도의 라인 항목을 포함하거나, 프로젝트 킥오프에 포함된 시딩 체크리스트를 클라이언트에게 전달하세요. 요점은 노동 분업을 명시적으로 만드는 것입니다. 도구는 유지 전략이 아닙니다. 멤버십 사이트 신화는 사람들이 플랫폼이 그들을 위해 판매하길 기대할 때 일반적인 원인입니다.

그래도 커뮤니티를 고집하면 무엇을 켜야 하나?

클라이언트가 현실 확인을 통과하고 실제로 커뮤니티를 운영한다면, 정확히 하나의 토론 형식을 켜세요. 세 개가 아니라. 포럼은 스레드형이고 검색 가능하며 비동기식입니다. 라이브 룸은 즉각적이고 일시적이며 직원이 많이 필요합니다. 소규모 팀으로 둘 다 잘 중재할 수 없으며, 그렇게 하려고 하면 클라이언트에게 '커뮤니티'가 끊임없는 활동을 의미한다고 가르치게 됩니다. 그것은 약속해서는 안 되는 기준입니다.

실용적인 규칙: 하나의 공간, 하나의 형식, 한 명의 지명된 중재자. 현실 확인에서 식별한 행동과 일치하는 형식을 선택하세요. 원하는 행동이 '질문에 답하고 답을 얻는 것'이라면 포럼으로 시작하세요. '화요일 정오에 어려움을 이야기하기 위해 나타나는 것'이라면 라이브 이벤트로 시작하세요. 그런 다음 처음 90일 동안 가벼운 지표를 설정하세요: 총 회원 수, 가입 수가 아니라 목표 행동을 두 번 이상 한 회원 수. 활동이 두 번 언급되면 공간이 살아 있는지 박물관인지 알 수 있습니다.

이것을 제품 라인으로 가격 책정하려면? (구조 임무가 아니라)

발견 대화 자체를 청구 가능한 제품으로 만드세요. 스코핑 콜, 스켈레톤 구축(네, 정말), 결제 구성, 그리고 한 번의 수정 라운드를 포함하는 고정 요금 멤버십 사이트 설정 패키지를 만드세요. 그 이상의 모든 것 — 커뮤니티 디자인, 맞춤 기능, 중재 시간, 통합 — 은 별도의 작업 명세서입니다. 그것이 전부입니다. 각 선택 기능을 변경 주문으로 견적하면 클라이언트는 갑자기 우선순위를 정하는 법을 배웁니다. 모든 것을 하나의 상승하는 견적으로 묶으면, 더 많은 범위가 무료라고 가르치게 됩니다.

반복 가능한 프로세스는 다음과 같습니다: 콜 전에 보내는 설문지, 고정 가격의 한 페이지 작업 명세서, 팀이 이전에 실행한 구축 일정, 보류 기능 목록 템플릿. 디자인 무드보드가 존재하기 전에 클라이언트에게 라이브 날짜를 말할 수 있어야 합니다. 또한 더 나은 대화를 얻을 수 있습니다: 클라이언트는 최소한의 비용, 커뮤니티 추가 비용, 그리고 자신의 시간 비용을 봅니다. 그들이 스켈레톤에 지불하는 것을 꺼린다면, 그것이 아프기 전에 배우게 됩니다.

아무도 듣고 싶어 하지 않는 부분

모든 멤버십 사이트는 반복적인 행동에 대한 내기입니다. 플랫폼은 단지 봉투일 뿐입니다. 많은 클라이언트를 위해 이것을 구축하는 사람으로서 당신의 일은 봉투에 주소를 쓰고 우표를 붙이는 동시에 아무도 손으로 라이브 공연을 배달하는 일에 서명하지 않도록 하는 것입니다. 커뮤니티가 생기게 할 수는 없습니다. 조건을 만들고, 가능한 가장 작은 버전을 선택하고, 구축하지 않는 것에 대한 명확한 목록을 클라이언트에게 전달할 수 있습니다.

그 마지막 부분이 당신의 진짜 가치입니다. 클라이언트는 무엇을 빼야 할지 보지 못하기 때문에 당신을 고용했습니다. 그러니 그들을 위해 그것을 빼주세요 — 자신감 있게, 의도적으로, 서면으로. 일단 스코프를 정하면, 전달은 거의 지루해집니다: 멤버십 사이트 출시가 실제로 출시되는 것은 작고 결정이 사전에 이루어졌을 때입니다. 빈 포럼과 방대한 맞춤 포털은 비쌉니다. 제때 완성된 스켈레톤은 '강력한 커뮤니티 플랫폼'보다 훨씬 더 가치 있습니다.