1️⃣ 피그마에서 일하면서 고객 집착에 대해 배운 것
원본 링크 : https://www.lennysnewsletter.com/p/what-working-at-figma-taught-me-about
이미지 클릭 시 링크 이동
✅ 7년 동안 제품 부사장으로서 Figma를 이끌어온 Sho Kuwamoto의 글
– Figma의 첫 번째 제품 리더였으며, 지난 7년 동안 제품 부사장으로서 Figma를 이끌어온 Sho Kuwamoto가 Figma에서 배운 점들에 대해 작성한 글입니다. 그는 고객 집착이 Figma가 전 세계 사람들에게 사랑받는 제품이 될 수 있었던 가장 큰 이유라고 말합니다.
– 이 글에는 고객 집착에 대한 구체적인 사례들이 함께 담겨 있어 실제로 우리의 제품에 그의 관점을 적용해 볼 수 있는 기회를 제공합니다. 프로덕트랩에서는 고객 집착에 대한 그의 관점을 3가지 교훈으로 나누어 정리해 보았습니다.
✅ 프로덕트랩에서 원본 글을 요약하고 보완한 글
1. 첫 번째 교훈. 고객 지원은 모두 함께
1-1. 10명의 사용자들을 가볍게 여기지 마세요
– Figma에 새로 입사한 지 약 한 달이 지났을 때 한 엔지니어가 사이트가 동작하지 않도록 만드는 버그를 신고했습니다. 이 버그를 수정해야 한다는 것을 알고 있었지만 Figma는 아직 공식적으로는 공개되지 않은 상태였고 엔지니어링 팀은 복잡한 프로젝트를 진행 중이었습니다.
– 저는 버그를 당장 해결하는 것보다 복잡한 프로젝트를 성공적으로 마치는 것을 우선시하려고 했습니다. 하지만 그때 Figma의 CEO인 딜런은 내게 이렇게 말했습니다.
– 나 : “딜런, 우리가 아직 공식적으로 공개되지 않은 상태라는 건 알고 있죠?
– 딜런: “그래서?”
– 나: “말 그대로 사이트가 다운되었다는 걸 아무도 모른다는 거죠.”
– 딜런: “그건 사실이 아니에요. 사용자가 있잖아요!”
– 나: “그러니까. . 10명 정도?”
– 딜런: “그중 몇 명은 업무용으로 저희의 서비스를 사용하고 있어요!”
– 나: “아직 공식적으로 공개되지 않은 상태의 서비스를 사용하는 건 그들 책임이 아닐까요?”
– 딜런: “당장 고쳐요!”
1-2. 팀원들의 관점보다 고객의 관점을 우선시하세요
– 지금의 Figma는 제가 상상했던 것 이상으로 성장했습니다. 이제는 제게 사람들이 기능의 우선순위를 정하는 방법이나 제품 프로세스를 운영하는 방법에 대한 조언을 요청합니다. 하지만 여기에 대해서는 특별히 해드릴 말씀이 없습니다. 저희가 가진 프로세스는 완벽하지 않습니다. 여전히 지저분하고 실수도 많이 일어납니다.
– 하지만 한 가지 말씀드릴 수 있는 건 Figma에서는 고객의 니즈를 최우선으로 생각한다는 점입니다. 리서치를 수행하는 방법, 커뮤니티를 구축하는 방법, 기능의 우선순위를 정하는 방법에서 이러한 철학이 드러납니다. Figma는 팀원들의 관점보다 고객의 관점을 우선시하는 것에서 시작되며, 이는 초창기부터 우리 문화로 자리 잡았습니다.
1-3. 고객 지원은 모두가 함께 해야하는 일입니다
– 첫 번째 비공개 베타를 출시했을 때 우리는 베타 서비스를 사용하는 유저들로부터 수많은 지원 요청을 받았습니다. 베타 서비스 유저들과 수시로 연락을 주고받으며 Figma라는 제품을 함께 만들어 갔습니다. 디자이너와 개발자도 직접 유저들과 버그나 사용성 문제에 대한 대화를 나눴습니다. 이는 곧 저희 팀의 문화로 자리 잡았습니다.
– 전담 지원팀을 고용한 뒤에도 디자이너와 개발자는 직접 유저들과 대화를 나눴습니다. 물론 대부분의 시간을 코딩이나 디자인 작업에 할애해야 했고, 간혹 유저들에게 실수를 하는 경우도 있었지만, 우리는 고객 지원이 핵심이라고 생각했기 때문에 이러한 방식을 고수했습니다.
Figma가 10명 이하의 조직일 때의 모습
1-4. 엔지니어가 업무 시간을 고객 지원에 사용한다는 것
– 논리적으로 보면 엔지니어가 업무 시간의 20% 정도를 고객 지원에 사용한다면 제품 개발 속도가 느려져야 하지만, 실제로는 그 반대의 현상이 발생했습니다. 고객 지원에 직접 참여함으로써 엔지니어는 고객에게 무엇이 중요한지 빠르게 파악할 수 있었고, 빠르게 대응할 수 있었습니다. 사용자는 코드의 줄 수를 기준으로 개발 속도를 판단하지 않습니다. 중요한 일을 얼마나 빨리 처리하는지를 기준으로 판단합니다.
1-5. Figma는 이렇게 고객들을 지원했습니다
– (1) 고객의 문제를 파악하고, (2) 즉각적인 지원을 제공하여 고객의 불편을 해결하고, (3) 필요한 경우 다른 고객이 동일한 문제를 겪지 않도록 제품을 변경하는 것이 저희의 프로세스였습니다. 이러한 접근 방식은 버그를 수정하는 데에도 사용되었지만, 제품의 개선점을 찾아 새로운 기능을 통해 해결하기도 했습니다.
– 저희는 저희가 보유한 컴퓨터에서는 재현할 수 없는 문제를 겪고 있는 고객을 위해 한 시간을 운전해서 직접 방문하기도 했습니다. 또는 중요한 프로젝트를 진행 중인 유저들을 위해 제품에 문제가 발생하면 주말에도 대응했습니다. 그들의 문제는 곧 우리의 문제라고 여겼습니다.
– 전담 영업팀이 없던 시절에는 직무와 관계없이 모두가 고객들의 전화를 받으며 고객을 도왔고, 공항에서 무작위로 Figma 사용자를 찾아 질문을 던지기도 했습니다. 우리는 고객과 대화할 수 있는 순간들을 찾아 그러한 순간들을 고객을 이해하고 도울 수 있는 기회로 삼았습니다. 바로 이 지점이 사람들이 Figma를 좋아하는 이유가 아닐까 생각합니다.
Figma에서 유저들의 피드백 수집을 담당한 Aaron Clayton-Dunn과 함께
2. 두 번째 교훈. 제품이 아닌 서비스에 집중하기
2-1. 팀원들의 관점보다 고객의 관점을 우선시하는 것이 어려운 이유
– 시장마다 상황이 다르지만 디자인 협업 툴을 만들 때는 다른 모든 것보다 사용자들의 만족도에 초점을 맞추는 것이 중요하다는 것을 알게 되었습니다. 결국 우리 서비스가 좋은 서비스인지를 결정하는 것은 사용자입니다. 서비스를 만드는 우리가 아닙니다.
– Figma의 규모가 커지면서 우리는 고객의 관점이 아닌 우리 자신의 관점으로 초점을 옮기고 싶은 유혹이 생겼습니다. 고객이 중요하게 생각하는 기능보다 더 쉽게 개선할 수 있는 기능이 있을 수도 있고, 더 많은 수익을 올릴 수 있는 기능이 있을 수도 있습니다. 저는 개인적으로 제 관점보다 고객의 관점을 우선시하는 것이 여전히 어렵습니다.
2-2. 서비스 지향적 사고방식의 의미
– 제가 사용하는 한 가지 비결은 스스로를 마치 서비스 업계에 종사하는 것처럼 생각하는 것입니다. Figma는 호텔이나 레스토랑이고 고객은 손님이라고 상상합니다. 우리는 단지 소프트웨어를 통해 서비스를 제공하는 것뿐입니다. 본질은 소프트웨어가 아니라 서비스입니다. 이것이 바로 서비스 지향적 사고방식입니다.
– 팀이 더 나은 제품을 만드는 데 도움이 되는 많은 프레임워크가 있지만, 대부분의 프레임워크는 제품 중심의 사고방식을 취합니다. 서비스 지향적 사고방식에서는 제품을 도구로 생각합니다. 제품이 아니라 고객 경험을 우선시하고 이를 성공의 지표로 생각합니다.
2-3. 사람들이 훌륭한 디자인을 할 수 있도록 돕는 것이 본질
– 전통적인 프레임워크에서는 더 나은 제품을 만들기 위한 다양한 방법론을 제시합니다. 저는 거꾸로 생각합니다. Figma의 팀원으로서 제 일은 사람들이 훌륭한 디자인을 할 수 있도록 돕는 것이지, Figma라는 제품을 더 낫게 만드는 것이 아닙니다. Figma는 단지 제 일을 도와주는 도구일 뿐입니다. 이러한 사고방식은 팀원들의 관점보다 고객의 관점을 우선시할 수 있도록 만들어줍니다.
3. 세 번째 교훈. ‘느낌’을 중요하게 생각하기
3-1. 제품 주도 성장에서 ‘느낌’을 중요하게 생각한다는 것
– 물론 합리적인 기준에 따라 구매를 결정하는 소프트웨어도 있습니다. 하지만 분명히 그렇지 않은 소프트웨어도 존재합니다. 대표적인 예가 디자인 관련 소프트웨어입니다. 디자이너에게 선호하는 툴에 대해 물어보면 그들은 ‘느낌’에 대해 이야기합니다. 마치 음악가가 자신이 좋아하는 악기에 대해 이야기하는 것과 비슷합니다.
– 특히 제품 주도 성장을 추구하는 경우, 소프트웨어가 주는 느낌을 매우 중요하다고 생각합니다. 사람들은 본능적으로 자신도 모르게 느낌을 중요하게 생각하며 이는 분명한 사실입니다. 사실 저는 느낌이 제품 주도 성장에서 가장 중요하다고 생각합니다.
– 그렇기에 우리는 제품 초기부터 ‘느낌’에 대해 고민했습니다. 처음 Figma를 공식적으로 출시할 때, 수많은 기능을 넣는 대신 세련되고 잘 디자인된 느낌을 주는 핵심 기능에 집중했습니다. 이러한 ‘느낌’을 주기 위해 유저 입장에서 중요하다고 여겨질 수 있는 기능들 중 완성도가 높지 않은 기능들을 제외했습니다.
– 완성도 높은 초기 기능들을 보며 유저들은 우리가 고객의 피드백을 바탕으로 계속해서 완성도 높은 기능들을 추가할 것이라는 믿음을 가질 수 있었습니다. 만약 우리가 완성도가 높지 않은 소위 ‘느낌’이 좋지 않은 기능들을 그대로 출시했다면 유저들에게 해당 기능들을 개선한 뒤에 ‘느낌’이 좋아졌다는 것을 설득하는 데 많은 시간을 할애해야 했을 것입니다.
멀티플레이어 기능을 출시한 후의 Figma 팀
3-2. Figma가 ‘느낌’을 위해 중점적으로 고려한 것
– 성능 : 사용자가 문서를 편집할 때 변경 사항을 얼마나 빠르게 표시할 수 있는지 측정합니다. 가능한 한 초당 60프레임을 유지하려고 노력합니다.
– 친숙함 : 대부분의 디자인 툴을 사용하는 유저들은 키보드 단축키 등 기존에 익숙한 습관들을 가지고 있습니다. 가능한 이러한 습관들을 해치지 않으려고 노력합니다.
– 일관성 : 사실 Figma는 상당히 복잡합니다. 그렇기에 Figma 내 모든 기능들이 동작하는 방식에는 내부적으로 정해진 규칙이 있으며, 이러한 규칙으로 인해 사용자들은 그 규칙을 정확히 알지 못하는 경우에도 자신의 행동에 따라 Figma가 어떻게 동작할지 어느정도 예측할 수 있습니다.
초기 Figma의 서버 로그를 보고 있는 Sho Kuwamoto
✅ 팀원들과 이런 이야기를 나눴어요.
– 이번 글은 저희 팀을 반성하게 만드는 글이었어요. 팀원분들과 함께 지금 우리가 정말 유저분들에게 집중하고 있는 것이 맞는지, 좋은 서비스를 제공하기 위해서는 어떻게 해야 할지, 좋은 느낌을 전달하기 위해서는 어떻게 해야 할지 각각의 지점에 대해 많은 대화를 나눴어요. 그동안 베타 서비스를 운영하며 배운 점들을 바탕으로 새롭게 리뉴얼을 준비하고 있는 저희 팀에게 꼭 필요한 시간이었어요.
PRODUCT LAB에 대해 더 알고 싶다면➡️ https://productlab.oneoneone.kr/subscription
