FeedLog를 만들기 시작했을 때, 저는 꽤 간단한 아이디어를 가지고 있다고 생각했습니다. 작은 SaaS 팀들에게 사용자 피드백을 수집하는 더 나은 방법을 제공하는 것이었습니다.
첫 번째 버전은 피드백 보드, 기능 요청, 공개 로드맵, 변경 로그에 초점을 맞췄습니다. 특별히 복잡한 것은 없었습니다. 사용자들이 아이디어를 공유하고 창업자들이 사람들이 원하는 것을 추적할 수 있는 장소일 뿐이었습니다.
저는 그 아이디어가 마음에 들었습니다. 다른 창업자들도 그렇게 생각할 것이라고 생각했습니다.
그러다 사용자들을 찾아보려고 노력했습니다.
구축은 쉬운 부분이었다
인디 개발자들에게 연락하고, SaaS 창업자들과 이야기하며, 사람들의 관심을 제품에 얻으려고 많은 시간을 보냈습니다.
대부분의 대화는 정중했습니다. 몇몇 사람들은 흥미로워 보인다고 말했습니다. 하지만 누군가가 실제로 다른 도구를 자신의 제품에 통합하도록 하는 것은 제가 예상했던 것보다 훨씬 어려웠습니다.
그리고 한참 후에, 저는 원래의 아이디어에 대해 의문을 갖기 시작했습니다.
피드백 도구가 유용하지 않은 것은 아닙니다. 정말로 유용합니다. 하지만 시간이 제한된 작은 SaaS 창업자에게 기능 요청을 수집하는 것이 가장 시급한 문제가 아닐 수도 있습니다.
모든 것을 직접 처리하고 있다면, 고객 질문에 답하고, 버그를 수정하고, 어려움을 겪는 사용자들을 돕는 것에 더 신경 쓰고 있을 가능성이 높습니다.
피드백 보드는 있으면 좋은 것입니다. 고객이 필요할 때 도움을 받는다는 느낌은 훨씬 더 즉각적입니다.
그 깨달음이 제가 제품에 대해 생각하는 방식을 바꿨습니다.
대부분의 제품 피드백은 대화에서 시작된다
제가 처음 시작했을 때 진정으로 고려하지 못했던 것이 있습니다.
고객들은 지원 요청과 제품 피드백을 항상 분리하지 않습니다.
누군가는 기능을 어떻게 사용하는지 물어보다가, 현재 워크플로우가 혼란스럽다고 언급할 수 있습니다. 다른 사람은 버그를 보고하면서 같은 작업을 처리하는 더 나은 방법을 제안할 수도 있습니다.
때로는 간단한 지원 대화가 전용 피드백 양식보다 무엇을 개선해야 하는지에 대해 더 많이 알려줍니다.
하지만 그러한 대화들은 잃어버리기 쉽습니다.
질문에 답하고 채팅을 닫은 다음, 다른 일을 합니다. 일주일 후, 누군가 유용한 것을 제안했던 것이 어렴풋이 기억나지만, 누가 또는 정확히 무엇을 말했는지 기억할 수 없습니다.
저는 지원(support)과 피드백(feedback)이 정말로 분리된 공간에 존재해야 하는지 의문을 갖기 시작했습니다.
그래서 저희는 FeedLog의 방향을 바꿨습니다
단순히 피드백 관리 도구만 계속 구축하는 대신, 고객 지원 쪽으로 작업을 시작했습니다.
일반적인 질문에 답변하도록 돕는 AI 고객 지원 기능, 팀이 자체 도움말 콘텐츠를 생성하고 관리할 수 있는 지식 기반(knowledge base), 그리고 인간의 주의가 필요한 대화를 위한 받은 편지함(inbox)을 추가했습니다.
원래의 피드백 기능들, 즉 피드백 보드(feedback boards), 로드맵(roadmaps), 변경 로그(changelogs)는 여전히 존재합니다.
다르다는 점은 제가 이들을 바라보는 방식입니다.
고객이 피드백 보드를 방문하여 아이디어를 제출할 것이라고 기대하기보다는, 일반적인 지원 상호작용 중에 유용한 피드백을 포착하는 것을 더 쉽게 만드는 것이 목표입니다.
이것이 저희가 FeedLog로 탐구하고 있는 방향입니다: AI 고객 지원과 제품 피드백을 결합하여, 여러 개의 분리된 도구를 관리하기를 원하지 않는 작은 팀들을 위해 특히 그렇습니다.
지식 기반(knowledge base)이 중요한 이유
제가 피하고 싶었던 것 중 하나는 단순히 일반적인 답변만 제공하는 AI 챗봇을 구축하는 것이었습니다.
누군가 귀하의 제품에 대해 질문하면, 그 답변은 귀하의 제품에 대한 실제 정보에서 나와야 합니다.
여기서 지식 기반이 역할을 합니다.
창업자는 도움말 아티클(help articles)을 만들고, 일반적인 질문들을 문서화하며, 제품 정보를 정리할 수 있습니다. 그런 다음 AI 어시스턴트는 그 콘텐츠를 사용하여 고객에게 응답할 수 있습니다.
또한 이는 팀이 시간이 지남에 따라 문서를 개선할 이유를 제공합니다.
만약 고객들이 계속 같은 질문을 한다면, 답변을 찾기가 더 쉬워야 할 수도 있습니다. 만약 AI가 무언가를 답변하는 데 어려움을 겪는다면, 어쩌면 지식 기반에 중요한 정보가 빠져있기 때문일 수 있습니다.
지원(support) 대화가 사용자들이 무엇을 묻는지뿐만 아니라, 문서와 제품 경험 중 어느 부분이 개선이 필요한지 이해하는 데 도움이 될 수 있다는 아이디어가 좋습니다.
여전히 하나의 큰 질문이 남아있다
제가 이 변화가 우리의 사용자 확보 문제(user acquisition problem)를 즉시 해결했다고 말할 수 있다면 좋겠습니다.
하지만 그렇지 않습니다.
저희는 아직 초기 단계이며, 고객 지원과 피드백을 결합하는 것이 소규모 SaaS 팀들이 정말 원하는 것인지 여전히 파악 중입니다.
또한, 제가 사용자들을 찾느라 고군분투했기 때문에 단순히 제품을 더 복잡하게 만들었을 가능성도 있습니다.
몇 주 동안 새로운 기능을 구축한 후에 생각하기에는 꽤 불편한 생각이네요.
하지만 사람들이 왜 채택하지 않는지 이해하지 못한 채 제품을 계속 다듬는 것보다는, 이 방향성을 테스트하는 것이 낫습니다.
저희는 FeedLog를 공개적으로 구축하고 있으며, 프로젝트를 탐색하고 싶은 분들을 위해 소스 코드는 GitHub에서 이용 가능합니다.
다시 시작한다면 다르게 할 것들
저는 아마도 문제에 대해 제가 이해한다고 가정하는 데 시간을 덜 쓰고, 창업자들이 실제로 고객 요청을 어떻게 처리하는지 관찰하는 데 더 많은 시간을 보낼 것 같습니다.
그들의 지원 대화가 어디서 발생하는지, 기능 요청(feature requests)은 어떻게 추적하는지, 그리고 이 두 워크플로우 사이에서 무엇이 손실되는지를 물어볼 것입니다.
그리고 그들의 가장 큰 좌절감이 질문에 답하는 것인지, 피드백을 정리하는 것인지, 아니면 단순히 관리해야 할 도구가 너무 많은 것인지를 이해하려고 노력할 것입니다.
왜냐하면 더 많은 기능을 추가하는 것이 반드시 진전(progress)을 의미하지는 않기 때문입니다.
때로는 단지 구축해야 할 것을 더 많이 발견했다는 의미일 뿐입니다.
저는 이것이 어느 쪽인지 여전히 파악하려고 노력 중입니다.
만약 SaaS를 구축하고 있다면, 고객 지원과 제품 피드백을 분리하여 관리하나요? 아니면 둘 다 한 곳에 모아두는 것이 더 좋을까요?