by
Aug 27. 2023
#12 제품 세미나와 판매 전략
2023년 34주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/55
다음 회고 ☞ https://brunch.co.kr/@327roy/57
인트로
#1 동호회 가입
회사의 동호회에 가입했다.
가입한 곳은 사내 밴드 동호회!
회사로 인해 형성된 네트워크 속에서 작은 네트워크가 또 생기는 순간이다.
회사가 동호회를 지원해주고, 동호회의 사람들을 회사를 통해서 만났다는 그 사실이 회사에 애착심을 더 가지게 만드는 것 같다. 보이지 않는 가치에 과감히 투자하는 회사가 멋있기도 하고, 우리도 모르는 사이 그 가치가 회사에게 발현되고 있다는 사실이 조금씩 체감되기도 하고.
노트
#2 제품 세미나와 판매 전략
#판매전략 #세미나 #B2B #SaaS
B2B SaaS 제품의 PM/기획자로 일하게 되면서 가장 먼저 체감한 특징은 제품의 판매 전략이었다.
일반적인 B2C 제품의 경우 타깃 고객이 대부분 일반 대중인 만큼 제작한 광고 소재의 도달 범위가 많은 것이 유의미한 결과라고 생각한다. 다수의 대중들이 구매력을 가지고 있으며, 결국 그들은 잠재 고객이 될 수 있기 때문이다. 그래서 일전에는 UTM, GTM 등 사용자 추적을 위한 다양하고 재밌는 방법을 공부하며 적용했다.
하지만 B2B 제품, 특히 SaaS 제품의 경우 접근을 달리할 수밖에 없다. 주 타깃 고객이 기업인 만큼 고객의 업종과 규모, 의사결정권자와 절차에 큰 영향을 받기 때문이다. 특히 실제 사용자는 회사의 구성원이라고 할지라도, 기업의 경영진 몇 명을 설득했을 때 제품이 팔리는 경우가 많다. (e.g., 성과관리 솔루션)
B2B SaaS 제공자들이 온/오프라인 행사를 여는 것이 이 때문일 것이다. (e.g., 제품 세미나) [온라인 광고 > 고객 유입 > 제품 판매] 흐름이 이루어지기엔 기업은 의사결정 절차가 훨씬 길며 의사결정에 소비되는 비용이 비싸기 때문이다. 그래서 제품 시연(Demo)이 효과적일 때가 더 많다.
이러한 배경으로 자사에서는 제품 세미나를 연에 몇 번씩 개최한다. 기획자인 만큼 제품을 잘 알고, 설명할 수 있기 때문에 행사 지원을 나갈 때가 종종 있는데, 덕분에 실제 고객사 혹은 잠재 고객들의 목소리를 눈앞에서 들을 수 있다. 고객들의 목소리를 생생하게 들으며 시사성을 띈 기능을 확인할 수도 있고 말이다.
다만 오프라인 행사를 개최할수록 생기는 걱정은 1) 현재 자사 제품이 시즈널한 성격을 가지고 있다는 것과 2) 오프라인 행사의 물리적 한계다.
자사 제품이 가장 많이 활성화되는 시기는 상반기, 하반기 정도인데, 이 때문에 고객의 반응이 한참 뒤에야 온다는 것. 미리 고객들에게 제품을 인지시킨다는 관점에서는 성공적일 수 있겠지만, 반응이 나중에 온다는 것은 각 세미나별 퍼포먼스 파악이 힘들다는 것이다. 따라서 회사에서 행사 기획을 할 때 비용을 보다 넉넉히 잡을 것이고, 결국 지속적인 누수 비용(인력 지원 등)이 발생하지 않을까 걱정된다.
또한 세미나는 보통 서울에서 평일에 주최하는데, 이 때문에 서울/경기가 거점이 아닌 회사가 참여하는 것은 사실상 무리가 있다.
이 두 가지 특징 이 때문에 먼 미래의 이야기겠지만 온라인 비즈니스임에도 불구하고 시장의 고갈을 생각하게 된다. 다른 서비스와 전략의 궤를 유사하게 한다면 [제품 콘텐츠 발행 및 온라인 마케팅 → 팬덤/커뮤니티 형성 → 웨비나]로 풀어가는 방법이 있을 것이다. 옆동네 ‘F사’, ‘L사’가 비슷한 방법을 하고 있기도 하다.
우리의 전략은 현재로서 좋은 선택이라고 생각하지만, 안전장치를 생각할 필요도 있다.
#3. 챗 GPT가 말해주는 B2B SaaS 마케팅 전략
#챗GPT
[Prompt]
A회사의 제품은 마케팅 전략에 어떤 주안점을 두고, 어떤 마케팅 전략을 사용할 수 있을까?
조건 1. 위 회사는 [~~~ SaaS 제품]을 만드는 회사야.
조건 2. 보편적인 B2C 제품과 비교해서 작성해 줘
조건 3. (제품에 대한 상세 맥락 설명)
[Response]
B2B (Business-to-Business) 제품인 귀사의 SaaS 제품과 일반적인 B2C (Business-to-Consumer) 제품의 마케팅 전략은 여러 가지 측면에서 차이가 있습니다. 여기에는 주요 차이점과 B2B 제품에 대한 몇 가지 마케팅 전략을 설명하겠습니다.
B2B vs B2C 마케팅 전략의 주요 차이점
1. 대상 고객:
◦ B2B: 기업, 조직, 혹은 전문가들이 주요 고객이며, 복잡한 의사결정 과정을 거칩니다.
◦ B2C: 개인 소비자를 대상으로 하며, 비교적 간단한 구매 결정을 내립니다.
2. 판매 주기:
◦ B2B: 판매 주기가 길고, 계약 협상과 승인 과정이 필요합니다.
◦ B2C: 판매 주기가 짧고, 즉각적인 구매가 일반적입니다.
3. 제품 복잡성:
◦ B2B: 제품이 복잡하고 맞춤화가 필요할 수 있으며, 전문 지식이 필요합니다.
◦ B2C: 제품이 단순하고 직관적일 수 있으며, 일반 소비자가 쉽게 이해할 수 있습니다.
4. 가격과 가치:
◦ B2B: 높은 가격대의 제품이며, ROI (투자 수익률)에 중점을 둡니다.
◦ B2C: 저렴한 가격과 편리함, 감성적인 가치에 중점을 둡니다.
5. 커뮤니케이션 채널:
◦ B2B: 전문적인 콘텐츠 마케팅, 세미나, 전시회, 이메일 마케팅 등이 중요합니다.
◦ B2C: 소셜 미디어, TV 광고, 온라인 광고 등이 효과적입니다.
B2B 마케팅 전략
1. 콘텐츠 마케팅: 전문가들을 대상으로 전문 지식을 공유하는 블로그, 웹세미나, 화이트페이퍼 등을 제공합니다.
2. 관계 구축: 장기적인 관계 구축을 위해 고객과의 긴밀한 협력과 신뢰 구축에 중점을 둡니다.
3. 맞춤형 솔루션 제공: 고객의 특정 요구 사항과 문제를 해결하기 위한 맞춤형 제품 및 서비스를 제공합니다.
4. ROI 중심의 접근: 고객에게 제품이 가져올 수 있는 구체적인 경제적 이익을 강조합니다.
5. 계정 기반 마케팅 (ABM): 특정 기업이나 조직을 대상으로 한 마케팅 전략을 구축하여 효율적으로 리소스를 활용합니다.
B2B 제품의 마케팅은 복잡한 의사결정 과정과 긴 판매 주기를 고려해야 하므로, 전략적인 접근과 전문 지식이 필요합니다. 귀사의 SaaS 제품의 경우, 고객의 특정 요구와 문제를 해결하고, 조직의 성장과 효율성을 향상하는 방법을 중심으로 전략을 구축하는 것이 효과적일 것입니다.
p.s.
맥락을 설명해 줬음에도 불구하고 챗GPT의 답변은 보편적인 B2B, B2C 서비스의 마케팅 전략 차이 정도를 설명한다.
Prompt의 맥락 설명이 부족했거나, 챗GPT의 학습된 자료로서 서비스에 대한 이해가 부족한 것이 이유가 아닐까.
전략을 보다 디테일하게 뽑아내려면 서비스, 제품 관점이 아니라 이론과 사례 중심으로 우회 접근해야 할 듯하다.
#4 롱블랙
#롱블랙 #피식대학 #성장 #회고
종종 PM들이 모인 톡방에 콘텐츠 구독 서비스 롱블랙의 아티클을 올려주시는 분이 있다.
아티클이 발행된 당일 동안은 아티클 내의 광고 시청 시 본문을 모두 읽을 수 있어서 좋다. 본문은 대부분 고퀄리티 인터뷰 내용으로 짜여 있어 좋은 인사이트를 많이 얻는다.
이번 주에는 피식대학 멤버들의 인터뷰에 대한 글이 올라왔다.
글을 읽고 먼저 든 생각은 성장에 대한 집착을 통해 성공한 분들이라는 것이었다. 무엇이든 자신의 분야에서 성공하는 사람들은 시기를 잘 잡은 것도, 운이 좋기도 했다는 것은 맞겠지만, 결국 이미 준비가 잘 되어 있었기에 가능했던 것이라고 생각한다.
별개로 그들이 어떤 분석과 생각을 거쳐 피식대학이 세상에 나오게 되었는지, 멤버들이 어떻게 모이게 되었는지도 알 수 있어서 좋았다.
성장에 집착하는 사람들은 어떤 형태로든 회고를 이어나가는 것 같다. 어떤 분야든 개선과 발전은 돌아보기와 흐름 읽기에서 이루어지는 듯.
https://www.longblack.co/note/795?ticket=NTf37be1d10faf3ec9a4659cc9bfe303644fbf5a30
p.s. 롱블랙에서는 그날 발행된 아티클의 경우 5초짜리 광고를 보면 누구나 본문을 읽을 수 있게 해 준다. 위에 첨부한 링크는 24시간의 유효기한을 가지고 있는 링크인데, 유효기한이 다 되면 아티클은 구독을 해야만 확인할 수 있게 된다.
ⓒ 롱블랙첨부한 URL을 보면 롱블랙 아티클 고유번호 뒤에 ?ticket=으로 시작하는 파라미터를 확인할 수 있다. 이 파라미터를 통해 접근 권한을 확인하는 것으로 추측된다.
만약 내가 이를 기능으로 구현한다면 어떻게 할까? 아마 [관리자가 백오피스(CMS) 진입 > 아티클 관리 > 아티클 클릭하여 ‘공유링크 생성’ > 24시간 유효 기간을 지닌 공유링크가 생성됨]의 흐름으로 기능을 기획할 것 같다. 공유링크 생성 버튼 클릭 시 특수한 접근 권한을 가지고 있는 파라미터를 생성하는 형태로! 그리고 생성자에 대한 보안 로그를 따로 관리할 듯하다.
보통 기획자는 실제로 제품을 구현하는 사람보다 ‘왜’와 ‘무엇’에 더 집중하는 사란들이라고 생각한다. 이 때문에 가끔은 내가 요청한 것이 어떤 기술을 통해 구현되었는지(어떻게)를 알게 되면 재밌기도 하다.
#5 숨은 로직 찾기
#로직 #기획부채
자사 제품에는 파견온 기획자와 개발자가 다이렉트 메시지로 소통하며 제작한 화면과 기능이 있다.
문제는 대부분의 이런 화면, 기능들은 기획서와 히스토리 그 무엇도 없다는 것. 그런 상황에서 CX팀을 통해 고객사가 특정 화면의 로직을 알고 싶다는 요청이 들어왔다. (이 화면에는 특정 정보의 상태값을 보여주는 기능이 있는데, 그 기능의 상태값별 정책을 궁금해했다.)
이 정보의 상태값은 특정 수치별로 if 분기를 태워 프론트 단에서 바로 처리하는 것이었는데, 이걸 직접 테스트하면서 확인하는 것은 비효율적이기에 개발 리더분께 요청해서 함께 코드를 직접 확인하며 로직을 역추적했다. 코드를 해석하고 나서 시나리오를 몇 개 대입해 보았는데 엥 이런. 로직에 구멍이 존재했다. 정말 코드를 까봐야만 알 수 있는 구멍.. 특정 조건일 때 절대 가장 상위 위계의 상태값이 나올 수가 없었다.
이후 이를 메우기 위한 추가 정책까지 기획해서 개발 리더에게 Jira 티켓을 전달하고, CX팀에게는 고객 문의 대응을 위한 가이드를 전달했다. 다음 주초까지 관련 매뉴얼을 작성해서 아카이빙 하면 이번 이슈는 클로징. 과거의 기획 부채가 지금 나에게 이자와 함께 찾아온 번거로운 건이었다. (1~1.5 시간 정도 소모함)
업무 공유와 히스토리 관리를 잘해야 하는 이유를 다시 한번 느낌.
#6 실수를 숨기지 않는다는 것
#실수 #인정
사람은 누구나 실수를 한다.
남에게 드러나는 실수든, 드러나지 않는 실수든, 실수가 크든 작든 실수는 하기 마련이다.
이 중 위험하다고 생각하는 실수의 유형은 ‘남에게 당장 드러나지 않는 큰 실수’라고 생각한다. 예를 들어 기획자의 입장에서 큰 실수라고 하면 보통 현재 개발 중인 건에 대해서 개발을 갈아엎어야 하는 정도의 실수라고 말할 수 있을 것이다. (실수를 실수라고 인지하지 못하는 경우도 있다. 이것도 무서움)
이런 실수가 무서운 점은 실수를 말하는 것이 겁이 나 숨기면 숨길수록 실수의 크기가 점점 커지게 된다는 것이다. 개발이 완료되고 QA 중에서야 실수를 인정하게 되면 일정 조정도 힘들뿐더러, 이로 인해 그 상황에서의 차악책을 찾아야 할 수도 있다.
가령 기존 프로세스를 개선하는 기획을 할 때 중요한 사용자 시나리오를 고려하지 않은 경우라면? 실수를 잘 숨기고 배포된다 하더라도 빠른 시일 내 고객들로부터 버그로 접수될 것이다. 그리고 결국 기존 정책과 비교하여 실수가 동네방네 알려지게 될 것이다. 따라서 스스로 알아차린 실수라면 빠르게 이해관계자(개발 담당자, 제품 책임자)에게 알릴 수 있는 용기가 필요하다고 생각한다.
#7 신기능 마이너 배포
#Semantic #마이너 #배포
제품의 마이너 배포가 있는 날에는 오전 8시 전에 출근한다.
제품의 특성상 신기능 배포의 경우 이른 오전(고객사 출근 전) 혹은 저녁(고객사 퇴근 후)에 가능한데, 내가 입사하기 전에는 저녁에 배포를 하다가 현재는 오전 배포로 일정을 가져가고 있다.
아침에 잠을 많이 자는 것을 좋아하지 않는 터라 본인의 경우 아침 배포를 더 좋아하는데, 회사와 물리적 거리로 인해 신기능 배포하는 날에는 새벽 5시 반쯤 일어나서 출근하는 편이다.
배포가 무사히 완료되면 빠르게 배포된 신기능들을 검증한다. 이때 개발자 및 기획자가 모두 달라붙어 검증에 집중하는데, 중간중간 CX팀으로부터 리포팅되는 버그로 인해 검증이 오후까지 미뤄지는 경우도 있다. 다른 버그들을 빠르게 발견해서 다행이다 싶으면서도, 배포한 기능이 아닌 다른 기능의 버그 처리로 인해 검증이 미뤄지는 게 불안하기도 하다.
따라서 마이너 버전 배포라고 할지라도, 제품의 이해관계자와 고객이 부담되지 않을 만큼의 배포 기능 적정 수를 유지할 필요가 있다고 느낀다. 3~4주에 한 번 마이너 버전 배포를 하는데, 배포하는 기능이 너무 많아도 문제이니 말이다. 과연 고객에게 한 번에 업데이트된 수많은 기능의 가치가 잘 전달될까 물으면 그것은 또 아닐 것이다.
p.s. 이번 회사의 장점 중 하나는 애자일적인 프로젝트 관리 프로세스 등 다양한 프로세스를 많이 경험할 수 있다는 것이다. 우리는 Jira를 특히 잘 활용하고 있는데, Jira를 사용한 릴리즈 버전 관리 프로세스가 참 알차다. 규모가 작은 스타트업이라면 이 정도 관리는 불필요하겠지만, 그래도 이를 알아둠으로써 앞으로 더 질 좋은 제품을 만들 수 있을 환경을 구축할 수 있을 듯하다.
#8 34주 차 KPT
#회고 #성찰 #KPT
[KEEP]
1. 이번 마이너 배포도 무사히 완료!
2. 가입한 밴드 동호회의 첫 합주를 진행했다. 스트레스 뻥! 회사 생활의 만족도도 UP!
3. 마일스톤 회고가 상당히 인상 깊었다.
- Celebration Grid Retrospective 프레임워크를 사용했다.
- 개발팀, 고객가치팀, 사업팀, 기획팀, 대표님 등 많은 이해관계자가 모여 내용을 공유하고 개선 방법을 찾아보는 시간을 가져서 좋았다.
- 나중에 기회가 되면 따로 글로 풀어볼 생각이다.
ⓒ agilefellow