81억 달러 가치를 받은 핀테크 스타트업의 뒷 이야기
Will: Ramp의 제품 문화에 대해 설명해주실 수 있나요?
Geoff: 저희 제품 문화에는 세 가지 요소가 있습니다. 첫째, Ramp는 빠른 제품 속도입니다. 지난 2년간 5개 새 제품 라인과 다양한 규모의 기업에 대응하는 기능들을 배포해왔습니다. 속도에 관해서 사고할 때 속도를 중심으로 조직과 문화를 정의하거나 설계해야 하며, 속도 기반으로 했을 때 단점에 열려있어야 합니다.
둘째는 위임입니다. 많은 경우 제품은 비즈니스 요구사항을 반영합니다. 비즈니스 팀과 제품팀으로 구성되며, 조직 구조상 분리되어 있습니다. 특히 금융, 테크, 혹은 핀테크에서 그렇습니다. 금융 기술은 대부분 기술 부문을 보유한 금융 기업이기 때문입니다.
테크 기업이 진정으로 나왔을 때 테크 조직에서 비즈니스를 주도하도록 했습니다. 이들은 우리가 개발한 제품을 파는 것이지, 그들이 파는 것을 개발하지 않습니다. 우리가 Ramp 초기에 의도적으로 설정한 제품 주도 문화였습니다. 즉, 고객 서비스 형태로 비즈니스를 위한 제품을 만드는 것이 아닌, 비즈니스 서비스 형태로 고객을 위한 제품을 만드는 것입니다.
셋째는 무엇이 아니라 무엇이 되어야 하는지를 정하는 데 적합합니다. B2B 시장에선 고객으로부터 요청을 받기 쉽습니다. 버튼과 컬럼을 추가하는 방식으로요. 그리고 정말 형편없는 B2B 제품에서 시작해 소수 고객에만 의미있는 무언가를 대신해 모두에게 의미없는 제품이 됩니다. 따라서 세 번째 문화적 측면은 고객이 요청한 것 대신, 고객이 필요한 것을 정의하는 능력에 기반합니다. 그리고 무엇이 되어야 하는지를 깊게 생각할 수 있는 능력이 있습니다.
Will: 속도를 기반으로 했을 때 트레이드 오프는 어떤 것인가요?
Geoff: 여기에 두 가지 차원이 있습니다. 첫 번째는 속도에 대한 요구가 기능 중심 팀에 있는 반면, 플랫폼팀은 정밀도, 품질, 가동시간에 집중합니다. 우리는 시간이 지남에 따라 인증, 결제 시스템 그리고 의사결정 시스템에 대해 매우 강력한 플랫폼 역량을 구축했습니다.
기능 중심 팀은 장기적인 관점에서 기술적 로드맵이 부족했습니다. 그리고 리스크는 “우리가 잘 만들고 있는가?”가 아닌, “우리가 고객이 원하는 것을 만들고 있는가?”에 있었습니다. 따라서 기능을 가능한 빨리 배포하고 고객에게 검증받는 속도가 필요합니다. 물론, 피그마 프로토타입을 사용할 수 있습니다. 저희도 이미 많이 사용하고 있구요. 하지만 빠르게 만들어 배포해야 할 때도 있습니다. 테스트하기 위해서 특정 영역에서 기술 부채를 의도적으로 더합니다.
두 번째는 포괄성에 관한 것입니다. 우리는 사용 케이스의 80%에 가깝지 않는 기능을 배포합니다. 하지만 훨씬 의미 있습니다. 10배의 경험을 생각하고, 1배 또는 2배의 경험으로 돌아가 점진적으로 개발하고 배포하며 추진력을 만들어냅니다. 결코 빛을 보지 못하는 6개월 프로젝트보다 속도를 죽이는 것은 없습니다. 사람들은 의욕을 상실하고, 환경과 데이터는 변합니다. 궁극적으로 실제로 하기로 한 것은 처음부터 잘못된 것입니다. 속도는 이를 완화하는데 도움을 줍니다.
우리는 두 가지를 희생하게 됩니다. 하나는 확실하지 않는 영역의 기술 부채이며, 다른 하나는 기능의 완성도입니다. 기능은 좋은 사용 경험을 가질 수 있지만, 모든 이의 단일 문제를 해결하는 것은 아닙니다. 범위를 줄이고 속도를 빠르게 하는 한 가지 방법은 당신이 풀고자 하는 것의 고집스러워야 한다는 거라고 생각합니다. 예를 들어, 모든 각 기업은 서로 다른 방식으로 권한을 다룹니다. 아마도 3년 동안 모든 것을 담은 체크박스가 있는 가장 좋은 권한 시스템을 만드는 데 시간을 쓸 수 있겠죠. 모든 단일 기능에 대해 인식할 경우 제품 개발 프로세스는 느려지고 맙니다.
혹은 우리는 4가지 역할이 있다고 할 수 있죠. 당신은 역할을 가져가거나 둘 수 있습니다. 식당에서 파는 메뉴판과 비슷합니다. 모든 직원에게 땡볕에서 모든 것을 조리하라고 훈련시킬 수도 있습니다. 혹은 6가지 옵션만 가질 수 있습니다. 당신은 6가지 메뉴에 능숙하고 훨씬 빨리 만들 수 있습니다. 그래서 우리는 독단적인 방법을 택했고 이는 개발과 유지보수의 상당한 복잡성을 줄여주기 때문에 속도를 극적으로 개선하는데 도움을 줍니다. 우리가 결정하는데 영향을 미치는 것이 있습니다. 이제 고객은 사용자 지정 가능한 권한을 원하므로, 거래를 잃을 수 있습니다. 괜찮습니다. 우리는 속도에 다시 집중할 수 있도록 기꺼이 이러한 거래를 잃을 것입니다.
그렇다고 고객 경험을 희생하지 않습니다. 결코 나쁜 고객 경험을 주는 것을 배포하지 않습니다. 우리는 제품과 개발과 마찬가지로 디자인 관련 보고를 CTO에게 전달합니다. 때때로 제품에 대한 디자인 보고가 있는데 올바른 디자인과 사용자 경험이라는 측면에서 본질적으로 우선 순위가 상충하기 때문에 실수라고 생각합니다. 따라서 매우 강력한 디자인팀이 제품 개발 프로세스에 동등한 파트너로 있는 것은 유저 경험을 희생시키지 않을 수 있습니다.
Will: 문제가 정의되고 나서 솔루션을 설계하는 단계에 누가 참여하게 되나요?
Geoff: 기술 분야에서 제가 깨달은 것은 권한이 있는 엔지니어는 요구사항 문서를 받고 싶지 않다는 사실이었습니다. 이들은 솔루션의 공동 설립자가 되고 싶어 했습니다. 따라서 이 질문은 사실 엔지니어를 언제 참여시키는가에 가깝습니다. 당신이 매우 흥미로운 문제를 발견하고 잠재적 솔루션에 수렴하거나 솔루션에 대한 의견이 형성된다는 강력한 신호를 받았다면, 그때 엔지니어와 디자이너를 불러드렸습니다.